REA Can Reverse Engineer Almost Anything. Here Is What That Actually Changes

A tool called REA, short for Reverse Engineer Anything, spent the first half of October 2026 near the top of GitHub's trending list. The pitch is blunt: point an AI coding agent at an app you do not have the source for, and it will read the compiled program, explain how a feature works, show you the evidence, and help you rebuild that feature in your own project.

The headlines leaned on the obvious anxiety, and the star count got quoted so many different ways that it became its own tell. One launch write-up reported it crossing 66,000 stars in a day and 113,000 soon after, another put it past 140,000 in five days, the repository page I looked at showed well over 300,000, and a skeptical fact-check argued several of those figures do not line up. I am not going to add another number to that pile. What matters is not whether it is at number one this week, it is what the thing actually does and what you should change because it exists.

I went through the REA repository, the vendor launch post, a careful hands-on test, and a security paper that most of the coverage ignored. Here is the grounded version, with the parts that actually affect anyone who ships software or defends it.

What REA actually is

REA is an open-source project, MIT-licensed, published on npm as rea-agents. It is two things in one package: a command-line tool, and an MCP server that plugs into an AI coding agent. It supports Claude Code, Codex, Cursor, Gemini CLI and Grok Build out of the box, and anything else that speaks MCP with a manual config.

On its own, an AI model cannot disassemble a binary. REA is the layer that lets it. Underneath, it drives the tools reverse engineers already use, and routes each kind of target to the right one:

The workflow the project describes is a loop: decompile, understand, recreate. The agent asks REA for analysis, REA runs the heavy tool locally and returns a structured answer, and the agent reasons over that answer rather than over a wall of raw assembly.

The one honest design idea: evidence first

The part of REA worth borrowing as a concept, whatever you think of the tool, is that it is built to make the agent show its work.

Instead of letting the model say "this function checks a password" and trusting it, REA is structured around what it calls an evidence bundle: a conclusion is supposed to point at a specific function, a byte offset, a cross-reference or a recovered source map. It even tracks a ledger of claims the rebuilt code is supposed to satisfy, and a coverage score for how much of a feature is actually proven versus guessed. When the decompiled code and the observed runtime behaviour disagree, that contradiction is flagged rather than smoothed over.

That matters because large language models are confident narrators, and a confident wrong answer about a binary is worse than no answer. Tying each claim to an artifact is the same discipline a good threat hunter uses: every line in a finding points at a query and a row of evidence. It does not make the model correct, but it makes the model checkable, which is the next best thing.

Is it magic, or is it Ghidra with a wrapper?

The most useful thing I read was not a launch announcement, it was a hands-on test by someone who ran four separate jobs through Claude Code twice: once with REA, and once with the agent just told to install and drive Ghidra itself.

Both approaches finished all four tasks. REA was faster on three of them and slower on one. When the agent did not have REA, it simply wrote its own Ghidra scripts and got there anyway. The tester's verdict was that REA was not fundamentally more capable than a patient agent with a free disassembler, it just served decompiled code to the model more directly.

That is the honest framing the hype skips. REA did not invent AI-assisted reverse engineering, and it did not unlock anything a determined person could not already do. What it changed is the friction. One setup command, a dozen target types, and an evidence-first structure lower the skill floor a lot. A study of 153 practitioners cited in the coverage found LLM help lifted novices toward expert-level comprehension. That is the real story: not a new superpower, a much shorter on-ramp.

The legitimate uses are real, and they are the point

It is easy to write about a tool like this as if its only purpose is theft. It is not, and treating it that way misreads where the value is.

• Malware analysis and incident response. Pulling apart a hostile binary to understand what it does is daily blue-team work. An agent that serves decompiled logic with evidence can speed up triage, as long as you remember the warning further down about hostile samples.
• Interoperability. Understanding an undocumented file format or protocol so your own software can read it is a classic, and in many places legally protected, reason to reverse engineer.
• Security research. Finding and reporting vulnerabilities in software you are authorised to test.
• Software preservation. Keeping abandoned or orphaned software running, a genuine use the project calls out.
• Learning. Reading how real programs are built is one of the fastest ways to understand low-level systems, and an agent that explains assembly in plain language is a strong study aid.

Every one of those is lawful and useful. The tool is neutral. The judgement sits with the person pointing it at something.

What you should change if you ship software

Here is the part most of the viral coverage buries, and it is the part that actually matters for anyone building a product.

REA does not break anything that was secure. It makes something that was already true impossible to keep ignoring: anything you ship to a user's device can be read. Client-side code has always been reverse-engineerable. What changed is the cost. Work that took a specialist days now takes an agent minutes at the price of some API calls, so the window where "nobody will bother" protected you has effectively closed.

The defensive posture that follows is not new, it is just newly urgent:

