Rafal Strzalinski • 23 January 2026
Can an AI agent navigate Ghidra, the NSA’s open-source reverse engineering suite, well enough to hack an Atari game? Ghidra is powerful but notoriously complex, with a steep learning curve. Instead of spending weeks learning its interface, what if I could simply describe my goal and let an AI handle the complexity?
Childhood dream
River Raid, the Atari 8-bit version. My first computer was an Atari back in the 80s, and this particular game occupied a disproportionate amount of my childhood attention.
The ROM is exactly 8kB — almost comical by modern standards. And yet this tiny binary contains everything: graphics, sound, enemy AI, and physics simulation — all compressed into hand-optimized 6502 assembly.
The objective was straightforward: unlimited lives. It’s the quintessential hack, a rite of passage that kids with hex editors performed for entertainment back in the 80s. In 2025, instead of a hex editor, I have an AI.
Setup
Ghidra doesn’t have a native AI assistant, so I needed a way to bridge the gap between my instructions and the tool’s internal API. This is where the Model Context Protocol (MCP) comes in.
I found an open-source MCP server for Ghidra — essentially a connector that allows Claude to talk directly to Ghidra. The concept is elegant: Claude connects to the running Ghidra instance, analyzes the binary, renames functions, and identifies code patterns programmatically.
In practice, the experience was considerably less elegant:
- MCP has no standard distribution format (e.g., Docker, npm) — you git clone and hope for the best.
- The resulting chain is: Claude → MCP server → Ghidra extension → Ghidra. Four components, four places where things can break.
AI meets 6502
Here’s the thing: I don’t use disassemblers daily. Ghidra’s workflow was completely foreign to me. The whole point was to see if AI could bridge that gap — I’d feed it a mysterious binary, and the Ghidra + LLM combination would figure out it’s a cartridge dump, handle the memory mapping, and guide me through.
Reality was harsher. To test the AI properly, I renamed the binary to a.rom — no helpful filename hints. When importing, I selected only the CPU architecture (6502) without specifying the platform. Claude’s first instinct was reasonable: it asked for the MD5 hash to search for known ROM signatures. The MCP tools don’t expose hashing, so that avenue closed immediately.
First problem: Ghidra loaded the ROM at $0000, not $A000 where Atari cartridges live. All cross-references pointed nowhere.
Claude identified the issue with admirable clarity: “The ROM should be loaded at $A000, not $0000. You’ll need to rebase the memory image.”
Me: “Can you perform the rebase?”