1. Conecte-o ao computador (baud rate: 115200)
2. IMPORTANTE: H é a função que imprime a ajuda, use-a em qualquer lugar
3. Conecte o GND da placa ao GND do Jtagulator, os pinos 1,2,3 da placa aos canais 1,2,3 do Jtagulator
4. V: define a tensão de trabalho
5. U: entra no menu de identificação UART
6. U: inicia a identificação
7. Text string to output: default
8. Starting channel: canal onde colocamos o pino 1 da placa
9. Ending channel: canal onde colocamos o pino 3 da placa
10. Ignore non-printable characters: Yes
11. Pronto!

• $BAUDRATE pode ser um dos encontrados aqui
• $BAUDRATE mais comuns
  • 115200
  • 9600
  • 57600
  • 38400
  • 19200
• IMPORTANTE: se errarmos o $BAUDRATE, podemos ver caracteres estranhos ou até NADA
• ctrl + a -> k -> y: fechar o screen

1. Encontre uma referência a GND
   • Usando componentes encontrados anteriormente
   • Geralmente placas de metal estão em GND
2. Encontre uma referência a VCC
   • Usando componentes encontrados anteriormente
   • Procure por capacitores, eles geralmente têm um ponto em VCC
3. Teste os pinos candidatos a JTAG preenchendo a tabela abaixo (os itens são, respectivamente, cada coluna da tabela)
   1. Teste a resistência dos pinos JTAG em relação a GND (multímetro na medição de resistência, geralmente 200k)
   2. Teste a resistência dos pinos JTAG em relação a VCC (multímetro na medição de resistência, geralmente 200kOhm)
   3. Ligue o dispositivo e teste a tensão dos pinos JTAG em relação a GND (multímetro na medição de tensão, geralmente 20V)

   • Tabela
4. Compare os valores encontrados com os pinouts JTAG mais usados, disponíveis em jtagtest

1. Conecte-o ao computador (baud rate: 115200)
2. IMPORTANTE: H é a função que imprime ajuda, use-a em todo lugar
3. Conecte o GND da placa ao GND do Jtagulator, os pinos 1,2,3... da placa aos canais 1,2,3... do Jtagulator
4. V: define a tensão de trabalho
5. J: entra no menu de identificação JTAG
6. Lá temos duas opções
   • I: identificar com varredura IDCODE, não encontrará TDI (rápido), melhor se eu tiver muitos pinos para identificar
   • B: identificar com varredura BYPASS, encontrará TDI (lento), melhor se eu tiver menos pinos para identificar
7. Starting channel: canal onde colocamos o pino 1 da placa
8. Ending channel: canal onde colocamos o pino n da placa
9. Already known pins: Não, mas poderia acelerar o processo se já soubermos alguns pinos
10. Inicie e espere.. Pronto!

• O JTAG pode ter sido desabilitado (hardware, remoção de um resistor), então é possível que o que você encontrar com o multímetro e o Jtagulator não seja consistente; podemos resolver isso colocando um resistor de cerca de 300Ohm ou 1kOhm entre esse pino e o VCC
• O JTAG pode ter sido desabilitado (hardware, remoção de um resistor); esse problema pode ser resolvido recolocando esse resistor ou fazendo uma conexão direta curto-circuitando os pads do resistor
• O JTAG pode ter sido desabilitado (software, definindo alguns valores)
• O JTAG pode ter sido desabilitado (hardware, queimando um fusível... nesse caso não há esperança)

• Procure por informações de carregamento do bootloader e pelo processo de inicialização do SO; aqui você pode encontrar informações sobre o sistema de arquivos

• Procure pelo processo de inicialização do SO; aqui você pode encontrar informações sobre as partições da EEPROM, seus nomes, pontos de montagem e tamanho na RAM
• Se você vir partições duplicadas, provavelmente é para atualizações de firmware; você pode imaginar o porquê

• Procure por init started ou algo parecido; isso provavelmente estará perto da string BusyBox ou algo análogo

• Procure pelo menu do bootloader; provavelmente aqui podemos encontrar a resposta para essa pergunta

• O comando help é seu amigo
• Tente encontrar uma maneira de despejar o conteúdo da memória; Python é seu amigo
• Dados OOB (correção de código de erro) não são tão úteis para despejar