• Keep secrets and real logic server-side. API keys, pricing logic, model weights, licensing checks and anything you cannot afford to have read do not belong in a shipped client. If the client can run it, assume a competitor can read it within days.
• Treat obfuscation as a delay, not a wall. It raises the cost and buys time. It does not make code unreadable, and at least one analysis firm argues heavy obfuscation can even mislead a decompiler into producing plausible-but-wrong output, which cuts both ways.
• Update your threat model. Assume AI-assisted reverse engineering is a baseline capability your adversary has now, the same way you assume they can read your JavaScript.
• Ship value faster than it can be copied. When the client is readable, the moat is execution, iteration and the server-side half of your product, not secrecy.

The twist nobody is talking about: the analyst is now a target

There is a second-order risk here that I care about more than the cloning panic, because it is the kind of thing that is easy to miss until it bites.

If you hand a compiled program to an AI agent and ask it to explain the code, that program is now untrusted input feeding an LLM. Researchers at the Naval Postgraduate School demonstrated exactly the attack you would fear: they compiled extra strings into a binary that did not change what the program does, but did carry a prompt injection. When a Ghidra-connected agent read those strings, it reported a decompilation of a completely different, innocent-looking program. The real behaviour was hidden behind text written for the model, not the human.

If that sounds familiar, it is the same class of attack I pulled apart in the Microsoft 365 Copilot threat hunt: instructions smuggled into content that an AI reads and obeys, indirect prompt injection. There, the poisoned content was an email. Here, it is the binary under the microscope. It is also cousin to the AI agent I wrote about that got tricked into attacking its own network: the moment an agent trusts input it should have treated as hostile, the input is in charge.

The practical takeaways are short and worth taking seriously:

• Analyse untrusted or malicious samples in an isolated VM, not on your working machine, which you should be doing anyway.
• Treat anything the agent concludes about a hostile sample as a lead to verify against the raw disassembly, never a verdict.
• Remember the agent is reading attacker-controlled data. That is the whole threat model of this decade, and it does not pause because the data happens to be a binary.

So where does that leave REA

It is a genuinely capable, well-built, open tool that lowers the barrier to something people have always been able to do. It is not a crime in a box, and it is not magic. The clone-your-app-overnight framing oversells what it does and misses the two things that actually matter: client-side code was never private, and the AI doing the reading can itself be fooled by what it reads.

If you build software, the move is to assume your shipped client is an open book and design around that. If you defend networks, add AI-assisted reverse engineering to the list of things your adversary can do cheaply now, and add poisoned input to AI tools to the list of things your own side has to guard against. Both of those were true last month. A trending repository just made them impossible to keep filing under "later."

If you want to look at the project itself, it lives at github.com/morluto/rea, the vendor's own writeup is here, and the attack-the-analyst research is the paper worth reading in full. Get it only from the official source, because a copied name and README do not make a download real, which is a lesson that long predates AI.

Frequently asked questions

What is REA (Reverse Engineer Anything)?

REA is an open-source, MIT-licensed MCP server and command-line tool, published on npm as rea-agents, that gives an AI coding agent real reverse-engineering tools. It drives engines such as Ghidra, Hopper, IDA and JADX, plus a Chrome-family browser for websites, and hands the agent structured findings with evidence instead of raw disassembly.

How do I install REA?

With a supported Node.js version (22.19 or later, 24.11 or later, or 26+) and npm, run npx rea-agents setup. The wizard detects your agents, shows the configuration changes, backs up your existing settings and registers the MCP server. Native binary analysis also needs a separately installed engine such as Ghidra, which needs a recent JDK of its own.

Which AI agents does REA work with?

The setup wizard supports Claude Code, Codex, Cursor, Gemini CLI and Grok Build. Any other client that can launch a local MCP server can be registered by hand.

Does REA send my files to the cloud?

The analysis runs locally, so the binary itself stays on your machine. The findings REA produces are read by your AI agent, so they travel to whatever model provider that agent uses, under that provider's data policy. Keep confidential or customer code away from it unless that is acceptable for your setup.

Do I need IDA Pro or Hopper to use REA?

No. Ghidra is free and can drive the native workflows, and static JavaScript, Electron and .NET inspection need no native engine at all. If you do use a commercial tool such as IDA Pro, Hopper or JEB, you supply your own licence. REA grants no licence, key or activation.

Is reverse engineering software legal?

It depends on what you analyse, where you are, and the licence terms of the software. Many jurisdictions allow it for interoperability or security research, and the project says it is for lawful research, education, interoperability, preservation and software you own or are authorised to examine. That is not blanket permission, so read the licence and get real legal advice before anything commercial. I am not a lawyer.

Can a malicious file attack an AI reverse-engineering agent?

Yes, in principle. Researchers at the Naval Postgraduate School showed that strings compiled into a program can carry prompt injections that make a Ghidra-connected agent report a decompilation of a different program. Treat anything the agent concludes about an untrusted sample as a lead to verify, not a verdict, and keep untrusted samples in an isolated VM.

Is REA actually better than telling Claude to use Ghidra directly?

Not dramatically, going by the one careful hands-on test I found. The tester ran the same jobs through Claude Code both with REA and with plain Ghidra scripting, and both finished every task. REA was faster on three of four and slower on one. Its real value is the evidence-first structure and the breadth of targets behind a single setup command, not a capability a patient agent could not reach another way.