1. Connect it to the computer (baud rate: 115200)
2. IMPORTANT: H is the print help function, use it everywhere
3. Connect board GND to Jtagulator GND, board pins 1,2,3 to Jtagulator channels 1,2,3
4. V: set working voltage
5. U: enter UART identification menu
6. U: start identification
7. Text string to output: default
8. Starting channel: channel where we put the pin 1 of the board
9. Ending channel: channel where we put the pin 3 of the board
10. Ignore non-printable characters: Yes
11. Done!

• $BAUDRATE can be one of the ones found here
• Most common $BAUDRATE
  • 115200
  • 9600
  • 57600
  • 38400
  • 19200
• IMPORTANT: if we fuck up $BAUDRATE we could see gibberish or also NOTHING
• ctrl + a -> k -> y: close screen

1. Find a reference to GND
   • Using previously found components
   • Usually metal plates are at GND
2. Find a reference to VCC
   • Using previously found components
   • Search for capacitors, they usually have a point at VCC
3. Test JTAG candidate pins filling the table below (bullet points are respectively each column of the table)
   1. Test JTAG pins resistance against GND (multimeter to resistance measurement, usually 200k)
   2. Test JTAG pins resistance against VCC (multimeter to resistance measurement, usually 200kOhm)
   3. Power up the device and test JTAG pins voltage against GND (multimeter to voltage measurement, usually 20V)

   • Table
4. Compare found values with mostly used JTAG pinouts, available at jtagtest

1. Connect it to the computer (baud rate: 115200)
2. IMPORTANT: H is the print help function, use it everywhere
3. Connect board GND to Jtagulator GND, board pins 1,2,3... to Jtagulator channels 1,2,3...
4. V: set working voltage
5. J: enter JTAG identification menu
6. There we have two options
   • I: identify with IDCODE scan, will not find TDI (fast), better if i have a lot pins to identify
   • B: identify with BYPASS scan, will find TDI (slow), better if i have less pins to identify
7. Starting channel: channel where we put the pin 1 of the board
8. Ending channel: channel where we put the pin n of the board
9. Already known pins: No but it could speed the process up if we already know some pins
10. Start and wait.. Done!

