Ingeniería inversa de firmware, paso a paso

⏱️ Lectura: 15 min

El dueño anterior de un Renault Latitude 2014 no exageraba: sin una tarjeta SD específica de TomTom, el auto bloquea el menú donde se cambia la hora. Por eso un ingeniero estonio aplicó ingeniería inversa de firmware a la unidad de navegación en lugar de pagar 60 euros por esa tarjeta.

📑 En este artículo

1. TL;DR
2. ¿Qué es la ingeniería inversa de firmware?
3. Por qué importa auditar firmware sin documentación
4. Cómo funciona: del binario crudo al sistema de archivos
5. Ejemplos prácticos y cómo empezar
6. Casos de uso reales
7. Errores comunes y buenas prácticas
8. Comparativa de herramientas
9. Profundizando: firmas, verificación y emulación
10. Preguntas frecuentes
    1. ¿Es legal hacer ingeniería inversa de firmware en un dispositivo que me pertenece?
    2. ¿Qué diferencia hay entre análisis estático y análisis dinámico de firmware embebido?
    3. ¿Qué herramienta conviene para empezar con la extracción de sistema de archivos?
    4. ¿Cómo se identifica el tipo de filesystem dentro de una imagen de firmware?
    5. ¿Qué hacer si el firmware de un dispositivo embebido está cifrado o firmado?
11. Referencias

El caso, documentado en el blog nns.ee, es la anécdota que dispara esta guía sobre cómo auditar cualquier dispositivo embebido sin documentación: extraer el sistema de archivos, ubicar configs reales y entender qué herramientas usar.

TL;DR

• binwalk identifica y extrae el filesystem oculto en un firmware; montarlo en modo lectura expone configs reales.
• Los archivos de configuración casi siempre viven bajo /etc, /usr/local/etc o /data en Linux embebido.
• QEMU permite emular un firmware ARM sin arriesgar el hardware original durante las pruebas.
• Un DRM atado al CID de una tarjeta SD, como en el caso de TomTom, bloquea imágenes modificadas antes de instalarlas.
• Comparar binarios de versiones distintas con binwalk y diff ayuda a ubicar qué cambió entre firmwares.

¿Qué es la ingeniería inversa de firmware?

La ingeniería inversa de firmware es el proceso de analizar el software que corre dentro de un dispositivo embebido (router, cámara, unidad de navegación) sin su código fuente ni documentación, para entender su estructura interna, extraer su sistema de archivos y localizar configuraciones, credenciales o lógica de negocio ocultas en el binario.

Se diferencia de la ingeniería inversa de software de escritorio en un detalle clave: casi nunca hay un instalador ni una API pública que describa el formato del archivo. Lo único disponible suele ser un binario de actualización que el propio fabricante distribuye para que el dispositivo se actualice solo, sin pensar que alguien lo va a abrir con un editor hexadecimal.

Esta disciplina se aplica tanto en seguridad ofensiva (buscar vulnerabilidades explotables) como en seguridad defensiva y en interoperabilidad: entender qué hace tu propio router, tu cámara IP o, como en este caso, la unidad de navegación de tu auto, cuando el fabricante nunca publicó un manual técnico.

Por qué importa auditar firmware sin documentación

Los fabricantes de electrónica embebida rara vez publican specs completas de su firmware: no hay changelog, no hay API docs, y las actualizaciones llegan como un binario opaco. Esa opacidad no es casualidad. Atar funciones básicas (como cambiar la hora) a un accesorio propietario, como hizo TomTom con la tarjeta SD de mapas, es una forma de vendor lock-in: vendés el hardware una vez y seguís cobrando por el accesorio que lo hace funcionar del todo.

Del lado de la seguridad, abrir el firmware es la única manera de confirmar qué hay realmente adentro de un dispositivo que vas a conectar a tu red o a tu auto. Credenciales hardcodeadas, servicios de depuración abiertos en producción o lógica de validación incompleta aparecen todo el tiempo en firmwares de IoT doméstico, y la única forma de encontrarlos antes de que lo haga alguien con intenciones distintas es auditarlos primero.

