Reverse Engineer Anything (REA) conecta un agente de programación con IA a herramientas que inspeccionan software compilado, aplicaciones empaquetadas y el comportamiento del navegador. Expone esas herramientas mediante el Model Context Protocol (MCP) y una interfaz de línea de comandos. El resultado útil es una explicación respaldada por pruebas: ubicaciones en el código, relaciones, observaciones y lagunas explícitas. No promete recuperar un repositorio completo con el código fuente original. Proyecto oficial
Para mí, la pregunta más útil sobre REA es concreta: ¿puede explicar cómo funciona una característica con suficiente detalle para orientar una implementación o diagnosticar un cambio? Esta guía aborda ese proceso, las decisiones de configuración y cómo interpretar los resultados sin confundir una explicación plausible con una verificada.
Lo que aprenderás:
- Dónde encaja REA entre un agente de programación y los motores de análisis.
- Qué tipos de aplicaciones necesitan herramientas adicionales.
- Cómo configurarlo y diagnosticar una conexión ausente.
- Cómo delimitar una investigación y evaluar sus pruebas.
- Qué no puede determinar REA a partir de un artefacto local por sí solo.
Nota sobre la investigación: Documentación y metadatos del paquete consultados el 17 de octubre de 2026. Esta guía se basa en investigación documental; no es una evaluación práctica de rendimiento. Los comandos de configuración que aparecen a continuación se contrastaron con la documentación, pero no se ejecutaron para este artículo.
¿Qué es Reverse Engineer Anything?
REA es una capa de análisis que proporciona a un agente medios concretos para investigar software. El agente elige una pregunta, REA realiza la inspección correspondiente y el agente interpreta los hallazgos. Una investigación de código nativo puede utilizar un descompilador instalado; una de Electron puede empezar por el JavaScript empaquetado. El mismo proyecto también ofrece flujos de trabajo desde la terminal. Presentación de REA
Esta división importa al evaluar los resultados. El modelo redacta la explicación, mientras que las herramientas subyacentes aportan las observaciones. Una respuesta fluida sigue necesitando ubicaciones que la respalden y una declaración clara de qué se inspeccionó realmente.
Si aún no conoces el protocolo, mi guía para crear un servidor MCP con Python explica cómo un agente llama a las herramientas de un servidor. REA es una aplicación concreta de esa arquitectura.
¿Qué puede analizar REA?
Elige la vía de análisis según el artefacto que tengas. La extensión de un archivo no basta para determinar qué detalles de la implementación se pueden recuperar.
| Objetivo | Hallazgos útiles | Requisito o límite principal |
|---|---|---|
| Ejecutable o biblioteca nativa | Ensamblador, pseudocódigo, cadenas, funciones y referencias | Un proveedor de análisis nativo adecuado, como Ghidra, Hopper o IDA |
| Paquete de JavaScript o Electron | Módulos, importaciones, rutas y relaciones IPC | El análisis estático puede funcionar sin un descompilador nativo |
| Ensamblado administrado de .NET | Metadatos, instrucciones CIL y declaraciones P/Invoke | La inspección estática no ejecuta el ensamblado |
| Página del navegador | DOM, información de scripts y observaciones acotadas de red | Un navegador de la familia Chrome que pertenezca al usuario y esté expuesto mediante CDP |
| APK de Android | Manifiesto, clases, métodos descompilados y referencias | Los requisitos previos documentados de JADX y JDK |
Estas vías tienen distintos alcances. La guía de investigación de código nativo, la guía de flujos de trabajo de JavaScript, la referencia de código administrado, la referencia del navegador y la guía de Android describen sus límites.
Por ejemplo, poder inspeccionar metadatos de .NET e instrucciones CIL no significa que puedas tratar un ejecutable NativeAOT como un ensamblado administrado normal. Del mismo modo, observar las solicitudes de un navegador puede revelar el comportamiento visible desde el cliente, pero no los detalles de implementación del servidor que no se distribuyen con la aplicación.
Cómo instalar REA para un agente de programación
Empieza por Node.js y npm. La versión publicada el 14 de octubre y los metadatos del paquete consultados para este artículo indican REA 6.5.0, compatible con Node 22.19+ dentro de la rama 22.x, 24.11+ dentro de la rama 24.x, o 26+. Consulta los metadatos del paquete publicado cuando lo instales; la versión más reciente puede cambiar.
Para una configuración reproducible de Codex, primero consulta una vista previa de los cambios:
npx -y rea-agents@6.5.0 setup --client codex --dry-run --json
Después, ejecuta la configuración interactiva:
npx -y rea-agents@6.5.0 setup --client codex
Revisa la configuración propuesta y las ubicaciones de destino de las habilidades, aprueba los cambios que quieras y reinicia el agente. La opción -y acepta la solicitud de npm para descargar el paquete; no sustituye la aprobación de configuración de REA. La guía de instalación explica las copias de seguridad y los clientes compatibles.
Instalar únicamente la habilidad aporta instrucciones. No registra el servidor MCP ni pone a disposición los motores de análisis. Si faltan herramientas, inspecciona el registro:
npx -y rea-agents@6.5.0 doctor --client codex --json
Un registro correcto no demuestra que la sesión actual del agente se haya conectado satisfactoriamente. Reiníciala o vuelve a conectarla y comprueba que las herramientas de REA estén disponibles. El contrato de MCP distingue las comprobaciones de registro de la identidad del servidor en funcionamiento.
Los proveedores de análisis nativo requieren una decisión aparte. La configuración puede ayudarte a instalar Hopper de forma opcional y con tu aprobación; otros motores tienen sus propios requisitos. La compatibilidad del sistema anfitrión también varía según la operación. En Linux, la vía documentada para JavaScript y Electron necesita un ps compatible con procps para comprobar a quién pertenecen los procesos. Sigue la matriz de instalación de la vía que elijas. En particular, la integración documentada de Ghidra para Windows x64 es experimental y de solo lectura; la instalación de Hopper está orientada a los entornos macOS y Linux compatibles. No des por hecho que los flujos de análisis nativo sean equivalentes entre sistemas operativos. Límites de Ghidra en Windows
También puedes usar la CLI sin registrar un agente. Guarda los resultados JSON completos cuando otros comandos posteriores los necesiten: cada invocación de la CLI es un proceso independiente, mientras que MCP puede conservar pruebas para consultas posteriores dentro de una conexión. Un identificador de pruebas de otra conexión no es un resultado portable. Guía de CLI y Evidence
Un flujo práctico de investigación con REA
Yo empezaría por un comportamiento observable y un criterio claro para detenerme. «Explica cómo exporta un documento esta aplicación» es más fácil de verificar que una petición abierta de reconstruirlo todo.
1. Define el artefacto y la pregunta
Registra la versión de la aplicación, el paquete o ejecutable exacto y la característica que quieres investigar. Mantén separados los hallazgos de distintas compilaciones. Escribe qué considerarías una respuesta útil: quizá el formato de serialización, el manejador que recibe un evento o la función que transforma un valor.
Para un paquete de Electron ya seleccionado y que tienes autorización para analizar, este sería un ejemplo de instrucción para el agente:
Usa REA para investigar la función del portapapeles en el paquete local seleccionado. Sigue la API expuesta a través de preload e IPC hasta el manejador del proceso principal. Cita las ubicaciones del código, distingue las observaciones de las inferencias y enumera los pasos sin resolver. Redacta una explicación antes de proponer una implementación.
Es un ejemplo de flujo de trabajo, no el informe de una investigación realizada aquí.
2. Sigue una característica a través de las pruebas disponibles
En las aplicaciones JavaScript, REA puede rastrear relaciones a partir de puntos iniciales como un módulo, una API, una cadena o un canal IPC. Sigue esas relaciones e inspecciona el código relevante. Un nombre coincidente es un punto de partida útil, pero no demuestra por sí solo un comportamiento. La documentación del flujo de trabajo de JavaScript describe cómo los rastreos conservan las observaciones estáticas, las inferencias y las incógnitas.
El caso de estudio del portapapeles de Notion publicado por el proyecto ilustra este enfoque. Conecta una API del portapapeles accesible desde la página, a través de envoltorios de preload y un canal IPC, con un componente del proceso principal que escribe en el portapapeles y comprueba el remitente. El ejemplo publicado identifica Notion Desktop 7.6.1, analizado con REA 4.1.0, y distingue la lectura del paquete de las pruebas guardadas de los módulos. Es una demostración del proyecto, no un resultado que yo haya reproducido.
3. Separa observaciones, inferencias e incógnitas
Durante la investigación, yo mantendría una tabla breve de hallazgos:
| Categoría del hallazgo | Afirmación de ejemplo | Siguiente paso |
|---|---|---|
| Observación | Hay un manejador registrado para un canal IPC concreto | Conserva su ubicación exacta en el código |
| Inferencia | El manejador parece atender el comando de copiar | Comprueba quién lo llama y el flujo de argumentos |
| Incógnita | No se resolvió un manejador seleccionado dinámicamente | Indica explícitamente qué pruebas faltan |
Los contratos de resultados de REA conservan la identidad de las pruebas y la información sobre la cobertura. Un resultado vacío con una cobertura incompleta no permite establecer que un comportamiento esté ausente. Esta distinción es especialmente importante al comparar versiones. Contratos de Evidence
4. Verifica el comportamiento antes de confiar en una reconstrucción
Un recorrido estático establece relaciones en el código inspeccionado. Para afirmar qué sucede durante una interacción, necesitas pruebas adecuadas obtenidas en tiempo de ejecución para esa interacción.
La observación del navegador puede recopilar pruebas acotadas de una página existente, incluidos metadatos de scripts y de red. Su capacidad de observación pasiva se limita a la página seleccionada y al intervalo de observación. No debes presentar una captura como si fuera el historial completo de la aplicación. Guía de observación del navegador
Para una reconstrucción, yo convertiría cada comportamiento respaldado por pruebas en una comprobación de aceptación: la salida esperada para una entrada conocida, el tratamiento de entradas malformadas y los casos límite importantes. Prueba la implementación con esas comprobaciones. Es una recomendación de ingeniería, no una afirmación de que REA verifica automáticamente toda una aplicación reconstruida.
Limitaciones relevantes en proyectos reales
El resultado descompilado es una interpretación del artefacto distribuido. Las herramientas de código nativo pueden mostrar instrucciones y pseudocódigo, pero eso no reconstruye los comentarios originales, la organización del proyecto ni su historial de desarrollo. Inspecciona las funciones relevantes y mantén las limitaciones del proveedor junto a las conclusiones. Análisis de código nativo
Las herramientas disponibles dependen de la versión instalada y del entorno. La rama main del repositorio puede describir trabajo posterior al paquete publicado. Usa los esquemas de herramientas y la información de disponibilidad del servidor instalado. Fijar una versión del paquete mejora la reproducibilidad; no garantiza que todos los ejemplos de la documentación actual se apliquen sin cambios.
El análisis local no significa que todos los resultados permanezcan en tu equipo. REA indica que el análisis del objetivo se ejecuta localmente, mientras que el agente recibe los resultados de las herramientas. Por tanto, las prácticas de tratamiento de datos de tu proveedor del modelo siguen siendo relevantes. Preguntas frecuentes del proyecto
El alcance determina el coste de la investigación. Cabe esperar que repetir inspecciones amplias consuma más tiempo y contexto del agente que hacer consultas posteriores bien enfocadas. Conserva los resultados útiles e investiga las lagunas que afecten a tu pregunta. Si diseñas tú mismo ese bucle del agente, LangChain frente a LangGraph explica las decisiones de flujo de control detrás de las bifurcaciones y el estado persistente.
Cuándo usaría REA
REA resulta útil cuando la respuesta depende del comportamiento del software distribuido o de un artefacto cuyo código fuente original no está disponible: investigar la compatibilidad, comprender un componente heredado o explicar un cambio entre compilaciones. Con un repositorio de código fuente completo, normalmente empezaría por leer el código y ejecutar sus pruebas.
El código desarrollado por REA tiene licencia MIT, pero los motores de análisis comerciales mantienen sus propios requisitos de licencia. El proyecto incluye la investigación autorizada, la interoperabilidad y la preservación del software entre sus usos previstos. Licencia y orientaciones del proyecto
Para una primera investigación, elige una característica pequeña, identifica el artefacto exacto y pide una explicación respaldada por pruebas. El criterio de éxito es un recorrido que puedas inspeccionar y una conclusión cuyos límites comprendas. Esa es una base útil para implementar software, incluso cuando queden preguntas abiertas.
Fuentes
- Repositorio oficial y preguntas frecuentes de REA
- Presentación y guías de REA
- Versión REA 6.5.0
- Guía de CLI y Evidence
- Límites de Ghidra en Windows
- Metadatos del paquete publicado en npm
- Instalación y configuración
- MCP en ejecución y contratos de Evidence
- Flujos de trabajo para aplicaciones JavaScript
- Investigación de binarios nativos
- Análisis de código administrado
- Observación del navegador
- Análisis de Android
- Caso de estudio del portapapeles de Notion
