REA: ¿el fin del software cerrado?

01 Una noche de octubre, le doy un EXE a Codex

Como muchos, descubrí REA en mis feeds de noticias. Vi algunas demostraciones en YouTube con el escepticismo habitual del desarrollador que ya ha conocido varias revoluciones capaces de hacerlo todo, salvo funcionar en su propio proyecto. Una de esas largas noches de octubre, finalmente le pedí a Codex que instalara las herramientas necesarias y preparara REA.

Mis primeras peticiones eran modestas: «¿Cómo funciona este botón?», «¿A qué corresponde el texto de la esquina inferior derecha?». Quería comprobar si el sistema podía analizar realmente una aplicación o si iba a ofrecerme una explicación muy convincente de algo que no había entendido. Entonces lancé, casi por provocación: «¿Puedes rehacer la aplicación con funciones equivalentes y compilarla en el lenguaje que prefieras?».

Más de cinco horas después, anunció una primera versión, algunos elementos pendientes y un ejecutable que podía probar. Lo abrí. Visualmente, en los recorridos que ensayé, tuve la sensación de estar de nuevo en la aplicación original. No era una descripción ni una maqueta: tenía delante un programa en ejecución. Me quedé francamente asombrado.

Continué con otro proyecto, más difícil de analizar y con más protecciones. De nuevo, los resultados me sorprendieron. No voy a identificar ese software ni a describir sus protecciones: el interés de este artículo está en otra parte. Mi reacción inmediata fue exagerada, pero sincera: «El software de escritorio ha muerto. Los programas compilados ahora son de código abierto». Con algo de perspectiva, lo expresaría de otra forma. Lo que se tambalea es la idea de que un ejecutable entregado sin sus fuentes seguirá siendo una caja negra inaccesible indefinidamente.

02 REA explicado con un juguete que ha perdido las instrucciones

Imagina un pequeño tren construido con bloques. Tienes el tren, pero no las instrucciones. Puedes observar cómo giran las ruedas, qué botón enciende la luz y cómo parecen conectarse las piezas. Alguien con suficiente paciencia podría escribir unas instrucciones nuevas para construir un tren que se comporte de forma parecida. No serían necesariamente las originales, ni organizarían las piezas exactamente igual.

Con el software sucede algo similar. El ejecutable es el tren ya construido. Las herramientas de ingeniería inversa permiten examinar sus mecanismos. REA ofrece a un agente de IA acceso organizado a esas herramientas. El agente reúne indicios, propone una explicación y puede escribir y probar una nueva implementación. La compilación convierte después esa implementación en un programa utilizable en la máquina de destino. ^[1][2]

El detalle importante, incluso en esta explicación para un niño, es que las instrucciones perdidas no reaparecen automáticamente. Se intenta comprender el funcionamiento con suficiente precisión para reconstruirlas. Los comentarios del desarrollador, los nombres de variables eliminados y algunas decisiones de diseño no vuelven simplemente porque intervenga una IA.

03 Por dentro: REA no trabaja solo

REA significa Reverse Engineer Anything. El proyecto proporciona, entre otras cosas, un servidor MCP y una interfaz de línea de comandos. Conecta a los agentes con herramientas de análisis existentes; no es un descompilador universal surgido de la nada. Para binarios nativos puede apoyarse en motores como Ghidra, Hopper o IDA, según la configuración y las capacidades disponibles. Ghidra, por ejemplo, ya ofrece desensamblado, descompilación y grafos de análisis. ^[1][3]

MCP, o Model Context Protocol, sirve aquí de interfaz entre el agente y las herramientas. En lugar de pedirme que copie manualmente páginas de resultados, el agente puede llamar a una función de análisis y recibir su respuesta. Codex permite conectarse a servidores MCP: REA le da un entorno de investigación, no un conocimiento mágico de todos los programas. ^[4][5]

Una investigación puede comenzar con un texto que aparece en pantalla, localizar las funciones que lo referencian, seguir sus llamadas y comparar los resultados con lo que hace la aplicación al pulsar un botón. REA documenta este análisis dirigido. Pero una relación observada en el código no demuestra por sí sola que un escenario se haya ejecutado: hay que distinguir el análisis estático de las observaciones durante la ejecución. ^[2]

