1. Подключите его к компьютеру (скорость: 115200)
2. ВАЖНО: H — функция печати справки, используйте её везде
3. Подключите GND платы к GND Jtagulator, контакты платы 1,2,3 к каналам 1,2,3 Jtagulator
4. V: установите рабочее напряжение
5. U: войдите в меню идентификации UART
6. U: начните идентификацию
7. Text string to output: по умолчанию
8. Starting channel: канал, куда мы подключили контакт 1 платы
9. Ending channel: канал, куда мы подключили контакт 3 платы
10. Ignore non-printable characters: Да
11. Готово!

• $BAUDRATE может быть одним из тех, что указаны здесь
• Наиболее распространённые $BAUDRATE
  • 115200
  • 9600
  • 57600
  • 38400
  • 19200
• ВАЖНО: если мы облажаемся с $BAUDRATE, можем увидеть абракадабру или вообще НИЧЕГО
• ctrl + a -> k -> y: закрыть screen

1. Найдите опорную точку GND
   • Используя ранее найденные компоненты
   • Обычно металлические пластины находятся на GND
2. Найдите опорную точку VCC
   • Используя ранее найденные компоненты
   • Поищите конденсаторы, обычно одна их ножка на VCC
3. Проверьте кандидатов в контакты JTAG, заполняя таблицу ниже (пункты списка соответствуют столбцам таблицы)
   1. Проверьте сопротивление контактов JTAG относительно GND (мультиметр в режиме измерения сопротивления, обычно 200k)
   2. Проверьте сопротивление контактов JTAG относительно VCC (мультиметр в режиме измерения сопротивления, обычно 200kOhm)
   3. Включите устройство и проверьте напряжение контактов JTAG относительно GND (мультиметр в режиме измерения напряжения, обычно 20V)

   • Таблица
4. Сравните найденные значения с наиболее часто используемыми распиновками JTAG, доступными на jtagtest

1. Подключите его к компьютеру (скорость передачи: 115200)
2. ВАЖНО: H — функция вывода помощи, используйте её везде
3. Подключите GND платы к GND Jtagulator, контакты платы 1,2,3... к каналам Jtagulator 1,2,3...
4. V: установите рабочее напряжение
5. J: войдите в меню определения JTAG
6. У нас есть два варианта
   • I: идентификация с помощью сканирования IDCODE, не найдёт TDI (быстро), лучше, если нужно идентифицировать много контактов
   • B: идентификация с помощью сканирования BYPASS, найдёт TDI (медленно), лучше, если контактов для идентификации меньше
7. Starting channel: канал, куда мы подключили контакт 1 платы
8. Ending channel: канал, куда мы подключили контакт n платы
9. Already known pins: Нет, но это может ускорить процесс, если мы уже знаем некоторые контакты
10. Запустите и подождите.. Готово!

• JTAG может быть отключён (аппаратно, удалением резистора), поэтому возможна несогласованность результатов, полученных с помощью мультиметра и Jtagulator; это можно решить, установив резистор примерно 300Ohm или 1kOhm между этим контактом и VCC
• JTAG может быть отключён (аппаратно, удалением резистора); эту проблему можно решить, вернув резистор на место или соединив напрямую, замкнув контактные площадки резистора
• JTAG может быть отключён (программно, установкой некоторых значений)
• JTAG может быть отключён (аппаратно, перегоревшим предохранителем... в этом случае надежды нет)

