REA Project on GitHub: AI Agents Leverage Ghidra for Full-Stack Reverse Engineering, Reshaping Software Moats

Over the past two days, a project called REA (Reverse Engineer Anything) has taken GitHub by storm.

How popular is it? As of October 12, its repository page displayed 120,000 stars. For comparison, OpenClaw—which sparked a viral "lobster farming" trend and achieved remarkable growth earlier this year—accumulated 60,000 new stars within just three days of its breakout moment.

Project URL: https://github.com/morluto/rea

As stated in the GitHub README, the project’s core mission is to "Reverse engineer anything with agents, from app behavior down to native binaries."

In simple terms, REA leverages AI coding agents like Claude Code and Codex, connecting them via MCP (Model Context Protocol) to reverse engineering tools such as Ghidra and Hopper. This enables agents to analyze software without source code, trace implementation details for specific features, and attempt to write similar functionality based on their analysis.

REA offers the deepest support for native binary files, but its coverage extends far beyond that:

• Native Applications: Mach-O, ELF, PE, and macOS .app bundles, including Swift and Objective-C metadata.
• Packages and Archives: ZIP, APK, IPA, ASAR; it can also generate file manifests without extracting the archives.
• Electron and JavaScript Apps: Statically maps entry points, modules, IPC channels, preload scripts, and source maps without running the application.
• Websites: Passively observes browsers you already control via local Chrome DevTools endpoints.
• .NET (Managed PE/CLI): Inspects metadata, members, and native code boundaries without executing the program.
• Version Diff Analysis: Compares two versions of an application and generates a change report.

As Replit CEO Ahmad Msad noted, "What's happening in AI-driven reverse engineering and decompilation is incredible. Soon, all software may effectively become open source."

For the past forty years, part of the value proposition of software rested on the premise that "source code is inaccessible": I write the code, compile it into a binary, you can't get the source, so you have to buy mine. REA challenges this very premise. When AI can read binaries, trace call chains, and generate refactored code, who can still be stopped by the lack of source code?

This will undoubtedly reshape the industry's rules of the game. For companies resting on past achievements, failing to invest actively in product development, or not updating rapidly enough, the question is no longer "Will someone clone us?" but rather "When will we be cloned, and will the cloner move faster than us?"

The myth of the "closed-source moat," which has persisted for half a century, seems to be officially collapsing at this moment.

"These subscription models should disappear. It's greedily absurd." "Software is doomed."

"If this actually works, nothing will remain proprietary anymore! Software is truly finished!"

Decades of Hard Skills, Mastered by Agents in Years

Have you ever had this experience? You're using an app and notice a feature that works exceptionally well—offline search returns results instantly, or the sync mechanism is incredibly smooth. You want to implement something similar in your own product, but you have no source code, no documentation, and no idea how it was implemented.

Previously, dealing with this meant learning reverse engineering. You'd find a disassembler, struggle through its API, sift through strings and symbols, manually trace call graphs, and juggle between different tools. It was a hard skill that most application developers simply didn't have time to learn.

REA takes a different approach: delegate this task to your AI coding assistant, such as Claude Code, Cursor, Codex, Gemini CLI, Windsurf, or Claude Desktop.

More precisely, REA is an open-source tool (MIT License) written in TypeScript that provides agents with a consistent way to investigate software. Its core function is acting as an orchestration layer between AI agents and reverse engineering tools.

One user joked that it's like "someone gave Claude Code a decompiler."

The reverse engineering tools invoked by REA are not new; they have been evolving for years. Ghidra was open-sourced in 2019, Hopper dates back to 2011, and IDA has been used by reverse engineers since the 1990s. What REA does is enable agents to invoke these tools, integrating previously manual analysis steps into the programming workflow.

For example, a request might be: "Use REA to reverse-engineer the Notes app, figure out how offline search works and explain it clearly, then implement a similar version for my project using TypeScript and SQLite." In the background, the Agent leverages REA tools to roughly complete the following steps:

However, LLMs entering the field of reverse engineering did not start with REA.

LLM-assisted reverse engineering has been developing for several years. As early as 2022, research teams from New York University and the University of Calgary tested whether Codex could assist with reverse engineering in their paper 《Pop Quiz! Can a Large Language Model Help With Reverse Engineering?》. Researchers asked the model to read code and decompiled code, determine function purposes, identify program capabilities, and infer variable names or key values.

This pioneered the use of LLMs to parse decompiled pseudocode, but at that time, AI was merely a "reading comprehension add-on" requiring manual copy-pasting. Over the subsequent years, technology diverged into two paths: one group, such as the open-source LLM4Decompile from Southern University of Science and Technology (SUSTech), attempted to bypass traditional engines by natively translating machine code directly into C source code; the other path moved toward Agent-based automation architectures like REA—building a scheduling bridge between LLMs and traditional tools like Ghidra and IDA, allowing AI to truly grow "hands and eyes," achieving an end-to-end reverse engineering workflow that automatically extracts symbols, traces call chains, and generates deployable code.

In April this year, a senior security professional used an Agent paired with Ghidra MCP to dissect everything from ordinary games to bank-grade apps.

Game-related tasks were straightforward: For Cocos2d games, pure static analysis identified the Blowfish algorithm and deduced the key; for Unity games, observing ciphertext characteristics allowed guessing the Lua comment format, thereby deducing the XOR key.

What was truly surprising was banking apps. These apps typically feature multi-layer packing and obfuscation, along with a full suite of protections including anti-injection, anti-debugging, root detection, and emulator detection. According to his post-mortem summary, the AI analyzed layer by layer, bypassed these protections, and ultimately managed to open the apps on rooted emulators and capture request contents.