El resultado es un ciclo: observar, comprender, implementar, compilar, ejecutar, comparar y corregir. Lo que me impresiona es la conexión entre esas etapas. La ingeniería inversa existía mucho antes de los agentes de IA; lo que cambia en mi trabajo es la rapidez con la que puedo pasar de una pregunta sobre un binario a una versión modificable.

Para empezar, la documentación oficial propone, entre otras opciones, npx rea-agents setup. El asistente presenta las integraciones y los cambios antes de pedir aprobación. Eso no elimina la necesidad de un motor adecuado ni de respetar su licencia. Y para reproducir una experiencia conviene registrar la versión de REA, el motor de análisis y el modelo utilizados, no únicamente el prompt. ^[6]

04 Por qué insisto en la palabra «nativamente»

No buscaba simplemente conseguir que arrancara un juego antiguo. Quería obtener un programa construido para mi equipo actual. No es el mismo objetivo que ejecutar el archivo original en un entorno compatible o en un emulador.

Eso no convierte a la emulación en una solución inferior. Sigue siendo una herramienta extraordinaria, y mis experimentos anteriores con capas de compatibilidad también me resultaron útiles. Simplemente quería otra cosa: intervenir en el propio programa, modificar su visualización, la entrada del mando o su funcionamiento en red.

Una precisión técnica: escribir «NATIVAMENTE» en un prompt no obliga matemáticamente a una reescritura completa. Es una exigencia sobre el resultado. La solución podría combinar código reconstruido, bibliotecas de compatibilidad o traducción de partes del programa. Por eso hay que examinar lo que se ha construido y lo que realmente se ejecuta, no confiar solo en la palabra utilizada por el agente. Compilar para otro destino también exige adaptar las bibliotecas y el entorno de compilación. ^[8]

05 Cluedo: vuelta al Pentium III de mi abuela

Yo también me hago mayor. Hay juegos a los que quiero volver no porque tengan los mejores gráficos actuales, sino porque me transportan inmediatamente a otra época. Cluedo, en su versión de 1998, es uno de ellos. Me veo otra vez delante del Pentium III de mi abuela, a principios de los años 2000, dedicando una cantidad de tiempo perfectamente razonable a encontrar al culpable. Razonable según mis criterios, claro.

Volví entonces a los catálogos de juegos antiguos agrupados bajo el término «abandonware». La palabra resulta útil para recuperar una época; no constituye permiso legal para descargar o redistribuir todo lo que aparece en ellos. Volveré sobre este punto porque es importante en esta historia. ^[12][14]

En la copia de Cluedo que estudié, mi diagnóstico incluía un programa de 32 bits y un componente antiguo de 16 bits. Distingo lo identificado en mi ejemplar de una afirmación sobre todas las ediciones del juego. El problema general sí está documentado: Windows x64 no proporciona NTVDM para ejecutar aplicaciones antiguas de Windows de 16 bits. Un juego puede tener una parte principal de 32 bits y quedar bloqueado por un componente auxiliar más antiguo. ^[7]

Mi petición a Codex era clara: obtener una versión nativa para un Windows moderno x64 utilizando las herramientas REA. Elegí un esfuerzo de razonamiento elevado. Después de varias horas y las iteraciones necesarias, tenía una versión jugable. El resultado me impresionó especialmente porque no había partido del repositorio de código fuente del juego, sino de sus archivos distribuidos.

06 Ya que estamos: formato panorámico y después Raspberry Pi

Cuando el juego funcionó, apareció un problema muy contemporáneo: ya no tengo pantallas 4:3 en casa. Pedí adaptar la interfaz a 16:9. No quería limitarme a estirar la imagen y convertir a los personajes en versiones ligeramente aplastadas de sí mismos; quería que la visualización encajara correctamente en la nueva pantalla.

Ese cambio exige pensar en la distribución de los elementos, las coordenadas de clic y las proporciones de los recursos. Una imagen puede parecer correcta mientras una zona interactiva continúa en su posición antigua. Por tanto, hay varios comportamientos que probar, no solo una resolución que sustituir en un archivo.

Después fui un paso más allá: «Ahora quiero que funcione nativamente en mi Raspberry Pi 4 ARM64». Y obtuve una versión que pude utilizar en la Pi. Volver a ver aquel juego en una máquina tan pequeña, después de haberlo conocido en el PC de mi abuela, me produjo una sensación extraña.

