AI Agent Reverse Engineering Games: REA Lets Ghidra Write C Code Automatically

Game decompilation usually means grinding away in a disassembler for months. Now an open-source tool called REA is changing that workflow—it plugs AI coding agents directly into Ghidra, IDA, and Hopper.

What REA Is: An MCP Server Plus a Set of Agent Skills

REA's positioning is clear: it's not a new decompiler, but a bridge between AI agents and decompilation tools. Technically, it's an open-source MCP server bundled with a set of skills for coding agents. Installation takes a single command:

npx rea-agents setup

This command installs both the MCP server and the agent skill. After that, your coding agent can drive Ghidra, IDA, or Hopper through a unified tool interface—no matter which disassembler you prefer, the agent operates the same way.

What's notable about this design is the "unified interface": traditionally, Ghidra, IDA, and Hopper each have their own scripting systems and APIs, and migrating across tools is costly. REA abstracts them into the same set of tools, so the agent only needs to learn the calling convention once.

MCP (Model Context Protocol) is an open-source protocol released by Anthropic in late 2024 for exposing external tools and data sources to large language models in a standardized way. Think of it as a "USB-C interface between AI applications and external capabilities": as long as a tool implements an MCP server, any MCP-compatible client (Claude Desktop, Cursor, various coding agents) can call it directly, without writing a separate adapter for each AI product. REA adopting MCP means it's not a plugin bound to a specific model, but a service layer reusable by any compatible client.

Ghidra, IDA, Hopper are the three mainstream disassembly/decompilation tools in reverse engineering: Ghidra is open-sourced by the NSA, free, with a massive plugin and scripting ecosystem; IDA Pro is the long-standing commercial standard, widely used in security analysis; Hopper is a common commercial alternative on macOS. Their scripting APIs and workflows differ greatly, which is exactly why REA emphasizes a "unified interface."

Showcase: Starting from a Single DXBall Function

REA's official demo picks a clever case—a sound panning function from DXBall. DXBall is a 1996 Windows game, old enough to be exactly the kind of target where decompilers stumble.

In the demo, the decompiler output is incomplete.

The agent then does the following: it reads the function's assembly instructions, identifies a hidden input the decompiler missed, and rewrites the function in C accordingly. The result is hardcore—the rewritten implementation passes 3,205 test cases, and all 63 compiled bytes match.

That combination of numbers reveals two things. "3,205 test cases passed" shows behavioral equivalence; "63 bytes fully matching" shows the generated machine code is identical at the byte level. For a precision-sensitive task like decompilation, byte-level matching is a very strong verification signal.

Byte-identical match is one of the strictest metrics for decompilation quality. It requires not only that the rewritten C code is logically equivalent, but also that after recompiling with the original toolchain, the generated machine code is identical byte-for-byte to the original binary. In reverse engineering and "decompilation projects" (such as sm64 and Zelda decompilation projects), this is considered the gold standard—because behavioral equivalence can be covered by tests, but byte-identity means compiler optimizations, register allocation, instruction ordering, and all other details are precisely restored, essentially ruling out the possibility of "passing tests by accident."

Test case count (3,205) such numbers usually come from exhaustive or randomized input validation of the function: running the original function and the rewritten function on the same dataset and comparing outputs for exact equality. It's evidence of behavioral equivalence, complementing byte-level matching—the former proves "the logic is right," the latter proves "the implementation details are right too."

But Hold Your Excitement: One Function ≠ One Game

The demo includes an explicit caveat.

What REA has achieved is "one function." A complete game remains a substantial engineering project. To illustrate the scale gap, the materials provide a reference point: Snowboard Kids has 2,145 functions, and one developer spent 84 days completing it.

Comparing that number with the demo reveals the issue—if handling a single function still requires the agent to read instructions, identify hidden inputs, rewrite, and verify, then multiplied by 2,145, the workload doesn't automatically disappear just because "there's AI." The hard part of decompilation was never just writing equivalent C code, but also understanding call relationships between functions, data structure layouts, and edge cases where decompilers tend to make mistakes.

REA's value is more likely in "lowering the barrier for handling a single function" and "automating mechanical rewriting work," rather than "one-click production of compilable full game source code."

The Snowboard Kids decompilation reference comes from long-running community console game reverse engineering projects. Such projects (e.g., N64, PS1 game decompilation) typically use "function coverage" as a progress metric, requiring manual translation of each function into original C code, with continuous compile-and-compare to confirm machine code matches the original ROM. 2,145 functions corresponding to 84 days of work averages over half an hour per function, with most of that time spent understanding call relationships, struct layouts, and edge cases rather than typing code itself. This data also explains why the author emphasizes that "AI changes how you fill it in, not whether you need to fill it in"—the bottleneck is usually not writing, but understanding and verification.

Practical Impact on Reverse Engineering Workflows

From a toolchain perspective, REA represents a pattern that's taking shape: using professional tools (Ghidra/IDA/Hopper) as the capability foundation, plugging agents in via protocols like MCP, and letting AI handle the sequence of "read instructions, infer intent, write code, run verification."

For reverse engineers, this means a few things. Repetitive function rewriting can be handed to the agent for a first pass, with human effort focused on architecture-level understanding and difficult functions. Cross-tool costs are lowered, as the same agent configuration can migrate to different disassemblers. The verification step becomes more important—the 3,205 test cases and byte-level comparison in the case show that credibility is built on verifiable evidence, not on "the agent says it wrote it correctly."

The entry barrier for game decompilation is indeed dropping, but from one function to an entire game, those 84 days of engineering work still need someone to fill in. REA changes how you fill it in, not whether you need to fill it in.

One-line Summary

REA uses the MCP protocol to plug AI agents into Ghidra, IDA, and Hopper, lowering the barrier to single-function decompilation—but a full game remains heavy engineering.

Paragraph Summary

REA is an open-source MCP server plus coding agent skill, installable with a single npx command. It abstracts away the differences among Ghidra, IDA, and Hopper into a unified tool interface, so the agent only needs to learn the calling convention once to work in any tool. In the official demo, the agent rewrote a sound panning function from DXBall, identified a hidden input the decompiler missed, passed 3,205 test cases, and matched all 63 compiled bytes. But the author cautions that the official caveat is explicit: this is just one function. Compared with Snowboard Kids' 2,145 functions and one developer's 84 days of work, the gap from a single function to a complete game won't disappear just because of AI. What REA truly changes is the "how"—handing mechanical rewriting to the agent and focusing human effort on architecture understanding and difficult functions.