REA: Reverse Engineer Anything With AI Agents [2026]

REA is an open-source MCP server and command-line tool that lets AI agents like Claude Code, Codex, and Cursor reverse engineer anything: native binaries, Electron and JavaScript apps, .NET assemblies, Android APKs, and live browser behavior. Say that phrase to most developers and they picture uploading their target to some cloud model. That's not what happens. REA runs the whole analysis on your own machine and hands the agent the disassembly, so the model can explain how a feature works right down to the instruction level.

That one detail changes everything, and almost nobody is writing about it yet. So here's the plain-English version.

What Is REA, and Why It's Suddenly Everywhere

The morluto/rea repository went from obscure to roughly 145,000 stars and 33,600 forks in a matter of days, sitting on 2,527 commits and shipping under the permissive MIT license. Its explanatory blog post went live on 10 October 2026, and the YouTube channel Better Stack called it the "top trending repo on GitHub." Search "rea reverse engineer anything with agents" a week ago and you'd find the project's own docs and nothing else. No independent explainer. No SERP competition. No People-Also-Ask box. This is ground-floor coverage of a GitHub trend that hasn't finished exploding.

The pitch is almost too good: spot a feature you like in any app, point an agent at it, understand how it works. REA sits right at the collision of two of 2026's loudest currents, AI agents and reverse engineering, and it hands a decades-old hobbyist craft to anyone who can type a sentence.

Here's the rundown from the channel that shoved it into everyone's feed:

The worked example on REA's homepage is the one that makes it click: why does a calculator show 220 when you type 200 + 10%? Doing that by hand means decoding branches, tracing calls, and recovering the rule from x64 assembly. With REA it's one question in English, and the agent comes back with the actual arithmetic the binary runs.

How REA Works: MCP, Local Analysis, and Evidence-Backed Answers

Under the hood, REA is a server that speaks the Model Context Protocol (MCP), the open standard that lets a large language model call external tools in a structured way. Run the setup and REA registers itself as an MCP server with your coding agent, then installs the matching workflow and skill instructions. From that point the agent has a new set of verbs: disassemble this, inspect that, trace this call path.

The second half is what separates REA from pasting a hex dump into a chatbot. Every bit of analysis runs locally. No code and no binaries leave your machine. The disassemblers, the decompilers, the APK unpackers all execute on your hardware, and the agent reasons over what they produce.

The third piece is the one I keep coming back to. Every REA result ships with its supporting evidence and the stated limitations behind the conclusion, not just a bare answer. You get the offset, the decompiled snippet, the reasoning chain, and an explicit note on what the tool couldn't determine.

The honest part of REA isn't the answer. It's that every answer ships with the evidence and the limitations behind it.

This is where real experience changes how you read the feature. I run a 7-agent publishing pipeline for this blog, 261+ posts deep, and the clearest lesson it taught me is that deterministic, evidence-producing steps placed before any LLM judgment catch more than doubling the size of your review model does. REA's evidence-and-limitations contract is that same bet applied to binary analysis. A chatbot will hallucinate a decompilation and sound completely sure of itself. REA forces the model to show its work, which is exactly why its output is worth trusting when a bare prompt to a frontier model is not.

What You Can Reverse Engineer With REA

The honest answer to "what can this actually do" is: more surface area than any single traditional tool covers. REA spans four target families.