• Полезные команды
  • halt: остановить CPU (как заморозка)
    • ДОЛЖНА ВЫПОЛНЯТЬСЯ ПЕРЕД КАЖДОЙ ОПЕРАЦИЕЙ ОТЛАДКИ
  • reset: сбросить CPU
  • reg: прочитать регистры CPU
  • flash info bank $BANKID или flash info $BANKID: выводит информацию о банке флэш-памяти $BANKID (я думаю, банки = блок памяти)
  • flash list: получает список ассоциативных массивов для каждого устройства, объявленного с помощью flash bank (в $BOARDCONFIGFILE), нумерация с нуля
  • flash banks: выводит однострочную сводку по каждому устройству, объявленному с помощью flash bank (в $BOARDCONFIGFILE), нумерация с нуля
  • flash write_image erase "$BINTOWRITE" $ADDRTOSTART: записать во флэш-память
    • $BINTOWRITE: может быть bin (двоичный), ihex (Intel hex), elf (ELF-файл), s19 (Motorola s19), mem...
    • $ADDRTOSTART: адрес, с которого начать запись (я думаю, по умолчанию 0)
  • flash dump_image $OUTFILE $ADDRTOSTART $SIZETODUMP: дамп памяти
    • $OUTFILE: двоичный файл для сохранения дампа
    • $ADDRTOSTART: адрес, с которого начать чтение (я думаю, по умолчанию 0)
    • $SIZETODUMP: количество байт для дампа
• Подробнее здесь:
  • OpenOCD PDF
  • OpenOCD HTML
• TODO

• Ищите информацию о загрузке загрузчика и процессе запуска ОС; здесь можно найти сведения о файловой системе

• Ищите процесс запуска ОС; здесь можно найти сведения о разделах EEPROM, их именах, точках монтирования и размере в RAM
• Если вы видите дублирующиеся разделы, это, вероятно, для обновления прошивки; вы можете догадаться, почему

• Ищите init started или что-то подобное; это, вероятно, будет рядом со строкой BusyBox или чем-то аналогичным

• Ищите меню загрузчика; здесь, вероятно, мы сможем найти ответ на этот вопрос

• Команда help — ваш друг
• Попробуйте найти способ сбросить содержимое памяти; Python — ваш друг
• Данные OOB (коррекция кода ошибок) не так полезны для дампа

• Используйте binwalk, file и hexdump -C, чтобы проверить, в порядке ли сброшенный файл, и является ли он сжатым или зашифрованным
  • С помощью binwalk -E анализируем энтропию файла
    • Энтропия БЛИЗКА К 1: случайный, сжатый или зашифрованный файл
    • Энтропия НИЖЕ 1: обычный исполняемый файл или обычный файл
• Используйте binwalk -e для извлечения идентифицируемых сегментов файла

• 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 или binwalk -W -i для сравнения образов (если, например, мы думаем, что они могут быть одним и тем же образом)

• Пример команды (в зависимости от типа файловой системы): fakeroot -s fakeroot.dat usquashfs -d squashfs-root u04-sqfs.dat
  • fakeroot: создаёт поддельное root-окружение; полезно для эмуляции прав на файлы, файлов устройств...
    • -s fakeroot.dat: сохранить поддельное root-окружение для последующего восстановления командой fakeroot -i fakeroot.dat bash
  • usquashfs: извлекает файловую систему squashfs (в вашем случае может отличаться)
    • -d squashfs-root: папка назначения
    • u04-sqfs.dat: образ файловой системы для извлечения

• Ищите интересные файлы, запускаемые процессом init; в целом не останавливайтесь на названиях, углубляйтесь в то, какой бинарный файл выполняется, и анализируйте их; наиболее интересны нестандартные
• Ищите строку factory mode; если нам удастся перевести устройство в заводской режим (если он существует), взломать его станет намного проще
• Полезные команды
  • Текстовый редактор
  • grep
  • find
  • xargs
  • strings

• Допустимо: то же X, более высокое Y

Соберите с помощью системы сборки (выбирайте функции и автоматически отслеживайте зависимости)

• Лучшие варианты систем сборки
  • Проект Yocto
  • Buildroot (лучший)
  • Система сборки OpenWRT

Начните эмуляцию

• Скрипт эмуляции QEMU
  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
  

• Если при выполнении бинарного файла выводится ошибка об отсутствующих библиотеках, установите LD_LIBRARY_PATH следующим образом (внутри машины): export LD_LIBRARY_PATH=/lib:/usr/lib:$PATHTOORIGINALFILESYSTEMLIBFOLDER
• Мы также можем эмулировать 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