REA: the end of closed-source software?

01 One October evening, I give Codex an EXE

Like many people, I discovered REA in my news feeds. I watched a few demonstrations on YouTube, with the usual scepticism of a developer who has already seen several revolutions capable of doing absolutely everything—except working on their own project. During one of those long October evenings, I finally asked Codex to install the necessary tools and set up REA.

My first requests were modest: “How does this button work?” “What does the label in the bottom-right corner correspond to?” I mainly wanted to find out whether the system could actually analyse an application or would produce a highly convincing explanation of something it had not understood. Then, almost as a provocation, I asked: “Can you rebuild this application with equivalent functionality and compile it in whichever language you choose?”

More than five hours later, it announced an initial version, some remaining work and an executable to try. I launched it. Visually, along the paths I tested, I felt as though I was back in the original application. This was not just a description or a mock-up: I had a running program in front of me. I was genuinely stunned.

I continued with another project that was harder to analyse and more heavily protected. Again, the results surprised me. I will neither identify that software nor describe its protections: that is not the purpose of this article. My immediate reaction was exaggerated, but entirely sincere: “Desktop software is dead. Compiled programs are now open source.” With some distance, I would phrase it differently. What is really being challenged is the idea that an executable shipped without source code remains an inaccessible black box indefinitely.

02 Explaining REA with a toy whose instructions are missing

Imagine a little train built from toy bricks. You have the train, but no longer have the instructions. You can inspect how the wheels turn, which button switches on the light and how the pieces seem to connect. Someone patient enough could write new instructions for building a train that behaves similarly. They would not necessarily recover the original instructions or arrange the pieces in exactly the same way.

Software follows a similar idea. The executable is the assembled train. Reverse-engineering tools let you examine its mechanisms. REA gives an AI agent organised access to those tools. The agent collects evidence, proposes an explanation, and can then write and test a new implementation. Compilation turns that implementation into a program for the target machine. ^[1][2]

The important point, even in this explanation for a child, is that the missing instructions do not automatically come back. The aim is to understand the behaviour well enough to reconstruct them. Developer comments, stripped variable names and some design intentions do not simply reappear because AI is involved.

03 Under the bonnet: REA does not work alone

REA stands for Reverse Engineer Anything. The project provides, among other things, an MCP server and a command-line interface. It connects agents to established analysis tools; it is not a universal decompiler that appeared from nowhere. For native binaries, it can use engines such as Ghidra, Hopper or IDA, depending on configuration and available capabilities. Ghidra, for example, already provides disassembly, decompilation and analysis graphs. ^[1][3]

MCP, the Model Context Protocol, acts here as the interface between the agent and its tools. Instead of asking me to manually copy pages of results, the agent can call an analysis function and receive its response. Codex supports MCP servers, so REA gives it an investigation environment—not magical knowledge of every program. ^[4][5]

An investigation might begin with a string displayed on screen, locate functions referencing it, follow their calls and compare the findings with what the application does when someone clicks. REA documents this kind of focused analysis. However, a relationship found in code does not by itself prove that a scenario actually ran: static analysis and runtime observations must be distinguished. ^[2]

The result is a loop: observe, understand, implement, compile, run, compare and fix. Bringing those steps together is what impresses me. Reverse engineering existed long before AI agents; what changes in my daily work is how quickly I can move from a question about a binary to a version I can modify.

To get started, the official documentation includes npx rea-agents setup. The setup assistant presents integrations and proposed changes for approval. That does not remove the need for a suitable analysis engine or compliance with its licence. And to reproduce an experiment, record the REA version, analysis engine and model used—not just the prompt. ^[6]

04 Why I insist on “natively”

I was not simply trying to get an old game to start. I wanted a program built for my current machine. That is a different objective from running the original executable in a compatible environment or an emulator.

That does not make emulation inferior. It remains a fantastic solution, and my earlier experiments with compatibility layers were useful too. I simply wanted something different: to work on the program itself, changing its display, controller input or networking behaviour.

