Why buy anything if you can reverse anything?

REA, short for “Reverse Engineer Anything”, is all over the internet this week. It has 148,000 GitHub stars, most of them collected in a single week¹. The quick explainer: it wraps your coding agent around the reverse-engineering tools that already exist, so the agent can open an app without its source code, work out how a feature works and build its own version. Does it really work? Sort of, and also not really.

If it worked on any app, a lot of software would stop being worth buying. In practice it does reverse some things. On apps of even moderate complexity it falls short quickly, and for a tool that promises to reverse any binary, the agents using it go looking for the original source, or someone else’s decompilation, whenever there is one to find.

The numbers below come from REA’s repository and its 771 issues, 51 public attempts reported on GitHub, X, YouTube and Hacker News, and three benchmarks from 2026, all read on 12 October 2026.

inside REA

REA is a local MCP server and command-line tool, and it has no model of its own. It runs the reverse-engineering tools that already exist: Ghidra, IDA and Hopper for native binaries, JADX, apktool and adb for Android, Chrome DevTools and mitmproxy for web apps and their traffic, Frida for running processes, and about a dozen more¹. It hands their output to your coding agent as evidence records, each marked observed, inferred or unknown. Claude Code, Codex or whichever agent you use does the rest, including writing the rebuild.

A diagram of one run. The target app, a binary, an Electron bundle or an APK, goes to REA, which runs Ghidra, IDA or Hopper, JADX, apktool and adb, DevTools and mitmproxy, and Frida or Binwalk on it. REA returns evidence records marked observed, inferred or unknown. The coding agent reads them and writes a rebuild. A check runs the rebuild and the original side by side; in the example, 2 of 54 checks differ, the agent fixes them, and the second rebuild matches.

fig 1REA runs the tools and collects evidence. The model reads it, writes the rebuild and fixes it until the check passes. The run is illustrative. The tool list is from REA's README¹.

The most useful idea in it is in its instructions to the agent: separate what you saw from what you guessed, and cite an evidence ID for every claim. The repository is large for its age, with about 250,000 lines of TypeScript and 165,000 lines of tests. It was created in April and went from version 3.2 to 6.4 in eight days¹.

148,000 stars

REA had about 4,200 stars on 5 October, according to a commenter tracking it in the Hacker News thread, which reached 783 points². By 10 October the count was 54,600, and on 12 October the GitHub API reported 148,143¹.

REA's GitHub stars: about 4,200 on 5 October, 10,300 on 7 October, 17,500 on 8 October, 54,600 on 10 October and 148,100 on 12 October, about 35 times more in a week.

fig 2From about 4,200 to 148,000 stars in a week. 5 to 10 October: counts posted by a Hacker News commenter². 12 October: GitHub API¹.

Commenters on Hacker News said the curve “reeks of botting”². The repo has one fork for every four stars, far more forks than a starred repo usually gets¹, and on 9 October its author created 79 forks of “awesome” lists and skill directories, all named rea-…, apparently to submit REA to them³. Nothing proves the stars were bought. A separate repository, rea-tools/rea, offers a Windows download called rea-x64.7z, while the real project publishes no release files at all⁴, so install REA only from npm or the original repository.

51 attempts

Fig 3 places every public report found of someone pointing an agent with REA at a real target. They come from REA’s issues and discussions, about 20 repositories that say they were built with it, two community galleries, the Hacker News threads, posts on X and YouTube videos⁵.

Fifty-one public attempts with REA, by target size and result. The 9 attempts by REA's own contributors all worked: a single DX-Ball function, three Touhou game decompilations, a Notion clipboard trace and four small targets. Of the 42 independent attempts, 20 worked, 16 partly worked and 6 failed. Of those 20, nine are toy or small targets, such as the Untangle puzzle, a PowerToys colour picker clone and one Ski or Die minigame; six are single features of mid-size apps, such as Obsidian's quick switcher and the Claude Slides editor; and five are claims about apps their authors didn't name. The six failures are a World of Warcraft slice, Grokbot, a NES ROM, a .NET NativeAOT app, a 1.85 MB Swift macOS app and the macOS sharingd daemon. Partial results include a Wispr Flow teardown that became a 64-line script and a QuickBooks study that became an independently written ledger.

fig 3Independent users got 20 full results out of 42: nine on toy or small targets, six on single features of mid-size apps and five on apps nobody named. Each mark is one report, judged against what its author set out to do. Squares are REA's own contributors. "Public code" means a repository or file anyone can inspect; the rest are videos, posts or claims. Hover a mark for the target.

The nine reports from REA’s own contributors all worked. The best are decompilations of three Touhou games, matched byte for byte almost completely (1,106 of 1,107 functions for Touhou 8, 696 of 697 for Touhou 9.5) over roughly two weeks each, by the project’s second most active committer⁶.

Of the 42 independent reports, 20 worked, 16 partly worked and 6 failed. The ones that worked are small targets or single features. Someone rebuilt the Untangle puzzle from its 167 KB exe with 52 of 54 claims right⁷, and someone else rebuilt one minigame from the 1990 DOS game Ski or Die after seeding 559 functions by hand⁸. On mid-size apps, REA was often not what did the work. In a video rebuilding Obsidian’s quick switcher, REA’s search for “switcher” returned nothing, and Claude read the 3.7 MB of minified JavaScript directly⁹. MindStudio rebuilt features of macOS Preview with and without REA, and the agent without it finished first¹⁰.

