binwalk

Ingeniería inversa de firmware: guía paso a paso 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. 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. El SoC Samsung S5P6440 de la unidad TomTom Carminat LIVE corre un kernel Linux 2.6.28.10, según el análisis publicado en noviembre de 2026. 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. binwalk, publicado por ReFirmLabs, sigue siendo la primera herramienta que corren la mayoría de los analistas de firmware embebido. 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. HerramientaCuándo usarlaVentajaLimitaciónbinwalkPrimer escaneo de cualquier imagen de firmware desconocidaDetecta firmas de decenas de filesystems y formatos de compresión automáticamentePuede extraer basura si hay firmas falsas positivas dentro de datos binariosunblobCuando binwalk no logra extraer limpio o hay capas anidadasExtracción recursiva más robusta y mejor manejo de formatos propietariosMás lento y con más dependencias que instalardd + mount -o loopCuando ya se identificó el offset exacto del filesystemControl total, sin depender de heurísticas de tercerosRequiere calcular offsets a mano con un hexdumpQEMUPara ejecutar el firmware extraído sin tocar el hardware realPermite iterar sin riesgo de dejar el dispositivo inservibleEmular periféricos específicos (bus CAN, pantallas táctiles) suele requerir parches manuales 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.

🚨 ENGENHARIA REVERSA COM IA | QUANTO TEMPO ATÉ HACKEAREM SEU BANCO? Engenharia reversa levava uma semana. O Low Level jogou o firmware criptografado de um monitor da Dell pra uma IA, e em 16 minutos ela extraiu a chave, descriptografou o binário e ainda provou que tava certo. Achar falha em software virou commodity. E fica a pergunta: quanto tempo até fazerem o mesmo com o internet banking legado do seu banco, com a maquininha de cartão e com a sua hard wallet? ⭐ Seja membro do canal: youtube.com 📸 Instagram: instagram.com 📌 Canal de cortes: youtube.com 🔗 Vídeo original (Low Level): youtu.be 🛠️ REA, o repo de engenharia reversa com IA que viralizou essa semana: morluto/rea CAPÍTULOS 0:00 O que seu banco e sua hard wallet têm em comum 2:02 A IA que abriu o firmware em 16 minutos 2:27 Como era a engenharia reversa antes da IA 3:21 O que a IA fez, passo a passo 4:58 Engenharia reversa virou commodity 7:24 E aqui no Brasil? 7:54 Bancos com sistema legado 9:21 Maquininhas de cartão 9:50 Hard wallets 10:39 Isso é paranoia? 11:49 A pergunta que fica FONTES Ghidra, o framework de engenharia reversa da NSA: NationalSecurityAgency/ghidra binwalk: ReFirmLabs/binwalk Firmware da Trezor no GitHub: trezor/trezor-firmware [en-US] 🚨 AI REVERSE ENGINEERING | HOW LONG UNTIL THEY HACK YOUR BANK? Reverse engineering used to take a week. Low Level ran the encrypted firmware from a Dell monitor through an AI, and in 16 minutes it extracted the key, decrypted the binary, and even proved it was correct. Finding software flaws has become a commodity. And the question remains: how long until they do the same with your bank's legacy online banking, your card reader, and your hard wallet? ⭐ Become a channel member: youtube.com 📸 Instagram: instagram.com 📌 Editing channel: youtube.com 🔗 Original video (Low Level): youtu.be 🛠️ REA, the AI ​​reverse engineering repo that went viral this week: morluto/rea CHAPTERS 0:00 What your bank and your hard wallet have in common 2:02 The AI ​​that cracked the firmware in 16 minutes 2:27 What reverse engineering was like before AI 3:21 What the AI ​​did, step by step 4:58 Reverse engineering became a commodity 7:24 And here in Brazil? 7:54 Banks with legacy systems 9:21 Card payment terminals 9:50 Hard wallets 10:39 Is this paranoia? 11:49 The question that remains SOURCES Ghidra, the NSA's reverse engineering framework: NationalSecurityAgency/ghidra binwalk: ReFirmLabs/binwalk Trezor firmware on GitHub: trezor/trezor-firmware [es-US] 🚨 INGENIERÍA INVERSA CON IA | ¿CUÁNTO FALTA PARA QUE HACKEEN TU BANCO? Antes, la ingeniería inversa tardaba una semana. Low Level analizó el firmware cifrado de un monitor Dell mediante inteligencia artificial y, en 16 minutos, extrajo la clave, descifró el binario e incluso demostró su veracidad. Encontrar fallos de software se ha convertido en algo habitual. Y la pregunta sigue en pie: ¿cuánto tiempo pasará hasta que hagan lo mismo con la banca online tradicional de tu banco, tu lector de tarjetas y tu cartera física? ⭐ Hazte miembro del canal: youtube.com 📸 Instagram: instagram.com 📌 Canal de edición: youtube.com 🔗 Video original (Bajo nivel): youtu.be 🛠️ REA, el repositorio de ingeniería inversa con IA que se hizo viral esta semana: morluto/rea CAPÍTULOS 0:00 Qué tienen en común tu banco y tu billetera física 2:02 La IA que descifró el firmware en 16 minutos 2:27 Cómo era la ingeniería inversa antes de la IA 3:21 Qué hizo la IA, paso a paso 4:58 La ingeniería inversa se convirtió en un producto básico 7:24 ¿Y aquí en Brasil? 7:54 Bancos con sistemas heredados 9:21 Terminales de pago con tarjeta 9:50 Carteras de hardware 10:39 ¿Es esto paranoia? 11:49 La pregunta que queda FUENTES Ghidra, el marco de ingeniería inversa de la NSA: NationalSecurityAgency/ghidra binwalk: ReFirmLabs/binwalk Firmware de Trezor en GitHub: trezor/trezor-firmware