Repositorio REA (Reverse Engineer Anything): cómo usarlo

REA —«Reverse Engineer Anything»— está de moda: un servidor MCP de código abierto que permite a un agente de IA desarmar binarios, apps de Electron y .NET, APK de Android, sitios web y procesos en ejecución, y que ahora mismo es uno de los repositorios con más estrellas de GitHub. El lema que circula es «el software ha muerto, larga vida al software». Es una herramienta realmente capaz. También exige tener claro para qué sirve.

PlayCISO no la creó: la recomendamos, con el enfoque que de verdad necesita un equipo de seguridad. La añadimos a la biblioteca Learn, en Offensive / Pentesting.

Qué hace realmente

REA (licencia MIT, se configura con npx rea-agents setup) conecta un agente como Claude Code o Codex con herramientas reales de ingeniería inversa y ejecuta el análisis en local:

• Binarios nativos mediante Ghidra, IDA o Hopper: pseudocódigo, ensamblador, símbolos y referencias cruzadas.
• Apps: JavaScript/Electron, ensamblados .NET y APK de Android, con módulos, importaciones y descompilación.
• Otros objetivos: sitios web, firmware, WASM, bytecode de EVM y comportamiento en tiempo de ejecución capturado con tus propios permisos.

Es decir, convierte «pasar un fin de semana en un desensamblador» en «pedírselo al agente». Esa es toda la historia, con lo bueno y lo malo.

La parte honesta: es de doble uso

La ingeniería inversa es una disciplina de seguridad legítima y esencial. Los analistas de malware viven en ella. Los investigadores de vulnerabilidades la necesitan. La interoperabilidad, la revisión de firmware y la diligencia debida sobre proveedores dependen de ella. Sobre objetivos que estás autorizado a analizar, REA es una mejora real para el kit de un blue team y de AppSec.

Pero su README también invita abiertamente a lo otro: ves una función en una app que no es tuya, haces que tu agente averigüe cómo está construida y la reconstruyes. Ahí es donde pasa de la investigación al riesgo de propiedad intelectual, licencias, DMCA y términos de servicio. El propio aviso del proyecto dice que es para uso legal y que obtener la autorización es cosa tuya, que es exactamente lo correcto y exactamente la parte que el entusiasmo se salta. Analiza lo que tienes permiso para analizar. Si estás reconstruyendo el producto de otra persona, esa conversación es con tu asesor legal, no con tu agente.

Lo que importa aunque nunca la ejecutes

Olvida si tú usas REA. Supón que tu adversario sí. La señal real es que desarmar software se ha vuelto barato y rápido para todo el mundo. Si tu seguridad dependía de que nadie se molestara en hacer ingeniería inversa de tu app, esa suposición ya no vale. En concreto:

• Nada de secretos en el cliente. Las claves de API, los tokens, los endpoints ocultos y las URL «privadas» incluidos en una app móvil, de escritorio o de Electron son, en la práctica, públicos. Trátalos como ya filtrados.
• Las comprobaciones del lado del cliente son pistas, no fronteras de confianza. Verificación de licencias, bloqueo de funciones, detección de jailbreak o root, anti-manipulación: fricción útil, nunca un control. Aplícalo en el servidor.
• La ofuscación compra tiempo, no seguridad. Encarece el análisis; frente a un agente, ese coste acaba de bajar.
• Tu superficie de ataque incluye tu binario. ¿Qué revela tu app publicada sobre tu backend, tu lógica y tus flujos de datos? Es buen momento para averiguarlo antes que otro.

Tres formas de usarla bien

1. Triaje de malware: desarma un binario sospechoso en un laboratorio aislado en lugar de ir a ciegas.
2. Audita tus propias apps: apúntala al software que tú publicas y mira qué revela.
3. Diligencia debida de proveedores y firmware: inspecciona lo que estás autorizado a inspeccionar antes de confiar en ello dentro de tu entorno.

Hagas lo que hagas, escribe primero la política: quién de tu equipo puede hacer ingeniería inversa con agentes, sobre qué objetivos y con qué autorización registrada. Esa única página marca la diferencia entre una capacidad afilada y un incidente.

Si esto te anima a revisar tu propia exposición: lleva el sistema al Threat Model Studio para ver a qué llegaría un atacante que lee tu cliente, ajusta los controles que lo protegen con la biblioteca de controles de seguridad y fija las reglas para las herramientas manejadas por agentes con el paquete de políticas de gobernanza de IA. En la biblioteca Learn hay más recursos gratuitos y revisados como REA.

REA es un proyecto de código abierto de terceros, creado por su autor (morluto), no por PlayCISO. Los detalles reflejan el repositorio en octubre de 2026; el número de estrellas y su posición en tendencias cambian rápido. Úsalo solo sobre objetivos que tengas autorización legal para analizar.