REA ("reverse engineer anything") is a fast-rising GitHub repo — roughly 7–8k stars in a day — that packages an MCP server and CLI around existing reverse-engineering tools like Ghidra, Hopper and IDA Pro so a coding agent (Claude Code, Cursor, Codex) can investigate compiled binaries it has no source for. It doesn't recover original source code; it returns pseudo code, assembly, module maps, call paths and network activity with confidence levels and evidence. Rob demos it on a deliberately stripped and optimized "vault" app he built, and the agent finds the unlock logic among 242+ unnamed functions and writes a working code generator. His conclusion: reverse engineering was always possible, REA just removes the friction that acted as de facto protection, so code was never really the moat.
- REA is an MCP server plus CLI wrapper around established reverse-engineering tools (Ghidra from the NSA, Hopper, IDA Pro), exposing dozens of plain-language "intent" tools like open this binary, find the strings, follow the function callers.
- It works on native binaries for Mac, Windows and Linux, plus .NET, Android APKs, firmware, websites and smart contract bytecode — not just Electron apps.
- It does not return original source code; compilation destroys that. Output is pseudo code, assembly, module maps, call paths and network activity, each finding tagged with its source, the model's confidence, and what it couldn't determine.
- In the live test Rob compiled his own "vault" app with function names stripped; the agent loaded 242+ anonymous functions, decompiled, located the unlock check within a handful of calls, and wrote a generator that produced a valid code (AGNT-1001).
- The agent didn't copy code — it understood the logic and wrote something new that the original app didn't even contain.
- Security warnings: this isn't a sandbox, runtime capture runs with your permissions, binaries may carry prompt-injection payloads, and you should keep agent approval prompts on and run things in a sandbox.
- Legal caveats: reverse engineering for interoperability has generally been protected, but many terms of service ban it outright and breaking DRM or encryption is a separate legal problem; your own apps, open-source binaries and authorized tests are safe ground.
- Rob's framing is that this is a correction rather than a disaster — the real moat is data, users, cloud security, shipping speed, taste and server-side logic, and the defensive use case (auditing what apps on your machine send home) is genuinely valuable.
- Setup is a single command, npx rea-agent-setup, which shows a change plan, backs up your config, adds the MCP server and installs a skill that teaches the agent how to investigate; the repo is moving fast with frequent breaking changes.
The only concrete demonstration in the video, and it shows the key distinction between recovering source and reconstructing logic.
It opens up the binary and it gets back 242 plus functions. Every one of them is just called fun and an address... Within a handful of calls it's actually found the one that matters... It didn't copy the code. It understood the logic and then wrote something completely new, a code generator, which my app doesn't even have.
The central argument of the video, delivered as a calm counterpoint to the panic posts circulating about the repo.
That friction of reverse engineering was the protection and REA basically deletes all that friction... Code was never really the moat in the first place. Your moat really is in your data, your users, your cloud security, how fast you ship, your taste, and the stuff that runs on your servers.
It doesn't just hand you the original source code. Nothing can do that. When an app is compiled, the original code is gone.
That friction of reverse engineering was the protection and REA basically deletes all that friction.
If you ship a desktop app, a browser extension, a game, a mobile app, or a big client-side JavaScript bundle, you should now assume that anyone's agent can map out how it works.