REA: ingeniería inversa con agentes de IA — guía completa
Seguro que te ha pasado: pruebas una app, te encuentras una funcionalidad brillantemente resuelta —un buscador rapidísimo, una animación perfecta, un algoritmo de recomendación— y piensas "cómo lo habrán hecho esto". Y entonces caes en la cuenta de que no tienes el código fuente. Es un binario, una app cerrada, una caja negra.
Antes no había otra: abrir un desensamblador y sudar horas entre CALLs y direcciones de memoria. Hoy hay una forma muy distinta de hacerlo: dejar que tu agente de IA haga el trabajo pesado con evidencia verificable. Se llama REA (Reverse Engineer Anything) y en este artículo te cuento qué es, cómo se instala y cómo lo he usado para destripar un Pac-Man de Windows del que no tengo ni una línea de código. Spoiler: funciona mejor de lo que esperaba.
¿Qué es REA?
REA (Reverse Engineer Anything) es un proyecto open source con una frase muy clara en su README: "One MCP for reverse engineering across binaries, applications, and runtime behavior". Un único servidor MCP (Model Context Protocol) que cubre la ingeniería inversa sobre binarios, aplicaciones y comportamiento en ejecución. También hay un CLI (rea) con los mismos flujos, para quien prefiera trabajar solo desde la terminal.
Traducción práctica: tu agente de IA —Claude Code, Cursor, OpenCode, el que uses— se conecta a REA vía MCP, inspecciona el objetivo que le indiques y devuelve hallazgos con evidencia, con sus propias limitaciones incluidas. Nada de respuestas mágicas: te muestra cómo llega a cada conclusión y qué parte del análisis tiene sombras.
¿Y qué puede morder? La lista es larguísima:
- Binarios nativos (PE, ELF...), con motores como Hopper, Ghidra o IDA.
- Apps JavaScript/Electron: solo análisis estático, con Node.js, sin motor nativo.
- Ensamblados .NET y APKs (vía JADX + JDK), además de WASM, EVM y BEAM.
- Código Go/Rust, imports de PE y certificados.
- Formatos exóticos: GGUF/safetensors (pesos de modelos de ML), IL2CPP de Unity, Godot PCK, CUDA/PTX, apps empaquetadas con PyInstaller, bases de datos SQLite.
- Comportamiento y tráfico: HAR/SAZ, pcaps, capturas de procesos.
- Incluso firmware, con Binwalk/Unblob.
Sobre el marco ético, REA va clara: uso lícito —investigación, educación, interoperabilidad, preservación de software y análisis de software que posees o tienes autorización para examinar—. El repo incluye un DISCLAIMER.md que deja ese marco bien clarito.
En ficha técnica: está escrito en TypeScript, con licencia MIT, versión actual 6.7.0 y es un proyecto claramente activo (creado en abril de 2026, con commits de octubre de 2026).
Instalación paso a paso
Requisitos
- Node.js: 22.x (>=22.23.4), 24.x (>=24.22.1) o 26.12.1+, además de npm.
- Un motor nativo (Hopper, Ghidra o IDA) solo si vas a analizar binarios nativos. El análisis de apps JavaScript/Electron y ensamblados .NET no lo necesita en absoluto.
- Ojo: el motor nativo de Ghidra en Windows es experimental.
Setup interactivo
npx rea-agents setup
El setup te pregunta qué agentes usas, te muestra los cambios que va a aplicar y espera tu aprobación: añade el servidor MCP de REA y las instrucciones de workflow, con backups de la configuración existente. Al terminar, reinicia el agente.
CLI global
npm install --global rea-agents
rea --help
Solo la skill
Si prefieres no tocar tu configuración global, puedes instalar únicamente la skill:
npx skills add morluto/rea --skill reverse-engineer-anything
Diagnóstico
¿Algo no rula? Comando de referencia:
rea doctor --json
Acepta varios flags para acotar el diagnóstico: --client, --provider y --skill.
Actualizar
rea update
npx rea-agents@latest setup
Nota para Windows
Si usas Claude Code local en Windows, registrar el MCP queda así:
claude mcp add --scope local rea -- cmd.exe /d /c npx -y rea-agents@6.7.0 mcp
¿Con qué agente se puede usar?
Clientes soportados: 24 en total. Los que requieren rea-agents@6.5.0+ son: droid (Factory Droid), dsh (DeepSeek Harness), kimi (Kimi Code), qoder (Qoder), trae (Trae), workbuddy (WorkBuddy) y zcode (ZCode). Principales:
| Cliente | Notas |
|---|---|
| Claude Code | Totalmente soportado |
| Claude Desktop | Soportado |
| OpenCode | Recibe la entrada mcp.rea en su config (v1 y v2) |
| Codex | Soportado |
| Cursor | Soportado |
| Gemini CLI | Soportado |
| Windsurf | Soportado |
| Devin | Soportado |
| Antigravity | Soportado |
| GitHub Copilot CLI | Soportado |
| Qwen Code | Soportado |
| VS Code | Soportado |
| Grok Build | Soportado |
| Droid, Kimi Code, Trae... | Requieren 6.5.0+; los demás completan los 24 |
Lo cómodo: el setup los configura automáticamente; raro será editar la config a mano.
Y para que veas el espíritu de la herramienta, este es el prompt de ejemplo que trae el propio README:
"Understand how search works in the Notes app, show me the evidence, and build a similar feature for my project."
Traducido: "Entiende cómo funciona la búsqueda en la app Notes, muéstrame la evidencia y construye una funcionalidad similar para mi proyecto." Es el escenario del principio del artículo: una feature que te gusta, un objetivo cerrado... y tu agente sacando el patrón del interior para replicarlo en tu propio código. Con evidencia, para que puedas auditar cada afirmación.
Ejemplo práctico: ingeniería inversa de un Pac-Man sin código fuente
Ahora la parte que de verdad me apetece contar. Tengo en D:\WorkSpace\C\pac-man\ un pacman.exe: un juego de Pac-Man para Windows. ¿El detalle? **No hay ni rastro del código fuente**. Ningún .c, ningún Makefile. Solo el ejecutable y sus assets:
| Archivo | Qué es |
|---|---|
pacman.bmp, Comida.bmp, enemigo.bmp, muerte.bmp, roca.bmp |
Sprites |
andando.wav, bolita.wav, inicio.wav, muerte.wav |
Sonidos |
allegro-mingw-4.2.2.zip |
Copia de la librería gráfica |
libgcc_s_dw2-1.dll |
Runtime de GCC/MinGW |
allegro.log |
Log de ejecución de Allegro |
Antes de abrir ni una herramienta, los propios ficheros ya dan pistas: el allegro.log confirma que el juego usa la librería gráfica clásica Allegro 4.2.2 y abre una ventana de 880×600 a 32 bits de color; y la presencia de libgcc_s_dw2-1.dll revela que se compiló con GCC/MinGW. Conclusión inmediata: es un ejecutable Win32 sin fuentes. Target ideal para REA.
Vamos por fases, como iría el flujo real con un agente.
Paso 1: sin nada instalado
No tengo ni Hopper, ni Ghidra, ni IDA en esta máquina. ¿Impasse? Nada de eso: pido al agente (con OpenCode, en mi caso) que use REA para inspeccionar el PE a nivel de imports y certificados — herramientas como inspect_pe_imports no necesitan motor nativo.
REA devolvería la estructura del binario y, entre los imports y las cadenas (strings), las referencias a Allegro 4.2.2 y al runtime de GCC que ya sospechábamos. Con eso, el agente ya puede razonar: "esto es un exe de 32 bits enlazado a Allegro, la lógica del juego vive dentro del propio exe". Sin pseudocódigo todavía, pero con evidencia firme de con qué está hecho y cómo viene empaquetado.
Paso 2: con Ghidra instalado (proveedor nativo)
Con Ghidra disponible como proveedor nativo, el flujo sube de nivel. Prompt al agente:
"Abre pacman.exe con REA, encuentra cómo se gestiona la comida (
Comida.bmp) y muéstrame la evidencia; luego crea un prototipo de ese sistema para un juego mío en Python."
El agente abre una sesión binaria contra el exe y ahora sí accede a pseudocódigo, símbolos y grafos de llamadas. El output de REA incluye todo lo necesario: pseudocódigo + evidencia + limitaciones (por ejemplo, "esta función podría ser el bucle de colisión, pero los nombres de símbolos son autogenerados por Ghidra"). A partir de ahí, el propio agente redacta el prototipo Python: cómo se carga el tile de la comida, cómo se detecta la colisión Pac-Man/bolita... todo derivado del análisis, no de la intuición del modelo. Ojo, eso es lo esperado según la documentación de REA; no es una transcripción literal de una ejecución.
Paso 3: terminal directo, sin agente
¿Y si solo quieres husmear desde la consola? El CLI cubre los mismos flujos que el MCP. rea --help lista los comandos disponibles, y el patrón del README para lanzar un análisis es:
npx -y rea-agents@latest <comando> <ruta> --json
Con el --json del final, un script puede encadenar la salida y guardarla para después: útil para documentar hallazgos.
¿Y ahora qué?
Con lo aprendido, las opciones se abren: recrear la mecánica de los "sustos" (los fantasmas azules huyen cuando comes la píldora grande), imitar el comportamiento distintivo de cada fantasma o replicar la gestión de la puntuación por bolitas. Eso sí, siempre dentro del marco lícito del DISCLAIMER.md: análisis de software propio con propósito educativo, sin distribución del original ni de sus assets. Se trata de entender cómo funciona por dentro y llevar esas lecciones a tus propias creaciones.
Conclusión
REA no es una caja negra con humo de "IA mágica": es un servidor MCP que convierte la ingeniería inversa —territorio histórico de expertos con desensambladores de pago— en un flujo accesible para cualquiera que sepa escribir un prompt. Instalación en minutos, cobertura de formatos brutal y transparencia total en los resultados: evidencia, pseudocódigo y limitaciones claras, sin fingir certezas donde solo hay hipótesis. Y el marco ético queda explícito desde el propio repo: aprender, auditar, interoperar y preservar; nunca piratear.
Si quieres probarlo, el quick start no puede ser más simple:
npx rea-agents setup
Enlaces de referencia:
- Repo: github.com/morluto/rea
- Web oficial: rea.tools
- Showcases oficiales (con los casos DX-Ball, Notion y TH04, la reconstrucción de un shooter de PC-98): rea.tools/showcase/
- Comunidad: Discord de REA
¿Y a ti? ¿Qué binario, app o juego antiguo tienes por ahí esperando a ser destripado? Yo ya tengo mi Pac-Man por delante. Cuéntame cuál es el tuyo.