Un agente de código ya puede abrir el ensamblador de la calculadora de Windows, encontrar el salto que distingue sumar un 10% de multiplicarlo, y explicarte en español por qué 200 + 10% da 220. Eso es lo que hace REA, una herramienta que conecta a Claude Code, Cursor y otros agentes con el stack clásico de la ingeniería inversa con agentes: decompiladores, debuggers y volcados de memoria.
El proyecto, publicado en rea.tools, automatiza el trabajo que antes exigía horas con un debugger: decodificar ramas, rastrear llamadas y reconstruir la regla detrás de un programa. Lo interesante no es el truco puntual de la calculadora. El mismo flujo sirve para auditar un juego, un firmware o una librería de la que no tenés el código fuente.
TL;DR
- REA conecta Claude Code, Cursor y otros agentes a decompiladores y debuggers para analizar binarios en vivo.- npx rea-agents@latest setup instala la conexión y pide aprobar un plan antes de tocar archivos.- La calculadora de Windows muestra la regla real detrás de 200 + 10% = 220 leyendo su ensamblador x64.- El juego del dinosaurio de Chrome revela su aceleración exacta: de velocidad 6 sube a 13 en pasos de 0.001.- Ghidra, Frida y Binary Ninja siguen siendo necesarios: REA traduce sus datos a lenguaje natural, no los reemplaza.
¿Qué es REA?
REA es una herramienta de código abierto que conecta agentes de código, como Claude Code o Cursor, con las piezas clásicas de la ingeniería inversa con agentes: decompiladores, debuggers y volcados de memoria, para que el modelo explique, modifique o reconstruya una función de un programa sin que la persona lea ensamblador a mano.
A diferencia de un plugin para Ghidra o un script de Frida que corre análisis automático, REA no interpreta el binario por su cuenta. Le entrega al agente los mismos datos que usaría un analista humano (instrucciones de la CPU, código decompilado, llamadas a funciones, valores en memoria) y deja que el modelo razone sobre ellos en lenguaje natural. El resultado se parece más a tener un asistente que lee el desensamblado por vos y te cuenta qué encontró, que a una caja negra que escupe respuestas.
Se instala en el agente que ya usás, no reemplaza ninguna herramienta: se suma como una capa que le da ojos sobre programas compilados, procesos corriendo o scripts cargados en una página web.
Ghidra, publicado por la NSA en 2019, es uno de los decompiladores con los que REA puede trabajar.
Por qué importa el análisis de binarios con agentes
Durante décadas, entender un programa sin su código fuente exigió años de práctica con un desensamblador. La ingeniería inversa con agentes no borra esa curva de aprendizaje, pero la achica: alguien que nunca abrió x64dbg puede pedirle a su agente que traduzca el ensamblador a una hipótesis verificable, y dedicarse a revisar esa hipótesis en lugar de construirla desde cero.
El mismo principio aplica a software sin documentación: videojuegos abandonados que alguien quiere preservar, drivers sin manual, protocolos de red cerrados o malware que hay que entender antes de poder bloquearlo. En todos esos casos el código fuente no existe o no es accesible, y la única vía es examinar el binario tal cual corre.
📌 Nota: analizar software sin autorización del dueño o fuera de los límites legales de tu jurisdicción (excepciones de interoperabilidad, investigación de seguridad autorizada, software propio) puede tener consecuencias legales. REA no cambia esa regla.
Hay un trasfondo más amplio: los agentes de código ya leen y escriben archivos, navegan la web y ejecutan comandos. Darles acceso a procesos en ejecución y a decompiladores es el siguiente paso lógico de esa misma tendencia, no una categoría aparte.
Cómo funciona la ingeniería inversa con agentes en REA
REA actúa como un puente entre el agente y el programa objetivo. Cuando le pedís que inspeccione algo, REA se conecta al binario, al proceso en memoria o a la página web (vía una conexión de depuración local), extrae las instrucciones, el código decompilado o el script cargado, y le devuelve ese material al agente como texto que el modelo puede leer y razonar.
flowchart TD
A["Desarrollador"] --> B["Agente de código"]
B --> C["REA"]
C --> D["Binario o script en ejecución"]
D --> C
C --> B
B --> A
El agente no recibe una respuesta mágica: recibe los mismos insumos crudos que usaría un reverse engineer humano. Lo que cambia es quién hace la lectura línea por línea.
sequenceDiagram
participant D as Desarrollador
participant A as Agente
participant R as REA
participant P as Programa objetivo
D->>A: por qué 200 más 10 por ciento da 220
A->>R: inspeccionar el binario
R->>P: leer instrucciones y llamadas
P-->>R: ensamblador y valores
R-->>A: código decompilado
A-->>D: explicación de la regla
Esa separación de responsabilidades es la clave: REA se encarga de la mecánica de conectar con el proceso (atacharse a él, decompilar una función, leer una variable), y el agente se encarga de interpretar esos datos, formular una hipótesis y explicártela o convertirla en código nuevo.
Ejemplos prácticos
El ejemplo que usa el propio proyecto es la calculadora de Windows: 200 + 10% da 220, y la pregunta es por qué. Un analista humano seguiría tres pasos: decodificar qué rama del programa corresponde al botón %, rastrear a qué funciones llama esa rama, y reconstruir la fórmula a partir de los valores que ve pasar. Con REA, el prompt es directo: Use REA to inspect Windows Calculator. Why does 200 + 10% give 220? El agente hace esos tres pasos por su cuenta y devuelve la regla en texto.
La regla que reconstruye, en pseudocódigo propio para ilustrarla, es así:
double percent_button(double accumulator, double operand) {
double delta = accumulator * operand / 100.0;
return accumulator + delta;
}
// percent_button(200, 10) devuelve 220
// porque 200 * 10 / 100 = 20, y 200 + 20 = 220
El segundo ejemplo es más vistoso: el juego del dinosaurio que corre en la pantalla de error de Chrome cuando no hay conexión. El prompt pedido es Use REA to inspect this dinosaur game. Why does it get faster? REA lee el index.js que el navegador tiene cargado en ese momento y devuelve la condición real que mueve la velocidad: arranca en 6, suma 0.001 por cada actualización sin choque, y se detiene al llegar a 13.
let speed = 6;
const ACCELERATION = 0.001;
const MAX_SPEED = 13;
function tick() {
if (speed [Frida](https://frida.re/), publicado en 2013, permite instrumentar una app en ejecución sin recompilarla.
## Errores comunes y buenas prácticas
- **Analizar sin autorización**, la regla básica no cambia porque haya un agente de por medio: si no es tuyo o no tenés permiso, no lo analices.- **Confiar la hipótesis sin verificarla**, un modelo puede alucinar también leyendo ensamblador. La regla que devuelve REA es un punto de partida, no una conclusión probada.- **Mezclar datos crudos con inferencia**, lo que REA entrega (instrucciones, código decompilado) es un hecho; lo que el agente concluye a partir de eso es una hipótesis que hay que poner a prueba contra el programa real.- **Ignorar protecciones anti-depuración o empaquetado**, un binario ofuscado confunde tanto al analista humano como al agente; no esperes una respuesta limpia ahí.- **No documentar lo encontrado**, sin un registro de la sesión, la próxima vez hay que reconstruir todo el análisis desde cero.
## Comparativa con alternativas
OpciónCuándo usarlaVentajaLimitaciónGhidra o IDA manualAnálisis profundo de un binario complejo o malwareControl total sobre cada instrucciónCurva de aprendizaje de mesesFrida (instrumentación dinámica)Hookear funciones de una app en ejecución sin recompilarlaObserva comportamiento real en vivoHay que saber qué función buscar de antemanoBinary Ninja con scripts propiosAutomatizar análisis repetitivoAPI de scripting maduraIgual exige entender el binario primeroREA más un agente de códigoExplorar rápido un programa sin experiencia previa en RELenguaje natural, itera en minutosDepende del criterio del agente, no sustituye una auditoría formal
La ventaja de REA es la velocidad para explorar: en minutos tenés una hipótesis sobre qué hace una función. La limitación es la misma que tiene cualquier análisis asistido por un modelo de lenguaje: la respuesta puede sonar segura y estar mal, así que no reemplaza una auditoría formal cuando lo que está en juego es crítico.
## Profundizando (avanzado)
Por dentro, decodificar un binario pasa por etapas bien definidas: primero el desensamblador traduce bytes a instrucciones de la CPU (el ejemplo de la calculadora, con `CMP` y `JZ` comparando el código del botón presionado), después el decompilador levanta esas instrucciones a una representación intermedia y de ahí a pseudocódigo parecido a C, y por último alguien (o algo) reconstruye el grafo de control para entender qué rama lleva a qué resultado.
flowchart LR
A["Decodificar ramas"] --> B["Rastrear llamadas"]
B --> C["Recuperar la regla"]
Un modelo de lenguaje lee mejor el pseudocódigo tipo C que el ensamblador x64 crudo, porque se parece más a lo que vio durante su entrenamiento. Eso explica por qué REA entrega código decompilado en vez de solo direcciones y opcodes: no es una cuestión de estética, es lo que hace que el agente razone con menos errores.
El análisis estático (leer el binario quieto) y el dinámico (observarlo mientras corre) responden preguntas distintas. El caso de la calculadora es estático: se lee la lógica sin ejecutarla. El del dinosaurio es dinámico: se llama a la función real del juego en un navegador controlado para medir cómo cambia la velocidad. Un flujo de RE completo suele combinar ambos, y un agente conectado a REA puede pedir cualquiera de los dos según lo que necesite confirmar.
Las protecciones que más complican este trabajo (empaquetado, ofuscación de control de flujo, detección de depuradores, aleatorización de direcciones) no desaparecen porque haya un agente de por medio. Siguen siendo el límite real entre un análisis que toma minutos y uno que toma semanas, con o sin IA de por medio.
> **💡 Tip:** si el agente te da una regla que suena demasiado simple, pedile que la pruebe contra un segundo caso con números distintos antes de aceptarla.
Tu próximo paso: instalá REA con `npx rea-agents@latest setup` en un proyecto de prueba y pedile a tu agente que explique la función más simple de un binario que ya conozcas, para comparar su hipótesis contra el código real.
📖 Resumen en Telegram: [Ver resumen](https://telegra.ph/REA-el-CLI-que-da-ingeniería-inversa-a-Claude-Code-y-Cursor-10-10)
## Preguntas frecuentes
### ¿Qué hace exactamente REA por un agente de código?
Le da acceso a instrucciones de CPU, código decompilado y llamadas a funciones de un programa en ejecución, para que el agente razone sobre esos datos en lenguaje natural.
### ¿La ingeniería inversa con agentes es legal?
Depende de qué analices y con qué permiso. Software propio, investigación de seguridad autorizada o las excepciones de interoperabilidad que reconocen varias jurisdicciones son casos habituales; analizar algo sin derecho a hacerlo no cambia de estatus legal porque haya un agente de por medio.
### ¿REA reemplaza a Ghidra o Frida?
No. Se apoya en ese tipo de herramientas (decompiladores, debuggers, instrumentación dinámica) para obtener los datos; el agente es quien interpreta y explica.
### ¿Qué agentes de código funcionan con REA?
El proyecto está pensado para agentes como Claude Code o Cursor, instalado mediante `npx rea-agents@latest setup` directamente sobre el agente que ya tengas configurado.
### ¿Sirve REA para analizar malware?
Con las mismas precauciones de siempre: entorno aislado, sin ejecutar la muestra fuera de una sandbox, y nunca sobre una máquina conectada a datos reales.
### ¿Qué pasa si el agente se equivoca al explicar un binario?
Lo mismo que si se equivoca escribiendo código: la hipótesis hay que verificarla contra el programa real antes de confiar en ella o de construir algo encima.
## Referencias
- [REA](https://rea.tools/): sitio oficial del proyecto, con la guía de instalación y los ejemplos de la calculadora de Windows y el juego del dinosaurio.- [Ghidra](https://ghidra-sre.org/): framework de ingeniería inversa de código abierto publicado por la NSA, usado como referencia de decompilador clásico.- [Frida](https://frida.re/): toolkit de instrumentación dinámica para inspeccionar procesos en ejecución.- [Reverse engineering](https://en.wikipedia.org/wiki/Reverse_engineering): contexto histórico y técnico general del campo en Wikipedia.
📱 **¿Te gusta este contenido?** Únete a nuestro canal de Telegram [@programacion](https://t.me/programacion) donde publicamos a diario lo más relevante de tecnología, IA y desarrollo. Resúmenes rápidos, contenido fresco todos los días.
Top comments (0)