• JTAG may have been disabled (hardware, removing a resistor) so it is possible that what you find with the multimeter and Jtagulator isn't consistent; we can solve this putting a resistor of about 300Ohm or 1kOhm between this pin and VCC
• JTAG may have been disabled (hardware, removing a resistor); this issue can be solved putting back this resistor or making a direct connection short circuiting the resistor pads
• JTAG may have been disabled (software, setting some values)
• JTAG may have been disabled (hardware, blowing a fuse... in this case there's no hope)

• Look for OS starting process, here you could find info about partitions of the EEPROM, their names, mount points and length in RAM
• If you see partitions duplicated is probably for firmware upgrades, you can guess why

• Search for init started or something like this, this probably will be near BusyBox string or something analogous

• Search for bootloader menu, here probably we could find the answer to this question

• help command is your friend
• Try to find a way to dump the content of the memory, python is your friend
• OOB data (error code correction) is not so useful to dump

• Use binwalk, file and hexdump -C to check if the file dumped is ok or not and if is compressed or encrypted
  • With binwalk -E we analyze the entropy of the file
    • Entropy NEAR 1: random, compressed or encrypted file
    • Entropy BELOW 1: normal executable or file
• Use binwalk -e to extract identifiable segments of the file

• dd if=$IN_DUMPED_IMAGE of=$OUT_FILE bs=1024 skip=$BYTES_TO_SKIP_FROM_THE_START count=$HOW_MANY_BYTES_TO_WRITE
• sha1sum, md5sum or binwalk -W -i to compare images (if for example we think they could be the same image)

• Example command (based on filesystem type): fakeroot -s fakeroot.dat usquashfs -d squashfs-root u04-sqfs.dat
  • fakeroot: create a fake root environment, useful to emulate file permissions, device files...
    • -s fakeroot.dat: save fake root environment to further restore with command fakeroot -i fakeroot.dat bash
  • usquashfs: extract squashfs filesystem (could be different in your case)
    • -d squashfs-root: destination folder
    • u04-sqfs.dat: filesystem image to extract

• Look for interesting files started by init process and in general don't stop to the names, look in depth at what binary is being executed and analyze them; most interesting ones are the non-standard ones
• Look for factory mode string; if we succeed in putting the device in factory mode (if it exists) then hacking it is a lot easier
• Useful commands
  • Text editor
  • grep
  • find
  • xargs
  • strings

• Acceptable: same X, higher Y

Build using a build system (select features and autotrack dependencies)

• Best build system choices
  • The Yocto project
  • Buildroot (best)
  • OpenWRT build system

Start emulating

• QEMU emulation script
  root@kitploit:~

  #!/bin/bash
  # This script will build an environment without password for the user root
  export QEMU_AUDIO_DRV="none" # ignore audio drivers
  
  qemu-system-${PROCESSOR}${ARCHITECTURE} -M $CPUFAMILY \ # See point 2
                                          -m $RAMSIZE \
                                          -kernel $KERNELPATH \
                                          -nographic \ # No GUI
                                          -hda $FILESYSTEM \
                                          -net nic,model=$NETCARDMODEL \ # Model of net card, driver must be included in kernel
                                          -net user, hostfw=tcp::2222-:22, hostfw=tcp::9000-:9000 \ # 2222 as ssh and 9000 for GDB server
                                          -no-reboot \ # Terminate the machine when is halted
                                          -append "root=/dev/hda console=uart0" # Set root filesystem and console
  

  • If when executing a binary error about missing libs is print then set LD_LIBRARY_PATH as follow (inside the machine): export LD_LIBRARY_PATH=/lib:/usr/lib:$PATHTOORIGINALFILESYSTEMLIBFOLDER
• We could also emulate the NAND EEPROM
  root@kitploit:~

  #!/bin/bash
  
  # Part 1: Identify bytes for kernel module
  modprobe nandsim first_id_byte=$FIRSTBYTE \
                      second_id_byte=$SECONDBYTE \
                      third_id_byte=$THIRDBYTE \
                      fourth_id_byte=$FOURTHBYTE \
                      cache_file=/root/nandsim.bin \
                      parts=x,y,z,... # Define partitons size in number of erase blocks; the number of partitions depends on your device, partitions are usually print on boot
  
  # Part 2: Erase partitions created (analyze EEPROM partitions)
  flash_erase /dev/mtd0 0 8 
  flash_erase /dev/mtd1 0 20
  # ...
  
  # Part 3: Load partitions dumped from device in the ones just created
  nandwrite /dev/mtd0 part0.bin
  nandwrite /dev/mtd1 part1.bin
  # ...
  
  # Part 4: Create mountpoint for filesystem and attach (if UBIFS)
  mkdir /mnt/filesystem
  ubiattach -O $N -m $MTDDVENUM -d $UBIDEVNUM
  
  # Part 5: Mount
  mount -tubifs /dev/ubi${UBIDEVNUM}_0 /mnt/filesystem
  

  1. Identify bytes for kernel module
     • During boot usually information about NAND are print, look at it (above steps) and search for NAND ID, bytes print are in order first, second and fourth byte
     • We could find those information also searching the datasheet of the EEPROM
     • We could also use writesize, oobsize, erasesize, iowidth to find here the correct command
     • Else, trial and error
  2. Analyze EEPROM partitions print on boot to find their sizes and names, the last number in the flash_erase command is their size correlated to the erasesize (same as parts=x,y,z,...)
  3. Load partitions dumped from device in the ones just created
  4. Create mountpoint for filesystem and attach
     • -O: specify the volume id header offset, if wrong the system should tell you the right value anyway you could try different values like 512, 1024, 2048 (trial and error)
     • -m: mtd device number (see point 3)
     • -d: UBI device number (see point 5)

• Notes
  • Not so stable
  • Can give strange results
• How to
  1. Locate QEMU executable format: qemu-$PROCESSOR$ARCHITECTURE
     • Example: qemu-mips64
  2. If QEMU complains about missing interpreter pass the path of THE FOLDER CONTAINING this interpreter with -L (or see man)
     • To know what interpreter is used by an executable use readelf -l $EXECUTABLE

• Our built kernel should have (in respect to the original kernel)
  • Same kernel version
  • Same libc version (uClibc, uClibc-ng, musl, dietlibc...)
  • Same libraries versions (of the executable we are interested in)

1. Search the buildroot version that is the nearest to versions of our device
   • Sometimes during boot/exploring the dumped memory we could find the version of buildroot used (if the device was built using buildroot)
2. Find a linux version compatible with the buildroot version found and create a docker container, here a sample dockerfile (packages are important to run buildroot)
3. Download selected buildroot version from here and put it inside the docker container shared folder
4. Run and switch to the docker container
5. Extract buildroot and make manual to create buildroot's manual
6. Using make help buildroot prints all supported devices (boards); make $YOURBOARDNAME to create a buildroot configuration file of your board
7. make menuconfig (text based) or make xconfig (GUI) to select kernel modules to add to our build, we'll use make xconfig
   • Here there is an example/guideline but you will need to discover by yourself which modules in particular you will need to run your applications
   • Cheat: Edit->Find to search for modules
   • Options
     • Target options
       • Check Show options and packages that are deprecated or obsolete
       • Check Build packages with debugging symbols with highest debug level
       • Check Strip command for binaries on target to None
       • Check GCC optimization level to 0
     • Toolchain
       • Check Toolchain type to Buildroot toolchain
       • Check Kernel headers to Manually specified linux version
   • Remember to SAVE
8. To permanently save the configuration just defined use make savedconfig
9. Configure the kernel with make linux-menuconfig (text based) or make linux-xconfig (GUI), here we'll use CLI version
   • Here there is an example/guideline but you will need to discover by yourself which modules in particular you will need to run your applications
   • Options
     • Kernel type -> Preemption model (Preemptible Kernel (Low-Latency Desktop)) -> Preemptible Kernel (Low-Latency Desktop)
     • Kernel type -> Device drivers -> Memory technology device (MTD) support -> NAND device support -> Support for NAND flash simulator
     • Kernel type -> Device drivers -> -> ->
10. Configure uClibc (or your c lib) using uclibc-menuconfig (as always)
    • Enable debugging: Development/Debugging options -> Enable debugging symbols, if this doesn't work (compiling errors) then Development/Debugging options -> (Wall) compiler warnings -> add -Wall -ggdb -g3
      • -ggdb: provides debugging info to use with GDB
      • -g3: provide extra debugging information
    • Save
    • Enable features as in our device (trial and error, if you get errors investigate and then rebuild with features needed)
11. make, if problems iterate back
    • Possible compilation errors
      • Need to use -fPIC
        • Add --enable-shared in kernel modules (point 7) under Toolchain -> Additional gcc options or patch buildroot

• Saving configuration files for buildroot with git
  • Eternal tree configuration (tree view of files to be understand by buildroot) (br2)
    root@kitploit:~

    +-- board/
    |   +-- <company>/ (not always used)
    |       +-- <boardname>/
    |           +-- linux.config
    |           +-- busybox.config
    |           +-- kernel-defconfig (kernel config file)
    |           +-- <other configuration files>
    |           +-- post_build.sh (executed just before building the image, useful to copy root filesystem into the image)
    |           +-- post_image.sh
    |           +-- rootfs_overlay/ (everythin here will be copied in the final image)
    |           |   +-- etc/
    |           |   +-- <some file>
    |           +-- patches/
    |               +-- foo/
    |               |   +-- <some patch>
    |               +-- libbar/
    |                   +-- <some other patches>
    |
    +-- configs/
    |   +-- <boardname>_defconfig (buildroot config for our board)
    |   +-- uClibc.config (optional)
    +-- patches/
    |   +-- (here patches to be applied)
    |
    +-- Config.in (if using a br2-external tree)
    +-- external.mk (if using a br2-external tree)
    +-- external.desc (if using a br2-external tree)
    

  • To use an external tree invoke buildroot like this: make BR2_EXTERNAL=$PATHTOEXTTREE $COMMAND
  • To save buildroot config to our external tree: make BR2_EXTERNAL=$PATHTOEXTTREE savedefconfig

• Check Passwords encoding to MD5
• Check Init system to $DEVICEINITSYSTEM (or BusyBox)
• Check /dev management to Dynamic using devtmpfs only
• Check /bin/sh to Busybox default shell
• Check Install timezone info

• Set Kernel version to $DEVICEKERNELVERSION
• Check Kernel binary format to vmlinux

• Compressors and decompressors
  • bzip2 and xz-utils
• Debugging profiling and benchmark
  • Check gdb and full debugger
• Development tools
  • What you will need
• Filesystem and flash utilities
  • mtd, jffs2 and ubi/ubifs tools (or what you will need)
• Libraries
  • In general what you need (suggestions below)
  • Crypto
    • libsha1
    • libssh2
    • openssl
  • JSON/XML
    • expat
    • json-c

• rsync and what you need

• file

• ext2

• host mtd, jffs2 and ubi/ubifs tools
• host util-linux