REA: The AI Reverse Engineering Tool That Topped GitHub Trending

What Is REA and Why It Exploded

REA (Reverse Engineer Anything) is an open-source project that surged to #1 on GitHub Trending, gaining 300,000+ stars in two weeks. Developers have used it with AI coding agents like Codex to reverse engineer diverse targets: a smart toilet's Bluetooth protocol (integrated into macOS menu bar in 30 minutes), Feishu's client to enable dual-account login (6 minutes), the MuMu Android emulator to build a custom game player for BGMI, and the classic game Monopoly 4 rewritten in Flutter for iPhone. However, the author warns that using REA inside Codex has led to OpenAI account bans.

Reverse Engineering Fundamentals: What Compilation Discards

To understand reverse engineering, first consider compilation. Source code uses meaningful names ( userName, calcDiscount) and comments, but CPUs only execute machine code—binary instructions. Compilation translates human-readable code into an executable (exe, app), discarding the source. This is a lossy process : like a recipe turned into a finished dish, the original instructions (salt amount, heat level, why blanch first) are gone. Reverse engineering attempts to reconstruct the recipe from the dish—tasting for salt, observing color for soy sauce, inspecting knife cuts for technique. The reconstructed recipe won't match the original exactly, but the resulting dish can be 80-90% similar.

Disassembly: Machine Code to Assembly

An executable opened directly shows raw bytes (e.g., 55 48 89 E5 48 83 EC 10 C3). Disassembly translates each byte sequence into human-readable mnemonics: 55 becomes push rbp (save base pointer), C3 becomes ret (return). This mapping is precise—tools act as a "machine code dictionary"—but the output is verbose: a simple if statement may expand to a dozen assembly lines.

Finding the Needle: Strings and Cross-References

A disassembled program yields millions of lines. Reverse engineers don't read linearly; they hunt for clues . The most valuable are strings (e.g., "flip lid" in a toilet app) which remain intact in the binary and link to the code that uses them. Another clue is system interfaces : software must call OS APIs for Bluetooth, network, etc. Tracing "who calls the Bluetooth send function" leads to the command logic. This "who uses it, what it uses" traversal is called cross-reference (XREF) analysis , the core navigation technique in reverse engineering.

Decompilation: Assembly to Pseudocode

Assembly is still hard to read. Decompilers reconstruct control flow—identifying loops, conditionals—and emit pseudocode resembling C. However, the result is like "source code with mosaics": function names become FUN_00406400, parameters vanish (machine code has no parameter concept, only register/stack conventions), variables are renamed param_1, local_8, and constants appear in hex. For example, a decompiled function from the 1996 game DX-Ball initially showed:

int FUN_00401a20(int param_1) {
    int local_8;
    local_8 = param_1 * 0x1e + 0x14;
    if (local_8 < 0x100) {
        local_8 = FUN_00401b40(local_8);
    }
    return local_8;
}

Only by analyzing callers, runtime values, and game behavior (sound panning) did researchers restore the actual formula:

pan = ((double)x * 1.5625 - 500.0) * dxball_pan_scale;

This computes stereo pan from a brick's horizontal position. Industry-standard tools for disassembly/decompilation are IDA (commercial, powerful), Ghidra (NSA open-source, free), and Hopper (macOS-focused). REA builds on these.

Reverse Engineering Difficulty by Platform

Not all software is equally hard to reverse. From easiest to hardest:

Web & network requests : Browser dev tools reveal every request/parameter; often no code reading needed.

Electron / JS apps (Notion, Slack): Essentially packaged web pages. Minified JS retains strings, API names, structure; formatting restores readability.

Java, .NET, Android APK : Compile to bytecode preserving class/method names. Android often uses ProGuard obfuscation (renaming to a, b, c), but structure remains—far easier than machine code.

C, C++, Rust native binaries : Compile directly to machine code, losing maximal information. Requires full disassembly/decompilation/XREF workflow.

The opening examples align: the toilet's WeChat mini-program is JS (easy), while DX-Ball is a native binary (hard). Besides static analysis (reading files), dynamic analysis —running the software and observing network writes, file I/O, Bluetooth packets—is often combined.

The Bottleneck: Sheer Volume

A medium-sized native binary decompiles to tens of thousands of FUN_xxxx functions. Each layer requires reading, naming, and verifying; a wrong guess sends you down a rabbit hole. Historically, reversing a single feature took days or weeks—the primary protection for software was the cost of reverse engineering . This volume problem is exactly what modern AI excels at: reading massive code, hypothesizing intent, and iterating rapidly.

How REA Works: Bridging AI and Classic Tools

REA does not perform disassembly/decompilation itself. It wraps IDA, Ghidra, and Hopper—tools designed for human point-and-click—into AI-callable interfaces via the MCP (Model Context Protocol) . MCP provides a standardized plug for AI agents (Claude Code, Codex) to invoke actions like "list strings in file," "show pseudocode for function," "find callers of this function." REA also supplies a skill (operational manual) telling the AI the step-by-step reverse engineering workflow.

End-to-End Example: Notion Clipboard Format

Given the question "How does Notion preserve formatting when copying blocks across pages?", an AI equipped with REA executes:

Identify target : REA inspects the package, detects Electron, so JS extraction suffices.

Find clues : Search clipboard-related APIs, locate the copy-triggered code.

Follow cross-references : Trace from UI to the main process that actually writes the clipboard.

Conclude : Notion embeds a hidden "copy ID" in the clipboard payload and stores the full formatted data locally keyed by that ID. Pasting retrieves the data via the ID.

The AI iterates: after each tool call, it evaluates whether the answer is sufficient; if not, it invokes another tool, looping until the explanation is complete.

Preventing AI Hallucination: Citations and Binary Diffing

AI tends to hallucinate confidently. REA counters this in two ways:

Every conclusion must cite sources : Tool responses include file paths and function addresses. Unresolved areas are explicitly listed. An AI claim is valid only if traceable to evidence.

Round-trip verification : For the DX-Ball audio panning function, the AI rewrote the pseudocode into C, then tested 3,205 input cases against the original binary—all matched. Recompiling with the original 1996 compiler produced byte-identical machine code (63 bytes) . Like unit tests, the proof is in the execution, not the AI's assertion.

Limitations

No original source recovery : REA yields pseudocode, call graphs, and evidence; the final implementation is AI-rewritten for behavioral equivalence, not textual identity.

Anti-reverse engineering protections : Packers, obfuscators, and intentional code entanglement defeat both humans and AI.

Server-side logic is inaccessible : Many apps are thin clients; core rules run on the vendor's servers and cannot be reversed from the client.

Whole-app replication claims are suspect : REA excels at feature-level analysis. Full-app clones may look similar but behave differently underneath.

Simple JS apps may not need REA : For Electron/JS targets, AI can often analyze the unpacked source directly. REA's unique value is tackling native C/C++ binaries that AI cannot parse alone.

Conclusion

Reverse engineering's core loop—disassemble, decompile, find clues, cross-reference, verify—has not changed. REA's innovation is packaging these decades-old techniques into an AI-agent-friendly toolkit. This dramatically lowers the barrier: tasks that once required specialist weeks can now be done by a novice in minutes. For developers, the lesson is clear: code deployed to user devices holds no secrets . Critical logic and validation must reside on the server.