One technical distinction matters: writing “NATIVELY” in a prompt does not mathematically force a complete rewrite. It specifies an outcome. A toolchain might combine reconstructed code, compatibility libraries or translation of parts of the program. You therefore need to examine what was built and what actually runs, rather than trust the agent's terminology. Compiling for another target also requires appropriate libraries and a suitable build environment. ^[8]

05 Cluedo: back to my grandmother's Pentium III

I am getting older too. Some games appeal to me not because they have today's finest graphics, but because they instantly take me back to another time. The 1998 version of Cluedo is one of them. I can still picture myself at my grandmother's Pentium III in the early 2000s, spending an entirely reasonable amount of time hunting the culprit. Reasonable by my standards, anyway.

So I went back through old-game catalogues commonly described as “abandonware”. The word is useful for rediscovering an era; it is not legal permission to download or redistribute everything listed under it. I will return to that point, because it matters to this story. ^[12][14]

In the copy of Cluedo I examined, my diagnosis involved a 32-bit program and an old 16-bit component. I am distinguishing what I identified in my particular copy from a claim about every edition of the game. The general problem is documented: Windows x64 does not provide NTVDM to run old 16-bit Windows applications. A game can therefore have a 32-bit main program and still be blocked by an older auxiliary component. ^[7]

My request to Codex was clear: produce a native version for modern x64 Windows, using the REA tools. I used a high reasoning effort. After several hours and the necessary iterations, I had a playable version. What made the result so striking was that my starting point was not the game's source repository, but its distributed files.

06 While we are here: widescreen, then my Raspberry Pi

Once the game worked, I immediately ran into a thoroughly modern problem: there are no 4:3 monitors left in my home. I asked for the interface to be adapted to 16:9. I did not just want to stretch the image and turn everyone into a slightly squashed version of themselves; I wanted the display to fit the new screen properly.

That sort of change requires thinking about layout, clickable coordinates and the proportions of visual resources. An image can look right while an interactive area remains at its old position. There are several behaviours to test, rather than simply a resolution to replace in a file.

Then I pushed it further: “Now I want this to run natively on my Raspberry Pi 4 in ARM64.” I obtained a version I could use on the Pi. Seeing that game on this tiny machine, after first knowing it on my grandmother's PC, was a strange experience.

I played several games without encountering a bug. I am deliberately keeping that wording: not encountering a bug in my play sessions is not proof that none exist. But for my usage and the paths I tried, this was no longer just a menu demonstration. I could play.

07 Daytona USA Deluxe: widescreen and an Xbox controller

After Cluedo, I moved on to the 1997 PC version of Daytona USA Deluxe. The aim remained the same: get the game running on my Raspberry Pi, adapt the display to 16:9 and avoid depending on an entire ageing setup to enjoy it.

Once that worked, I added a very practical request: I wanted to use my modern Xbox controller. Not dig out a Saturn controller for nostalgia's sake, or spend the evening improvising keyboard bindings. Emulators can often provide their own mapping; in this case, I wanted that support inside the reconstructed version. The work therefore concerned controller input in that version, and I was able to play with that setup.

This is where the nature of the experiment changes. I am no longer only preserving the original behaviour: I am beginning to evolve the program. The old binary becomes the starting point for understanding, while the reconstruction becomes a project I can work on.

For this sort of port, my preference is C++ with a controlled set of dependencies. That does not guarantee performance: a poor algorithm remains a poor algorithm even when compiled in C++. But on a Raspberry Pi, I prefer an architecture whose costs I understand to a stack of layers added merely because an agent suggested them.

08 Destruction Derby: what about adding networking?

Destruction Derby, released in 1995, is another strong memory from my PlayStation years. In 2026, it is already more than thirty years old. For this third experiment, I reused my requirements: 16:9 display, ARM64 target and Xbox controller. Then I wondered whether I could go further and play with the other computers in the house.

