REA: The Fastest-Rising Repo Is a Little Scary (And a Real Test)

0:00There's a new open-source repo that lets your coding agent look inside an app it has no source code for, figure out how a feature works, show you the evidence, and then build you a version — and people are using it to crack desktop applications that have been closed-source for 20 years. It's REA, short for Reverse Engineer Anything, and it's one of the fastest-rising repos on GitHub right now. Rob Shocks (Switch Dimension, 20 years a developer) wants two things: to correct what most posts get wrong about it, and to explain why it changes something big for anyone who ships software. Then he puts it to a real test.

What REA is

1:00The README pitch: see a feature in an app you want in your own product, ask your agent to investigate it, and it does so without the source code. Under the hood it's an MCP server plus a CLI that plugs into Claude Code, Codex, Cursor, or anything that speaks MCP. The scope is broader than the Electron apps where you could already read the JS: native binaries on Mac, Windows, and Linux — a huge chunk of the desktop apps you use daily — plus .NET, Android APKs, firmware, websites, and even smart-contract bytecode.

What you get back

1:38The correction Rob makes up front: REA doesn't hand you the original source code. Nothing can — when an app is compiled, the original code is gone. What the investigation returns is pseudo-code, assembly, module maps, call paths, and network activity, each with evidence attached: where the finding came from, how confident the model is, and what it couldn't figure out. The point is that this used to cost a lot of money and time; now the friction is gone.

The architecture

2:11REA itself isn't a decompiler — "nothing revolutionary or special," as Rob puts it. It wraps the serious tools reverse engineers already use: Ghidra (free, from the NSA), Hopper (Mac), and IDA Pro (the expensive industry standard). Those tools are powerful and notoriously hard to learn; REA layers "dozens of plain-text intent tools" on top — open this binary, find the strings, follow the function calls — so an agent can find its way through. 2:53Setup is npx rea-agents setup: it shows a plan of what it will change, backs up your config, adds the MCP server plus a skill that teaches the agent the investigation workflow, and asks before touching anything critical.

The vault test

4:27Rather than "trust me bro," Rob built his own target: a vault app where you type an unlock code and it either lets you in or doesn't, with a hidden message that only appears when you get it right. He compiled it the way a real app ships — every function name stripped, so checkUnlockCode is just "a function at this address." Then he handed it to an agent with REA and Ghidra. 5:17The agent opened the binary, got back 242+ functions (each named just fun plus an address), started decompiling machine code back into C-like pseudo-code, and within a handful of calls found the one that matters. 5:32Does it actually work? It wrote a small code generator and produced the unlock code AGNT-1001 — and he was in. The telling detail: it didn't pull out the source or copy it. It understood the logic and wrote something completely new — a code generator his app doesn't even have.

The scary thesis

5:56The big claim: for years software has had an unspoken protection — you could always reverse-engineer an app, but it was slow, specialized, and expensive, so almost nobody bothered. That friction was the protection, and REA deletes it. Rob explicitly pushes back on the doom-posting (the "planes will start falling out of the sky" crowd): there are still many hurdles and layers before you can compromise a real system. But the realistic consequence stands — 6:56if you ship a desktop app, browser extension, game, mobile app, or a big client-side JS bundle, assume anyone's agent can now map out how it works. His framing: this isn't a disaster, it's a correction — "the code was never really the moat." Your real moat is your data, your users, your cloud security, how fast you ship, your taste, and the logic that runs on your servers where nobody else can inspect it.

Three warnings

7:22Three things to internalize:

• Legal. Reverse engineering for interoperability is generally protected, but many apps' terms of service explicitly ban it, and breaking DRM or encryption is a separate legal problem. Safe ground: your own apps, open-source binaries, security challenges, and things you're authorized to test. REA's own disclaimer says you're responsible.
• Not a sandbox. If you run a target through its runtime capture, it runs with your permissions. Don't point it at a random binary off a forum, and keep your agent's approval-prompt switch on — who knows what prompt injection is buried inside.
• Fast-moving repo. Lots of breaking changes and amazing energy — update constantly.

What it's good for

8:17As a software engineer, Rob would use it to learn how great desktop apps handle offline sync, clipboards, and search — then build his own; to audit the many Electron apps on his machine; and to recover logic from his own builds when the source went missing. What he wouldn't do is point it at a competitor and clone the product — legally risky, and it misses the point. Understand the idea and build something better, because you're never going to match their distribution anyway. And the security flip side: point it at apps on your own machine and ask "what is this actually doing, what is it sending home?" — there have been cases of compromised 3D printers and even coffee machines quietly exfiltrating data.

Claims checked

Sources & further reading