REA: ingeniería inversa con tu agente de código, probada con Ghidra y Electron

REA (Reverse Engineer Anything) es un servidor del Model Context Protocol (MCP) y una interfaz de línea de comandos (CLI) que dan a tu agente de código herramientas de ingeniería inversa: decompilar binarios con Ghidra, Hopper o IDA, reconstruir apps Electron, leer ensamblados .NET y observar webs. Se instala con el paquete de npm rea-agents, tiene licencia MIT y lo mantiene la cuenta de GitHub morluto. Lo probé el 18 de octubre de 2026 en un contenedor Docker arm64 con rea-agents 6.7.0, Node.js 24.21.0 y Ghidra 12.1.4. Aquí está lo que funcionó, lo que pesa y lo que conviene revisar antes de dejarlo tocar la configuración de tus agentes. También tienes la versión en inglés.

Puntos clave

• rea-agents 6.7.0 expone 207 herramientas MCP y 6 prompts, y su CLI tiene 153 órdenes. La lista de herramientas ocupa 3 158 352 bytes en JSON; con el perfil compacto baja a 219 211.
• El análisis estático de la app Electron Hyper 3.4.1 (un app.asar de 14 MB) recorrió 2236 archivos, encontró 18 canales de comunicación entre procesos (IPC) y 6 complementos nativos, y generó una evidencia JSON de 253 MB.
• Con Ghidra 12.1.4 decompiló un binario C despojado de símbolos y recuperó la lógica de validación con sus constantes: 31, 9973 y 4242.
• En Linux arm64, el ZIP oficial de Ghidra no trae el decompilador nativo: hay que compilarlo con gradlew buildNatives.
• rea setup reescribe la configuración de tus agentes con copia de seguridad, y rea uninstall la revierte. Pruébalo primero con un HOME falso.
• El paquete de npm se publica desde GitHub Actions con procedencia SLSA, y npm audit signatures lo verifica.

Qué es REA y qué analiza

REA es una capa de herramientas, no un modelo. Su setup sabe configurar 24 clientes, entre ellos Claude Code, Codex, Cursor y Gemini CLI. Tu agente llama a REA por MCP, y REA ejecuta el análisis en tu máquina y devuelve resultados con su evidencia y sus límites. Si el protocolo te suena nuevo, empieza por la guía de MCP en 2026.

Según el README del proyecto^[1], cubre estos tipos de objetivo:

• Binarios nativos: pseudocódigo, ensamblador, cadenas, símbolos y referencias, con Hopper, Ghidra o IDA como motor
• JavaScript y Electron: módulos, importaciones, mapas de código fuente, canales IPC y complementos nativos, sin motor externo
• Ensamblados .NET: metadatos e instrucciones del lenguaje intermedio común (CIL), sin cargar el ensamblado
• Webs: estructura, scripts y tráfico observado, con un navegador de la familia Chrome
• APK de Android: clases y métodos decompilados con JADX, más otras 15 familias (Go, Rust, WASM, SQLite, firmware, capturas de red)

El análisis estático de JavaScript y .NET lee los archivos sin ejecutarlos. La captura en tiempo de ejecución sí ejecuta el objetivo con tus permisos, y la documentación lo marca en cada guía.

Quién lo mantiene y cuánta tracción tiene

El repositorio morluto/rea se creó el 14 de abril de 2026 y pertenece a una cuenta personal de GitHub. El paquete rea-agents apareció en npm el 12 de julio de 2026 y suma 33 versiones; la 6.7.0 salió el 18 de octubre a las 08:12 UTC. Antes se publicó como @morluto/rea, cuya versión 0.2.1 se describía como automatización "for Hopper Disassembler".

Las cifras de popularidad son poco habituales. La API de GitHub devolvía 314 700 estrellas, 79 773 forks y 1213 incidencias abiertas el 18 de octubre de 2026 a las 11:28 UTC. La API de descargas de npm daba 307 234 descargas de rea-agents en la semana del 10 al 16 de octubre y 346 782 en los 30 días previos. No las interpreto: son lo que devolvieron las dos API ese día.

Cómo instalarlo sin tocar tu configuración real

Instálalo dentro de un contenedor con su propio HOME, porque setup y update reescriben archivos de configuración de agentes. Necesitas Node.js 22.19 o posterior, 24.11 o posterior, o 26. En Linux, REA exige además el ps de procps para comprobar a quién pertenece cada proceso que lanza, y la imagen node:24-slim no lo trae:

docker run -d --name rea-lab -e HOME=/home/lab -w /home/lab \
  node:24-slim sleep infinity
docker exec rea-lab bash -c 'apt-get update -qq && \
  apt-get install -y -qq procps curl jq'