También hay un argumento de reparación: si el fabricante desaparece, descontinúa el producto o simplemente no vende el repuesto en tu país, entender el firmware es la diferencia entre seguir usando el dispositivo o tirarlo. El autor del caso Renault no quería mapas ni pirateria, solo quería que el reloj del tablero mostrara la hora correcta tras el cambio de horario de invierno.

Cómo funciona: del binario crudo al sistema de archivos

Todo proceso de ingeniería inversa de firmware sigue más o menos el mismo orden, sin importar si el objetivo es un router, una cámara o una unidad de navegación de auto. Primero hay que conseguir el binario: bajándolo del sitio de soporte del fabricante como archivo de actualización, extrayéndolo de una tarjeta SD o eMMC, o volcándolo directo del chip de flash con un programador SPI si no hay otra forma de acceder a él.

Con el archivo en mano, el siguiente paso es identificar qué hay adentro. El comando file reconoce cabeceras conocidas, pero la mayoría de las imágenes de actualización no son un solo filesystem: son un contenedor con un bootloader, un kernel comprimido y uno o más filesystems concatenados uno detrás del otro. Ahí es donde entra binwalk, que escanea el binario byte por byte buscando firmas conocidas (números mágicos de squashfs, cramfs, ext3, jffs2, ubifs, gzip, LZMA) y reporta en qué offset empieza cada uno.

flowchart TD
A["Firmware descargado (.bin)"] --> B["bootloader"]
A --> C["particion recovery"]
A --> D["particion de datos (ext3/squashfs)"]
D --> E["etc: configs e init scripts"]
D --> F["usr: binarios y librerias"]
D --> G["data: ajustes de usuario"]

Una vez localizados los offsets, se extrae cada sección con dd o con la extracción automática de binwalk, y se monta el filesystem resultante en modo solo lectura. Desde ahí, explorar /etc, los scripts de init (SysV en /etc/init.d o unidades systemd), los binarios en /usr y las variables que arman los scripts de arranque suele revelar en minutos lo que la documentación nunca contó: qué demonio escucha en qué puerto, dónde vive el archivo de configuración real y qué credenciales quedaron escritas en texto plano.

flowchart TD
A["Adquirir el firmware"] --> B["Identificar formato y particiones"]
B --> C["Extraer el sistema de archivos"]
C --> D["Montar en modo lectura"]
D --> E["Explorar configs e init scripts"]
E --> F["Verificar hallazgos contra el dispositivo real"]

Ejemplos prácticos y cómo empezar

Este flujo se puede practicar hoy mismo en Linux (Debian o Ubuntu) con herramientas ya empaquetadas. En macOS alcanza con brew install binwalk; en Windows, lo más simple es correr los mismos comandos dentro de WSL2 con una distro Ubuntu.

Antes de nada, instalá las dependencias:

sudo apt update
sudo apt install -y binwalk file e2fsprogs squashfs-tools

Con una imagen de firmware descargada (llamémosla firmware.bin), el primer paso es identificar qué formato tiene:

file firmware.bin

Salida esperada, típica de una imagen de actualización de un dispositivo basado en Linux embebido:

firmware.bin: data

file casi nunca reconoce el contenedor completo porque es un formato propietario; por eso el segundo comando es binwalk, que escanea las firmas internas:

binwalk firmware.bin

La salida sigue el formato estándar de tres columnas (offset decimal, offset hexadecimal, descripción de la firma), por ejemplo:

DECIMAL       HEXADECIMAL     DESCRIPTION
--------------------------------------------------------------------------
0             0x0             uImage header, header size: 64 bytes
65536         0x10000         Linux kernel ARM boot executable zImage
1310720       0x140000        EXT filesystem, blocks count: 65536

Con los offsets identificados, se puede dejar que binwalk extraiga todo automáticamente:

binwalk -e firmware.bin

Esto crea una carpeta _firmware.bin.extracted/ con cada sección ya separada. Si una de ellas resultó ser una imagen ext3 (como el archivo ttsystem del caso Renault), se monta así:

