REA: entender un programa con IA, de la evidencia a la prueba

Herramientas para entender software · Revisión del 14 de octubre de 2026

Una pregunta concreta antes de abrir la caja

¿Qué hace exactamente esa función de un programa antiguo? ¿Dónde se transforma un dato antes de exportarlo? REA, abreviatura de Reverse Engineer Anything, propone conectar un agente de programación con herramientas de análisis para investigar ese tipo de preguntas. Su web oficial presenta el proyecto como una forma de comprender aplicaciones y sus comportamientos. El nombre es ambicioso; el valor de una investigación depende de qué consigue demostrar.

Para una empresa, una buena primera pregunta podría ser pequeña: averiguar cómo calcula un importe una función heredada o cómo construye una exportación. Son ejemplos hipotéticos de Olduvia. Acotar el problema permite decidir qué observar, qué datos hacen falta y cómo comparar una alternativa sin tener que reemplazar un sistema completo.

Qué aporta REA y qué sigue haciendo el agente

Según el repositorio oficial de morluto/rea, REA ofrece acceso por MCP y por línea de comandos a herramientas que devuelven hallazgos, referencias y límites. El agente utiliza esa evidencia para seguir investigando, explicar, implementar y probar. El análisis nativo profundo puede apoyarse en Hopper, Ghidra o IDA; la inspección estática de JavaScript y .NET no requiere esos motores nativos.

La distinción importa: recibir un fragmento de código descompilado no acredita que una nueva implementación sea equivalente. Hace falta entender entradas, dependencias y casos de error. Nuestra propuesta es conservar esa cadena de comprobación, de modo que una conclusión pueda revisarse sin depender de que la explicación del agente resulte convincente.

El recorrido también puede volver atrás. Si una comparación falla, quizá la hipótesis era incompleta, faltaba un estado interno o se eligió una entrada poco representativa. Documentar ese fallo es parte del resultado: permite corregir la investigación y evita convertir una suposición en una especificación.

DX-Ball: comprobar una función no es reconstruir todo el juego

La demostración del autor sobre DX-Ball investiga cómo una posición horizontal se convierte en paneo de sonido. Informa de 3.205 casos comparados con la función x86 original y de 63 bytes coincidentes tras compilar con una cadena de herramientas fijada y aplicar las reubicaciones revisadas. Son dos comprobaciones de esa función, no una certificación de equivalencia del juego completo. La página indica que el juego jugable sigue en desarrollo.

Olduvia no ha ejecutado esas pruebas. Lo interesante del ejemplo es que permite distinguir niveles de evidencia: una explicación de la fórmula, una comparación de resultados y una comprobación del código compilado. Para otro programa podrían ser necesarias pruebas distintas. Un resultado en ese entorno no demuestra que cualquier binario pueda recuperarse con el mismo esfuerzo o precisión.

Notion: seguir una llamada entre capas

La demostración de Notion Desktop 7.6.1 describe el recorrido del portapapeles: API de la página → capa preload → comunicación IPC → proceso principal → portapapeles de Electron. El autor conecta el canal y sus envoltorios leyendo el paquete de la aplicación. Es una investigación de un mecanismo concreto, no una reproducción del producto ni de su servidor.

La lectura empresarial es directa: cuando una función atraviesa varias capas, observar solo la pantalla puede dejar fuera el paso decisivo. Seguir una llamada ayuda a delimitar responsabilidades. No permite deducir automáticamente qué ocurre en sistemas remotos que no se han observado.

Tres columnas para no confundir una pista con una prueba

Imaginemos una exportación de un programa heredado que estamos autorizados a estudiar. Esta comparación es una plantilla didáctica de Olduvia, no una captura de REA ni un trabajo realizado para un cliente.

Las columnas evitan una confusión frecuente: que una salida coincida en un ejemplo no demuestra que coincida siempre. Conviene conservar los casos que contradicen la explicación, además de los que la apoyan. La comparación debería incluir errores esperables y condiciones que importen al negocio, no solo el recorrido más cómodo.

Observar el navegador tiene un alcance definido

La documentación de observación web describe una vía CDP pasiva y limitada para obtener evidencia de DOM, scripts, metadatos de red y capturas. No equivale a un mando general del navegador. Una captura incompleta o una ventana sin registros no acredita ausencia de actividad ni equivalencia. La documentación separa otros proveedores de ejecución porque tienen facultades y ciclos de vida diferentes.

Aplicado al ejemplo de exportación, un registro que no muestre una petición solo permite hablar del alcance de esa observación. Para afirmar que la operación es completamente local haría falta evidencia adicional. Es una cuestión de método: describir lo observado con sus límites antes de generalizar.

Instalación, datos y permisos: tres decisiones separadas

La guía oficial de instalación distingue el registro del servidor MCP y las instrucciones de trabajo del agente, con respaldos de configuración. Instalar solo una skill no instala las herramientas. Los requisitos de Node.js y de cada proveedor evolucionan; conviene consultar esa guía al preparar el entorno, en lugar de copiar una receta que pueda quedar desactualizada.

Que el análisis se ejecute localmente tampoco significa que sus resultados permanezcan necesariamente en el equipo: el agente los recibe y el proveedor de su modelo aplica su propia política de datos. Así lo aclara el README oficial. Antes de analizar material privado hay que decidir qué información puede entrar en ese flujo.

El código propio de REA se distribuye con licencia MIT; eso no concede derechos sobre el software analizado ni sustituye las licencias de sus dependencias. El aviso de uso del proyecto sitúa la herramienta en análisis autorizados y excluye, entre otros usos, copiar código protegido o eludir controles de acceso. Este artículo no es una autorización para analizar productos ajenos.

Cómo plantearíamos un primer trabajo en Olduvia

Elegiríamos una función concreta, datos de prueba autorizados y un criterio de aceptación acordado antes de empezar. Por ejemplo, documentar una exportación para diseñar una alternativa propia compatible con un proceso interno. Prepararíamos una copia de trabajo y compararíamos resultados sin sustituir directamente el sistema que usa la empresa.

La entrega útil sería un conjunto de hallazgos trazables, dudas pendientes, una implementación revisable si procede y pruebas que expliquen hasta dónde coincide el comportamiento. Si faltan permisos, datos o evidencia suficiente, el alcance tendría que reducirse. No prometeríamos recuperar todo un producto a partir de una demostración.

Esta forma de trabajar conecta con el método de Olduvia: partir de una necesidad, definir cómo comprobar el resultado y avanzar con cambios acotados. Cuéntanos qué función o proceso necesitas entender.

Fuentes primarias consultadas el 14/10/2026. Las demos y sus cifras pertenecen al autor de REA; Olduvia ha revisado documentación, no ha instalado ni ejecutado REA. Portada conceptual generada con IA; diagramas y ejemplos editoriales propios.