REA, the “reverse engineer anything” project, earned 10 × ten thousand stars in a week. What did it actually revolutionize?

You have no source code or documentation, but you want to understand how a feature in an app works—perhaps even use the same idea in your own product. This used to be the kind of hard problem that took reverse engineers weeks to crack. Now, you can say a single sentence to an AI agent, and it will open Ghidra or IDA on its own.

This article looks at REA (Reverse Engineer Anything), which has recently been all over AI developer circles, and the bigger question behind it: when reverse engineering goes overnight from an expert craft to something anyone can request in a sentence, what does that mean for developers and the closed-source software industry?

Here is the conclusion up front: REA itself does not introduce much new technology. What is new is that it puts this work in the hands of AI—and ordinary people.

The opening story that had people cheering

In 2026-10, a developer named Brandon Thomas did something that won applause across the internet.

The motivation was simple: he was so disgusted by Adobe’s subscription cancellation fees that he decided to give the company a taste of its own medicine. Using Claude Opus 5.5, he reverse-engineered and rewrote 7 applications from Adobe’s suite:

He then released them for free as open-source software. PhotoCraft alone picked up 4.6 × ten thousand stars in less than 10 days. On Hacker News, the author wrote:

"Software is over. But for real. I just one-shotted Photoshop. The whole thing."

The story went viral because it turned “reverse engineering” from something spectators could only imagine into a tangible reality: one person and one AI taking on a tech giant’s entire suite.

What REA actually does

If Thomas’s story was “individual effort + AI,” REA is the tool that turns that approach into a product and makes it accessible to everyone.

The project’s homepage says this right at the top:

“See a feature in an app that you want to add to your own product? Have an agent investigate it for you.” “Even without source code, an agent can inspect an app, explain how a feature works, show evidence, and implement something similar in your project.”

What it connects

Reverse engineering literally means working backward from a compiled program to understand how it was written internally. Traditionally, this was a specialist skill for security researchers: switching between decompilers (Ghidra, IDA, Hopper), disassemblers, and debuggers, tracing call chains, and searching strings. Spending days on a single feature was routine.

REA connects that entire toolkit to AI coding agents. It uses MCP (Model Context Protocol), a general-purpose protocol that lets agents such as Claude Code, Codex, and Cursor invoke external tools.

Once it is installed, you can tell the agent, “Figure out how search works in this app,” and it will follow this process on its own:

1. Open the target program and identify its overall structure and basic information
2. Search for relevant strings using keywords
3. Use XRef (cross-references) to trace which functions reference those strings
4. Follow the call chain step by step toward the core logic
5. Inspect the target functions’ pseudocode and underlying assembly, cross-checking the two
6. Return a complete chain of evidence: functions, call relationships, and decompiled code

The standard workflow in the official documentation is: open the binary → search for clues → XRef → Call Graph → Decompile → reconstruct the feature.

Its scope goes far beyond taking apart EXEs

REA supports much more than Windows programs:

• Native programs: Mach-O, ELF, PE, and macOS .app bundles (including Swift/ObjC metadata)
• Packages and archives: ZIP, APK, IPA, and ASAR, with file listings available without extraction
• Electron and JS apps: mapping entry points, modules, IPC channels, preload scripts, and source maps
• Websites: passively observing the browser through a local Chrome DevTools endpoint
• .NET (managed PE/CLI): inspecting metadata without running the program
• Version comparison: comparing two versions of an app and producing a change report

Why it took off: the barrier to entry came down

What REA has really changed is the barrier to entry.

Previously, to get AI to help you with reverse engineering, you first had to know how to do it yourself: install IDA, configure plugins, know what questions to ask, and understand assembly. Those requirements shut out the vast majority of application developers.

Now, a single command is enough:

bash

Code walkthrough

Copy code

npx rea-agents setup

Choose the agent you want to connect (Claude Code / Codex / Cursor / Gemini CLI / Windsurf…), confirm, and the configuration is written for you. It was AI bloggers and major tech accounts, rather than the security community, that pushed it onto the trending lists. That alone says a lot.

The reason it became popular boils down to this: the technology is not new; the people using it are.

This week’s reverse-engineering results

Case one: a 3A game reconstructed byte for byte

One of the most widely discussed accounts of this wave came from reverse engineer Maurice Heumann.

He had more than a dozen Claude Code and Codex agents work in parallel to reconstruct 99% of a shooter’s functions as C++ source code. For 83%, the compiled output matched the original program byte for byte.

