AI Reverse Engineering in 2026: How LLM Agents Drive Ghidra and IDA (and Where They Fail)

A year ago, "AI reverse engineering" meant pasting a decompiled function into a chat window and asking what it did. In 2026 it means something different: an agent such as Claude, Codex or a local model drives the disassembler itself - it lists functions, follows cross-references, renames variables and reads pseudocode, one tool call at a time, through the Model Context Protocol (MCP).

This guide explains how that works, which tools exist for Ghidra, IDA Pro, Binary Ninja and Android, what a real session looks like, what the first serious benchmark found, and the limits you will hit. It also covers the part most tutorials skip: what you are allowed to reverse engineer in the UK, the EU and the US.

What "AI reverse engineering" actually means now

Reverse engineering is recovering how a program works without its source code. The slow part has always been the reading: thousands of unnamed functions like FUN_00401a30, registers instead of variables, and no comments. Language models are good at exactly that kind of pattern reading - they recognise a CRC loop, a string decoder or a licence check far faster than a person scrolling through assembly.

What changed is tool access. An MCP server exposes the disassembler's functions - "decompile this address", "list cross-references", "rename this symbol", "search strings" - as tools the model can call. The model is no longer guessing from a snippet you chose; it navigates the binary itself and comes back with findings and the evidence behind them.

The usual stack has four parts:

1. The agent - Claude Code, Claude Desktop, Codex, Cursor or another MCP client.
2. An MCP server - the bridge that turns tool calls into disassembler actions.
3. The analysis engine - Ghidra, IDA Pro, Binary Ninja, radare2, jadx or Frida.
4. The target - a native binary, an APK, an Electron app, a firmware image or a network capture.

The main tools, by engine

A community index of AI reverse engineering projects, awesome-ai-reverse-engineering, lists 122 repositories; 74 of them are MCP servers or plugins for disassemblers. The ones you will meet first:

If you only want to try the idea, Ghidra plus GhidraMCP is the zero-cost route. If you already pay for IDA, the IDA servers are more capable. If your targets vary - an Electron app this week, a .NET DLL next week - a multi-engine MCP like REA saves you wiring up five separate servers.

A real session: patching lives in River Raid

The clearest public write-up so far is Quesma's River Raid case study. The author loaded the 8 KB Atari 8-bit ROM into Ghidra as raw 6502 code, connected Claude through GhidraMCP, and asked for infinite lives. What happened is a good summary of the whole field:

• It found the right code. Claude identified the Atari 8-bit platform from hardware register addresses and located the routine that loads, decrements and stores the lives counter.
• It knew the fix but could not apply it. The patch was replacing DEY ($88) with NOP ($EA) at offset 0x355. The MCP server had no write access, so the human applied it with dd. In the emulator, the lives stayed at 3.
• It needed help with setup. Ghidra loaded the ROM at $0000 instead of $A000, so every cross-reference pointed nowhere. Claude diagnosed the problem correctly but could not rebase the program itself.
• It was confidently wrong once. It guessed the game was Centipede. The author's conclusion is worth remembering: confidence and accuracy are unrelated.
• It was slow. Some tool calls took around 30 seconds - fine for a batch task, painful interactively.

That pattern - excellent at reading and locating, weak at broad context and anything that needs write access - matches what most people report.

What the first benchmark says

CrackMeBench (2026) tests agents on symbol-poor CrackMe binaries built from C, Rust and Go templates. Each agent gets a shell in a network-less Docker sandbox with standard reverse engineering tools, a five-minute budget per task and three scored submissions. The program itself is the judge: the agent must produce a serial or key generator the binary accepts.

Two things stand out. Results drop sharply on the harder and the real-world public tasks, and the gap between models is large. Treat any single leaderboard as a snapshot, though - the tasks are small, the budget is five minutes, and models change every few months.

Setting it up: the part that takes longest

Every tool follows the same shape: install the engine, install its plugin or extension, start the MCP server, then register that server with your agent. In Claude Code that last step is claude mcp add; in Claude Desktop it is the MCP section of the config file. Follow each project's README for the exact commands - they change between releases, and the Quesma author counted four separate points of failure in the chain (client, MCP server, Ghidra extension, Ghidra).

REA tries to collapse that into one command:

npx rea-agents setup --dry-run     # print the plan, change nothing
npx rea-agents setup               # register the MCP server with your agents

I tried exactly that on Windows with Node.js 22.18.0 to inspect my own website's build output. The dry run planned nothing and returned status: needs_human with the remediation "Install Node.js 22.x (>=22.19), 24.x (>=24.11), or 26+". Two lessons: check the runtime requirement before anything else, and always run the dry run first - a setup tool that edits your agent's configuration should show you its plan before it writes a byte.

Once a server is registered, start small. Good first prompts are "list the exported functions and summarise what each module does" and "find where this string is used and explain the check around it". Ask for addresses and evidence with every claim, so you can verify instead of trusting.

Where AI reverse engineering is genuinely useful

• Triage. Getting a first map of an unfamiliar binary - which functions matter, where the network code is, what the strings suggest - in minutes rather than an afternoon.
• Naming and annotation. Proposing names for hundreds of functions and variables, which a human then reviews.
• Explaining known patterns. Crypto routines, compression loops, custom string encoding, licence checks.
• Your own software. Understanding a legacy binary whose source is lost, checking what a build really contains, or finding why a minified JavaScript bundle is so large. As a web developer, that last one is where I would use it most: the same tools that read malware can read your own production bundles.

The limits you will hit

• Confident mistakes. Always ask for the address and the instructions behind a claim.
• Write access. Many servers are deliberately read-only. Patching, rebasing and retyping often stay manual.
• Speed and cost. Large binaries mean many tool calls; each one costs time and tokens.
• Obfuscation and packing. Packed or virtualised code defeats the model just as it defeats static analysis.
• Prompt injection. A binary can contain strings written to manipulate the agent reading it. Researchers have published attacks on exactly these setups. Never give a reverse engineering agent your real credentials or an unrestricted shell, and analyse untrusted samples in a disposable virtual machine.

Is it legal? UK, EU and US basics

This is general information, not legal advice - get proper advice before reverse engineering anything commercial.

• UK: the Copyright, Designs and Patents Act 1988 (section 50B) allows decompiling a program to achieve interoperability with another program, under conditions, and section 50BA allows observing and testing a program's behaviour if you have the right to use it.
• EU: the Software Directive (2009/24/EC, Article 6) gives a similar, narrow interoperability exception.
• US: reverse engineering for interoperability has been accepted as fair use in several cases, but the DMCA's anti-circumvention rules (section 1201) apply when protection measures are involved, with specific exemptions such as good-faith security research.

Licence terms matter too: many end-user licences forbid reverse engineering, and the AI provider's own usage policy applies to what you ask the model to do. Analysing your own code, open-source software, CTF challenges or malware samples for defence is the safe ground.

Where to start

1. Install Ghidra and pick a target you are allowed to analyse - a CrackMe or a CTF binary is ideal.
2. Connect GhidraMCP to Claude Code or Claude Desktop and ask for a function map with addresses.
3. Verify three of the agent's claims by hand before trusting the fourth.
4. When your targets diversify, look at a multi-engine MCP such as REA - after checking its Node.js requirement and running the dry run.

The agent-harness side of this story is moving just as fast. If you want to see how an open agent framework is put together from the inside, read my teardown of DeepSeek Harness. And if you are curious what this kind of bundle inspection finds on a real website, here is how I fixed unused JavaScript and LCP render delay in Next.js.