Si la IA puede aplicar ingeniería inversa a cualquier app, ¿qué pasa con la seguridad?
La IA ayuda a analizar software compilado, pero la salida de un descompilador no demuestra una vulnerabilidad. Descubre qué cambia con REA y cómo validar hallazgos.
Más allá de ASPM
AppSec basada en pruebas para equipos que desarrollan con IA
Plexicus usa AI Swarm Pentest para explorar rutas de aplicaciones autorizadas, validar qué es explotable y dar a los equipos evidencia para priorizar la remediación.
Explorar AI Swarm PentestUn vídeo de Fireship publicado el 12 de octubre de 2026 plantea si todas las aplicaciones se están volviendo “de código abierto”, lo quieran o no sus creadores.
El vídeo explora el análisis de software asistido por IA, incluido Reverse Engineer Anything (REA). REA es un kit de código abierto que conecta agentes con herramientas de ingeniería inversa mediante MCP.
La idea resulta atractiva: un agente puede ayudar a inspeccionar una aplicación compilada, recorrer los resultados de análisis y explicar parte de su comportamiento sin disponer del código fuente original.
Eso puede acelerar algunas investigaciones. No convierte el software propietario en código abierto, no recupera exactamente el código original ni demuestra una vulnerabilidad.
Cada conclusión es una hipótesis hasta que la respalda evidencia independiente.
En seguridad de aplicaciones (AppSec), la pregunta útil no es si la IA puede “entender cualquier app”, sino cómo mejorar la visibilidad sin sacar artefactos, herramientas y conclusiones de un proceso de seguridad defendible.
Qué hace Reverse Engineer Anything
REA conecta agentes de programación con capacidades de ingeniería inversa.
Según el artefacto y su configuración, se pueden investigar binarios nativos, aplicaciones JavaScript y Electron, ensamblados .NET, paquetes Android, firmware y otros formatos.
El análisis de binarios nativos puede utilizar herramientas consolidadas como Ghidra, IDA o Hopper.
Estas herramientas preceden a los agentes de IA actuales: desensamblan código máquina, producen pseudocódigo aproximado, muestran referencias entre funciones y permiten inspeccionar la estructura del ejecutable.
Usa REA solo para análisis lícitos y autorizados. El repositorio indica que el análisis de las herramientas se ejecuta localmente. Los resultados llegan al proveedor de modelo configurado y se aplica su política de datos.
REA no concede licencias de IDA ni Hopper, que se licencian por separado. La capa de agente ayuda a formular preguntas, recuperar resultados relevantes, seguir referencias y resumir una posible ruta de implementación.
Un analista puede usarla para localizar dónde se gestiona una función en un programa desconocido y después revisar las funciones implicadas y comprobar su interpretación.
El agente ayuda a investigar; no reconstruye automáticamente el programa completo ni certifica su comportamiento. Los compiladores transforman información, pueden faltar símbolos y el pseudocódigo puede ser incompleto o engañoso.
Una función reconstruida quizá solo se parezca a la original.
Por qué importa para AppSec
Más visibilidad cuando no hay código fuente
Las organizaciones dependen de aplicaciones de terceros, bibliotecas nativas, clientes móviles, firmware y productos comerciales cuyo código no pueden inspeccionar.
El análisis de binarios puede aportar visibilidad cuando no sirven los métodos centrados en el código fuente. Puede señalar una ruta de entrada sospechosa, datos codificados o una función inesperada que merezca revisión.
Una función sospechosa no demuestra que algo sea explotable. Hay que establecer si una entrada puede alcanzarla, con qué configuración y con qué impacto.
Una SBOM ayuda a identificar componentes, pero ni una SBOM ni la inspección del binario demuestran por sí solas que un componente sea seguro o vulnerable.
Generación más rápida de hipótesis
La ingeniería inversa exige conocimientos de formatos ejecutables, ensamblador, memoria, convenciones de llamada y compiladores.
La IA puede ayudar a recorrer parte de esa complejidad: seguir una entrada candidata entre funciones, localizar una operación arriesgada o reunir resultados relacionados.
Esto puede orientar la revisión humana hacia operaciones de memoria, uso de criptografía, analizadores nativos y límites donde datos no confiables influyen en funciones privilegiadas. La salida de las herramientas sigue siendo una pista.
El análisis estático puede carecer de contexto de ejecución y una explicación del modelo puede ser incorrecta.
Una fuente de información para pruebas autorizadas
El análisis de binarios puede servir de apoyo a una prueba de penetración cuando el propietario ha autorizado expresamente el objetivo y los métodos.
Un analista puede investigar una ruta sospechosa y diseñar una prueba controlada para comprobar si es alcanzable y explotable en las condiciones acordadas. REA no es, por sí solo, una plataforma completa de pentesting autónomo.
La ingeniería inversa no garantiza encontrar vulnerabilidades, explotarlas ni corregirlas. Mantén las pruebas dentro del alcance escrito y valida las afirmaciones con evidencia reproducible.
El supuesto de seguridad que cuestiona la ingeniería inversa
El código compilado es más difícil de leer que el código fuente, pero el secreto de implementación no es un límite de seguridad.
Si una aplicación de escritorio comprueba permisos solo en el cliente y el backend acepta la petición sin volver a aplicar la regla, alguien puede modificar el cliente o llamar directamente al servicio.
El problema es confiar indebidamente en un comportamiento controlado por el cliente, no que exista un descompilador.
La autorización sensible debe aplicarse en un servicio confiable, en línea con OWASP ASVS v5.0, V8 Authorization.
La ofuscación, el anti-debugging y el anti-tampering elevan el coste de inspeccionar o modificar software. Pueden servir como defensa en profundidad en móviles, juegos y otros clientes.
OWASP MASVS-RESILIENCE los considera complementarios. No compensan fallos de autenticación, autorización o diseño criptográfico.
Los agentes de ingeniería inversa también pueden ser atacados
Un agente de IA puede analizar un binario con cadenas, metadatos u otro contenido controlado por un atacante.
Si una herramienta devuelve ese contenido y el agente lo interpreta como instrucciones, el artefacto puede cruzar un límite de confianza mediante prompt injection indirecto. Una secuencia simplificada:
- El agente recibe un binario desconocido.
- Una herramienta extrae cadenas, metadatos o pseudocódigo.
- Parte del contenido busca influir en un sistema de IA.
- El agente lo confunde con instrucciones fiables o una conclusión válida.
- Puede proponer una acción fuera de alcance o repetir una afirmación falsa en el informe.
También existe el riesgo de corroboración falsa: varios resultados pueden repetir el mismo texto derivado del artefacto. No son evidencias independientes solo por aparecer en paneles o formatos distintos.
El preprint de arXiv de julio de 2026 “When Binaries Talk Back: Representation-Confusion Attacks on LLM-Assisted Reverse Engineering” estudia este riesgo bajo condiciones controladas.
El experimento utilizó programas C sintéticos y controlados para Linux ELF/x86-64 y dos modelos.
Antes de los controles de ejecución propuestos, informa que los modelos propusieron una acción insegura plantada por un atacante en 35 de 40 casos adversariales.
El propio REA no fue evaluado, y estos porcentajes no miden la prevalencia de fallos en el mundo real. Es un resultado de los modelos, tareas y configuración concretos de los autores.
La lección general: el artefacto analizado debe seguir siendo dato no confiable, nunca una autoridad para el agente. Para proteger el flujo:
- trata cadenas, metadatos, pseudocódigo y documentos extraídos como entradas no confiables;
- limita permisos de herramientas y exige aprobación para acciones sensibles o fuera de alcance;
- registra la procedencia para vincular cada afirmación con su artefacto y resultado de herramienta;
- valida hallazgos importantes con pruebas independientes y autorizadas; y
- aísla binarios desconocidos y código de análisis generado de credenciales y sistemas de producción.
Este riesgo corresponde a OWASP LLM01
Prompt Injection.Limitar los permisos del agente concuerda con OWASP LLM06
Excessive Agency.Flujo de trabajo basado en evidencias
Un proceso fiable pasa de la observación a la validación. Estas siete etapas son una arquitectura de referencia práctica; no implican que REA o Plexicus implemente cada una.
- Define el alcance autorizado. Registra artefactos, entornos, métodos permitidos y acciones que requieren aprobación humana.
- Preserva el artefacto. Guarda hashes, versiones, arquitectura, procedencia y datos de componentes para vincular los resultados con la compilación exacta.
- Analiza con herramientas adecuadas. Inspecciona importaciones, símbolos, rutas, desensamblado y pseudocódigo; anota versiones y límites.
- Genera hipótesis. Pide a la IA que señale comportamientos sospechosos, pero etiqueta cada observación como posible hallazgo.
- Valida en aislamiento. Ejecuta pruebas controladas dentro del alcance para determinar si la debilidad existe y es alcanzable.
- Registra evidencia e impacto. Conserva resultados, ubicaciones relevantes, supuestos de entorno y consecuencias observadas; separa evidencia de interpretación del modelo.
- Verifica la corrección. Repite la prueba original y comprueba que no haya regresiones.
El resultado debe ser un hallazgo revisable, no solo una explicación convincente.
El análisis de binarios complementa otras técnicas
| Método | Qué permite inspeccionar | Limitación importante |
|---|---|---|
| SAST | Código fuente y representaciones compatibles | Puede no captar condiciones de ejecución |
| SCA | Componentes conocidos y riesgo de dependencias | No descubre todos los fallos desconocidos |
| DAST | Comportamiento observable de una aplicación en ejecución | Depende de rutas alcanzables y condiciones de prueba |
| Análisis de binarios | Código compilado y estructuras ejecutables | La lógica descompilada puede ser ambigua |
| Ingeniería inversa asistida por IA | Navegación y correlación de resultados | Las conclusiones del modelo requieren verificación |
| Pentesting | Comportamiento de seguridad en condiciones autorizadas | La cobertura depende del alcance, tiempo y acceso |
El objetivo no es sustituir SAST o DAST por el análisis de binarios, sino combinar evidencias adecuadas para entender mejor el riesgo.
Cómo prepararse
- Aplica la autorización en sistemas confiables. No protejas operaciones sensibles solo con controles del cliente.
- Reduce los secretos distribuidos. No incluyas credenciales privilegiadas y duraderas en aplicaciones descargables.
- Protege los componentes nativos. Prioriza diseños seguros para la memoria, endurecimiento del compilador, validación de entradas y pruebas.
- Inventaría los artefactos. Incluye binarios, firmware y componentes de terceros en los procesos de riesgo y respuesta.
- Usa ofuscación como defensa adicional. Aplícala según el modelo de amenazas, no como sustituto de una arquitectura segura.
- Protege los agentes de análisis. Impide que artefactos no confiables reemplacen instrucciones; limita por separado acceso a archivos, red, credenciales y ejecución.
- Exige evidencia reproducible. Una explicación expresada con confianza no equivale a una vulnerabilidad verificada.
Estas prácticas concuerdan con OWASP MASVS-RESILIENCE.
También concuerdan con OWASP ASVS v5.0, V8 Authorization. La versión final publicada del SSDF es NIST v1.1.
NIST SP 800-218 v1.2 (Rev. 1) era un borrador público inicial fechado en diciembre de 2025, no una versión final: NIST SP 800-218 Rev. 1 IPD.
¿La IA aplicará ingeniería inversa a todas las aplicaciones?
“Todas” oculta grandes diferencias técnicas. Una función sencilla, un programa nativo ofuscado, un servicio distribuido y un firmware que depende del hardware no se analizan igual.
Un agente puede reconstruir una ruta sin entender la aplicación entera, o generar código parecido pero no equivalente. Es más razonable esperar que la IA reduzca el coste de examinar ciertos programas compilados.
Esto puede ayudar a defensores e investigadores y también reducir barreras para atacantes.
El efecto dependerá de la implementación, la gobernanza, la autorización y la validación independiente, no de que todo el software pase a ser de código abierto.
AppSec necesita pruebas, no solo visibilidad
REA conecta herramientas de ingeniería inversa consolidadas con flujos asistidos por IA. Su importancia está en las preguntas que plantea sobre la transparencia del software y los sistemas que analizan artefactos no confiables.
Encontrar una ruta sospechosa es el inicio. Los equipos deben determinar si es alcanzable, explotable, qué impacto tiene y si se corrigió.
La IA puede acelerar la investigación, pero los resultados requieren evidencia, validación y una remediación responsable.
Ese es el principio de Proof-Driven AppSec: pasar de observaciones a hallazgos validados y correcciones verificadas.
Explora Plexicus para conocer su enfoque de pruebas de seguridad asistidas por IA, Deep Code Analysis y AppSec basada en evidencias.
Preguntas frecuentes
¿Puede la IA aplicar ingeniería inversa a software cerrado?
Puede ayudar a desensamblar, descompilar y analizar comportamientos, pero no garantiza recuperar el código fuente exacto ni componentes de servidor que no están en el artefacto.
¿Qué es Reverse Engineer Anything (REA)?
Es un kit de código abierto que conecta agentes de programación con capacidades de ingeniería inversa mediante MCP. Los formatos y las integraciones dependen de la configuración.
¿Puede encontrar vulnerabilidades?
Puede ayudar a identificar rutas sospechosas y formular hipótesis. Hace falta análisis adicional y pruebas autorizadas para confirmar una vulnerabilidad.
¿La ingeniería inversa vuelve inseguras las apps propietarias?
No. La seguridad no debe depender del secreto de implementación. Puede revelar debilidades cuando una aplicación confía en controles del cliente o en comportamientos ocultos.
¿Un agente puede sufrir prompt injection?
Sí. Cadenas o resultados de herramientas controlados por un atacante pueden influir en el agente si se tratan como instrucciones fiables. La investigación ha demostrado riesgos de confusión de representación en experimentos controlados.
¿Puede sustituir al pentesting?
No. Puede orientar pruebas autorizadas, pero inspeccionar código no demuestra por sí mismo explotabilidad ni impacto.
Referencias
- Fireship: Every app on Earth is now open source… whether it likes it or not
- Reverse Engineer Anything (REA)
- Ghidra
- When Binaries Talk Back: ataques de confusión de representación (julio de 2026)
- OWASP LLM01 Prompt Injection
- OWASP LLM06 Excessive Agency
- OWASP MASVS-RESILIENCE
- OWASP ASVS v5.0, V8 Authorization
- NIST SP 800-218: Secure Software Development Framework, v1.1 final
- NIST SP 800-218 Rev. 1 initial public draft