• Use binwalk, file e hexdump -C para verificar se o arquivo despejado está ok ou não e se está compactado ou criptografado
  • Com binwalk -E analisamos a entropia do arquivo
    • Entropia PRÓXIMA de 1: arquivo aleatório, compactado ou criptografado
    • Entropia ABAIXO de 1: executável ou arquivo normal
• Use binwalk -e para extrair segmentos identificáveis do arquivo

• 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 ou binwalk -W -i para comparar imagens (se, por exemplo, acharmos que podem ser a mesma imagem)

• Exemplo de comando (baseado no tipo de sistema de arquivos): fakeroot -s fakeroot.dat usquashfs -d squashfs-root u04-sqfs.dat
  • fakeroot: cria um ambiente root falso, útil para emular permissões de arquivo, device files...
    • -s fakeroot.dat: salva o ambiente root falso para restaurar depois com o comando fakeroot -i fakeroot.dat bash
  • usquashfs: extrai o sistema de arquivos squashfs (pode ser diferente no seu caso)
    • -d squashfs-root: pasta de destino
    • u04-sqfs.dat: imagem do sistema de arquivos a extrair

• Procure por arquivos interessantes iniciados pelo processo init e, em geral, não pare nos nomes; analise em profundidade qual binário está sendo executado e analise-os; os mais interessantes são os não padronizados
• Procure pela string factory mode; se conseguirmos colocar o dispositivo no modo de fábrica (se existir), hackeá-lo fica muito mais fácil
• Comandos úteis
  • Editor de texto
  • grep
  • find
  • xargs
  • strings

• Aceitável: mesmo X, Y maior

Compile usando um sistema de build (selecione recursos e rastreie dependências automaticamente)

• Melhores escolhas de sistema de build
  • The Yocto Project
  • Buildroot (melhor)
  • Sistema de build do OpenWRT

Comece a emular

• Script de emulação 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
  

