En este artículo
Un binario no trae comentarios. Tampoco trae intención. Lo que trae es una secuencia de instrucciones que, leída con prisa, parece ruido. REA propone algo distinto: que un agente la recorra con evidencia y que cada conclusión pueda rastrearse hasta una instrucción, una cadena o una llamada.
Qué es REA y qué no es
REA es un toolkit de ingeniería inversa asistida por agentes. Su trabajo es conectar un modelo con herramientas que ya existen —Hopper, Ghidra o IDA para binarios nativos— y devolver un paquete de observaciones: pseudocódigo, assembly, cadenas, símbolos, llamadas y referencias cruzadas. El análisis corre en local y cada resultado incluye la evidencia y las limitaciones de la conclusión.
Eso es distinto de un decompilador. Un decompilador intenta reconstruir fuente; REA orquesta herramientas y conserva el rastro de por qué el agente llegó a una hipótesis. Tampoco es un botón que convierte un ejecutable en un port. Es una capa de investigación: útil para entender una función, un protocolo o una decisión de compilación, no para saltarse el trabajo de verificación.
La distinción importa porque la conversación pública suele mezclar tres cosas: inspeccionar un binario, decompilarlo y recompilarlo para otra plataforma. REA pertenece a la primera. Las otras dos tienen sus propios frameworks, sus propios costos y sus propios problemas legales.
Qué ve un agente en un binario
La tabla de objetivos de REA es amplia: binarios nativos, aplicaciones JavaScript y Electron, ensamblados .NET, APK de Android, firmware, bases SQLite, capturas de red y hasta señales lógicas grabadas. Para cada formato devuelve una representación distinta. En nativo, pseudocódigo y referencias; en JavaScript, módulos, imports, rutas e IPC; en .NET, metadatos e instrucciones CIL; en Android, manifiesto, clases y métodos decompilados.
Esa variedad es útil para una investigación editorial porque permite comparar el mismo concepto en capas distintas. Un agente puede ver una cadena en un binario, la misma cadena en un bundle de JavaScript y la llamada que la consume en una captura de red. La correlación entre capas es más valiosa que cualquiera de las tres por separado.
| Objetivo | Qué devuelve | Qué exige |
|---|---|---|
| Binario nativo | Pseudocódigo, assembly, strings, símbolos, llamadas | Hopper, Ghidra o IDA |
| JavaScript / Electron | Módulos, imports, source maps, rutas, IPC | Node.js y npm |
| .NET | Metadatos, CIL, dependencias nativas | Nada: análisis estático |
| APK Android | Manifiesto, clases, métodos decompilados | JADX y JDK |
| Firmware | Regiones, extracción y handoff a análisis nativo | Binwalk o Unblob |
El bucle de evidencia
El flujo que propone REA se parece menos a “preguntar y recibir” y más a un método científico pequeño. El agente formula una hipótesis —“esta función valida una licencia”, “este string es una ruta de configuración”—, elige la herramienta, obtiene una observación y decide si la hipótesis se sostiene. Si no se sostiene, la descarta y vuelve a empezar con una nueva.
“Analysis runs locally, and results include the evidence and limitations behind each conclusion.” — README de REA.
Ese detalle es el que separa un asistente útil de un generador de confabulaciones. Un modelo puede inventar una explicación plausible para cualquier función; lo que no puede inventar es una referencia cruzada que aparezca en el binario. La evidencia actúa como freno.
En la práctica, el bucle tiene cuatro artefactos: la hipótesis, la consulta a la herramienta, la observación y el veredicto. Si el agente no guarda los cuatro, el resultado es una opinión con formato técnico.
Un caso conceptual, paso a paso
Imagina un ejecutable que muestra “licencia inválida” cuando falta un archivo. El agente no empieza leyendo todo el binario: busca la cadena, encuentra la función que la referencia y observa la bifurcación que decide el mensaje. Con eso formula una hipótesis: “esta función comprueba la existencia de un archivo y devuelve un booleano”.
La verificación no consiste en confiar en el pseudocódigo. Consiste en cambiarlo todo lo posible: ejecutar el binario en un entorno controlado, quitar el archivo, observar el comportamiento y compararlo con la hipótesis. Si el comportamiento coincide, la hipótesis gana confianza; si no, se descarta. El pseudocódigo fue el mapa, no el territorio.
Ese patrón es el mismo que se usa para entender un formato de archivo, un protocolo de red o una decisión de compilación. Cambia la herramienta, no el método. Y es la razón por la que un agente con buenas herramientas sigue necesitando un humano que decida qué merece verification.
Los límites del análisis estático
El análisis estático ve código, no intención. Puede decir que una función compara dos valores; no puede decir si esa comparación es una licencia, un idioma o un checksum. Puede encontrar una cadena; no puede saber si se usa en producción o es código muerto. Puede reconstruir una llamada; no puede garantizar que el binario que analiza sea el que corre en el usuario.
Hay tres límites prácticos. Primero, la ofuscación: nombres eliminados, cadenas cifradas y flujo alterado convierten el pseudocódigo en un jeroglífico. Segundo, la dependencia del proveedor: sin Hopper, Ghidra o IDA, REA no hace análisis nativo. Tercero, la ausencia de ground truth: si no hay una fuente independiente —documentación, comportamiento observable, una segunda build— la conclusión sigue siendo una hipótesis.
| Puede | No puede |
|---|---|
| Encontrar cadenas, símbolos y referencias | Decir qué significa una función sin contexto |
| Correlacionar capas y formatos | Garantizar que el binario analizado es el desplegado |
| Proponer hipótesis verificables | Sustituir la verificación en runtime |
Cómo evaluar una conclusión
Antes de publicar o de actuar sobre una conclusión de REA, aplico cuatro preguntas. ¿La observación es reproducible con la misma versión del binario y la misma herramienta? ¿La cadena de evidencia llega hasta una instrucción o una referencia concreta, o se queda en “el agente dice”? ¿Existe una hipótesis alternativa que explique lo mismo con menos pasos? ¿Qué observación la refutaría?
Si alguna respuesta falta, la conclusión no está lista. Ese criterio es más útil que cualquier benchmark de “precisión” porque no depende de una tabla que nadie reprodujo. También evita el error más común: tratar el pseudocódigo como si fuera el código fuente original. No lo es. Es una reconstrucción plausible, con nombres inventados y decisiones que el compilador tomó por nosotros.
La ola de ports nativos de 2026 se apoya en herramientas como esta, pero no se explica solo por ellas. Los frameworks de recompilación, los runtimes de compatibilidad y el trabajo humano de QA siguen siendo la mayor parte del costo. REA hace más barata la parte de investigación; no elimina las otras.
Para seguir leyendo
El repositorio de REA documenta los proveedores y los límites de cada formato. El resumen semanal de decomp y recomp ayuda a poner la herramienta en contexto: la mayoría de los ports de la ola no salen de un solo agente, sino de frameworks y trabajo de QA.
Si te interesa el lado del hardware, en nuestra guía de modelos de 27B–35B explicamos cuánto ocupan y cuándo compensa usarlos. Para entender por qué la velocidad de un agente no depende solo del modelo, revisa la guía de speculative decoding y MTP. Y si vienes del gaming, la guía de emulación retro en Steam Deck muestra el otro extremo del mismo problema: hacer que código antiguo corra en hardware nuevo.
Preguntas frecuentes
¿REA descompila un juego completo?
No. Inspecciona binarios y devuelve evidencia sobre funciones y estructuras. Un port completo requiere recompilación o decompilación, runtime, assets y QA.
¿Necesito Hopper, Ghidra o IDA?
Para análisis nativo, sí. REA no incluye un motor de decompilación propio; se apoya en esas herramientas.
¿Puedo usarlo sin conexión?
El análisis corre en local. Algunas capacidades, como la inspección de sitios o capturas, dependen de las herramientas externas que configures.
La evidencia es el producto. El pseudocódigo es solo la interfaz. Si el agente no puede mostrar por qué cree lo que cree, el resultado no sirve para tomar decisiones —y menos para publicar.
El conocimiento verdadero trasciende a lo público 🌀
Continúa explorando Inteligencia Artificial con piezas relacionadas y evidencia adicional.
Ver relacionados