Jugué varias partidas sin encontrar errores. Mantengo deliberadamente esa formulación: no encontrar un error durante mis partidas no demuestra que no exista ninguno. Sin embargo, para mi uso y los recorridos probados, ya no estaba ante una simple demostración de menú. Podía jugar.

07 Daytona USA Deluxe: pantalla panorámica y mando Xbox

Después de Cluedo, continué con la versión para PC de Daytona USA Deluxe de 1997. El objetivo seguía siendo el mismo: recuperar el juego en mi Raspberry Pi, adaptar la visualización a 16:9 y evitar depender de toda una instalación antigua para disfrutarlo.

Una vez conseguido, añadí una petición muy práctica: quería utilizar mi mando Xbox moderno. No sacar un mando de Saturn por nostalgia ni pasarme la noche improvisando teclas. Los emuladores suelen ofrecer su propio mapeo; en mi caso quería integrar ese soporte en la versión reconstruida. El trabajo se centró en la entrada del mando de esa versión y pude jugar con esa configuración.

Aquí cambia la naturaleza de la experiencia. Ya no se trata únicamente de preservar el comportamiento original: empiezo a evolucionar el programa. El binario antiguo sirve de punto de partida para comprenderlo; la versión reconstruida se convierte en un proyecto sobre el que puedo trabajar.

Para este tipo de adaptación prefiero C++ y un conjunto de dependencias controlado. Eso no garantiza automáticamente el rendimiento: un algoritmo malo sigue siendo malo aunque esté compilado en C++. Pero en una Raspberry Pi prefiero una arquitectura cuyo coste entiendo a una acumulación de capas añadidas solo porque las propuso el agente.

08 Destruction Derby: ¿y si añadimos juego en red?

Destruction Derby, publicado en 1995, es otro recuerdo muy intenso de mi época con PlayStation. En 2026 ya ha superado los treinta años. Para esta tercera experiencia mantuve los objetivos: visualización 16:9, destino ARM64 y mando Xbox. Después me pregunté si podía ir más lejos y jugar con los otros ordenadores de la casa.

Pedí un modo multijugador en red. En mi reconstrucción obtuve una versión que permite jugar en la red local, con compilaciones para Windows, Mac Apple Silicon y Raspberry Pi ARM64. Hablo del resultado de mi proyecto y de mis pruebas, no de una versión oficial ni de una compatibilidad garantizada con todos los equipos.

Añadir multijugador no consiste en conectar dos botones «Jugar». Hay que decidir qué información intercambiar, quién determina el estado de la partida y qué ocurre cuando las máquinas no reciben la información al mismo tiempo. Posiciones, colisiones y sincronización pasan a ser problemas de desarrollo por derecho propio. Estos puntos explican el trabajo que hay que abordar; no pretendo documentar aquí el protocolo exacto de mi versión.

Otra precisión sobre las arquitecturas: un Mac Apple Silicon y una Raspberry Pi pueden ser ARM64 sin compartir el mismo ejecutable. Cambian el sistema operativo, las bibliotecas y la cadena de compilación. La ventaja es disponer de una base de código adaptable a varios destinos, no de un archivo universal que se copie en todas partes. ^[8]

09 Magia negra, pero no un botón «convertir»

Cuando cuento esto utilizo con gusto la expresión «magia negra». El contraste entre los archivos iniciales y el resultado es suficientemente fuerte como para justificarla tomando un café. Técnicamente, sin embargo, hay que separar varias tareas: analizar el programa, reconstruir su comportamiento, reutilizar posiblemente algunos recursos y desarrollar funciones nuevas.

Los gráficos, las músicas, los vídeos, los textos y los niveles no se convierten de repente en código C++ libremente reutilizable. Una reconstrucción puede necesitar los archivos de datos del juego original. Sin inventariarlos, no sabemos qué pertenece al código nuevo, qué depende de la copia original y qué podría compartirse. El propio proyecto REA recuerda que los resultados del análisis no conceden derechos sobre el programa examinado. ^[14]

Para evaluar seriamente un resultado necesito más que una ventana que se abre: una compilación reproducible, los recorridos esenciales, partidas guardadas que se carguen, los controles realmente utilizados y pruebas en los equipos de destino. También cuentan la duración de las sesiones, los casos no probados y las regresiones. Que un agente anuncie «terminado» no significa que haya terminado la validación.

