Can AI clone any app? Reverse engineering and the REA tool, explained

Can AI clone any app? On the public evidence, nobody knows, and the headlines about the end of software are well ahead of it. REA is a tool that gives an AI agent the equipment to study a finished program without its source code. It has been used to reimplement narrow features, but nobody has shown that a whole application can be reliably replaced. That gap is the heart of this article.

Source code is the human-readable set of instructions a program is built from. Customers usually receive only the compiled version, which a machine can run but a person cannot easily read. Reverse engineering means working out how a program behaves without having that source code. It is an old craft, practised by security researchers, compatibility engineers and software preservationists. In October 2026 a tool called REA, short for Reverse Engineer Anything, shot up the GitHub charts (Startup Fortune wrote about it on 9 October 2026). Headlines have called it a threat to closed-source software, and in some cases the end of software as a business. This article looks at what REA does, how it works, and what has actually been demonstrated.

What REA is

REA is an open-source tool, released under the MIT licence, that lets an AI agent study a program whose source code is unavailable to the investigator. The agent here is the kind described in what an agent actually is: a loop built around a language model that tries something, looks at the result and adjusts. Claude Code, Codex and Cursor are examples.

You can use REA through an agent or from the command line. To the agent it appears as an MCP server, a service that tells the agent which tools are available and how to call them.

The range of targets is wide: installed desktop programs, websites, Android apps, firmware and network captures, plus desktop apps built with JavaScript (Electron). Support varies by platform and by which tools you have installed. On 24 October 2026 the project's GitHub page showed roughly 375,000 stars, which are bookmarks given by visitors. Sources quote different figures from different days, so treat the number as a measure of interest, not of quality.

How it works

The most important thing to know is what REA is not: a new way of taking programs apart. Tools for that have existed for decades, and professionals still use them. Ghidra, Hopper and IDA Pro turn desktop programs back into a more readable form, and JADX does the same for Android apps. REA mostly uses your own installations of those tools and gives the agent one consistent way to call them. It also includes its own parsers for several file formats, and analysing JavaScript apps does not need native tools at all. None of this is entirely new, since GhidraMCP already exposes Ghidra to language models over MCP. What REA adds is breadth of targets, and findings returned with their evidence and their stated limits.

A reconstruction workflow has three steps:

1. Inspect. The agent asks REA to analyse a target. The analysis runs on your own machine.
2. Interpret. REA returns findings with the evidence behind them, plus a list of what it could not establish. The agent draws conclusions from them.
3. Rebuild. The agent writes a new implementation and tests it against the original.

Everything turns on the gap between steps 2 and 3. Evidence does not guarantee a correct reading of it. REA's own disclaimer warns that decompilation, reconstruction, heuristics and AI-assisted analysis may be incomplete or incorrect. Decompilation means turning a compiled program back into something more readable, and it often loses the names and structure that told the original programmers what each part does. The agent has to infer meaning from text strings, library calls and structure. Difficulty varies by orders of magnitude between targets: JavaScript and Android apps are far easier than a native program with its names stripped out.

A language model also readily fills gaps with plausible code that looks right and is not. Testing against the original works well when the result can be measured, as in a calculation. Comparing a user interface, timing or environment-dependent behaviour is much harder, and tests only tell you about what was tested. So important conclusions still need checking against the original findings.

Four steps that the headlines skip

Studying a program, understanding it, building a new version and keeping a working product alive are different achievements. In the examples reviewed here, the public evidence mostly sits on the first rungs. The steps are also not strictly sequential: they overlap.

What the examples show

The dinosaur game. In a DataCamp tutorial an agent worked out how Chrome's offline dinosaur game works and built an original game on the same mechanics, with new characters. The agent was Pi, not Claude Code. Chrome's internal chrome://dino page could not be inspected directly, so the agent pulled the game's JavaScript out of the browser's installed resources and handed it to REA. The instructions told the agent not to look at Chromium's source code. Two caveats. This is analysis of JavaScript, not of a compiled native program, and the game's source is already public in the Chromium tree. The game is also very well known, so the model may have known something about it already. The experiment shows that an agent can find resources and analyse code extracted from them. It does not show how well the same workflow would cope with an unknown, closed algorithm.

macOS Preview. In an informal comparison described by MindStudio, an agent built a Preview-like application with REA and without it. With REA the result came close to the original, but the agent without REA also produced a working version, and finished first. Both routes delivered several visible features. Preview is a well-known application too, so the model may have known a lot about how it behaves without any analysis. The write-up gives no assessment criteria, repeat runs or coverage figures, so it does not show which route produces a more complete or reliable application. Nor does it report tests of file compatibility or edge cases.

REA's own measurements. The project has published efficiency measurements, and they address a narrower question: how efficiently an agent can retrieve analysis results. The link points to a specific commit, a fixed saved version of the page, because the page changes fast and holds many follow-up studies. These measurements assess specific analysis workflows and optimisations, such as returning compact replies instead of full ones, and they cover a Linux x64 environment. They are not a test of whether REA produces better replacement applications than an agent working without it. Reply sizes fell sharply, but total time and model token use were mixed: some results better, some worse, and several are single runs. The project itself warns against generalising from them. The page documents its scripts and inputs, but the raw receipts and transcripts behind the results are kept in a private lab, so some claims cannot be checked from the page alone. The data is also the project's own. The project does publish results that do not flatter it, which is a good sign but not proof.

These examples leave one question unresolved: what does REA add over an ordinary coding agent? The public comparisons reviewed here do not establish a consistent advantage for REA.

Why it gets called a software killer

The claim has a sensible argument behind it. Some companies have built their protection on the fact that a finished program is hard to look inside. If studying a program gets easier, that protection thins out. Combining old methods can also be a real advance even when the methods are old, if it lowers costs or opens the work to a new group of users.