mkdir -p /mnt/fw
sudo mount -o loop,ro _firmware.bin.extracted/140000.ext3 /mnt/fw

Para confirmar que el montaje quedó en modo solo lectura antes de tocar nada:

mount | grep /mnt/fw

Salida esperada:

/dev/loop0 on /mnt/fw type ext2 (ro,relatime)

Desde ahí, buscar archivos de configuración es cuestión de recorrer las carpetas típicas de cualquier Linux embebido:

find /mnt/fw/etc -maxdepth 2 -type f \( -name "*.conf" -o -name "*.cfg" \)
ls /mnt/fw/etc/init.d/ 2>/dev/null

Este es el punto donde el autor del caso Renault encontró que el menú de ajustes dependía de una definición leída desde la tarjeta SD, y no desde el propio filesystem: la lógica de la aplicación de configuración nunca llegaba a cargarse sin ese archivo externo.

Casos de uso reales

Esta técnica aparece todo el tiempo fuera del mundo automotriz.

• Dispositivos de consumo sin manual técnico: routers domésticos, cámaras IP y, como en el caso que abre este artículo, unidades de navegación de auto que dependen de un accesorio propietario para funciones básicas.
• Investigación de seguridad ofensiva y defensiva: analistas que buscan credenciales hardcodeadas, puertas traseras o claves privadas filtradas dentro de imágenes de actualización públicas.
• Interoperabilidad y reparación: proyectos de la comunidad, como el trabajo previo sobre la misma unidad TomTom Carminat LIVE publicado en GitHub, que documentan protocolos no oficiales para que otros no repitan el trabajo desde cero.

Errores comunes y buenas prácticas

• Montar en modo lectura-escritura por error: usá siempre -o loop,ro; montar en rw puede corromper la imagen antes de terminar el análisis.
• Trabajar sobre el original: copiá el dump con dd antes de tocar nada; si algo sale mal, volvés a copiar en vez de volver a desoldar el chip de flash.
• Asumir el filesystem por la extensión del archivo: un .bin no dice nada sobre su contenido; confiá en las firmas de binwalk o en los números mágicos, no en el nombre.
• Flashear una imagen modificada sin probarla antes: emulá primero con QEMU o un entorno de prueba; un flasheo fallido en hardware real puede dejar el dispositivo sin arrancar.
• Ignorar la verificación de firmas: si el dispositivo rechaza tu imagen modificada sin explicación clara, lo más probable es que haya una capa de verificación antes del flasheo, no un bug tuyo.

⚠️ Ojo: flashear una imagen modificada sin probarla antes en un emulador puede dejar un dispositivo embebido sin arrancar; en electrónica de consumo rara vez hay una forma barata de revertirlo.

Comparativa de herramientas

Ninguna herramienta cubre todos los casos: la mayoría de los analistas termina combinando binwalk para el primer escaneo con un montaje manual cuando las firmas no alcanzan.

Profundizando: firmas, verificación y emulación

La ingeniería inversa de firmware se pone interesante cuando el dispositivo no acepta cualquier imagen modificada. En el caso Renault, el ingeniero reempaquetó el ttsystem extraído y dejó que la unidad lo instalara desde la tarjeta SD. La unidad aceptaba imágenes originales sin problema pero rechazaba la modificada, pese a que la lógica visible del actualizador no mostraba ninguna validación obvia. Eso llevó a montar un emulador con QEMU, usando un kernel 2.6 parcheado para ignorar las syscalls de reinicio que el sistema disparaba cada tres segundos sin la partición recovery presente, y confirmar ahí que faltaba una capa de verificación completa antes de aceptar una actualización.

sequenceDiagram
participant U as Unidad
participant SD as Tarjeta SD
participant R as Particion recovery
U->>SD: lee imagen de actualizacion
SD-->>U: entrega ttsystem firmado
U->>R: arranca en modo recovery
R->>R: verifica firma y hash
alt firma valida
R-->>U: aplica la actualizacion
else firma invalida
R-->>U: rechaza la imagen
end