The agents also use whatever source is already around. The Untangle rebuild came with an audit of where each identifier came from, and 10 of them came from the model’s memory of the original source, not from anything REA showed it⁷. Two of the three Touhou decompilations continue work people had already done by hand⁶. In ProgramBench, which is covered below, agents given internet access looked up the original source in 20 to 36% of runs¹¹.

Five of the six independent failures are mid-size or large native programs or formats REA can’t open, and the sixth stopped at Claude’s safety check. A 1.85 MB Swift app for macOS timed out after 40 minutes¹², a .NET NativeAOT app produced only raw assembly¹³, and on World of Warcraft REA returned only the file’s identity, although a community gallery lists that project as a success¹⁴. The largest independent teardown, of the dictation app Wispr Flow, ended with REA’s calls timing out after about an hour and a rebuild that is a 64-line Python script with none of the app’s cloud features¹⁵. No public attempt covers an app like Raycast, Things, Slack or Figma.

the benchmarks

Researchers have been measuring the same task since the spring, without REA: give an agent a program it can run but not read, and ask it to rebuild it.

ProgramBench gives agents an executable and its documentation for 200 programs, from small command-line tools to FFmpeg and SQLite, with a median size of 8,635 lines¹¹. No model rebuilt any of them completely, and the best passed 95% of the tests on only 3% of the programs. An August leaderboard update put that share at 16.5%¹⁶.

Mean share of tests passed when rebuilding a program from its executable, by program size. Claude Opus 4.6: 73.9% on small programs, 53.3% on medium, 24.7% on large. Claude Opus 4.7: 73.8%, 52.1%, 25.0%. Claude Sonnet 4.6: 67.1%, 48.8%, 28.6%. GPT 5.4: 50.9%, 39.9%, 18.0%. Gemini 3.1 Pro: 50.9%, 37.7%, 17.8%.

fig 4Every model passes fewer tests as programs get bigger, and on medium programs the best pass about half. ProgramBench, table 11¹¹. Size groups are the paper's difficulty bins, set by lines of code times one plus the number of runtime dependencies.

On the medium group, 143 of the 200 programs, the best models pass about half the tests. Their rebuilds are also far smaller than the originals: most fit in one to three files, against a median of fifteen in the reference programs¹¹.

MirrorCode, from Epoch AI and METR, gives agents more time and money¹⁷. Claude Opus 4.7 rebuilt gotree, a 16,000-line Go tool, passing 2,000 of 2,001 tests in 14 hours for $251, and pkl at about 60,000 lines. ruff stopped at 67% of hidden tests, and 8 of the 25 programs were never fully rebuilt. Both benchmarks use programs that read and write text. ProgramDistill tests web apps, where agents rebuild features by clicking through a working copy: GPT-6 Astra reproduced 49.2% of full-app workflows and Claude Opus 5 28.8%, and in one setting success fell from 96% to 32% as more features that depend on each other had to be rebuilt¹⁸.

an exact check

The rebuilds that fully worked had one thing in common: a cheap, exact way to compare the result with the original.

Rebuilds with an exact automatic check: Snowboard Kids 2, matched byte for byte, 100% after 20 months; Touhou 8, 1,106 of 1,107 functions; gotree, 2,000 of 2,001 tests for $251; a C compiler of about 100,000 lines, about 99% of GCC's torture tests for about $20,000; Chromatron with a pixel-diff tool, 307,199 of 307,200 pixels. Rebuilds without one: Chromatron before the pixel diff, which looked like a remake; PhotoCraft, a Photoshop clone with about 65% of pixels matching; Cursor's agent-built browser, which didn't reliably build; the Wispr Flow rebuild, a 64-line script; and 26 web apps in ProgramDistill, with 29% to 49% of workflows reproduced.

fig 5With an exact check, agents get to byte-for-byte and pixel-for-pixel copies. Without one, they produce something that looks close. Sources: Snowboard Kids 2¹⁹, Touhou 8⁶, MirrorCode¹⁷, Anthropic²⁰, Quesma²¹, PhotoCraft as reported by byteiota²², The Register²³, the Wispr Flow teardown¹⁵, ProgramDistill¹⁸.

Matching decompilation projects compile each function and compare its bytes with the original game, which is how Snowboard Kids 2 reached 100% after 20 months of work by people and agents¹⁹. Anthropic’s C compiler used GCC as its reference and cost about $20,000²⁰. Chromatron, a 1990s puzzle game, looked “like a remake” to the person rebuilding it until they built a tool to compare screenshots pixel by pixel. After that, the rebuild matched 307,199 of 307,200 pixels²¹.

A real app has no such check. Its behaviour depends on saved state, settings, file formats, timing and a server you can’t see, and none of that can be compared automatically. Even passing tests isn’t the same as matching: in one study, 5 to 13% of decompiled functions that passed every test still behaved differently from the original when fed random inputs²⁴. Where the check is weak, the result looks like PhotoCraft, a Photoshop clone built by agents in a few days, with about 65% of pixels matching and testers on Hacker News calling it “very broken”²².

why buy anything

What REA and an agent can get you today is a feature. They can explain how one part of an app works, sometimes in minutes, and rebuild that part when you can check it. The whole app is out of reach: on the benchmarks the best models pass about half the tests on mid-size programs, and in public, nobody has shown a full rebuild of an app people pay for.

I’d use REA to understand how a feature works before building my own version, and I wouldn’t cancel a subscription because of it. ProgramBench’s share of programs rebuilt to 95% of tests went from 3% to 16.5% between May and August, so I’ll check again in six months.

sources