REA: ingeniería inversa con IA, funcionamiento y límites
REA es una herramienta que conecta agentes de IA con herramientas de ingeniería inversa para investigar cómo funciona el software. Distingue el alcance de la verificación de los casos públicos de las limitaciones del análisis de servidores y explica la seguridad, los derechos de autor y la reproducibilidad de los resultados del análisis.
REA permite que los agentes de IA invoquen herramientas de ingeniería inversa mediante MCP.
Comprender cómo funciona un archivo ejecutable no es lo mismo que reconstruir el código fuente original.
El caso publicado de DX-Ball muestra los resultados de la verificación de una función concreta; no significa que se haya reconstruido el juego completo.
El código del servidor y los modelos privados que no están incluidos en la app no se pueden obtener solo con analizarla.
Hay que documentar las evidencias y los aspectos no verificados en los resultados del análisis, y comparar el funcionamiento con el del original.
REA conecta a la AI con herramientas de ingeniería inversa para que investigue cómo funcionan las aplicaciones. Los casos públicos muestran que es posible analizar funciones concretas y volver a implementarlas. Es difícil considerarlos una prueba del fin de la industria del software o de que se pueda copiar un servicio entero.
Las cifras de verificación de DX-Ball corresponden al registro del caso oficial del 7 de octubre de 2026.
¿Qué es REA?
REA son las siglas de Reverse Engineer Anything. Es un proyecto que conecta herramientas de análisis de software con agentes de AI. No es un único modelo de AI que haga por sí solo todos los análisis.
La ingeniería inversa consiste en rastrear la estructura y el funcionamiento de un software terminado. En coreano se denomina 역공학. Su objetivo es identificar lo necesario para explicar una función o garantizar la compatibilidad.
La compilación convierte el código escrito por personas en una forma ejecutable. Durante el proceso pueden desaparecer los comentarios y parte de la información sobre los nombres. La optimización también puede cambiar el aspecto de las funciones y las fórmulas.
Sin embargo, no todas las aplicaciones quedan reducidas a código máquina sin nombres. Algunas distribuciones incluyen código JavaScript o información de depuración. Por eso, el método de análisis depende del formato del archivo y de la información que conserve.
Término | Explicación sencilla | Precaución al interpretar el resultado
Desensamblado | Representar el código máquina como instrucciones de ensamblador | Hace falta interpretar el propósito de las instrucciones
Descompilación | Representar el código ejecutable en una forma parecida al código fuente | No se garantiza que sea idéntico al código fuente original
Análisis estático | Examinar archivos sin ejecutar el programa | Hay que distinguirlo de las rutas de ejecución reales
Análisis dinámico | Observar el funcionamiento mientras se ejecuta el programa | No se conoce el comportamiento fuera de las condiciones observadas
Reimplementación | Escribir código nuevo que reproduzca el funcionamiento identificado | Es necesario compararlo con el original
¿Cómo se conectan la AI y Ghidra?
REA envía las solicitudes de análisis del agente a las herramientas mediante MCP. MCP es una especificación de conexión para que la AI y las herramientas externas intercambien solicitudes y resultados. Ghidra es una herramienta de ingeniería inversa para examinar archivos ejecutables.
El README oficial también explica la integración con Hopper e IDA, además de Ghidra. El análisis estático de JavaScript no requiere un motor de análisis nativo. Por tanto, describir REA solo como una forma de controlar Ghidra automáticamente limita el alcance de sus funciones.
El análisis suele seguir este orden:
· Se eligen la aplicación y la función que se van a investigar.
· Se localizan las partes relacionadas por medio de cadenas de texto o llamadas a funciones.
· Se interpreta el funcionamiento siguiendo las instrucciones y el flujo de datos.
· Se comprueba la evidencia que falte con llamadas adicionales a las herramientas.
· Se compara la reimplementación con el funcionamiento del original.
Ghidra ya contaba con funciones de análisis automático. REA permite que el agente continúe haciendo solicitudes de análisis. La precisión real depende del objeto analizado, el motor de análisis, el modelo y el método de verificación.
Alcance del análisis según las condiciones
Lo que puede comprobarse con REA depende de los archivos y del entorno de ejecución a los que se tenga acceso. Una aplicación local puede contener código que se comunica con un servidor. Eso no significa que incluya la implementación interna del servidor.
Objeto de análisis | Qué puede comprobarse | Qué no puede concluirse solo con el análisis
Archivo ejecutable local | Fórmulas, cadenas de texto, relaciones entre llamadas a funciones | Todos los comentarios originales y la intención de diseño
Aplicación JavaScript·Electron | Estructura de módulos, conexión entre la interfaz y el procesamiento interno | La lógica de procesamiento que solo está en el servidor
Página web y registros de comunicación | Scripts descargados, solicitudes y respuestas observadas | Todo el código fuente del servidor y la base de datos
Archivo de modelo incluido localmente | Estructura e información del archivo al que se tiene acceso | Un modelo privado usado solo en el servidor
Función observada durante la ejecución | Su funcionamiento con esas entradas y en ese entorno | Su funcionamiento con todas las entradas y ante todos los fallos
Reimplementar un servicio también exige atender requisitos que quedan fuera de las funciones observadas. Los permisos de las cuentas y la gestión de errores son ejemplos de ello. Aunque una interfaz funcione de manera parecida, no puede concluirse que el servicio entero sea igual.
Alcance de la verificación del experimento de la calculadora de 8 minutos y 41 segundos
La cifra de 8 minutos y 41 segundos procede de una demostración cuyo registro original no se ha podido comprobar. El número de llamadas a herramientas indicado junto a ella es 17. Tampoco se ha podido verificar de forma independiente la afirmación de que se encontraron 4 reglas de cálculo.
Las condiciones de la prueba deben comprobarse en el vídeo original y en el registro de ejecución. El tiempo necesario varía según el modelo y el tamaño del programa. Un solo éxito no permite juzgar la velocidad ni la precisión habituales del análisis.
En el análisis de una calculadora, leer las fórmulas no basta para completar la verificación. El orden en que se aplican los descuentos y los cupones puede cambiar el resultado. También hay que comprobar por separado cómo se trunca la división de enteros.
· El orden de aplicación de descuentos y cupones
· El importe base para calcular los impuestos
· El punto en que se redondean o truncan los cálculos intermedios
· La salida en los valores límite donde cambian las condiciones
· El registro de la comparación al introducir los mismos datos en el original y en el código reimplementado
Para demostrar que el análisis es rápido también hacen falta registros aparte de la respuesta correcta. Las ejecuciones fallidas y el número de reintentos afectan a la comparación. Con la evidencia comprobada hasta ahora, es difícil afirmar en general que supera a las personas.
Resultados comprobados en los casos públicos
Los casos oficiales muestran la ruta del portapapeles de Notion y una función de cálculo de DX-Ball. Ambos especifican el alcance de la función investigada. También hay que tener en cuenta que son registros publicados por el proyecto REA.
Caso | Trabajo comprobado en la documentación pública | Lo que no debe deducirse de ello
Notion Desktop 7.6.1 | Seguimiento de la ruta desde una llamada interna de la aplicación hasta el portapapeles del sistema | Que se haya copiado todo el servicio de Notion
DX-Ball 1.07 | Reimplementación de la función que convierte la posición en pantalla en valores de audio para izquierda y derecha | Que se haya terminado de reconstruir todo el juego
Aplicación alternativa ligera a Razer Synapse | En esta revisión no se encontró un registro concreto de verificación del original | Que sea un resultado de REA verificado oficialmente
Editor de diapositivas relacionado con Claude | En esta revisión no se confirmaron el objeto ni el alcance de la reimplementación | Que se haya reconstruido el modelo privado de Claude
El caso de Notion rastrea cómo una llamada desde la interfaz pasa por la comunicación interna. Al final, llega a la función de Electron que escribe en el portapapeles. Es un caso que explica la ruta de procesamiento de una función concreta.
En el caso de DX-Ball se comprobaron en el archivo ejecutable las entradas de la función y las constantes de cálculo. Las pruebas comparativas de esa función fueron 3,205. En el resultado compilado, coincidieron 63 bytes tras tener en cuenta el tratamiento de reubicación examinado.
Este registro respalda la reimplementación de una función concreta. La documentación oficial indica que sigue en curso la reconstrucción ejecutable del juego completo. Hay que distinguir entre la verificación de algunas funciones y la finalización del producto entero.
¿Qué garantizan las etiquetas de observación e inferencia?
Las etiquetas de evidencia sirven para distinguir de dónde sale una conclusión. La documentación de REA diferencia las observaciones, las inferencias y la información no confirmada. Sin embargo, no todas las herramientas usan las mismas cuatro etiquetas.
La documentación oficial emplea distintas expresiones de estado y confianza según el tipo de análisis. Para interpretarlas, puede ser útil separar sus significados como se muestra a continuación. Las categorías de la tabla son explicativas.
Categoría | Significado | Qué revisar
Observación | Comprobación directa en un archivo o un resultado de ejecución | Versión del objeto analizado y ubicación de la evidencia
Deducción | Conclusión calculada a partir de valores y relaciones observados | Cálculo y premisas
Estimación | Interpretación que requiere más comprobaciones | Posibilidad de otras explicaciones
Sin confirmar | Parte para la que no se ha obtenido evidencia | Alcance de la investigación y motivo de la falta de confirmación
El documento oficial DISCLAIMER.md señala los límites de los resultados del análisis.
Decompilation, reconstruction, heuristics, and AI-assisted analysis may be incomplete or incorrect. Fuente: REA DISCLAIMER.md
Esto significa que la descompilación y el análisis con AI pueden ser incompletos o erróneos. La etiqueta de observación no elimina la posibilidad de errores de las herramientas. El valor de las etiquetas de evidencia está en dejar constancia de dónde revisar el resultado.
Errores frecuentes
El malentendido más común es dar por verificado un resultado porque se puede explicar. Un código fácil de leer puede comportarse de otra manera que el original. Las rutas que no se han investigado deben quedar indicadas por separado.
Malentendido | Interpretación más precisa
La descompilación recupera el código fuente original | A menudo se obtiene una representación parecida al código fuente
Si hay una ruta en el código, se ejecutó | Una conexión estática no es lo mismo que observar la ejecución
Si no se encontró una función, no existe | El alcance de la investigación o la compatibilidad de la herramienta pueden ser insuficientes
Si la herramienta terminó correctamente, el análisis está completo | Incluso un resultado correcto puede dejar puntos sin confirmar
Si el resultado tiene evidencia, no hay alucinaciones | Hay que revisar tanto la evidencia como su interpretación
La documentación de la CLI de REA también distingue entre terminar correctamente y completar el análisis. Aunque la tarea termine, puede quedar evidencia pendiente o preguntas sin resolver. Hay que comprobar las limitaciones del resultado, no solo el mensaje de finalización.
Registros que permiten volver a verificar los resultados
Un análisis reproducible debe conservar las condiciones en las que se obtuvo la conclusión. El código puede cambiar con una actualización aunque la aplicación mantenga el mismo nombre. Si solo se anota la dirección de una función, puede ser difícil encontrarla en otra versión.
Los registros Evidence de REA conservan la información que identifica el objeto analizado y la ubicación de la evidencia. Las instantáneas permiten reutilizar resultados de análisis cuando las condiciones coinciden. Eso no significa que el resultado guardado también se haya verificado en la versión más reciente.
Para dejar un registro de verificación, siga estos pasos:
· Anote la versión y el hash del archivo analizado.
· Registre las versiones de REA y del motor de análisis.
· Vincule cada conclusión con una ubicación del archivo o una dirección de función.
· Conserve las entradas y salidas tanto del original como del código reimplementado.
· Anote por separado las condiciones que no pudo investigar y las pruebas fallidas.
Un hash es un valor identificativo que permite comparar si dos archivos son iguales. Conservarlo permite rastrear a qué distribución se refiere la explicación. También permite delimitar el alcance de un resultado cuando la AI lo cite más adelante.
Análisis local y envío de datos al exterior
Decir que el análisis se hace localmente no excluye el envío de datos al exterior durante el resto del trabajo. Según el README oficial, REA analiza el objeto de forma local. El agente de AI conectado recibe los resultados de las herramientas.
Si se usa un modelo externo, los resultados del análisis pueden enviarse al proveedor del modelo. La política de datos aplicable depende del servicio conectado. Si se trata de una aplicación de la empresa o de archivos privados, compruebe primero por dónde se envían los datos.
· Qué código y cadenas de texto se envían al modelo
· Qué información de cuentas y tokens de acceso contienen los registros
· Qué datos personales contienen los registros de comunicación
· Dónde se guardan los resultados del análisis y cuál es la política de conservación
También hay que distinguir entre examinar archivos estáticamente y ejecutar un programa. La observación durante la ejecución puede afectar a los archivos o al estado de una cuenta. Trabaje con los programas en los que no confíe en un entorno de pruebas aislado.
Seguridad y derechos que deben comprobar los desarrolladores
La información secreta incluida en una aplicación puede quedar expuesta mediante ingeniería inversa. OWASP explica el problema de incluir información sensible en los paquetes distribuidos. Este riesgo existía antes de la aparición de REA.
En particular, no deben incluirse en la aplicación claves API secretas con permisos de servidor. OWASP recomienda mantener los valores secretos estáticos del lado del servidor. La ofuscación puede dificultar su extracción, pero no garantiza que sigan siendo secretos.
· Revise las contraseñas y claves secretas incluidas en los archivos distribuidos.
· Limite los permisos y el periodo de validez de los tokens de autenticación.
· Verifique en el servidor los permisos de quien hace cada solicitud.
· Sustituya las credenciales que hayan quedado expuestas.
Lo que está permitido en ingeniería inversa depende del país, el contrato y el trabajo concreto. No puede darse por hecho que cualquier actividad esté permitida por tener fines de compatibilidad. El análisis y la redistribución de código e imágenes deben examinarse por separado.
La licencia MIT de REA no concede derechos sobre el software analizado. Los principios de uso del proyecto figuran en el documento oficial DISCLAIMER.md. Compruebe los límites aplicables en la legislación correspondiente y en las condiciones del software analizado.
¿Qué cambios puede haber en la industria del software?
REA muestra que podría reducirse el esfuerzo necesario para entender funciones existentes. Es una perspectiva que se desprende de los casos de análisis publicados. No hay cifras verificadas sobre la reducción de costes en el conjunto de la industria.
Conocer cómo se implementan algunas funciones no equivale a saber operar un servicio. La calidad de los datos y la respuesta ante fallos no se pueden copiar solo mediante el análisis de un archivo ejecutable. Por tanto, hay que evaluar por separado la facilidad para imitar funciones y la competitividad de una empresa.
Elemento del negocio | Lo que se desprende del alcance del análisis de REA
Una función interna de la aplicación | Posible reducción del esfuerzo de investigar su implementación y reimplementarla
Procesamiento exclusivo del servidor | Difícil de obtener solo mediante el análisis del cliente
Datos y permisos de acceso | Deben obtenerse y gestionarse por separado de la comprensión del código
Estabilidad y confianza operativa | Siguen siendo necesarias las pruebas, el mantenimiento y la respuesta ante fallos
Conservación de software existente | Posibilidad de reconstruirlo función por función y conservar la evidencia
Los casos públicos de REA muestran un cambio en la forma de entender el software. No son pruebas de que desaparezca la demanda de desarrollo. Incluso después de reimplementar una función, queda por verificar su compatibilidad y la calidad de su funcionamiento.
Injoys