La segunda capa de protección era más agresiva todavía: las tarjetas SD originales llevan un CID (un identificador único grabado en la tarjeta) y los archivos de mapas venían firmados contra ese CID específico. Copiar los archivos a una tarjeta SD en blanco no funcionaba porque la firma no correspondía al nuevo CID, el mismo principio que usan los DRM de consolas de videojuegos para atar contenido a un número de serie de hardware.

💭 Clave: cuando un dispositivo rechaza una imagen modificada sin ningún mensaje de error claro, es la señal más confiable de que existe una capa de verificación (firma, hash o DRM) antes del flasheo.

Para esta auditoría de binarios de firmware, emular en QEMU en lugar de flashear directo al hardware real es la diferencia entre poder iterar cien veces en una tarde o convertir la unidad en un ladrillo a la primera prueba fallida. La desventaja es que emular periféricos específicos casi nunca viene de fábrica en el emulador: hay que escribir o parchear esos drivers a mano, que es justo lo que documentó el autor del caso original.

📖 Resumen en Telegram: Ver resumen

Tu próximo paso: descargá una imagen de firmware pública de cualquier router viejo que ya no uses (muchos fabricantes publican los .bin de actualización en su sitio de soporte) y corré binwalk -e sobre ella para practicar el flujo completo antes de intentarlo en un dispositivo que sí te importa.

Preguntas frecuentes

¿Es legal hacer ingeniería inversa de firmware en un dispositivo que me pertenece?

En la mayoría de jurisdicciones, analizar el firmware de un dispositivo propio para interoperabilidad o reparación está protegido bajo excepciones de derechos de autor, aunque las leyes varían por país. Redistribuir el binario extraído o saltar un DRM con fines de piratería sí puede violar contratos de licencia o leyes anti-elusión.

¿Qué diferencia hay entre análisis estático y análisis dinámico de firmware embebido?

El análisis estático examina los binarios extraídos sin ejecutarlos: strings, desensamblado, grep sobre archivos de configuración. El análisis dinámico corre el firmware real o emulado (por ejemplo con QEMU) para observar su comportamiento en tiempo de ejecución, algo imprescindible cuando la lógica depende de hardware externo como un bus CAN.

¿Qué herramienta conviene para empezar con la extracción de sistema de archivos?

binwalk sigue siendo el punto de partida estándar: identifica firmas conocidas y extrae automáticamente. Si el resultado queda corrupto o incompleto, unblob suele resolver los casos con capas anidadas o formatos propietarios que binwalk no reconoce del todo.

¿Cómo se identifica el tipo de filesystem dentro de una imagen de firmware?

Primero con file sobre el binario extraído, que reconoce cabeceras estándar de ext2/3/4, squashfs, cramfs, jffs2 o ubifs. Si no da resultado, un hexdump de los primeros bytes contra una lista de números mágicos conocidos suele confirmar el formato exacto.

¿Qué hacer si el firmware de un dispositivo embebido está cifrado o firmado?

Primero hay que confirmar que realmente está cifrado y no solo comprimido: la entropía alta en todo el archivo (que binwalk también mide) es la pista típica. Si hay firma pero no cifrado, el contenido se puede extraer igual; lo que se bloquea es instalar una versión modificada, no leer la original.

Referencias

• nns.ee: el artículo original sobre cómo el autor hizo ingeniería inversa de firmware al Renault Latitude 2014 para poder cambiar la hora.
• andronedev/carminat-tomtom-live-re en GitHub: trabajo previo de ingeniería inversa sobre la misma unidad TomTom Carminat LIVE.
• binwalk en GitHub: la herramienta de firma y extracción de firmware usada como primer paso en la mayoría de los análisis.
• QEMU: el emulador que permite correr un firmware extraído sin arriesgar el hardware original.
• ext3 en Wikipedia: referencia sobre el sistema de archivos que resultó contener la imagen ttsystem del caso Renault.

📱 ¿Te gusta este contenido? Únete a nuestro canal de Telegram @programacion donde publicamos a diario lo más relevante de tecnología, IA y desarrollo. Resúmenes rápidos, contenido fresco todos los días.

Imagen destacada: Foto de Vishnu Mohanan en Unsplash