• Se, ao executar um binário, for impresso um erro sobre bibliotecas ausentes, defina LD_LIBRARY_PATH da seguinte forma (dentro da máquina): export LD_LIBRARY_PATH=/lib:/usr/lib:$PATHTOORIGINALFILESYSTEMLIBFOLDER
• Também poderíamos emular a EEPROM NAND
  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
  ```# Parte 5: Montagem
  mount -tubifs /dev/ubi${UBIDEVNUM}_0 /mnt/filesystem
  

  1. Identifique os bytes para o módulo do kernel
     • Durante o boot, normalmente informações sobre a NAND são exibidas; observe-as (passos acima) e procure por NAND ID; os bytes impressos estão na ordem: primeiro, segundo e quarto byte
     • Também é possível encontrar essas informações pesquisando o datasheet da EEPROM
     • Também podemos usar writesize, oobsize, erasesize, iowidth para encontrar aqui o comando correto
     • Caso contrário, tentativa e erro
  2. Analise as partições da EEPROM exibidas no boot para descobrir seus tamanhos e nomes; o último número no comando flash_erase é o tamanho delas correlacionado ao erasesize (mesmo que parts=x,y,z,...)
  3. Carregue as partições extraídas do dispositivo nas que acabaram de ser criadas
  4. Crie um ponto de montagem para o sistema de arquivos e anexe
     • -O: especifica o offset do cabeçalho do volume id; se estiver errado, o sistema deve informar o valor correto; mesmo assim, você pode tentar valores diferentes como 512, 1024, 2048 (tentativa e erro)
     • -m: número do dispositivo mtd (veja o ponto 3)
     • : número do dispositivo UBI (veja o ponto 5)

• Notas
  • Não é tão estável
  • Pode dar resultados estranhos
• Como fazer
  1. Localize o formato de executável do QEMU: qemu-$PROCESSOR$ARCHITECTURE
     • Exemplo: qemu-mips64
  2. Se o QEMU reclamar de interpretador ausente, passe o caminho da PASTA QUE CONTÉM esse interpretador com -L (ou veja man)
     • Para saber qual interpretador é usado por um executável, use readelf -l $EXECUTABLE

• Nosso kernel compilado deve ter (em relação ao kernel original)
  • Mesma versão do kernel
  • Mesma versão da libc (uClibc, uClibc-ng, musl, dietlibc...)
  • Mesmas versões das bibliotecas (do executável em que estamos interessados)

1. Procure a versão do buildroot mais próxima das versões do nosso dispositivo
   • Às vezes, durante o boot/exploração da memória extraída, podemos encontrar a versão do buildroot usada (se o dispositivo foi construído com buildroot)
2. Encontre uma versão do Linux compatível com a versão encontrada do buildroot e crie um contêiner docker; aqui está um exemplo de dockerfile (os pacotes são importantes para executar o buildroot)
3. Baixe a versão selecionada do buildroot aqui e coloque-a na pasta compartilhada do contêiner docker
4. Execute e alterne para o contêiner docker
5. Extraia o buildroot e use make manual para criar o manual do buildroot
6. Usando make help, o buildroot exibe todos os dispositivos suportados (placas); use make $YOURBOARDNAME para criar um arquivo de configuração do buildroot para a sua placa
7. Use make menuconfig (baseado em texto) ou make xconfig (GUI) para selecionar os módulos do kernel a serem adicionados à nossa compilação; usaremos make xconfig
   • Aqui está um exemplo/diretriz, mas você precisará descobrir por conta própria quais módulos em particular serão necessários para executar seus aplicativos
   • Dica: Edit->Find para pesquisar módulos
   • Opções
     • Target options
       • Marque Show options and packages that are deprecated or obsolete
       • Marque Build packages with debugging symbols com o maior debug level
       • Defina Strip command for binaries on target para None
       • Defina GCC optimization level para 0
     • Toolchain
       • Defina Toolchain type para Buildroot toolchain
8. Para salvar permanentemente a configuração recém-definida, use make savedconfig
9. Configure o kernel com make linux-menuconfig (baseado em texto) ou make linux-xconfig (GUI); aqui usaremos a versão CLI
   • Aqui está um exemplo/diretriz, mas você precisará descobrir por conta própria quais módulos em particular serão necessários para executar seus aplicativos
   • Opções
     • 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 o uClibc (ou sua biblioteca C) usando uclibc-menuconfig (como sempre)
    • Habilite a depuração: Development/Debugging options -> Enable debugging symbols; se isso não funcionar (erros de compilação), então Development/Debugging options -> (Wall) compiler warnings -> adicione -Wall -ggdb -g3
      • -ggdb: fornece informações de depuração para usar com o GDB
      • -g3: fornece informações de depuração adicionais
    • Save
    • Habilite os recursos conforme o nosso dispositivo (tentativa e erro; se ocorrerem erros, investigue e então recompile com os recursos necessários)
11. Execute make; se houver problemas, volte e itere
    • Possíveis erros de compilação
      • Need to use -fPIC
        • Adicione --enable-shared nos módulos do kernel (ponto 7) em Toolchain -> Additional gcc options ou aplique um patch no buildroot

• Salvando arquivos de configuração do buildroot com git
  • Configuração de árvore externa (visão em árvore dos arquivos para serem entendidos pelo 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)
    

  • Para usar uma árvore externa, invoque o buildroot assim: make BR2_EXTERNAL=$PATHTOEXTTREE $COMMAND
  • Para salvar a configuração do buildroot na nossa árvore externa: make BR2_EXTERNAL=$PATHTOEXTTREE savedefconfig

• Defina Passwords encoding para MD5
• Defina Init system para $DEVICEINITSYSTEM (ou BusyBox)
• Defina /dev management para Dynamic using devtmpfs only
• Defina /bin/sh para Busybox default shell
• Marque Install timezone info

• Defina Kernel version para $DEVICEKERNELVERSION
• Defina Kernel binary format para vmlinux

• Compressors and decompressors
  • bzip2 e xz-utils
• Debugging profiling and benchmark
  • Marque gdb e full debugger
• Development tools
  • O que você precisar
• Filesystem and flash utilities
  • mtd, jffs2 and ubi/ubifs tools (ou o que você precisar)
• Libraries
  • No geral, o que você precisar (sugestões abaixo)
  • Crypto
    • libsha1
    • libssh2
    • openssl
  • JSON/XML
    • expat
    • json-c

• rsync e o que você precisar

• file

• ext2

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