Eso hace interesantes mis experimentos sin convertirlos en una promesa universal. No afirmo que una aplicación de veinte años se pueda reescribir siempre en cinco horas. Afirmo que, en algunos proyectos que probé, la diferencia entre el esfuerzo que imaginaba y el resultado obtenido me sorprendió de verdad.

10 ¿El software compilado se ha vuelto de código abierto?

Mi primera reacción fue: «Ahora todo es de código abierto». Es una buena frase de desarrollador asombrado, pero una mala definición. El código abierto no significa únicamente poder leer código: también implica una licencia que concede derechos de uso, modificación y redistribución. Reconstruir un programa no cambia por sí solo la licencia del original. ^[11]

El cambio que percibo es económico y técnico. Si un comportamiento puede comprenderse y reconstruirse con menos trabajo humano, el editor no puede apoyarse igual que antes en el simple hecho de entregar un binario opaco. Su valor no desaparece: el soporte, la calidad, las actualizaciones, los datos, las garantías y el ecosistema no se reducen al archivo EXE.

Un antivirus ilustra bien la diferencia: reconstruir parte del cliente no recrea automáticamente la investigación de amenazas, las actualizaciones ni sus servicios asociados. En un IDE, comprender un comportamiento y eliminar un control de licencia también son objetivos diferentes. La capacidad de análisis no debe confundirse con el derecho a utilizar gratuitamente todo un producto. ^[14]

Tampoco significa que todo código protegido sea inmediatamente legible. Según los componentes, el cifrado, la ofuscación, las dependencias o lo que esté realmente disponible, el análisis puede seguir siendo parcial. REA describe explícitamente los límites de sus observaciones; el agente no debería sustituir la información ausente por certezas bien redactadas. ^[2][14]

Para mí, por tanto, el software de escritorio no ha muerto. Incluso podría encontrar una segunda vida: más portable, reparable y adaptable cuando lo permitan las condiciones técnicas y jurídicas. Lo que pierde fuerza es la resignación del «ya no tenemos las fuentes, así que no podemos hacer nada».

11 Chrome en un CPC464 y las promesas sobre PS2

A estas alturas, la imaginación inevitablemente se dispara: «¿Y si pido un Chrome moderno para mi Amstrad CPC464? Sueldo un poco más de memoria y arreglado». 😄 La broma resume bastante bien la euforia. Pero añadir RAM no convierte esa máquina en un ordenador contemporáneo: hablaríamos de una adaptación radical, un demake o una visualización remota, no del mismo navegador completo trasladado sin concesiones.

La misma prudencia se aplica a PlayStation 2. Que una herramienta analice determinadas instrucciones o binarios no significa que pueda reconstruir automáticamente cualquier juego para ARM64. El motor de análisis, los formatos, los componentes propios de la plataforma y las pruebas siguen siendo determinantes. En la documentación pública consultada para este artículo no identifiqué una garantía general de adaptación nativa de PS2; no voy a anunciar que llegará «antes de que se publique el artículo». ^[1][15]

Eso no resta interés a la posibilidad. Simplemente evita convertir el entusiasmo por una tecnología que avanza deprisa en un calendario de entregas inventado.

12 Con el SaaS falta una parte del rompecabezas

Todo lo anterior parte de una ventaja importante: una parte sustancial del programa está presente en los archivos de los que dispongo. En una aplicación SaaS, el navegador no recibe necesariamente el motor de negocio. Recibe lo necesario para mostrar las páginas y comunicarse con el servidor.

REA documenta la observación de páginas, scripts e intercambios de red accesibles en un entorno autorizado. Esos indicios pueden ayudar a comprender pantallas, parámetros o ciertos comportamientos. No revelan automáticamente el código del servidor. Observar la respuesta de una API no equivale a recuperar la función que la produjo. ^[9][10]

Pensemos en una factura. El front puede enviar un importe y recibir un estado. Pero en el servidor pueden intervenir quince reglas: permisos, sociedad, fecha, tipo de cliente, excepciones contractuales o validaciones sucesivas. Si solo observo un caso, no conozco los otros catorce. Varias implementaciones diferentes pueden producir exactamente la respuesta que he visto.