Note that he used Hex-Rays’ official MCP, not REA. That makes the point all the clearer: AI can now reverse-engineer to the exact, pass-or-fail standard of “identical bytes after compilation.” This is not a rough approximation of the behavior; it is genuinely getting close to the original code.

Case two: reverse-engineering Claude Code itself

Someone had REA analyze Claude Code itself—a huge bundle with thousands of modules and tens of MB of compressed code, so complex that traditional reverse engineering would mean confronting a vast amount of minified code.

The approach was right, but the target was simply too large: during deep analysis, REA at one point exhausted the JavaScript heap. That failure is a signal in itself: AI was already throwing everything it had at the task.

Case three: reverse-engineering Sony Sound Connect and “copying” a feature into your own app

A technical article on Tencent Cloud described what its author called “the closest example so far to reverse-engineering a real commercial app.” The author connected a Samsung S24 Ultra, had Codex use REA to analyze Sony’s Sound Connect app, and then independently developed an Android app that enables Wind Noise Reduction as soon as it opens.

Previously, when you saw an interesting feature in a piece of software, you could only guess from the outside how it worked. Now an agent can go inside the program, trace the implementation step by step, and even help you rebuild it.

Case four: reverse-engineering Adobe’s entire suite

This is the story from the opening. One more detail: Thomas’s approach is known as clean-room design—“I did not copy your code,” but instead understood the principles and rebuilt the functionality with a different implementation. Other reverse engineers take the byte-matching route: “write it exactly as you did.” Both approaches capture this broader wave.

Case five: playing old games for free

At the start of month 10, a batch of old games suddenly became playable in the browser: Halo: Combat Evolved, Half-Life, Diablo, GTA5, and COD: Modern Warfare 2. Although some of these 3A titles became available because old source code had leaked, faster AI-assisted reverse engineering also played a part.

The real impact on developers

This is what the article most wants to explore: beyond being a useful tool, what impact does it have on developers as a group?

Reverse engineering is losing value as a craft, but it is not dead

Reverse engineering used to depend heavily on accumulated experience, and many security researchers built their careers on it. As AI lowers the barrier to entry, a kind of professional anxiety is spreading: how defensible is the advantage of “I can always reverse-engineer someone else’s software”?

There are plenty of clear-eyed voices in the community. When REA was everywhere, Practical Reverse Engineering co-author Elias Bachaalany shared a recommendation of the project, opening with a single word:

Hype.

His point was that these tools have been around for a long time: GhidraMCP and IDA Pro MCP already existed last year. “AI connected to reverse-engineering tools” is not a new species; it has simply been repackaged.

Security blogger Xuanyuan Zhifeng was more specific:

• AI handles unpacked programs easily
• Lightly packed programs are manageable too
• Strong virtualization-based protection such as VMP remains beyond its reach for now
• REA does not even have dynamic debugging

So the accurate description is not “reverse engineering is dead.” AI has raised the ceiling of what it can achieve, but the really hard problems—heavy obfuscation, anti-debugging, kernel logic, and dynamic analysis—still need experts. It is good news for beginners, pressure for experts, and the biggest shock for the half-skilled reverse engineers in between.

Agents are repeating the leap from writing code to changing repositories

There is a precise analogy with the evolution of coding agents: AI used to help you write a few lines of code; now it can read repositories, change code, and run tests on its own. REA is bringing the same capability to reverse engineering.

Reverse engineering is gradually shifting from “people use tools” to “people ask questions, and agents use tools.”

This is no longer a demo: from understanding features in real software to reconstructing algorithms and verifying them with differential tests, agents can now complete the full reverse-engineering loop. In other words, “understanding anything installed on a computer” is becoming a basic capability.

Reverse engineering itself is eroding competitive moats

Eric S. Raymond, a veteran of the open-source world, put it more bluntly: the age of software secrecy is coming to an end, and almost all software that can be installed on your computer will lose secrecy as a competitive moat.

Vendors used to limit third-party access by keeping communication protocols private. In the future, anything you can install on your computer will, in practice, be close to open source. For product builders, this is the point to take most seriously: your moat cannot depend on “other people cannot understand the code.” It has to rest on stronger foundations such as user experience, ecosystem, service, and brand.

Some things still cannot be taken apart