I asked for network multiplayer. In my reconstruction, I obtained a version supporting play over the local network, with builds for Windows, Apple Silicon Macs and Raspberry Pi ARM64. I am describing my own project and tests, not an official port or guaranteed compatibility with every device.

Adding multiplayer is obviously not a matter of connecting two “Play” buttons. You must decide what information to exchange, which machine determines the game state and what happens when machines receive information at different times. Positions, collisions and synchronisation become development problems in their own right. These points explain the work involved; I am not claiming to document my version's exact protocol here.

A small architecture clarification: an Apple Silicon Mac and a Raspberry Pi can both be ARM64 without sharing an executable. Their operating systems, libraries and toolchains differ. The benefit is a codebase that can be adapted to multiple targets, not one universal file copied everywhere. ^[8]

09 Black magic, but not a “convert” button

When I tell this story, I readily use the words “black magic”. The contrast between the starting files and the result is strong enough to justify it over coffee. Technically, though, several activities must remain distinct: analysing the program, reconstructing its behaviour, potentially reusing resources and implementing new features.

Graphics, music, videos, text and levels do not suddenly become freely reusable C++ code. A reconstruction may still need the original game's data files. Without an inventory of those resources, you cannot tell what belongs to the new code, what depends on the original copy and what might be distributable. REA itself warns that analysis output does not confer rights over the program being examined. ^[14]

To assess a result seriously, I want more than a window that opens: a reproducible build, essential user paths, saves that load correctly, the controls actually used and tests on the target machines. Session length, untested cases and regressions matter as well. An agent announcing “finished” has not automatically completed validation.

That is what makes my experiments interesting without turning them into a universal promise. I am not claiming that a twenty-year-old application can always be rewritten in five hours. I am saying that, for certain projects I tried, the gap between the effort I expected and the result I obtained genuinely surprised me.

10 Has compiled software become open source?

My first reaction was: “Everything is open source now.” That is a good line from a stunned developer, but a poor definition. Open source does not only mean being able to read code: it also involves a licence granting rights to use, modify and redistribute it. Reconstructing a program does not, by itself, change the original's licence. ^[11]

The real shift I see is economic and technical. If behaviour can be understood and reconstructed with less human effort than before, a vendor cannot rely in the same way on merely delivering an opaque binary. Its value does not disappear: support, quality, updates, data, guarantees and the ecosystem are not reducible to an EXE file.

An antivirus illustrates that distinction: reconstructing part of its client does not automatically recreate its threat research, updates or associated services. With an IDE, understanding behaviour and removing a licence check are likewise different goals. Analytical capability should not be mistaken for a right to use an entire product free of charge. ^[14]

Nor does this mean that all protected code immediately becomes readable. Depending on the components, encryption, obfuscation, dependencies and what is actually available, analysis may remain partial. REA explicitly describes the limits of its observations; an agent should not replace missing information with elegantly phrased certainty. ^[2][14]

For me, desktop software is therefore not dead. It might even gain a second life: more portable, repairable and adaptable where the technical and legal conditions allow. What takes a hit is the fatalism of “we no longer have the sources, so there is nothing we can do”.

11 Chrome on a CPC464 and promises about the PS2

By this stage, the imagination inevitably gets carried away: “What if I asked for modern Chrome on my Amstrad CPC464? Solder on a little extra memory and we are done.” 😄 The joke captures the excitement rather well. But adding RAM does not turn that machine into a contemporary computer: we would be discussing a radical adaptation, a demake or a remotely rendered display, not the full same browser transferred without compromises.

The same caution applies to the PlayStation 2. An ability to analyse certain instructions or binaries does not mean that a tool can automatically rebuild any game for ARM64. The analysis engine, formats, platform-specific components and tests still matter. In the public documentation consulted for this article, I did not identify a general guarantee of native PS2 porting; I will therefore not announce that it will arrive “before this article is published”. ^[1][15]

