Reverse Engineer Anything: what the viral REA repo does, and what it means for makers

For most of this year, morluto/rea was a quiet GitHub repo. Then, in the first week of October, it took over GitHub Trending. Demo videos showed coding agents taking apart desktop apps and rebuilding features from the binary, and a lot of people decided software had just become copyable.

REA stands for Reverse Engineer Anything. We read the README, the project site and the early write-ups to answer two questions: what it really does, and what it changes for people launching software.

The short version

• It's a connector. REA is an MCP server and CLI. It doesn't decompile anything itself. It lets your coding agent drive tools like Ghidra, Hopper and IDA, plus browser and Android tooling.
• It works as a loop. The agent asks a question, REA inspects the app, and findings come back with evidence and a list of what's still unknown.
• The tools behind it are old. Decompilers have existed for decades. What's new is that an agent can now use them without a specialist in the room.
• The hype ran ahead of the evidence. Star counts went vertical. Careful comparisons are still thin, and at least one early side-by-side test found a plain agent got close without it.
• For makers, the moat moves. If a visible feature can be read and rebuilt, what protects you is the parts an agent can't decompile.

What REA is

The project describes itself as one MCP server for reverse engineering across binaries, applications and runtime behaviour. You install it with npx rea-agents setup, pick which agents to connect, and approve the plan. It names Claude Code, Codex, Cursor, Gemini CLI and Grok Build, and any agent that can run a local MCP server can use it.

The key detail is in the README. REA doesn't ship its own decompiler. For native apps it uses the copy of Hopper, Ghidra or IDA you already have. For everything else it calls existing tools: JADX for Android apps, a Chrome-family browser for websites, its own static analysis for JavaScript and Electron.

That list of targets is long. Native binaries, Electron apps, websites and saved network captures, Android APKs and devices, .NET assemblies, Go binaries, WebAssembly, firmware images and more. Each one comes with its own requirements, and some only work on Linux or macOS. Ghidra support on Windows is marked experimental.

How a session actually goes

You don't point REA at an app and get the source code back. You ask your agent about one feature, and the agent uses REA to go looking.

The project's own examples show the idea well. Asked how Chrome's offline dinosaur game speeds up, REA found the rule in the running game's script: start at 6, add 0.001 per update, stop at 13. Asked about the % button in Windows Calculator, it found that after a plus sign, % takes a share of the first number, so 200 + 10% gives 220. In both cases the useful output is a rule a person can check, with the evidence next to it.

That's also the honest limit. Results include unknowns and limitations, and somebody still has to read them. A wrong guess about a binary can look just as confident as a right one.

Is any of this new?

Not really, and the project doesn't claim it is. Ghidra, IDA and Hopper have been around for years. Security researchers, game modders and preservation projects have used them for a long time.

What changed is who can use them. Reverse engineering used to need someone who could read assembly and knew which tool to open. Now a coding agent can open the tool, read the output and try again, at three in the morning, for anyone who asks. REA is one of the first projects to package that well, and timing did the rest.

The week it went viral

The repo was created in April 2026. It started trending on 4 October. By 12 October, GitHub showed about 145,000 stars and 33,700 forks.

The releases came almost as fast. Versions 3.2 to 6.4 shipped between 3 and 11 October.

Stars measure attention, not results. The most-shared demos were rebuilds of small, well-understood apps. Write-ups that tried real comparisons were more measured. The gap between an agent with REA and a good agent on its own was smaller than the clips suggested, and the REA run was sometimes slower. That will change as the tooling matures, but it's worth knowing before you plan around it.

What it means if you're launching software

Here's the part that matters for most people reading Firstlaunch. Tools like REA make one kind of advantage cheaper to copy. A feature someone can see and click, a rule that lives in client code, a file format, a clever UI flow. If your whole product is a thin layer over a model, an agent can probably work out how it works.

None of that was ever a strong moat, and it's getting weaker. What's still hard to copy is everything that isn't in the binary: why you're building it, the people who already trust you, the channels you've earned, what you learn from real use, and how quickly you ship the next thing.

That's a big part of why we built Firstlaunch to be founder-first. Every launch starts with a one-minute founder video, YC-style. Anyone can rebuild a feature. Nobody can rebuild you.

Using it responsibly

• Only analyse what you're allowed to. The project lists lawful research, education, interoperability, preservation and software you own or are authorised to examine. Commercial tools like IDA Pro and Hopper still need their own licences.
• Know where your data goes. REA runs locally, but tool results go to your agent's model provider, under that provider's data policy. Think about that before you open anything proprietary.
• Runtime capture runs the target. Static inspection of JavaScript and .NET reads files only. Runtime capture runs the app with your permissions, so treat unknown binaries with care.
• Install from the real source. The official repo is morluto/rea and the package is rea-agents on npm. Lookalike repos offering Windows zip downloads have appeared, and the project says it has issued no token.

Questions makers are asking

Do I need REA to rebuild a feature?

Not always. For a web app or an Electron app, a capable coding agent can already read a lot of the shipped code. REA helps most with native binaries and Android apps, where the agent would otherwise have nothing readable to work with.

Can someone clone my whole app with it?

They can learn how visible features work, and rebuild some of them faster than before. Your servers, your data, your users and your team aren't in the binary. Most products are more than the part you can decompile.

Is it legal?

It depends on where you are, what you analyse and what you do with it. Interoperability and security research are protected in many places. Copying someone's product to sell as your own usually isn't. If you're unsure, ask a lawyer before you rely on it.

Should I protect my app against it?

Keep secrets and business rules on the server, not in client code, which was good advice before REA too. Obfuscation slows a person down more than it slows an agent. Your time is usually better spent on the things on the right-hand side of the chart above.

Sources: morluto/rea on GitHub, rea.tools, and daily star counts from Trendshift as reported by DEV Community. Star and fork totals are as shown on GitHub on 12 October 2026.

Building something people can't simply copy? Launch it on Firstlaunch, with your one-minute founder video up front.