IoT Nível 1: recon de hardware e extração de firmware

O firmware é a joia da coroa: é todo o código do aparelho. Com ele em mãos você faz análise estática sem risco de brickar nada. A OWASP FSTM (a metodologia de referência) define nove etapas; aqui cobrimos as três primeiras — obter, encontrar as interfaces e extrair — sempre no seu próprio device.

Formas de obter o firmware (FSTM, etapa 2)

Em ordem de preguiça: baixar do site do fabricante (muitos publicam as imagens de update); capturar a atualização OTA que o device baixa; ou, quando não há jeito, ler direto do chip de flash. A FSTM é explícita: não existe um método único — você tenta o mais fácil primeiro.

Achar as interfaces de debug

Abra o aparelho e procure um conjunto de 4 pads/pinos próximos: tipicamente VCC, GND, TX e RX — isso é UART. Com o multímetro em continuidade você acha o GND; o TX é o pino que oscila no boot. O baud rate comum é 115200. Conectado o USB-UART, você costuma cair num log de boot — e, com sorte, num shell.

# conversar com a UART do SEU device
picocom -b 115200 /dev/ttyUSB0
# se aparecer o log do U-Boot ou um shell, você está dentro
# do console de debug que o fabricante esqueceu ligado

Dump da flash SPI

Se a UART não dá o firmware, vai no chip. Identifique a flash SPI (um SOIC-8, ex.: Winbond W25Q), prenda o clipe e leia com o CH341A + flashrom. Essa é a técnica de 'chip-off lógico' — você copia a memória sem dessoldar.

# ler a flash SPI com o programador CH341A
flashrom -p ch341a_spi -r firmware.bin
# agora você tem uma cópia byte a byte do firmware

Extrair o filesystem

Com a imagem salva, o binwalk reconhece e extrai o que estiver dentro: kernel, um filesystem SquashFS, bootloader. A partir daí é análise estática — ler scripts de init, procurar credenciais fixas, chaves e binários suspeitos no Ghidra. É aqui que as classes clássicas (senha hardcoded, command injection, update sem assinatura) aparecem.

binwalk -e firmware.bin        # extrai o conteúdo
grep -rniE 'password|admin|key' squashfs-root/etc
# procure segredos, contas de serviço e configs reveladoras

Achar o bug é metade. A outra metade é reportar direito — e essa é a parte que separa pesquisa de barulho.

Quando achar algo, pratique divulgação responsável (Nível 5 da série). Referência máxima de IoT ofensivo publicado: a Keen Security Lab (Tencent) comprometeu a Tesla remotamente e publicou o paper 'Over-The-Air' na Black Hat USA 2018 — um estudo de caso de como cadeia de bugs vira impacto real, feito com divulgação coordenada. Metodologia: OWASP FSTM.