Throughout the process, he used Cursor paired with Claude Opus 4.6 high thinking mode. Most prompts were simple: "There is an APK in this folder; reverse-engineer it back to source code." Moreover, many app reversals took around 30 minutes. Based on Cursor's billing mechanism, the cost was less than $5; trying a Unity game with Claude Code consumed 40 million tokens, costing about$27. On average, the cost hovered around $30.

He himself exclaimed: "It was then I realized that I am the limiter of AI." What previously seemed impossible for AI was actually due to his own reluctance to let it try. "As long as you provide AI with an environment where it can perform, ensure it has access to sufficient logs to verify correctness, and give it enough time, there is nothing that cannot be reverse-engineered."

The Clone Wave Has Arrived: Has the Moat Shifted Location?

It can be said that reverse-engineering various apps was theoretically feasible long ago; it is only recently that the emergence of REA has brought more attention to this matter.

One netizen mentioned: "I suspect this is why my YouTube feed has been flooded with 'Vibe Code' clone videos of various commercial applications over the past few days. From Adobe to Microsoft Office flagship products, they are all there."

App cloning has occurred before in the mobile gaming sector: someone released a renamed Flappy Bird, and the next day a slew of imitators appeared. But now, instead of a slew, there are countless imitators. As long as someone wants a piece of software, it can potentially be cloned. Currently, this phenomenon affects small teams, but Adobe will also be impacted—clones have been made for Photoshop, Illustrator, and Adobe’s entire product suite, with some aspects even being better. This effort may not just be individual behavior.

Regarding REA itself, another netizen who tested it reported: "REA’s hype is well-deserved. I tried it with CapCut and several projects, and indeed, nothing was hidden."

He mentioned seeing others implement a feature well, tracing through modules, routing, and IPC communication to uncover the implementation logic, and directly reproducing it in his own project; software and libraries that don’t expose APIs can also be dissected, with many Electron/desktop applications running "naked." Another scenario involves "rescuing old software and libraries without source code—the Agent can invoke Ghidra and Hopper to read pseudocode and assembly, even precisely restoring algorithms from old games."

So the question arises: If even old software without source code can be dissected and reproduced, where lies the moat for software companies?

Technology expert Xu Hao’s view is that cloning can take away code, but it cannot take away knowledge. When facing software without source code, the focus has never been "rewriting it using another technology," but rather inferring its business logic and clarifying what it actually does. "Re-enacting it doesn't seem meaningful to me."

"Software itself is not the product; the knowledge within the software is". Applied to the REA context, this statement can be understood as follows: Although REA can restore binaries into code and generate a seemingly complete functional implementation, there remains a gap between "restoring code" and "understanding the software"—why it was designed this way, what the business rules are, which behaviors are intentional, and which are historical baggage.

In other words, writing code has never been the moat of a software company.

Experts interviewed by InfoQ also placed the answer outside of code: "Customer relationships, community, trust between people, and insight into needs are what companies truly need to cultivate."

In the past, some people cited "a few programmers writing excellent code" as a justification for starting a business, without clearly defining what problem they intended to solve or what value they could bring to the business. Software and code are merely means to deliver business value. Today, with development costs dropping, this shift actually creates opportunities for those who truly understand their industry, possess deep domain know-how, and can solve real-world problems to transform their experience into products.

QuickCreator Co-founder Yan Zhitao, an overseas content marketing platform, also believes, “REA will indeed further impact business models in the software industry, but I disagree that this signals the end of software.” There is a vast gap between building similar functionality, getting customers willing to pay, and serving them effectively over the long term. Access to code alone cannot bridge that gap.

“If software businesses couldn’t survive once source code became available, open-source business models would have ceased to exist long ago.”

The code for many open-source projects has always been accessible for study, use, and modification within license terms. Yet enterprises continue to purchase commercial subscriptions, hosting, and technical support—a phenomenon that has persisted for years. Take Red Hat, for example: its official subscription descriptions highlight value propositions including production-ready software, lifecycle management, compatibility, patches and updates, as well as technical support and expert resources. What customers pay for clearly extends far beyond downloading a copy of the code.

Enterprises can certainly choose to build internal teams to handle these tasks. However, doing so incurs costs—recruiting, training, accumulating experience, and maintaining that team long-term. For some companies, paying specialized vendors is a more appropriate choice than bearing all responsibilities internally.

After a version is released, who maintains it? When a dependency encounters issues, who determines if it impacts the business? When multiple products are used together, who verifies compatibility? These tasks do not automatically complete themselves just because the code is public.

A significant portion of what enterprises pay for is aimed at reducing the cost and uncertainty associated with using software effectively and maintaining it long-term. This explains why different companies can achieve vastly different business outcomes around the same open-source project. While code accessibility may be similar, service capabilities, customer relationships, and track records of delivery can differ dramatically.

However, this does not mean incumbent software companies can rest easy; AI will reshape service systems themselves. Tasks that previously required large teams—such as troubleshooting, documentation organization, configuration checks, and parts of implementation—may soon be handled by smaller teams leveraging AI. If new entrants can both build suitable products and provide reliable services at lower costs, they stand a chance to gradually build customer trust. Established giants cannot assume their advantage from having comprehensive service systems will last forever.

Returning to REA itself, what it changes is not “whether software has value,” but “what underpins software’s value.” As code and features become increasingly easy to replicate, the basis for charging must shift from “implementation difficulty” and “information asymmetry” to other factors—understanding of business needs, responsiveness to customers, and assurance of long-term system operation.

This shift may make some features cheaper, squeeze certain existing revenue streams, and create opportunities for new service providers to enter the market. Its impact on business models will be tangible, but the demand from enterprises for reliable software, professional services, and continuous support has not disappeared because of it.

The moat hasn’t vanished; it has simply moved from “you can’t see my code” to “you can’t take away my service capability and business understanding.”