docker exec rea-lab npm install --global rea-agents@6.7.0
docker exec rea-lab rea --version

La orden imprime 6.7.0. El paquete instalado ocupa 222 MB con sus 158 dependencias, porque incluye Playwright, un emulador de terminal y los SDK de MCP. rea doctor lista lo que falta: en un contenedor limpio, todos los motores nativos (Hopper, Ghidra, IDA, JADX, Kuna) aparecen como missing_analysis_engine, y el análisis de JavaScript funciona igual.

Cómo analizar una app Electron sin ejecutarla

analyze-javascript-application lee un app.asar (el archivo en el que Electron empaqueta el código de la app) o una carpeta extraída y reconstruye su grafo de módulos. Lo probé con Hyper^[2] 3.4.1, el terminal de Vercel con licencia MIT, descargando su .deb para arm64 dentro del contenedor:

cd /home/lab && mkdir targets && cd targets
curl -sSLO https://github.com/vercel/hyper/releases/download/\
v3.4.1/hyper_3.4.1_arm64.deb
dpkg-deb -x hyper_3.4.1_arm64.deb hyper
rea analyze-javascript-application \
  /home/lab/targets/hyper/opt/Hyper/resources/app.asar \
  --format json > /home/lab/hyper.json

La orden terminó con código 0 en 4 minutos, con una carga media del sistema por debajo de 3 durante la medición. El resultado es un JSON de 253 MB: un grafo con 10 552 nodos y 14 909 relaciones, de las que 4853 son importaciones y 15 son envíos IPC. Entre los hallazgos:

• 18 nodos de canal IPC y 5 manejadores, como electron-store-get-data en el proceso principal
• 14 operaciones IPC con nombre de canal dinámico que REA deja sin resolver en vez de adivinarlas
• 6 complementos nativos, entre ellos node-pty/bin/linux-x64-107/node-pty.node y tres binarios win32 de native-reg dentro de un paquete para Linux arm64

El resultado también es honesto con sus huecos. Hay 1994 archivos, casi todos en node_modules, con la marca resource_constraint, porque sus relaciones expandidas no cabían en el límite de memoria. La evidencia lo declara en lugar de omitirlos.

Cómo resumir una evidencia de 253 MB

Un agente no puede leer 253 MB de contexto, así que REA proyecta vistas sobre la evidencia guardada. La guía de la CLI^[3] propone envolverla con jq y pedir la vista summary:

jq -c '{source: {kind: "inline", evidence: .},
        view: {kind: "summary"}}' hyper.json > hyper-view.json
rea inspect-analysis-view hyper-view.json --format json \
  > hyper-summary.json

El resumen ocupa 22 843 bytes: una ventana, 22 operaciones IPC, 7 canales literales y ningún script de precarga. Esa es la pieza que pasarías al agente.

Qué fusibles de Electron tiene activados

inspect-electron-fuses lee los "fusibles" que Electron graba en el ejecutable, sin lanzarlo. En el binario hyper de 147 MB, RunAsNode, EnableNodeOptionsEnvironmentVariable y EnableNodeCliInspectArguments estaban activados, y EnableEmbeddedAsarIntegrityValidation y OnlyLoadAppFromAsar desactivados. Es un dato útil para auditar una app: con RunAsNode activo, el ejecutable acepta funcionar como un Node.js normal.

Cómo decompilar un binario nativo con Ghidra en Linux arm64

REA acepta Ghidra 12.1.x con un kit de desarrollo de Java (JDK) 21 o posterior. En arm64 hay un paso previo que la documentación avisa: el ZIP oficial de Ghidra 12.1.4 (570 MB) trae el decompilador nativo para linux_x86_64 y win_x86_64, pero no para linux_arm_64. Lo compilé con el Gradle que incluye la propia distribución, después de instalar gcc, g++, make, bison y flex y un JDK 21 de Temurin:

export JAVA_HOME=/opt/jdk21 PATH=/opt/jdk21/bin:$PATH
cd /opt/ghidra_12.1.4_PUBLIC/support/gradle
./gradlew buildNatives
export GHIDRA_INSTALL_DIR=/opt/ghidra_12.1.4_PUBLIC
rea doctor | grep -A3 ghidra-native_decompiler

La compilación acabó con BUILD SUCCESSFUL y rea doctor pasó a verde: "decompile reports elf arm64, which matches linux/arm64". Como objetivo compilé un programa C de 17 líneas que valida una clave con una suma de comprobación, y le quité los símbolos con strip. El binario resultante pesa 67 616 bytes. Después pedí a REA que buscara una cadena y siguiera sus referencias:

rea trace licencia.stripped "clave valida" --provider ghidra \
  --format json | jq -c '.normalized_result.references[0]'
rea decompile licencia.stripped 0x1007d4 --provider ghidra \
  --format json

trace encontró la cadena en 0x1008c8, referenciada desde 0x100880 dentro de la función FUN_001007d4 de 192 bytes. decompile devolvió este pseudocódigo:

    iVar4 = 7;
    for (; __s != pbVar1; __s = __s + 1) {
      iVar4 = (int)(iVar4 * 0x1f + (uint)*__s) % 0x26f5;
    }
    if (iVar4 == 0x1092) {
      puts("clave valida");
      uVar3 = 0;
    }

Las constantes son las de mi código fuente: 0x1f es 31, 0x26f5 es 9973 y 0x1092 es 4242, con la función auxiliar ya integrada en main por el compilador. Cada orden de la línea de comandos es un proceso nuevo que importa el binario en un proyecto temporal de Ghidra y lo borra al cerrar. Para encadenar consultas, usa --snapshot o el servidor MCP, que mantiene la sesión abierta.

Qué herramientas expone el servidor MCP

El servidor se arranca con rea mcp y habla MCP por la entrada y salida estándar. Lo interrogué con un cliente mínimo de 25 líneas en Node.js que envía initialize y pagina tools/list. Respondió como rea 6.7.0, con protocolo 2025-06-18, 207 herramientas y 6 prompts: investigate_feature, compare_application_versions, verify_reconstruction, trace_crash, audit_residual_unknowns y prepare_bounded_process_capture.

Las herramientas se agrupan por familia:

• Sesión nativa: open_binary, close_binary, procedure_pseudo_code, procedure_callers, xrefs, search_strings, batch_decompile, get_call_graph
• Flujos de alto nivel: binary_overview, analyze_function, trace_feature, trace_call_path
• JavaScript y Electron: analyze_javascript_application, trace_application_feature, inspect_electron_fuses, capture_electron_scenario
• Web: inspect_web_page, analyze_web_bundle, capture_browser_scenario
• Android y depuración: 26 herramientas adb, sesiones de Frida, GDB y Rizin

El catálogo pesa, y eso tiene coste de contexto en cada sesión del agente. La documentación de contratos MCP recoge que kimi-cli rechazaba peticiones con el catálogo completo y ofrece dos variables: REA_MCP_INPUT_SCHEMA_PROFILE=compact y REA_MCP_OUTPUT_SCHEMA_PROFILE=off. Con las dos, el mismo tools/list pasó de 3,16 MB a 0,22 MB:

Qué cambia rea setup en la configuración de tus agentes

rea setup registra el servidor MCP en los agentes que elijas e instala una skill de investigación. Lo ejecuté en el contenedor contra un HOME falso con un ~/.claude.json y un ~/.codex/config.toml mínimos. Primero con --dry-run, que solo devuelve el plan:

export HOME=/home/fake
rea setup --client claude_code --client codex --dry-run --format json
rea setup --client claude_code --client codex --yes --format json

El plan anunciaba cuatro acciones, y la ejecución hizo exactamente eso:

• ~/.claude.json: añade "rea": {"command": "/usr/local/bin/rea", "args": ["mcp"]} en mcpServers, conserva la entrada que ya había y reformatea el archivo con sangría
• ~/.codex/config.toml: añade una tabla [mcp_servers.rea] con startup_timeout_sec = 30 y tool_timeout_sec = 450
• Copias de seguridad: deja .claude.json.rea.backup y config.toml.rea.backup junto a cada archivo
• Skill: copia reverse-engineer-anything (88 KB, 7 archivos) en ~/.agents/skills/ y en ~/.claude/skills/

rea uninstall sin opciones quitó los dos registros y la skill, y dejó además una copia .recovery del estado anterior. Si usas Claude Code a diario, revisa antes qué servidores MCP tienes ya registrados en tu editor, porque el setup añade uno con 207 herramientas.

Cómo verificar que el paquete es el oficial

El README avisa de copias: "A similar repository name or copied README does not establish that a download is official". Las fuentes oficiales son tres: el repositorio morluto/rea, la web rea.tools y el paquete de npm rea-agents. El paquete se publica desde GitHub Actions con un editor de confianza OIDC y una atestación de procedencia SLSA (Supply-chain Levels for Software Artifacts), y npm comprueba ambas:

mkdir verify && cd verify && npm init -y
npm install --ignore-scripts rea-agents@6.7.0
npm audit signatures

