REA: cómo hacer ingeniería inversa con IA

La ingeniería inversa tiene mala fama por una razón concreta: se confunde con saltarse protecciones. Hacer ingeniería inversa de software propio o autorizado es otra cosa: es la práctica de entender cómo funciona un sistema para mantenerlo, interoperar con él, recuperar conocimiento o enseñar. REA (Reverse Engineer Anything) mete esa práctica dentro del flujo de un agente de IA.

No es un decompilador nuevo ni un botón que explique aplicaciones. Es una capa de orquestación: una CLI y un servidor MCP que da al agente herramientas para inspeccionar binarios, aplicaciones Electron, ensamblados .NET y webs, y devuelve los hallazgos con la evidencia y los límites que los acompañan. Esa diferencia —evidencia frente a relato plausible— es lo que hace que valga la pena.

Qué es REA exactamente

Hechos verificables a 26 de octubre de 2026: se distribuye como paquete npm rea-agents (versión 6.8.0), con licencia MIT, repositorio en morluto/rea y web en rea.tools. Requiere Node.js 22.x (>= 22.23.4), 24.x (>= 24.22.1) o 26.12.1+, además de npm.

Su README lo describe como un MCP para ingeniería inversa en binarios, aplicaciones y comportamiento en tiempo de ejecución. En la práctica, el agente pide una inspección, REA ejecuta herramientas locales y devuelve código, referencias y huecos. El agente usa eso para explicar el comportamiento o escribir una implementación y probarla.

Lo que no es:

• No es un decompilador propio. Para análisis nativo profundo usa Hopper, Ghidra o IDA como proveedores.
• No es un servicio en la nube. El análisis ocurre en tu máquina.
• No es una autorización. Que puedas analizar algo no significa que tengas derecho a hacerlo.
• No es infalible. Devuelve también lo que no sabe, y eso hay que leerlo.

Cómo funciona: agente, MCP y evidencia

MCPes el estándar que permite a un agente descubrir y llamar herramientas externas. REA expone su catálogo por MCP y el agente decide qué herramienta usar según la pregunta.

El bucle es simple: el agente pregunta, REA inspecciona, el agente recibe un resultado estructurado, formula una hipótesis y pide una nueva comprobación. La parte importante es la última: el resultado incluye evidencia y limitaciones. No es una caja negra que dice "esta app usa IPC"; te dice en qué archivo, qué fragmento y con qué confianza.

Conviene distinguir dos modos:

• Inspección estática: lee archivos sin ejecutar la aplicación. Es el caso de JavaScript, .NET, metadatos de APK, cabeceras de binarios o artefactos de modelos.
• Observación en tiempo de ejecución: ejecuta o interactúa con el objetivo con tus permisos. Sirve para capturar tráfico, comportamiento de procesos o sesiones web, pero puede modificar estado.

Mi lectura: la evidencia es el verdadero producto. La mayoría de losagentesfallan en análisis técnico no por falta de capacidad, sino por rellenar huecos con explicaciones plausibles. Un informe que separa hecho, inferencia y desconocido se puede auditar; uno que solo suena seguro, no.

Qué se puede analizar

La lista del proyecto es amplia. Estos son los grupos que más importan para un trabajo real:

• Aplicaciones JavaScript y Electron: módulos, imports, source maps, rutas, IPC y relación con addons nativos. No necesita motor nativo.
• Binarios nativos: pseudocódigo, ensamblador, cadenas, símbolos, llamadas y referencias. Necesita Hopper, Ghidra o IDA.
• Ensamblados .NET: metadatos, instrucciones CIL, dependencias nativas declaradas y comparación de builds. Es estático.
• Webs: estructura de página, scripts, observaciones de red y capturas. Requiere un navegador de la familia Chrome.
• Android: APK con JADX y un JDK completo; firmas de APK sin motor; recursos con Apktool; apps Flutter con análisis estático.
• Firmware, capturas de red, paquetes, SQLite, crashes registrados, objetos GPU y artefactos WASM, entre otros.

También hay formatos que resuelve sin instalar nada: binarios Go (versión del compilador, módulos y build settings), binarios Rust con cargo-auditable, metadatos IL2CPP de Unity, archivos PCK de Godot, certificados e imports de PE, notas ELF y módulos del kernel Linux.

