Hacia 1994 o 1995 recuerdo haber conocido un programa que mostraba en ensamblador las instrucciones de otros programas. No recuerdo su nombre. Sí recuerdo que el resultado era difícil de aprovechar: poder ver las instrucciones estaba muy lejos de entender cómo funcionaba el software.
Lo difícil nunca fue solo abrir el ejecutable. Era convertir sus instrucciones en una explicación útil.
Ese recuerdo me ha venido a la cabeza al conocer REA, siglas de Reverse Engineer Anything, una propuesta de ingeniería inversa con IA que permite a los agentes de inteligencia artificial utilizar herramientas para investigar aplicaciones.
La posibilidad de examinar un programa existe desde hace décadas. REA se incorpora a esa evolución con una propuesta concreta: que un agente pueda seguir pistas, consultar herramientas y explicar sus conclusiones con evidencias.
Para una empresa, la pregunta no es solo qué tecnología utiliza una aplicación. También importa saber qué reglas aplica, cómo intercambia información y qué habría que conservar antes de sustituirla.
Qué es REA y para qué sirve
REA es un conjunto de herramientas de código abierto para investigar software. Ofrece una interfaz de línea de comandos y un servidor MCP, el mecanismo que permite conectar sus capacidades con agentes de inteligencia artificial.
El reparto de tareas es sencillo: REA proporciona herramientas y resultados técnicos; el agente los utiliza para investigar, interpretar y proponer una respuesta.
Dependiendo del objetivo, puede trabajar con ejecutables nativos, aplicaciones JavaScript y Electron, ensamblados .NET y otros componentes. Los requisitos cambian según el formato, el sistema operativo y el motor de análisis disponible. La documentación oficial de REA detalla ese alcance.
Una investigación podría comenzar con una pregunta concreta: «¿Cómo convierte esta aplicación los pedidos en un archivo de exportación?».
Responder exige localizar las piezas implicadas y seguir la información entre ellas. El resultado útil no es una lista de instrucciones, sino una explicación que el equipo pueda revisar y contrastar.
Los antecedentes: cómo investigábamos el software antes de REA
Desensambladores: del ejecutable al ensamblador
Un desensamblador traduce instrucciones de código máquina a una representación en ensamblador. Permite examinar operaciones, saltos y llamadas que quedan ocultos dentro del ejecutable.
El programa que recuerdo probablemente pertenecía a esta familia. Sourcer e IDA son nombres que encajan con aquella época, aunque no tengo elementos para identificar cuál utilicé.
La historia publicada por Hex-Rays sitúa el nacimiento de IDA en 1991 y describe un contexto en el que muchas herramientas trabajaban por lotes. IDA introdujo una forma interactiva de explorar y corregir el análisis. La historia de IDA ayuda a entender ese cambio.
Aquellas herramientas realizaban un trabajo valioso, pero interpretar el resultado exigía conocimientos especializados. Una comparación entre dos valores podía formar parte de un cálculo comercial, una validación o una operación interna sin significado evidente para el negocio.
Descompiladores y entornos de análisis
Los descompiladores facilitan representaciones de mayor nivel, como pseudocódigo, que ayudan a seguir la lógica. Los entornos de análisis añaden navegación entre funciones, referencias y anotaciones.
Aun así, una representación legible necesita interpretación. Los nombres originales pueden haberse perdido y algunas construcciones admiten más de una reconstrucción.
La tarea consiste en relacionar esas piezas con un comportamiento: qué datos entran, qué decisiones se toman y qué resultado se produce. Las guías de análisis nativo de REA muestran un recorrido basado en instrucciones, llamadas y constantes.
Qué cambia con la ingeniería inversa con IA
El agente participa en la investigación
Con REA, un agente puede solicitar información sobre el objetivo y utilizar lo encontrado para continuar el trabajo. Una llamada lleva a otra función; una cadena de texto ofrece una pista; una referencia ayuda a localizar una operación.
Esto permite trabajar con preguntas sucesivas en lugar de empezar por un listado técnico sin un objetivo claro. La web oficial utiliza ejemplos como el comportamiento del porcentaje en una calculadora para mostrar cómo se sigue una función concreta.
De las instrucciones a una explicación con evidencias
Si REA afirma que una función calcula un descuento, el equipo debe poder localizar las instrucciones, los datos o las pruebas que sostienen esa afirmación.
La documentación distingue entre hechos examinados, relaciones inferidas e información desconocida. En los flujos de JavaScript, una relación estática entre componentes no demuestra por sí sola que ese recorrido se haya ejecutado. Los flujos de análisis de aplicaciones describen esas limitaciones.
La ventaja está en poder pedir al agente una explicación y revisar de dónde procede cada conclusión relevante.
Cómo se relaciona con Ghidra, IDA y Hopper
Para investigar binarios nativos, REA puede utilizar motores como Ghidra, IDA o Hopper. Esas herramientas siguen realizando el análisis especializado; REA facilita su utilización dentro del trabajo del agente.
| Componente | Función |
|---|---|
| Motor de análisis | Examina el binario y proporciona instrucciones, pseudocódigo o referencias. |
| REA | Da acceso a capacidades de investigación y devuelve resultados estructurados. |
| Agente de IA | Formula consultas, relaciona hallazgos y redacta una explicación. |
| Equipo técnico | Define el objetivo y verifica las conclusiones y las implementaciones. |
La compatibilidad y las herramientas necesarias deben comprobarse para cada objetivo.
Cómo funciona una investigación con REA
Una investigación empieza mejor con una pregunta que se pueda resolver y comprobar.
Las guías oficiales incluyen una aplicación de ejemplo cuya exportación CSV atraviesa varias capas: interfaz, comunicación entre procesos y escritura del archivo. Seguir ese recorrido permite identificar qué hace cada parte. La guía de JavaScript y Electron presenta ese flujo.
En un proyecto empresarial, el proceso podría ser el siguiente:
- Delimitar la operación: por ejemplo, cómo se genera una línea de pedido.
- Reunir los materiales: componentes, versiones y ejemplos disponibles.
- Seguir el recorrido: localizar entradas, transformaciones y salidas.
- Separar hallazgos e hipótesis: registrar qué se ha observado y qué falta.
- Contrastar el resultado: utilizar casos conocidos y condiciones excepcionales.
Si el objetivo es reconstruir una función, las pruebas deberían comparar su comportamiento con el original. Un ejemplo correcto puede ser insuficiente: los errores suelen aparecer en redondeos, datos incompletos o combinaciones poco habituales.
Un caso documentado: el portapapeles de Notion
El proyecto publica un análisis sobre cómo Notion Desktop copia texto y HTML al portapapeles.
La investigación sigue la llamada desde una API expuesta a la página, pasa por la comunicación entre procesos de Electron y llega a la escritura en el portapapeles del sistema. Los fragmentos permiten conectar esas capas.
El caso también examina cómo el contenido copiado conserva información estructurada. La documentación identifica los materiales utilizados y distingue el análisis del paquete de escritorio de las pruebas realizadas con módulos extraídos. El caso de Notion publicado por REA permite revisar el recorrido.
Es un ejemplo útil porque una acción cotidiana esconde varios pasos técnicos. Seguirlos permite saber dónde ocurre cada operación.
La investigación está publicada por REA sobre la aplicación. No demuestra que Notion utilice REA internamente ni equivale a reconstruir el producto completo.
Casos de uso de REA para empresas
Estos escenarios parten de las capacidades documentadas de REA. Su viabilidad tendría que evaluarse con los componentes de cada proyecto.
Recrear aplicaciones antiguas conservando sus reglas
En dos conversaciones con profesionales de empresas de la Región de Murcia me encontré con sistemas que ilustran este problema. Una empresa trabajaba con AS/400 de IBM en servidores propios; la otra mantenía su comercio electrónico sobre ASP.NET 4.
Ambas reconocían que sería conveniente pasar a tecnologías más nuevas, pero el coste asociado frenaba la decisión.
Recrear una aplicación exige averiguar qué comportamientos necesita conservar el negocio. Descuentos acumulados, excepciones por cliente o validaciones de pedidos pueden parecer detalles menores hasta que desaparecen en una migración.
Si faltan documentación o fuentes utilizables, REA podría ayudar a investigar componentes compatibles y preparar una especificación para la reconstrucción. Cuando existe código fuente completo, empezar por él puede resultar más directo.
No hemos analizado aquellos sistemas. Las fuentes consultadas tampoco permiten afirmar que REA pueda examinar directamente la aplicación de AS/400. Primero habría que identificar sus componentes y comprobar el soporte disponible.
Entender conexiones entre aplicaciones y ERP
En la conversación sobre el comercio electrónico apareció otro detalle: los profesionales con los que hablé tampoco tenían claro cómo se había construido la conexión con su ERP.
Una investigación podría empezar con preguntas concretas: ¿qué inicia la sincronización?, ¿cómo se relacionan los identificadores?, ¿dónde se transforma un precio?, ¿qué ocurre cuando falla el intercambio?
Si se conservan ensamblados .NET compatibles, REA documenta capacidades de inspección de tipos, métodos e instrucciones intermedias, además de comparación entre compilaciones. Ese análisis es estático y no ejecuta el código examinado. La documentación de análisis .NET detalla el alcance.
Eso podría aportar piezas de la explicación. Completarla exigiría revisar configuración, registros y pruebas controladas. Examinar un componente no permite atribuirle todo el comportamiento de una integración.
Recuperar acceso a formatos y datos antiguos
Otra situación aparece cuando una empresa conserva información en archivos que solo puede abrir una aplicación antigua.
La investigación podría centrarse en cómo el programa lee esos archivos, reconoce sus campos y transforma los valores. El objetivo sería estudiar un conversor o una herramienta compatible.
La dificultad dependería del formato y de los materiales accesibles. Conviene empezar con una muestra pequeña cuyo contenido se conozca y comprobar que los registros mantienen su significado.
Investigar fallos y cambios entre versiones
Una exportación deja de funcionar después de una actualización, pero la versión anterior se conserva y el fallo se puede reproducir.
Comparar componentes puede ayudar a localizar diferencias y orientar las pruebas. REA incluye flujos de comparación para aplicaciones JavaScript que registran cambios e incertidumbres de correspondencia entre versiones.
La diferencia entre versiones solo se convierte en una causa cuando reproduce el fallo en una prueba controlada. El objetivo práctico es reducir el área que el equipo debe revisar.
Qué puede recuperar REA y cuáles son sus límites
Reconstrucción y código fuente original
El análisis puede proporcionar pseudocódigo, instrucciones y relaciones entre componentes. Una implementación desarrollada a partir de esos hallazgos necesita pruebas propias.
Reproducir una función tampoco equivale a recuperar todas las decisiones de diseño ni el contexto en el que se escribió el programa.
Componentes accesibles y lógica remota
Examinar una página o su código cliente ofrece información sobre lo que recibe el navegador. Parte del comportamiento puede depender de servicios que no están disponibles para inspección.
La documentación de observación del navegador delimita los resultados a los scripts, solicitudes y materiales capturados en el contexto examinado.
Explicaciones y comportamiento verificado
Una explicación coherente debe probarse contra ejemplos relevantes. Para una aplicación comercial, conviene revisar operaciones habituales, excepciones conocidas y entradas problemáticas.
Cómo evaluar si REA tiene sentido en un proyecto
La primera prueba debería producir algo que el equipo pueda revisar: documentar una transformación de datos, explicar una exportación o comparar dos versiones.
Antes de empezar, conviene acordar una medida de utilidad. Puede ser el tiempo necesario para localizar una función, la cantidad de reglas verificadas o las dudas que quedan resueltas. También hay que registrar los errores y el trabajo de corrección.
Hay que revisar el tratamiento de la información. REA analiza los objetivos localmente, pero el agente recibe resultados y su proveedor de modelos aplica sus propias condiciones de datos. Las preguntas frecuentes del proyecto explican esta distinción.
El presupuesto debe incluir preparación, herramientas adicionales cuando sean necesarias, uso del modelo y validación técnica. Una prueba acotada permite estimar esos costes antes de ampliar el alcance.
Qué aporta REA al trabajo de comprender software
Mi recuerdo de los noventa tiene que ver con una dificultad concreta: podía ver las instrucciones de un programa y seguir sin entender lo suficiente para aprovecharlas.
REA permite incorporar un agente al trabajo de investigar esas instrucciones y otros componentes del software. Sus ejemplos publicados muestran recorridos delimitados en los que se puede examinar el material que sostiene una explicación.
Para una empresa, la pregunta útil será qué consigue aclarar sobre su aplicación. Una regla documentada puede ayudar a preparar un cambio. Una integración comprendida puede facilitar su mantenimiento. Una hipótesis verificada puede orientar una corrección.
La prueba será concreta: si REA ayuda a explicar una función y el equipo puede verificarla, habrá reducido parte de la incertidumbre antes de migrar.
Si tu empresa mantiene una aplicación antigua cuya lógica ya no está bien documentada, el primer paso puede ser analizar una función concreta y medir qué parte del sistema se consigue explicar.
Preguntas frecuentes sobre REA
¿REA es un descompilador?
REA conecta agentes con capacidades de investigación. Para el análisis nativo puede utilizar motores existentes, entre ellos Ghidra, IDA y Hopper.
¿Puede recrear una aplicación completa?
El alcance depende del software y de los materiales disponibles. Los casos documentados permiten valorar funciones delimitadas; una reconstrucción completa exigiría un proyecto y una validación mucho mayores.
¿Sirve para modernizar aplicaciones antiguas?
Podría contribuir al análisis previo de componentes compatibles. La migración también requiere diseño, tratamiento de datos, pruebas y planificación de la transición.
Si quieres seguir leyendo análisis sobre tecnología y modernización de software, visita Iberostudio.