That does not make the possibility any less exciting. It simply prevents enthusiasm for a rapidly developing technology from turning into an invented delivery schedule.

12 With SaaS, part of the puzzle is missing

Everything I have described benefits from an important advantage: a substantial part of the program exists in the files I possess. With SaaS, a browser does not necessarily receive the business engine. It receives what it needs to display pages and communicate with the server.

REA documents the observation of pages, scripts and network exchanges accessible in an authorised environment. Those clues can help explain screens, parameters or certain behaviours. They do not automatically reveal server-side code. Observing an API response is not the same as obtaining the function that produced it. ^[9][10]

Take an invoice. The front end might submit an amount and receive a status. Yet fifteen rules could run on the server: permissions, company, date, customer type, contractual exceptions or successive approvals. If I observe only one case, I do not know the other fourteen. Several different implementations could produce exactly the response I saw.

An alternative can still be built from specifications, authorised scenarios and tests. The business expert simply becomes essential again. The same applies to a game whose servers have closed: understanding the client may help design a compatible server, without magically recreating historical data, infrastructure or rules that were never observed.

13 And legally, is it allowed?

My first instinct was to write: “Of course not.” That would be just as wrong as saying: “AI rewrote it, so I have every right.” Under the European framework, observing software behaviour as a person entitled to use it is subject to rules. Decompilation necessary for interoperability also benefits from a strictly conditional exception; it is not a general right to clone any product. ^[12]

The distinction between functionality and the program's expression matters too. In SAS Institute v World Programming, the Court of Justice recalled that functionality is not, in itself, a form of expression protected by software copyright. That does not make code, manuals or all creative elements of an application freely reproducible. Independent reimplementation and copying protected content are not the same operation. ^[13]

The term “abandonware”, a game's age or a publisher closing down do not by themselves grant a reuse licence. Similarly, possessing a newly generated set of AI-written source files does not resolve their provenance or the relevant rights. Analysing, modifying, running, publishing and distributing are separate acts that must be examined separately. ^[12][14]

I therefore keep the excitement while separating the questions. The applicable law also depends on the country, contracts and intended use; this section offers European reference points, not personalised legal advice. It would be unfortunate to confuse the possibility of saving software with permission to appropriate everything in it.

14 What this changes for business applications

Beyond my games, I think about all the applications kept alive in virtual machines because nobody knows how to replace them. The accountant's program dependent on an old Windows version. The industrial tool whose vendor has disappeared. The file format understood by three people, two of whom have retired.

Within an authorised scope, the benefits can begin long before a complete rewrite: document behaviour, identify a calculation, understand a format, isolate a dependency and construct reference tests. That is already substantial. You can also decide to modernise only part of a system rather than immediately ask the agent to rebuild the universe.

But business software is not validated merely because its screen resembles the old one. Rounding, historical records, business rules and exceptions are sometimes precisely what makes it valuable. The faster an agent produces code, the more important business examples, traceability and comparisons become. I would not entrust an accounting close to a pretty window just because it compiles.

15 The end of software, or a new way to preserve it?

Over a few years, I have seen my work transformed by AI assistants, then development agents. My REA experiments add another piece: I no longer have to regard an old executable as an object frozen forever. I can begin asking questions, understanding parts of it and considering a reconstruction I probably would never have attempted before.

The title is deliberately provocative. I do not think software is disappearing, and I do not believe a prompt cancels its authors' rights. I do think our relationship with software dependency is changing. Preservation, repairability and interoperability become much more concrete when we can experiment for ourselves.

One question remains that reaches well beyond my Raspberry Pi: how do we preserve the knowledge contained in software while respecting those who created it? Believing knowledge should circulate need not mean denying authors' work. It can also encourage better licensing, source-code handover and planning for products after support ends.

Until we have settled that entire philosophical question, I have something important to do: finish my Cluedo game. On my Raspberry Pi. In widescreen. And I genuinely did not see that coming.