En resumen: la ingeniería inversa (reversing) de firmware ha sido durante décadas cosa de especialistas en ensamblador y arquitecturas poco comunes. Los modelos de lenguaje (LLM) no sustituyen ese conocimiento, pero sí reducen mucho el tiempo: generan los scripts, interpretan el ensamblador y ayudan a conectar hallazgos. En este artículo contamos cómo lo aplicamos al análisis de dispositivos embebidos, como los routers domésticos, y dónde están sus límites.
Durante décadas, el reverse engineering de firmware ha sido territorio exclusivo de especialistas con años de experiencia en ensamblador, arquitecturas RISC y formatos binarios propietarios. La curva de aprendizaje era enorme, las herramientas escasas y el tiempo necesario para analizar un dispositivo podía medirse en semanas. La irrupción de los modelos de lenguaje de gran escala está cambiando esa ecuación de forma notable.
Aquí recogemos la experiencia del equipo de BCNSoluciona usando IA como asistente principal en el análisis de seguridad de dispositivos embebidos de uso cotidiano, como los routers que los operadores distribuyen a millones de hogares. El objetivo es ilustrar el método y el cambio de proceso, no señalar ningún producto concreto.
El problema del firmware embebido
Desde el punto de vista de la seguridad, los dispositivos embebidos son objetivos peculiares. A diferencia de una aplicación web o un servidor en la nube, un equipo de este tipo:
- Ejecuta software propietario sin código fuente disponible.
- Funciona sobre arquitecturas de CPU distintas a las del PC del investigador (MIPS, ARM, PowerPC).
- Usa librerías personalizadas y formatos de imagen propios del fabricante.
- Suele gestionarlo el operador en remoto mediante protocolos como TR-069.
- Está presente en millones de hogares, lo que amplifica el impacto de cualquier vulnerabilidad.
Muchos de estos equipos usan arquitecturas como MIPS32 big-endian, habitual en los SoC de varios fabricantes. Ese es el primer obstáculo: la mayoría de herramientas de análisis están pensadas para x86/x64 o, en el mejor caso, ARM, y encontrar soporte sólido para arquitecturas menos habituales no es trivial.
El flujo de trabajo tradicional frente al asistido por IA
Sin IA, el proceso habitual es:
- Extraer el sistema de archivos con binwalk.
- Identificar a mano los binarios de interés.
- Cargar el binario en IDA Pro o Ghidra, configurar la arquitectura y esperar el análisis automático.
- Recorrer el desensamblado a mano, tomar notas y cruzar referencias.
- Buscar en la documentación del fabricante y en foros especializados para entender el contexto.
Cada paso puede llevar horas, y entender el código resultante exige experiencia en la arquitectura y en el ecosistema del fabricante.
Con IA, el flujo cambia:
- Extraer el sistema de archivos (esto sigue igual).
- Describir el objetivo al asistente: «busca funciones relacionadas con la autenticación en este binario para una arquitectura MIPS32 BE».
- La IA genera scripts de análisis, interpreta la salida de nm, strings y readelf, y localiza patrones de interés.
- Se itera en lenguaje natural: «¿qué hace esta función?», «¿hay algún patrón que convenga revisar con más detalle?».
- La IA ayuda a redactar el informe de hallazgos.
El tiempo de análisis se comprime mucho: lo que antes requería semanas se puede abordar en sesiones de trabajo de pocas horas.
Herramientas del análisis
Binwalk: extracción del firmware
El primer paso de cualquier análisis de firmware es extraer su contenido. Binwalk identifica automáticamente las secciones del binario: cabecera propietaria, kernel comprimido y sistema de archivos SquashFS.
Es habitual encontrar una cabecera propietaria del fabricante seguida de un SquashFS comprimido. Binwalk lo extrae sin problemas y deja un árbol de directorios navegable con todo el sistema de archivos del dispositivo.
$ binwalk -e firmware.bin
DECIMAL HEXADECIMAL DESCRIPTION
0 0x0 Firmware header
131072 0x20000 Squashfs filesystem (XZ compressed)Capstone: desensamblado multiarquitectura
Aquí se nota la falta de soporte de algunas herramientas: no todos los motores de análisis binario admiten arquitecturas poco comunes como MIPS32 big-endian. En lugar de bloquear el análisis, la IA propuso una alternativa inmediata: usar la librería Capstone directamente desde Python.
Capstone es un framework de desensamblado multiarquitectura que sí soporta estas variantes. Con un script de pocas líneas se puede desensamblar cualquier función del binario a partir de su dirección, obtenida antes con nm.
La IA no solo sugirió el enfoque: generó el script, lo corrigió cuando los primeros resultados eran incorrectos (el modo big-endian requiere combinar dos flags de Capstone de una forma poco obvia) e interpretó el desensamblado para explicar qué hacía cada función.
nm y strings: inventario rápido
Antes de desensamblar nada, nm da la tabla de símbolos del binario. En binarios que conservan los símbolos, esto ofrece directamente los nombres y direcciones de todas las funciones. strings lo complementa con las cadenas de texto literales: rutas, mensajes de error y comandos del sistema.
La IA analizó la salida de estos comandos para decidir qué funciones merecían un análisis detallado, priorizando por nombres descriptivos y por cadenas que suelen marcar puntos de interés en el código.
Patrones de seguridad habituales
Sin entrar en detalles que pudieran facilitar un uso malicioso, el análisis de esta clase de dispositivos suele revelar varios patrones problemáticos, comunes en el firmware embebido de generaciones pasadas:
Gestión de la autenticación. Es frecuente que el servidor web tenga un sistema de excepciones en el que ciertas rutas no comprueban credenciales. Si está mal implementado, puede dejar expuestas rutas sensibles. La IA es especialmente útil aquí: identifica la función a partir del nombre del símbolo, analiza su lógica y explica qué rutas quedan exentas y por qué.
Configuración de red IPv6. La revisión de la configuración por defecto a veces muestra diferencias entre el comportamiento del cortafuegos en IPv4 y en IPv6. La IA ayuda a cruzar ese hallazgo con el análisis de los sockets de red de los binarios del servidor para confirmar si ambos datos apuntan a la misma conclusión.
Componentes desactualizados. Es habitual que el firmware incluya versiones de OpenSSL, OpenSSH o BusyBox con varios años de antigüedad y sin soporte. No es un hallazgo nuevo (es endémico en los dispositivos embebidos), pero el número de equipos desplegados lo convierte en un riesgo relevante.
Ausencia de mitigaciones de memoria. A menudo los binarios no se compilan con las protecciones estándar contra corrupción de memoria (stack canaries, ASLR, NX). Es fácil de comprobar con readelf, y la IA aporta el contexto: qué significa en la práctica y cómo se compara con el estado del arte actual.
El papel concreto de la IA en el proceso
Más allá de las herramientas, lo interesante es cómo cambia el razonamiento. La IA aporta valor en tres frentes:
Como buscador especializado. «¿Qué hace setsockopt(AF_INET6) sin IPV6_V6ONLY en Linux?». La respuesta inmediata, con contexto de seguridad, ahorra tiempo de consulta de páginas man y RFC.
Como intérprete de ensamblador. Pegar unas líneas de desensamblado y preguntar «¿qué hace esta función, en español y sin código?» da una descripción funcional clara en segundos. No es perfecta (el análisis estático tiene límites), pero basta para orientar el trabajo.
Como colaborador para formular hipótesis. «Tenemos una ruta sin autenticación y un cortafuegos que no cubre IPv6. ¿Qué superficie de ataque describe esto?». Este razonamiento cruzado entre hallazgos dispersos es donde la IA aporta más. Un analista llega a las mismas conclusiones, pero la IA acelera la conexión de los puntos.
Limitaciones: la IA se equivoca
La IA no sustituye el criterio del analista. Varios momentos del análisis exigen verificación manual porque comete errores:
- Falsos positivos en el desensamblado: puede tomar por problema de seguridad una secuencia de instrucciones que es código legítimo.
- Contexto limitado: sin ejecutar el binario, el análisis estático tiene puntos ciegos. La IA suele reconocerlo, pero el investigador debe tenerlo presente.
- Alucinaciones en referencias externas: a veces describe el comportamiento de funciones de librería de forma incorrecta. Contrastar con las páginas man es imprescindible.
La IA multiplica la capacidad, pero no es un oráculo. El investigador sigue necesitando criterio propio para validar los hallazgos.
Es la misma forma en la que trabajamos en nuestros tests de intrusión: automatización e IA para ganar velocidad y cobertura, y especialistas que validan cada hallazgo antes de que llegue al informe. Si lo que quieres revisar son tus propios sistemas de IA, lo cubre el pentesting de IA.
Divulgación responsable
Cuando un análisis de este tipo revela vulnerabilidades reales, el camino correcto es la divulgación coordinada: avisar al fabricante y a los organismos competentes y respetar un plazo razonable (habitualmente 90 días) antes de publicar detalles técnicos.
En España, INCIBE-CERT (incibe-cert@incibe.es) es el punto de contacto para coordinar vulnerabilidades en tecnología de uso masivo. Notificar por este canal ayuda a que la corrección llegue a los usuarios afectados.
Conclusión
La ingeniería inversa de firmware embebido ha sido una disciplina de alta especialización y poco rendimiento por hora invertida. Los LLM no eliminan la necesidad de conocimiento técnico, pero sí reducen mucho el coste de entrada y el tiempo de análisis para investigadores con una base sólida en seguridad.
Los routers domésticos lo ilustran bien: arquitecturas poco habituales, herramientas con soporte limitado y configuración propietaria. Hace tres años, un análisis equivalente habría requerido un equipo especializado y semanas de trabajo. Con IA como asistente, un investigador puede completar un análisis inicial exhaustivo en días.
Esta democratización tiene implicaciones importantes: más investigadores pueden analizar más dispositivos, lo que debería traducirse en más vulnerabilidades encontradas y corregidas antes de ser explotadas. La otra cara (que también baja la barrera para los atacantes) es un debate que la comunidad de seguridad tendrá que seguir afrontando.
¿Fabricas o integras dispositivos conectados, o quieres saber qué encontraría un atacante en tus sistemas? Cuéntanos tu caso.
Preguntas frecuentes
¿Qué es el reversing de firmware?
Es el análisis del software interno de un dispositivo (router, cámara, impresora…) sin acceso a su código fuente, para entender cómo funciona y encontrar fallos de seguridad.
¿Puede la IA hacer sola la ingeniería inversa de un firmware?
No. Acelera la extracción, el desensamblado y la interpretación, pero comete errores y necesita un analista que valide cada hallazgo.
¿Qué herramientas se usan para analizar firmware?
Las habituales son binwalk para extraer el sistema de archivos, nm, strings y readelf para el inventario, y Ghidra, IDA Pro o Capstone para el desensamblado.
¿Qué hago si encuentro una vulnerabilidad en un dispositivo?
Notificarla de forma coordinada al fabricante y, en España, a INCIBE-CERT, y esperar un plazo razonable (habitualmente 90 días) antes de publicar detalles.
Reflexión del equipo de BCNSoluciona basada en trabajo realizado en entornos de laboratorio aislados sobre hardware propio, sin acceso a infraestructura de producción ni a dispositivos de terceros.