• Native binaries (compiled C, C++, Rust, Go machine code). This is the deep end, and it needs a disassembler.
• JavaScript and Electron apps (Slack, Notion, VS Code, pretty much anything shipped as a packaged web app). Static inspection here needs no native tooling at all.
• .NET assemblies (managed C# and F# DLLs and executables). Also inspectable statically, no disassembler required.
• Live browser behavior (what a page does when you click something: which request fires, what script generated it).

Deep native analysis needs an existing Hopper, Ghidra, or IDA install, or REA's setup can install Hopper for you with your approval. Static JavaScript and .NET inspection need no native disassembler whatsoever, which drops the barrier to near zero for the enormous slice of modern desktop software that ships as Electron. Want to keep the whole loop offline and private? Pair the agent with a local LLM instead of a cloud model and trade a little reasoning quality for a full air-gap.

And you don't need a coding agent at all. REA's CLI exposes the same workflows directly. A command like npx -y rea-agents@latest analyze-javascript-application /path/to/app --json runs standalone and emits structured output you can pipe wherever you want.

How to Reverse Engineer Anything With Agents: Setup in Minutes

Setup is genuinely a one-liner. Running npx rea-agents setup registers the MCP server with your agent and installs the skill instructions. After that it's a matter of pointing your agent at a target and asking a question.

The breadth of supported clients is unusual this early in a project's life. REA's setup explicitly supports 14 agents and editors: Claude Code, Claude Desktop, Codex, Cursor, Gemini CLI, Windsurf, Devin, OpenCode, Antigravity, GitHub Copilot CLI, Command Code, Grok Build, OMP, and VS Code. Grok Bot connects separately through its own chat connector.

If you're deciding which agent to drive it with, here's a pattern worth stealing. The hard-won lesson from running my own pipeline is that model-per-job-shape beats one-model-everywhere: a Sonnet-class model for tool-heavy loops, an Opus-class model for the prose and synthesis. Reverse engineering is almost all tool loop, so a fast tool-calling model paired with REA's local analysis is the pragmatic default. The short version of getting running:

1. Install a disassembler if you plan to touch native code (Ghidra is free; Hopper can be auto-installed).
2. Run npx rea-agents setup and pick your agent from the list.
3. Open your agent and confirm the REA MCP tools are registered.
4. Point it at a target file, APK, or running browser session.
5. Ask your question in plain English, and read the evidence it returns, not just the conclusion.

Real Case Studies: Aegis, a CTF Flag Checker, DX-Ball, Notion, and Touhou TH04

REA ships five official case studies, and together they draw the clearest map of its range. Here's the tour.

Aegis (Android APK). REA reconstructs how the open-source Aegis authenticator generates its 6-digit code: a clean demonstration of APK decompilation plus cryptographic logic recovery. If you've ever wondered how a time-based one-time password actually gets computed inside the app, this is that, automated. For the manual version of this discipline, I've written a full walkthrough of reverse engineering Android APKs with jadx and Ghidra.

A DownUnderCTF flag checker (native binary). The capture-the-flag use case, where REA solves a flag-checker challenge by recovering the validation logic straight from compiled machine code. CTF players have quietly been the most enthusiastic early adopters, and it's obvious why.

DX-Ball (1996 Windows game). REA recovers the sound-pan calculation from a 30-year-old executable. The 1996 date is the whole point: this works on software that predates every modern build toolchain.

Notion (packaged Electron app). REA traces how Notion copies text and HTML through its Electron IPC bridge, from renderer to preload to main process. This is the "how does my favorite app pull that off" scenario dragging in developers who've never opened a disassembler.

Touhou TH04 (16-bit PC-98 DOS game). REA reconstructs how the game aims a ring of bullets, on a 16-bit PC-98 target about as far from a modern binary as you can get.

That last one is worth sitting with, because the person behind those reconstructions has thought harder about this than most. As N0zoM1z0, a game-reconstruction reverse engineer and REA blog contributor, argues, the lasting value of manually reversing games like TH08 and TH04 was never the finished answer. It was learning verification and building knowledge that compounds across projects. Agents don't erase that. They move the bottleneck from "can I decode this" to "can I trust what I decoded," which is the entire reason REA's evidence model exists.

REA vs. Traditional Tools: Ghidra, IDA, Hopper, and Frida

The mistake to avoid is thinking REA replaces the tools you already know. It doesn't. It's a layer sitting on top of them.

Ghidra, IDA, and Hopper still do the heavy lifting on machine code. What REA adds is the reasoning layer and the plain-English interface. Instead of you manually renaming variables and chasing cross-references, the agent orchestrates those tools and narrates the result.

So how is this different from just asking a chatbot to explain a disassembly listing? Simon Willison, who has documented more real LLM-assisted tool use than almost anyone, has shown again and again that models are genuinely good at reading code when you hand them the actual artifact, and genuinely unreliable when you ask them to recall or invent it. REA operationalizes that. The model never guesses at the disassembly. It reasons over the real output of real tools and cites it.

There's a security wrinkle here that deserves more attention than the hype gives it. You're pointing an autonomous agent at untrusted binaries, and the agent's context is now full of strings and symbols an attacker may have crafted on purpose. That's a live prompt injection surface, and it folds into the broader discipline of AI security that every agentic tool now has to reckon with. Treat REA's analysis environment the way you'd treat any sandbox running hostile input, and read up on LLM security before you let an agent act on what it finds.

Is Reverse Engineering With AI Agents Legal and Ethical?

This is the question REA's own site never touches, and it's the one that decides how the tool actually gets used.

Reverse engineering is not inherently illegal in the United States. It's a long-recognized practice, protected in specific contexts. The friction comes from three places: software licenses, copyright law, and intent.

First, EULAs. Most commercial software licenses carry a clause banning reverse engineering. Violating it is a contract matter, and courts have been inconsistent about whether those clauses are even enforceable, but it's a real risk for production software you've agreed to terms on.

Second, the DMCA. Section 1201 of the Digital Millennium Copyright Act bans circumventing technical protection measures, but it carries explicit exemptions for interoperability, security research, and encryption research. The U.S. Copyright Office's triennial 1201 rulemaking renews and expands these, and as Cory Doctorow has argued for years, the gap between what the law nominally permits and what it practically chills is where most researchers get stuck. Good-faith security research on software you lawfully possess generally sits inside the exemptions. Cracking DRM to pirate content does not.

Third, intent. A CTF binary you were handed to solve, an open-source authenticator like Aegis, a 1996 game nobody sells anymore: all clean. Reversing a competitor's live production service to clone it, or stripping license checks, is a different universe of risk no matter which tool you reached for.

The uncomfortable truth is that REA lowers the skill floor without touching any of this. Having spent years building GIS and order microservices at Swiggy that supported millions of deliveries, I've stared at enough systems I only half-understood to know that understanding was never the dangerous part. Acting on it is. An agent that makes reverse engineering trivial makes the legal and ethical judgment the scarce resource, not the technical skill.

My prediction: within a year, every serious reverse-engineering tool will have an MCP layer like this one, and the interesting fights won't be about whether agents can read binaries. They'll be about whether EULA anti-reverse-engineering clauses survive contact with a world where understanding any app is one sentence away. If you ship software, that clause in your license just got a lot more theoretical. Plan accordingly.

Photo by Joan Gamell on Unsplash.