No todo funciona igual en todos los sistemas. En Linux, algunas funciones (Ghidra, JADX, firmware y análisis estático de JavaScript) necesitan un ps compatible con procps en el PATH. En Windows y macOS hay límites por proveedor. La documentación de instalación es la fuente que manda.

Instalación y primera inspección

El arranque oficial es:

npx rea-agents setup

El instalador pregunta qué agentes configurar, muestra los cambios propuestos y pide aprobación. Añade el servidor MCP y las instrucciones de trabajo, con copia de seguridad de la configuración existente. Después hay que reiniciar el agente.

El setup reconoce Claude Code, Codex, Cursor, Gemini CLI, Grok Build y otros agentes; cualquier cliente con MCP local se puede registrar a mano. Para Hopper ofrece una instalación opcional, siempre con aprobación.

Si necesitas reproducibilidad, fija la versión que verificaste:

npx rea-agents@6.8.0 setup

Para una inspección por terminal, sin agente:

npx -y rea-agents@latest analyze-javascript-application /ruta/absoluta/a/la/app --json

Sustituye la ruta por la de tu copia. En Windows, por ejemplo, D:/apps/ejemplo. El resultado incluye módulos, imports, límites de Electron y su evidencia.

Si lo vas a usar a menudo, instala el comando global y mantenlo actualizado:

npm install --global rea-agents
rea --help
rea update

Y una petición típica al agente, con alcance cerrado:

Analiza esta app de escritorio, que es mía y está en ./target. Quiero entender
cómo implementa la búsqueda local. Devuelve la evidencia, lo que no puedas
determinar y un plan para replicar la función en ./mi-proyecto. No modifiques
nada fuera de ./mi-proyecto y no ejecutes la app.

Evidence: el informe que puedes discutir

El README insiste en que los resultados incluyen la evidencia y las limitaciones de cada conclusión. Eso se traduce en tres preguntas que deberías hacer siempre:

1. ¿Qué archivo, instrucción, ruta o captura sostiene esta afirmación?
2. ¿Qué parte es inferencia del agente y no observación directa?
3. ¿Qué prueba adicional confirmaría o refutaría la hipótesis?

Un ejemplo del propio proyecto: en el caso de Notion, REA sigue la API de portapapeles del renderer, pasa por el preload y el IPC hasta el proceso principal, e inspecciona el formato enriquecido. No basta con decir "usa Electron"; el valor está en la cadena concreta.

En binarios nativos, la respuesta típica incluye pseudocódigo y ensamblador. Ahí la evidencia es la dirección, la instrucción y la referencia cruzada. Si el agente escribe una implementación sin citar ninguna, no tienes un análisis: tienes una hipótesis con buena prosa.

Un flujo de trabajo que aguanta revisión

1. Define el alcance por escrito: qué software, qué pregunta y qué queda fuera.
2. Guarda una copia y registra su hash o versión. Sin baseline no puedes comparar ni reproducir.
3. Formula una pregunta falsable. "¿Cómo funciona la app?" no sirve. "¿Qué ruta usa el renderer para escribir en el portapapeles?" sí.
4. Empieza por lo estático. Ejecuta solo cuando la pregunta lo exija y en un entorno desechable.
5. Pide evidencia y límites en cada paso, no solo la conclusión.
6. Reproduce el hallazgo en una copia limpia. Si no se reproduce, no está verificado.
7. Separa en tus notas hecho, inferencia y desconocido. Es la diferencia entre un informe y una opinión.
8. Documenta lo que no pudiste resolver. Los huecos también son resultado.

Si trabajas con versiones, guarda snapshots y compara. Una parte importante de la ingeniería inversa no es descubrir una función, sino entender qué cambió entre dos builds y por qué.

Límites, costes y riesgos

