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

Can AI produce a near-copy of an app, features and all, in moments, once it is given a finished program to study? That is what people are really asking about REA. The public examples I reviewed show reimplementations of narrow features. They do not yet show that a whole application can be reliably replaced, and that gap is the heart of this article.

Reverse engineering means working out how a program behaves without having its 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 by handing an AI agent the equipment for the job. 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, which tells it what REA can do.

The range of targets is wide: installed desktop programs, JavaScript and Electron apps, websites, Android apps, firmware and network captures. Support varies by platform and by which tools you have installed. On 21 October 2026 the repository showed roughly 357,000 stars. 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 for native programs, JADX for Android. REA uses your own installations of those tools and gives the agent one consistent way to call them. Even that is not 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. Function names, call relationships and pseudocode provide clues about what the code may do, but do not by themselves establish how a user-facing feature works. Important conclusions still need checking against the original findings and with tests.

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.

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. 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. 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 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. 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, 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. 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. It is still telling that the project publishes results that do not flatter it.

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. Those are three separate questions, and the sources reviewed reach at most the first.
• 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.
• 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.

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 weakens the idea that obscurity alone is protection.

The legal side

This section is not legal advice.

Function and protected expression need to be kept apart. In SAS Institute (C-406/10) the Court of Justice of the European Union held that the functionality of a program is not, as such, protected expression under software copyright. That is no general licence to copy code, manuals or other protected material. Reimplementing a feature in your own code is a different act from copying someone else's code, or their manuals and images.

Licence terms are not the only thing that matters, because some rights around studying programs are set by law. The exact limits 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. That is the project's own policy. Its disclaimer says separately that it adds no copyright-licence conditions to the MIT licence.

Two 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. Do not study something suspicious on your work machine without separate isolation.
• 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 buy or build software: do not assume that compiled code shipped to customers stays secret. 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. Always 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

REA gives agents structured access to software inspection tools, and it may make it easier to work out how a narrow feature behaves. Judge any claim about it on three things: how many findings can be verified, how much human effort it saves, and how fully a 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
• Court of Justice of the EU, C-406/10 (SAS Institute)