La salida fue "174 packages have verified registry signatures" y "36 packages have verified attestations". La atestación de rea-agents@6.7.0 apunta al flujo .github/workflows/release.yml del repositorio https://github.com/morluto/rea, rama release/6.7.0. Fija además la versión exacta en el registro MCP de tu agente en lugar de @latest: es la defensa contra los ataques a la cadena de suministro que llegan con una actualización. El paquete no declara scripts postinstall.

El propio proyecto marca el límite de su aislamiento. Lo dice su política de seguridad^[4]: "This is not a sandbox and does not protect against malicious processes already running as the same operating-system user." Abrir un binario no fiable delega su análisis en Ghidra o Hopper con tus permisos, así que hazlo en un contenedor o una máquina virtual, como harías con cualquier agente con acceso a herramientas.

Qué permite la ley sobre ingeniería inversa en la UE

Decompilar un programa no es ilegal por sí mismo en la Unión Europea, pero tiene condiciones. La Directiva 2009/24/CE^[5] fija dos excepciones que no necesitan permiso del titular:

• Artículo 5.3: quien tiene derecho a usar una copia puede "observe, study or test the functioning of the program in order to determine the ideas and principles" mientras la carga, ejecuta o almacena
• Artículo 6: puede reproducir y traducir el código cuando sea "indispensable to obtain the information necessary to achieve the interoperability of an independently created" programa, limitado a las partes necesarias

El artículo 6.2 prohíbe usar lo obtenido para otro fin o para crear un programa que copie la expresión del original. El artículo 8 declara nulas las cláusulas de licencia contrarias a esas excepciones. En España, la Ley de Propiedad Intelectual^[6] las recoge en su artículo 100, apartados 3, 5 y 6. Con un acuerdo de licencia de usuario final (EULA) que prohíba decompilar, la interoperabilidad sigue amparada en la UE; el resto de usos queda a lo que diga la licencia.

REA asume esa línea en su DISCLAIMER.md: el proyecto no ayuda a eludir protecciones anticopia (DRM), comprobaciones de licencia ni sistemas antitrampas, y exige licencias legítimas de IDA Pro, Hopper o JEB.

Cómo se compara con GhidraMCP, IDA Pro MCP y radare2-mcp

REA no es el primer puente entre un desensamblador y un agente; lo que cambia es el alcance. Los otros tres proyectos conectan un único motor y REA orquesta seis motores con un contrato de evidencia común:

Si solo decompilas binarios y ya vives en IDA o Ghidra, un puente de un solo motor añade menos superficie. REA compensa cuando la pregunta cruza capas, como seguir una función de una app Electron desde el renderer hasta un complemento nativo.

Preguntas frecuentes

¿REA sube mis binarios a algún servidor?

No. El análisis corre en tu máquina, según el README. Lo que sí sale de ella es lo que REA devuelve a tu agente, que lo envía a su proveedor de modelos con su propia política de datos.

¿Necesito Hopper, Ghidra o IDA?

Solo para binarios nativos. El análisis de JavaScript, Electron y .NET funcionó en mi prueba sin ningún motor. Para Ghidra en Linux arm64, cuenta con compilar el decompilador nativo.

¿Es legal usar REA con una app comercial?

Depende del uso y de tu jurisdicción. En la UE puedes estudiar su funcionamiento y decompilar lo necesario para la interoperabilidad aunque la licencia diga lo contrario; copiar su código o saltarte una protección no está cubierto.

Conclusión

REA cumple lo que promete en las dos partes que probé. Reconstruyó la estructura de una app Electron real sin ejecutarla y, con Ghidra, devolvió las constantes exactas de un binario sin símbolos. A cambio, pesa 222 MB, añade 207 herramientas al contexto de tu agente y saca una versión casi cada día. Si quieres probarlo, hazlo como aquí: en un contenedor, con la versión fijada, npm audit signatures antes de instalar y un --dry-run antes de dejar que setup toque tu configuración.

Fuentes: [1] Repositorio morluto/rea en GitHub^[1], [2] Instalación y setup de REA^[10], [3] Contratos MCP de REA^[11], [4] Política de seguridad de REA^[4], [5] rea-agents en npm^[12], [6] Casos de estudio en rea.tools^[13], [7] Directiva 2009/24/CE en EUR-Lex^[5], [8] Ley de Propiedad Intelectual en el BOE^[6], [9] Ghidra 12.1.4 en GitHub^[14].

Fuentes

1. README del proyecto
2. Hyper
3. guía de la CLI
4. política de seguridad
5. Directiva 2009/24/CE
6. Ley de Propiedad Intelectual
7. GhidraMCP
8. IDA Pro MCP
9. radare2-mcp
10. Instalación y setup de REA
11. Contratos MCP de REA
12. rea-agents en npm
13. Casos de estudio en rea.tools
14. Ghidra 12.1.4 en GitHub