But the claim runs into three problems:

• Studying is not replacing. Working out how one feature works does not make it cheap to build a dependable alternative, or to move customers across. There are three questions: does studying a feature get cheaper, does building a dependable alternative get cheaper, and does moving customers across get cheaper? The public examples reach at most the first. The third may be the most expensive: moving data, file compatibility, connections to other systems, training, support and trust.
• The work is not free. Open source does not make the whole job cheap: model usage, commercial analysis tools, compute and human checking all cost money. Building a copy is also only the start. The original's makers keep developing it, so a clone is always catching up, and code written by an agent can be maintained only if someone understands it.
• The server side stays out of view. REA studies what ends up on a user's machine or in their browser. Code that runs only on the provider's servers does not come with it. That is my own inference from how the sources describe the tool. It limits what REA can reveal about cloud services: it can inspect client-side code and observable behaviour, but cannot directly recover an implementation that remains on the provider's servers.

Software has also never been protected by obscurity alone. On top of it sit licences and terms of use, patents, data, certifications, connections to other systems, support, brand and the sheer hassle of switching. The examples reviewed do not establish how much REA reduces the cost of building a dependable replacement. It may still lower the bar for studying code that has been shipped to customers, and it is a reminder that obscurity has never been a reliable protection.

The legal side

This section is not legal advice.

Three things are easily confused, and the EU Software Directive (2009/24/EC) treats them differently:

• Observing how a program behaves while it runs. Under Article 5(3), a person with a right to use a copy of a program may observe, study and test its functioning in order to determine the ideas and principles underlying it, as long as they do so while performing acts they are entitled to do, such as running the program. A contract term cannot take this right away (Article 8).
• Taking the code apart. Decompilation is allowed without the rightholder's permission only where it is indispensable for the interoperability of an independently created program and the other conditions of Article 6 are met. The information obtained may not be used to develop, produce or market a program substantially similar in its expression. So it gives no licence to make a competing copy.
• Everything else. The directive does not displace patents, trade marks, unfair competition and trade secret protection, or contract law (Article 8). Terms of use can therefore restrict things other than the rights above.

Function and protected expression also need to be kept apart. In SAS Institute (C-406/10) the Court of Justice of the European Union held that neither the functionality of a program nor the programming language or data file format it uses is, as such, protected expression under software copyright. That is no general licence: copying the code and its original expression is protected. Reimplementing a feature in your own code is a different act from copying someone else's code, or their manuals and images.

An agent makes this distinction harder to draw. If an agent is fed decompiled code and writes a new implementation from it, the result may inherit the original's structure. Professionals use a "clean room" procedure for this: one team analyses, a different team implements, and the implementers receive only a description of the behaviour. Whether an agent's work is closer to copying or to independent implementation is a case-by-case question. The exact limits also depend on the country and the situation. If you plan to study someone's software, or to reimplement it commercially, get advice on your specific case first.

REA's own support and usage guidance limits use to lawful purposes: research, education, interoperability and software preservation, on software you own or are authorised to examine. The project's disclaimer says it does not support circumventing copy protection or copying closed software. Those are the project's own policies. The disclaimer says separately that it adds no copyright-licence conditions to the MIT licence.

Three practical points:

• REA is not a sandbox. The project's security guidance says that opening an untrusted program hands the analysis to the local tool you chose, with your user permissions. Some analysis is static, meaning the program is not run, but following behaviour while it runs starts the target. Do not study something suspicious on your work machine without separate isolation, for example in a virtual machine with no personal credentials or keys.
• The agent reads the target's text too. A program may contain text with instructions aimed at the agent, and the agent can run commands. The glossary calls this prompt injection.
• Where the results are processed. Running the analysis locally does not by itself say where the results end up. If you use a cloud model, whatever the agent sends to it goes to that service. Check the data-handling terms before feeding it anything you are not allowed to share.

What to take from this

If you only use software services: you do not need to do anything. Nothing in this news is a reason to switch services or to fear that they will disappear.

If you buy or build software: do not assume that compiled code shipped to customers stays secret. Keep the logic that creates value on the server, do not embed keys or secrets in code shipped to customers, and consider how much of the product's value depends on data, service, support and trust, and how easily a competitor could reproduce those.

If you study software: possible uses include fixing compatibility with an old program, checking a vendor's claims and preserving software, but carefully documented successes are still few. First make sure you have the right to examine the target (see the legal section), record which finding each conclusion comes from, and check the agent's conclusions against the original findings and with tests.

If you just want to make sense of the news: REA is an example of what happens when an agent is handed tools that used to belong to specialists. The same pattern runs through vibe coding and AI-assisted programming. The analysis tools are old; using them inside an agent-driven workflow is the newer development, and a person's role may shift from doing the work to directing and checking it. How much work this saves, and how much expert oversight it still requires, remain open questions.

Where this leaves us

In short: REA makes it easier to work out how a narrow feature behaves, but there is no public evidence that it can replace a whole application. Next time you read that AI will kill software, ask three things: how many of the findings can be verified, how much human effort is really saved, and how fully the rebuild covers the original.

Sources

• REA, GitHub repository (morluto/rea)
• REA: disclaimer
• REA: security guidance
• REA: efficiency measurements (commit 7d8e4e4)
• DataCamp: Reverse Engineer Anything Tutorial
• MindStudio: What the Viral REA MCP Actually Does
• Startup Fortune: An AI agent that reverse engineers any software just hit number one on GitHub
• GhidraMCP
• Chromium source: the dinosaur game
• Software Directive 2009/24/EC (EUR-Lex)
• Court of Justice of the EU, C-406/10 (SAS Institute)