Sigue siendo posible desarrollar una alternativa a partir de especificaciones, escenarios y pruebas autorizadas. Sencillamente, el experto funcional recupera inmediatamente su lugar. Lo mismo sucede con un juego cuyos servidores han cerrado: comprender el cliente puede ayudar a diseñar un servidor compatible, sin recrear mágicamente los datos históricos, la infraestructura ni las reglas nunca observadas.

13 Y jurídicamente, ¿es legal?

Mi primera reacción era escribir: «Por supuesto que no». Sería tan falso como afirmar: «Lo ha reescrito una IA, así que tengo todos los derechos». En el marco europeo, observar el funcionamiento de un programa cuando se tiene derecho a utilizarlo está regulado. La descompilación necesaria para la interoperabilidad también tiene una excepción sujeta a condiciones estrictas; no es un derecho general a clonar cualquier producto. ^[12]

También importa la diferencia entre funcionalidad y expresión del programa. En el asunto SAS Institute contra World Programming, el Tribunal de Justicia recordó que la funcionalidad no es, por sí misma, una forma de expresión protegida por el derecho de autor del software. Eso no autoriza a reproducir libremente código, manuales o todos los elementos creativos de una aplicación. Una reimplementación independiente y una copia de contenido protegido no son la misma operación. ^[13]

El término «abandonware», la antigüedad de un juego o el cierre de su editor no conceden por sí solos una licencia de reutilización. Del mismo modo, disponer de nuevos archivos fuente generados por IA no resuelve su procedencia ni los derechos afectados. Analizar, modificar, ejecutar, publicar y distribuir son actos diferentes que deben examinarse por separado. ^[12][14]

Conservo, por tanto, el entusiasmo, pero separo las cuestiones. La legislación aplicable también depende del país, los contratos y el uso previsto; esta sección ofrece referencias europeas, no asesoramiento jurídico personalizado. Sería una pena confundir la posibilidad de rescatar un programa con el permiso para apropiarse de todo lo que lo compone.

14 Qué cambia para nuestras aplicaciones de negocio

Más allá de los juegos, pienso en todos esos programas que conservamos en máquinas virtuales porque nadie sabe sustituirlos. La aplicación de la contable que depende de un Windows antiguo. La herramienta industrial cuyo editor ha desaparecido. El formato de archivo que entienden tres personas, dos de ellas ya jubiladas.

Dentro de un marco autorizado, las ventajas pueden aparecer mucho antes de una reescritura completa: documentar un comportamiento, identificar un cálculo, comprender un formato, aislar una dependencia y construir pruebas de referencia. Eso ya es muchísimo. También podemos decidir modernizar solo una parte, en lugar de pedir al agente que rehaga de inmediato todo el universo.

Pero una aplicación de negocio no queda validada porque su pantalla se parezca a la antigua. Los redondeos, los históricos, las reglas de gestión y las excepciones son a veces precisamente lo que le da valor. Cuanto más acelera el agente la producción de código, más importantes son los ejemplos funcionales, la trazabilidad y las comparaciones. No confiaría un cierre contable a una ventana bonita solo porque compila.

15 ¿El fin del software o una nueva forma de preservarlo?

En pocos años he visto mi oficio transformarse con los asistentes de IA y después con los agentes de desarrollo. Mis experimentos con REA añaden otra pieza: ya no tengo que considerar un ejecutable antiguo como un objeto congelado para siempre. Puedo empezar a plantearle preguntas, comprender algunas partes e imaginar una reconstrucción que probablemente no habría emprendido antes.

El título es deliberadamente provocador. No creo que desaparezca el software ni que un prompt anule los derechos de sus autores. Sí creo que está cambiando nuestra relación con la dependencia tecnológica. La preservación, la reparabilidad y la interoperabilidad se vuelven mucho más concretas cuando podemos experimentar por nosotros mismos.

Queda una pregunta que va mucho más allá de mi Raspberry Pi: ¿cómo preservar el conocimiento contenido en un programa respetando a quienes lo crearon? Defender que el conocimiento debe circular no obliga a negar el trabajo de los autores. También puede impulsarnos a organizar mejor las licencias, la transmisión de las fuentes y la vida de los productos después del fin de su soporte.

Mientras resolvemos toda esa cuestión filosófica, tengo algo importante que hacer: terminar mi partida de Cluedo. En mi Raspberry Pi. En 16:9. Y eso sí que no lo vi venir.