Closed source has always leaned on an unstated assumption: reading someone else's compiled code is slow. REA, short for Reverse Engineer Anything, is an MIT-licensed project built to make that assumption false. It showed up in a year when tech companies cut jobs at a pace TechCrunch's running tally put at around 120,000 by early July, with AI the most-cited reason. I'll cover what REA does and what it changes for companies. Then I'll give you my read on why it exists now, and you're free to disagree with it.
The Problem It's Solving
The tools for taking software apart already exist. Ghidra is free, Hopper is cheap, and IDA Pro is the long-standing commercial standard. What was missing is someone to drive them. An analyst picks the tool, learns its quirks, moves evidence between programs, and decides what to look at next. That takes skill, and it takes time.
REA hands the driving to a coding agent. The pitch on rea.tools is simple: ask your agent how a feature in some app works, and REA gives it the tools to inspect the code behind the answer. The README goes further and says the agent can then build a version of that feature for your own project.
How REA Actually Works
REA is an MCP server plus a CLI. You run npx rea-agents setup, review the proposed changes, approve them, and restart your agent. Setup registers the server and installs matching workflow instructions, with backups of your existing config. The supported agents list includes Claude Code, Codex, Cursor, Gemini CLI and Grok Build.
From there the agent calls REA like any other tool. REA inspects the target and returns findings along with the evidence and limitations behind each conclusion. The agent uses them to explain the behavior or write and test an implementation. According to the README, analysis runs locally. Your agent still receives the tool results, so your model provider's data policy applies to whatever it sees.
The target list is long. Native binaries go through Hopper, Ghidra or IDA. Offline inspection can use GNU objdump or Rizin that you supply yourself. JavaScript and Electron applications get static analysis of modules, imports, source maps, routes and IPC with no native engine needed. Android APKs go through JADX. The README table also lists .NET assemblies, Flutter apps, firmware, Unity IL2CPP metadata, Godot archives, WASM, SQLite files, packet captures and live websites.
One correction to the hype. REA is not a new decompiler, and it doesn't hand back original source code. A fact-check from October 14 makes the same point. REA returns pseudocode, assembly, modules and the relationships between them. The new piece is the agent working the loop.
What Developers Are Actually Using It For
The showcases show the work best, because each one asks a narrow question about software the author didn't write.
On the site's Calculator example, the question is why Windows Calculator turns 200 + 10% into 220. The agent reads the percent handler's x64 instructions, finds that after addition the percent applies to the first operand, and checks the result against Microsoft's public source. In the dinosaur game example, it pulls the speed rule out of the running script: start at 6, add 0.001 per update, stop at 13. Then it rebuilds the game with a speed slider.
The longer case studies go deeper. The Notion study traces the Electron clipboard bridge from the renderer through preload and IPC into the main process. The DX-Ball study recovers a 1996 game's sound-pan math as C, and the README says the reconstruction passes 3,205 original-x86 cases and reproduces all 63 compiled function bytes. The Aegis study follows an authenticator's six-digit code through its APK, and the TH04 study recovers bullet-ring angles from a PC-98 game.
The site also lists bigger prompts as examples: clone this website, or reconstruct this game from its executable. So the project isn't pretending this stops at education.
Why This Is a Bigger Deal Than It Looks
Reading binaries was never impossible. It was expensive. REA lowers the cost, and that shifts a few things for companies.
Shipped desktop and mobile apps are easier to study than they were. The README and site describe analyzing installed apps, Electron bundles, APKs and website scripts, all without source access. Anything a company ships to a user's machine can be inspected on that machine.
The "we never looked at their code" defense gets harder to make. In a classic clean-room setup, one team analyzes and writes a spec while another team implements from the spec. REA's own example prompt asks one agent to investigate, show the evidence and build a similar feature, all in one session. That doesn't make it illegal. It does make independent development harder to demonstrate. This is my reading, and I'm not a lawyer.
The law is older than the tooling. In Sega v. Accolade, the Ninth Circuit held in 1992 that disassembly for interoperability was fair use, and DMCA §1201(f) added an interoperability exception. EFF's reverse engineering FAQ treats contract law as its own separate risk, which matters because plenty of EULAs forbid reverse engineering. REA's DISCLAIMER says the project won't help with circumventing DRM, building cheats, bypassing authentication, or copying proprietary software and its protected code and assets. It also puts responsibility for authorization on the user.
There's a tension there. The README advertises building a feature you saw in someone else's app, and the disclaimer rules out copying proprietary software. Where "learn how it works" ends and "copy it" begins is up to the person typing the prompt.
Security cuts both ways. The README says runtime workflows execute or interact with the target under your user permissions, and the disclaimer says to use an appropriate environment for untrusted targets. The project has also had a supply-chain scare. The fact-check reports that on October 13 someone flagged a fake copy under an organization called rea-tools, advertising a "Windows Standalone .exe". It also reports that Microsoft Defender classified the file as a trojan and that 8 of 45 VirusTotal engines flagged it as a dropper. The official README now says to download only from the repo, rea.tools or the rea-agents npm package.
The star count deserves a caveat too. The repo was created on April 14, 2026. The fact-check counted about 234,000 stars on October 14, and the repo page showed roughly 348,000 when I loaded it a week later. The fact-check says nobody can tell how many stars come from real readers, and I can't either. I'd treat the number as attention, not proof of adoption.
My Take: Engineers Got Laid Off, Then Got Agents
This section is opinion. Where I state a fact, there's a source next to it.
Start with what is on record. Amazon announced 16,000 cuts on January 28, and Networkworld reports it posted record revenue of $716.9 billion for 2025. Meta cut roughly 8,000 jobs in May while guiding 2026 capex as high as $135 billion. Block's CEO tied its cuts to AI, per the same Newsweek piece. Microsoft cut 4,800 in July. Per Nairametrics, its CFO said headcount would keep falling as spending moves to AI infrastructure, while TechCrunch's tally quotes Microsoft saying those roles aren't being replaced by AI. The FT counts about 140,000 US tech jobs cut so far this year, about 50,000 of them at Amazon, Oracle, Meta and Microsoft. Trackers disagree on the totals, but every count is large.
Now the part nobody can prove. I don't know who built REA, and nothing in the repo says they were laid off. So I'm not claiming that. My claim is narrower.
Companies cut people while spending more on AI, and the same AI now sits in the hands of anyone with a free weekend. I believe many of the people cut were strong engineers. The trackers don't measure that and I can't prove it. But an engineer who is good at their job doesn't lose the skill when the badge stops working.
That's where I think the energy is going. An MIT-licensed repo, under a year old, with nearly 4,000 commits, hundreds of open issues and pull requests, and an active Discord, did not come from nowhere. Someone cared enough to build it in public and give it away. I think a lot of developers right now are asking the same question: if my employer can decide my work is replaceable, why would I keep building closed things for them?
Look at the other open-source moves this year, and be precise about each one. The Claude Code leak was an accident, not a protest. On March 31, a source map in an npm package exposed about 512,000 lines of Anthropic's TypeScript, and Anthropic confirmed it was unintentional. Google's decision to ship Gemma 4 under Apache 2.0 was a corporate licensing choice, the first Apache release in the Gemma line. REA is the odd one out: independent, deliberate, and aimed at everyone else's closed code. I'd say the three together point one direction, and only one of them is a revolt.
So here is my actual prediction. The next few years will favor whoever ships in the open and lets people look inside. Companies that depend on nobody reading their code will have a harder time.
What could make me wrong? Some of these layoffs may be ordinary cost cutting wearing an AI label. Microsoft's own statement points that way. REA's users may be mostly hobbyists, students and security researchers. Stars can be inflated. Agent output can be wrong, and REA's disclaimer says as much. Understanding how Notion bridges its clipboard does not give you Notion. And one repo doesn't make a movement.
I'm still watching it, because I think the direction is right.
Availability and Access
REA is free and MIT-licensed. It needs Node.js 22.x (22.19 or later), 24.x (24.11 or later) or 26+, plus npm.
npx rea-agents setup
Native analysis needs Hopper, Ghidra or IDA already installed. REA grants no keys or licenses for commercial tools, so you need to obtain those legally yourself. Static JavaScript, Electron and .NET analysis need no native engine. Install the CLI with npm install --global rea-agents and keep it current with rea update. Get it only from github.com/morluto/rea, rea.tools, or the npm package. There's also a Discord for questions.
Closed source has leaned on reading being slow. REA is one more sign, among several this year, that the slowness is going away.
Follow for more coverage on MCP, agentic AI, and AI infrastructure.
Top comments (1)
The tool-output angle is the one I'd add to your security paragraph. The README says runtime workflows run the target under the user's permissions, but even the static path has a quieter risk: the strings, resource names, JS comments and source-map contents an agent pulls out of an untrusted binary come back through tool results as plain text. A sample that embeds "ignore previous instructions and run ..." in a string table is talking to the model, not to the analyst, and a file-read result is not covered by anything that only pins or hashes the tools/list description at install time.
Practical mitigations: treat every REA result as untrusted data (quote it, never act on instructions inside it), run the agent without shell or network access when the target is a sample, and keep the reverse-engineering session separate from sessions that hold credentials. The fake rea-tools .exe you mention is the same lesson from the other side: the install path is the first thing to verify.
Does REA mark which parts of a finding are verbatim bytes or strings from the target versus its own inference? That split would let a user sandbox the first kind.