• Proveedores nativos: Hopper, Ghidra e IDA son herramientas con sus propias licencias. REA no concede licencias, claves ni activaciones. Los binarios grandes pueden necesitar subir los tiempos de arranque del proveedor.
• Node y sistema: las versiones soportadas no son un detalle. Un Node antiguo rompe la instalación; en Linux, la falta de procps rompe funciones concretas.
• Privacidad: el análisis es local, pero el agente recibe los resultados y su proveedor de modelo aplica su propia política de datos. "Local" no significa "nada sale de tu máquina" si el modelo es remoto.
• Estado del objetivo: la captura en tiempo de ejecución interactúa con la aplicación. Puede escribir archivos, abrir sesiones o dejar rastros. Usa una máquina virtual o una copia y documenta los cambios.
• Calidad: binarios empaquetados, ofuscación o protecciones anti-análisis pueden bloquear el trabajo. Un buen informe lo dice en vez de inventar.

Hay una función avanzada que conviene mencionar sin exagerar: REA puede convertir peticiones y respuestas grabadas de una web en un entorno ejecutable para agentes, con AgentEnv y Docker. Sirve para evaluación y aprendizaje por refuerzo, no para atacar el sitio original.

La línea legal y ética

El propio proyecto lo deja claro en su aviso: REA es para investigación lícita, educación, interoperabilidad, preservación de software y análisis de software que posees o estás autorizado a examinar. También dice que las copias crackeadas, las claves robadas y la evasión de restricciones de licencia no están autorizadas.

Eso se traduce en reglas prácticas:

• Trabaja sobre software propio o con autorización escrita. Si es de un tercero, define por escrito qué puedes hacer y qué no.
• No evadas DRM, licencias ni controles de acceso. Este artículo no enseña eso y la herramienta tampoco lo legitima.
• No extraigas datos personales, secretos comerciales ni credenciales. Minimiza y borra las capturas cuando termines.
• La interoperabilidad tiene marco legal distinto en cada jurisdicción. Si el caso es comercial, revísalo con un abogado.
• Respeta los términos de servicio y la privacidad de los usuarios. Un hallazgo técnico no elimina una obligación legal.

La licencia MIT de REA cubre el código propio del proyecto. Las herramientas de terceros y los materiales incluidos mantienen sus licencias. Y ninguna licencia de REA te da derechos sobre el software que analizas.

Cuándo no usar REA

• Cuando la documentación, el repositorio o el sistema de tickets ya responden la pregunta.
• Cuando basta con abrir las herramientas de desarrollo del navegador.
• Cuando no tienes autorización sobre el objetivo.
• Cuando necesitas una garantía legal, no un hallazgo técnico.
• Cuando la pregunta es cómo saltarse una protección. Eso queda fuera de alcance.

Qué se aprende de verdad

La ingeniería inversa con agentes no sirve solo para copiar una función. Sirve para leer arquitectura, comparar versiones, recuperar software abandonado, preparar interoperabilidad, investigar seguridad y enseñar cómo se construyen los sistemas.

Los casos publicados por el proyecto apuntan en esa dirección: reconstruir un cálculo de paneo de sonido en DX-Ball a partir de instrucciones x86, seguir el puente de portapapeles de Notion a través de Electron, o recuperar un cálculo de ángulos en un juego de PC-98. Son ejercicios de comprensión, no de apropiación.

Si quieres profundizar, el sitio tiene unglosariocon MCP, tool calling y agentes; unaruta de sistemas de agentespara entender el contexto;herramientas,promptsyRadarpara seguir el ecosistema. Y si vienes del diseño de agentes, el artículo sobreagentes en producciónexplica por qué la evidencia y los límites no son un adorno.

Fuentes

• Paquete npm: https://www.npmjs.com/package/rea-agents (versión 6.8.0, licencia MIT)
• Repositorio: https://github.com/morluto/rea
• Web y guías: https://rea.tools/
• Instalación: https://github.com/morluto/rea/blob/main/docs/installation.md
• CLI y evidencia: https://github.com/morluto/rea/blob/main/docs/cli.md
• Aviso de uso: https://github.com/morluto/rea/blob/main/DISCLAIMER.md
• Licencia: https://github.com/morluto/rea/blob/main/LICENSE
• Casos: https://rea.tools/showcase/

Verificado el 26 de octubre de 2026 contra la versión 6.8.0 publicada en npm, el README del repositorio y la documentación oficial. Los requisitos y capacidades pueden cambiar entre versiones: comprueba la versión que instalas.