REA: cuando tu agente abre el binario y te explica cómo funciona

Hay una escena que se repite en cualquier equipo de producto: ves una función en una aplicación ajena, piensas «esto lo quiero en lo mío», y ahí se acaba el camino. Del otro lado hay un binario compilado, un paquete sin código fuente o una app empaquetada. Explicarlo exige herramientas de ingeniería inversa, criterio y —sobre todo— tiempo.

REA (Reverse Engineer Anything) propone atacar ese hueco con un ángulo distinto: en lugar de convertirte en experto en desensambladores, conecta esas herramientas a tu agente. Tú preguntas en lenguaje natural; el agente inspecciona, rastrea el código y te devuelve la explicación con la evidencia que la sostiene.

• Repositorio: github.com/morluto/rea
• Web con guías y casos: rea.tools
• Paquete: rea-agents (npm)
• Licencia MIT · TypeScript · requiere Node 22.19+, 24.11+ o 26+

El problema real que resuelve

La ingeniería inversa clásica tiene tres barreras: la herramienta (Ghidra, Hopper, IDA), el criterio (saber leer ensamblador y pseudocódigo) y el tiempo (días de exploración para una sola pregunta). REA no elimina ninguna de las tres, pero mueve dos de ellas de sitio: el agente maneja el flujo de trabajo y tú te quedas con la pregunta y la decisión.

El planteamiento del proyecto es explícito: «ver una función que te gusta; entender cómo funciona, hasta el nivel de binario». Y el resultado final no es un informe: es una implementación construida para tu proyecto.

Cómo funciona

La arquitectura es la propia de un servidor MCP (Model Context Protocol), el estándar que usan los agentes para hablar con herramientas locales:

1. Tu agente llama a REA por MCP y le describe el objetivo.
2. REA inspecciona y rastrea el código usando los motores de análisis disponibles.
3. Devuelve hallazgos con evidencia: pseudocódigo, ensamblador, referencias, límites de lo que se sabe y lo que no.
4. El agente usa esa base para explicar el comportamiento, responder preguntas de seguimiento, escribir una implementación y probarla.

Lo importante es el punto 3. Un asistente que «te cuenta» cómo funciona algo sin enseñar de dónde lo saca es un generador de hipótesis. Aquí la conclusión viene atada a su prueba, y las limitaciones se declaran.

Además, el análisis corre en local: los archivos no se suben a ningún servicio de REA. Dicho esto, conviene leer la letra pequeña de siempre — el agente sí pasa los resultados a su proveedor de modelo, con la política de datos que ese proveedor tenga.

Qué se puede analizar: más de lo que parece

Aquí es donde el proyecto se sale de lo que uno espera de un «descompilador con agente». La tabla de objetivos soportados es sorprendentemente ancha:

Código y binarios
– Binarios nativos: pseudocódigo, ensamblador, cadenas, símbolos, llamadas y referencias (con Hopper, Ghidra o IDA).
– Go: versión del compilador embebida, módulos, reemplazos y opciones de compilación — sin necesidad de tener Go instalado.
– Rust: nombres, versiones, orígenes y dependencias extraídas de binarios cargo-auditable.
– WASM: validación, secciones y formas exactas de import/export.
– Bytecode EVM: selectores de despacho, offsets, argumentos inferidos y mutabilidad.
– .NET: metadatos, instrucciones CIL, dependencias nativas y comparación de builds (todo estático).

Aplicaciones
– JavaScript / Electron: módulos, imports, source maps, rutas, comunicación IPC y relaciones con complementos nativos.
– APKs de Android: manifiesto, clases, métodos descompilados y referencias; también recursos decodificados (tablas de cadenas, idiomas, versiones).
– Dispositivos Android: paquetes, procesos, logs, volcados y capturas de pantalla vía adb.
– Flutter: hash del snapshot de Dart, digests por ABI y procedencia del motor.
– Firmware: regiones, extracción y entrega al análisis nativo (Binwalk / Unblob).
– Webs: estructura de página, scripts, observaciones de red y capturas.