• Server-side logic remains out of reach: you can take apart the client installed on your own computer, but not the other half in someone else’s data center
• The context can overflow: users have already complained that the tool descriptions REA feeds to agents are so long that they quickly fill the context window
• More tools do not necessarily mean better results: x64dbg creator Duncan Ogilvie says he does not think exposing more tools to a model will make it perform better

A necessary reality check: being able to reverse-engineer something ≠ doing so legally

This is a serious subject. Stories alone are not enough; the underlying issues need to be explained.

Legally, reverse engineering and copying an implementation are different things

• On trade secrets, a 2020 judicial interpretation by China’s Supreme People’s Court makes clear that obtaining technical information by disassembling, measuring, and analyzing products acquired through publicly available channels does not constitute infringement of trade secrets.
• On copyright, Article Seventeen of the Regulations on Computer Software Protection permits using software to study and research the ideas and principles behind its design. Article Fifty of the Copyright Law lists “research into the reverse engineering of computer software” as one of the circumstances in which technological measures may be circumvented.
• But Article Six of the same regulations is also explicit: protection does not extend to the ideas, processing procedures, and methods of operation used in development.

The danger is that REA removes the wall between “a person reads the decompiled output” and “a person writes new code.” The agent reads the decompiled output, and the same agent writes the code, with no separation in between. Someone on Hacker News called this “washing IP.”

Three real danger zones

1. Taking apart a client’s software covered by an NDA and then sending it to a model provider may breach the agreement. REA is correct when it says analysis runs locally. But when the agent interprets the results, it sends decompiled code fragments, call relationships, and strings to the underlying model API. That step may cross a line.
2. The company whose software you are taking apart has a user agreement and lawyers. If it pursues the matter, the person squarely exposed to the risk is always you—the one who issued the instruction.
3. Model providers have limits too. Some people analyzing Jianying found that Claude stalled or restricted the work halfway through. Those are model-side guardrails at work, but the provider decides where and how they apply.

For tool builders like us: the most practical uses of REA

As a tool developer, the most valuable uses of REA are not “cracking software” or “getting back at a big tech company,” but these three constructive applications:

Researching competitors’ features. Want to see how a feature in an app is implemented? Have an agent investigate it, understand the approach, then design your own solution. Understanding ≠ copying.

Learning how things work. Taking apart a classic piece of software that interests you and examining its internal structure is an exceptionally efficient way to learn.

Recovering lost or legacy code. Lost the source code for an old project? Reconstruct it through reverse engineering. The official documentation even lists “recovering lost source code” as a use case.

Remember the boundary: understanding should help you build something better, not copy it outright. Work backward from the result to understand the implementation, then develop your own. That is the healthiest way to use it.

Getting started (up and running in 30 seconds)

1. Make sure Node.js and npm are installed
2. Install one of the required reverse-engineering tools (Ghidra is free, open source, and the most approachable option)
3. In your chosen agent (Claude Code / Codex / Cursor, for example), run:

bash

Code walkthrough

Copy code

npx rea-agents setup

1. Choose the agent and confirm the configuration. You can then tell it, “Help me understand how this app implements its XXX feature”

A final thought

Strip away the noise about “10 × ten thousand stars in a week,” and the excitement around REA comes down to one sentence:

Reverse engineering is moving from “people use tools” to “people ask questions, and agents use tools.”

The technology is old; what has changed is the barrier to entry and who has access to the capability. AI lets a single sentence trigger difficult work—reading code, understanding products, and examining implementations—that used to be reserved for a small group of people.

But you need to see both sides:

• The optimistic side: every developer gets an intelligent assistant that can “understand anything installed on a computer,” raising the ceiling for learning, research, and product development
• The sober side: competitive moats can no longer depend on code secrecy; difficult reverse engineering still requires experts; legal risks do not disappear just because engineers do not notice them

For developers, the lasting takeaway is not “it can reverse-engineer software,” but the larger trend it illustrates. Once AI can understand every clever idea someone has encoded in a binary, the only things left for us to defend are why we build, who we build for, and how well we do it.

References and source material: GeekPark, “10 × Ten Thousand Stars in a Week: AI Can ‘Reverse-Engineer Anything,’ but Do Not Get Too Excited”; 36Kr, “Is Software Finished? REA Racks Up 12 × Ten Thousand Stars in Three Days”; Tencent Cloud Developer Community, “REA Goes Viral: AI Agents Start Doing Reverse Engineering on Their Own”; Everyone Is a Product Manager, “AI Starts Reverse-Engineering Everything.”