Datos y comportamiento en ejecución
– Bases SQLite: tablas, columnas, índices, vistas, disparadores y filas.
– Capturas de red (HAR o SAZ): peticiones, respuestas, payloads expuestos y de dónde salen.
– Resúmenes de tráfico: endpoints, DNS, SNI de TLS, distribución de protocolos y peticiones HTTP.
– Crashes de Linux: registros, hilos, señales y candidatos de mapeo.
– Paquetes de señales lógicas grabadas (por ejemplo con sigrok).
– Comportamiento de procesos: salida de terminal, interacciones, código de salida y comparación entre ejecuciones.

El detalle que separa lo útil de lo decorativo: unos objetivos se leen sin ejecutar nada (JavaScript estático, .NET) y otros implican ejecutar o interactuar con el objetivo, con los efectos que eso tenga. La propia documentación lo distingue sin adornos.

Tres casos reales, no diapositivas

Lo que más me convence del proyecto es que publica trabajo terminado, con repositorio y verificación:

DX-Ball — reconstruir un cálculo de sonido. Siguieron una llamada de sonido por dentro hasta su rutina de posición-a-paneo, leyeron las instrucciones y convirtieron un pseudocódigo incompleto en C. La reconstrucción pasa 3.205 casos de prueba sobre el x86 original y reproduce los 63 bytes de la función compilada. Ese último dato es el que importa: no «se parece», sino que coincide.

Notion — el puente del portapapeles. Encontraron la API del renderer, la siguieron a través del preload y del IPC hasta el proceso principal, y diseccionaron el formato de portapapeles enriquecido. Es el caso típico de «quiero entender cómo una app de escritorio moderna maneja algo que la mía no maneja bien».

TH04 — un juego de PC-98. Inspeccionaron las instrucciones de 16 bits del juego original, recuperaron los cálculos de ángulo fijo y apuntado, y compararon su C++ con la salida del compilador histórico. Arqueología de software con control de errores.

Los tres tienen caso de estudio enlazado desde el repositorio, y dos incluyen el repositorio de la reconstrucción. Cuando un proyecto enseña su trabajo en vez de prometerlo, la conversación cambia.

Instalación y requisitos

El punto de entrada es una línea:

npx rea-agents setup

Eso registra el servidor MCP en tu agente e instala las instrucciones de trabajo asociadas. Después, dos detalles que conviene no pasar por alto:

• Node 22.19+, 24.11+ o 26+ según la rama instalada.
• Motor de análisis nativo opcional: Hopper, Ghidra o IDA si vas a trabajar con binarios nativos. Para JavaScript y .NET no hace falta ninguno. El propio REA puede instalar Hopper, pero pidiendo permiso.

También hay uso por terminal, sin agente de por medio:

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

Y actualización con rea update o refrescando el setup.

Lo que no es, y conviene decirlo

• No es magia ni un sustituto del criterio. Un modelo puede equivocarse interpretando pseudocódigo; lo que cambia es que aquí puede enseñarte el fragmento y el byte que sostienen su conclusión.
• No convierte en legal lo que no lo es. Entender cómo funciona algo no es lo mismo que poder copiarlo. Licencias, patentes y condiciones de uso siguen ahí, y el proyecto no las resuelve por ti.
• No todos los objetivos cuestan lo mismo. Análisis estático de JavaScript: barato. Binario nativo grande con un decompilador: otra liga, y con tiempos de arranque que a veces hay que ampliar.
• No es un servicio en la nube. Corre en tu máquina, con tus herramientas y tu sesión de usuario. Eso también significa que ejecutar ciertos análisis toca tu sistema, como cualquier otra herramienta local.

Por qué merece la pena mirarlo

Llevamos dos años viendo agentes que escriben código; la parte de entender sistemas ajenos se ha quedado atrás, y es justo donde el trabajo humano es más caro. REA apunta a ese desequilibrio con una idea simple y bien ejecutada: el agente no sustituye al ingeniero de reverso, le quita de encima el trabajo de picar piedra.

Para quien construye producto, el caso de uso es directo: ver una función que funciona, entender por qué funciona y llevarla a tu proyecto con una implementación propia. Para quien audita, es una vía rápida a la evidencia. Y para quien aprende, es la diferencia entre leer un tutorial y abrir el archivo.

El repositorio, las guías y los casos completos están en rea.tools y en github.com/morluto/rea. Si lo pruebas con algo, merece la pena mandarles el caso: el proyecto pide ejemplos explícitamente.