Skip to content

Reverse engineering with AI agents: the 12-repo stack, plus REA

A post doing the rounds on r/SATNA_PROJECT lists 12 open-source reverse-engineering tools and the MCP bridges that hook them up to AI agents. The framing is sound — extraction tools, debugging and binary inspection, and MCP integrations as the connection layer — and it matches how the ecosystem actually behaves. What's not on the list is the repo generating more noise in this space right now than everything else combined: REA, Reverse Engineer Anything. I pulled every repo on the list plus REA, read the READMEs and docs, and checked star counts, licenses, and commit dates against the GitHub API. This is what each one is actually good at, where the list falls short, and how the pieces fit together.

Method: GitHub API metadata for all thirteen repos as of November 3, 2026, full README and docs reads for the four MCP bridges and REA, and release notes anywhere version pinning matters. I did not run a binary through any of it for this post — it's a map of the ecosystem, not a lab report, and the claims are sourced from shipped docs and repo metadata.

The layering is the part worth keeping

The claim under the post is right and worth saying out loud: the agent doesn't reverse engineer anything. Ghidra decompiles, the debugger reads live state, the unpacker unpacks. What MCP changes is who turns the knobs. An agent can run the hundred boring iterations — rename this, re-decompile with the new type, follow this caller, re-comment that struct — that used to eat a human afternoon.

So the useful question per repo is: which layer does it own, and is that layer worth wiring to an agent at all.

Layer 1: core analysis and extraction

Ghidra

The NSA's framework, and the reason most of the rest of this list exists. Disassembly, its own IR (P-code) and decompiler, graphing, versioned projects, a real scripting API — Java, with Jython now an optional extension. Nothing open comes close on architecture coverage, and free is one of the ways it isn't IDA.

The decompiler is good enough to work in, and headless mode makes CI-scale batch analysis possible. The costs are honest: it's Java, it wants RAM, and analysis quality per binary still comes from iterating — the tool automates, the intent comes from you or your agent. If you're going to learn one engine off this list, it's this one.

Apktool

Decodes an APK's resources — the binary resources.arsc, 9-patches, all of it — into a nearly editable form, and rebuilds the package after changes. The post's distinction matters and people skip it: decoded resources are not source code. The code Apktool gives you is smali, and nobody writes business logic in smali by choice; for readable Java you want JADX. Where Apktool is irreplaceable is what an app declares — permissions, exported components, feature flags sitting in resources — and rebuilds of patched packages.

Binwalk

Signatures and entropy across a blob, then extraction: filesystems, compressed blocks, bootloaders. The v3 rewrite moved it to Rust and made it faster. Two notes. Development is slower than everything else here — last push August, while the rest of this list pushed within the week. And the identification half is worth more than the extraction half: nested containers usually need a second pass with something smarter. That something is unblob.

unblob

The pitch is recursion: apply every extraction handler it knows, repeatedly, until nothing new comes out. What you get back is an extracted tree plus a report of what it couldn't recognize. Fewer stars than binwalk; the engineering is better than the star count suggests. For firmware, run both — binwalk to identify, unblob to actually get things out.

Layer 2: debugging and binary inspection

pwntools

Not a disassembler — Python glue for driving processes, crafting payloads, ROP chains, shellcode, and remote interactions. It's the layer where analysis turns into interaction, and a decade of CTF culture stress-tested it. For agents it matters as a library to script against — REA uses pwntools itself as a provider for binary diagnostics.

pwndbg

A debugger plugin that makes GDB and LLDB show what you actually want: heap state, disassembly around $pc, syscall arguments, gadgets. The LLDB caveat the post flags is real — the project calls it early-stage — so don't assume the two debuggers behave alike. The agent angle: pwndbg's structured output is what a bridge wants to hand a model, instead of raw x/20gx noise.

LIEF

  • lief-project/LIEF · C++ with Python and Rust bindings · Apache-2.0 · ~5.6k stars · very active

The one here for programs rather than people: parse and modify ELF, PE, Mach-O, plus DEX/OAT/VDEX. If Ghidra is for humans reading pseudocode, LIEF is for tooling that edits binaries — header patching, import manipulation, packing analysis. Anything that needs to change a binary instead of read it should call LIEF rather than hand-edit bytes at offsets.

Detect It Easy

Format identification, compiler and packer signatures, entropy, quick viewers. A triage tool for the first thirty seconds with any file, and the post's caveat is the right one: the results are leads, not verdicts. DIE tells you a file smells like a .NET assembly packed with ConfuserEx, which tells you which of the other eleven tools to open next.

Layer 3: the bridges

This is where the list earns its keep, and where I learned things I didn't know going in.

ghidra-mcp

Started life as a fork of LaurieWired/GhidraMCP and has left it behind. 219 agent-visible tools. GUI and headless servers, Docker deployment, Ghidra Server (version control) integration, batch operations that cut API calls by roughly 93%, P-code emulation for running one function in isolation, and 16 live-debugger endpoints over Ghidra's TraceRmi — dbgeng on Windows, gdb/lldb elsewhere.

The feature I keep coming back to is convention enforcement in the tool layer: renames get auto-prefixed by type, style violations get warned or rejected, and function documentation gets a 0–100% completeness score. The failure mode it fixes is a real one — six agent sessions, six naming styles, and a rename pass six months later that shouldn't have to happen. Then there's cross-binary documentation transfer: SHA-256 function hashing, so document v1.0 once and the annotations ride to v1.1 automatically. Two gotchas: the extension only loads on the exact Ghidra build it was compiled against (12.1.4 right now), and the README says plainly that the dev branch breaks APIs — build nothing on it. Most production-ready bridge on the list.

jadx-ai-mcp + jadx-mcp-server

A JADX-GUI plugin plus a Python MCP server. The agent can pull the selected class, list methods, fetch smali, read AndroidManifest.xml, search by keyword, walk xrefs, rename classes, methods, fields, and packages — writes that persist in the project — add comments, and query the JADX debugger's stack frames, threads, and live variables. Modern JADX installs the plugin with one line: jadx plugins --install "github:zinja-coder:jadx-ai-mcp".

The same author ships an apktool-mcp-server in the same suite, which the list doesn't mention. If the target has an APK in it, this pair plus JADX and Apktool is a complete agentic Android stack.

radare2-mcp

The official radareorg project, and the one that changed my mind about how these bridges should be built: written in C against r2's own API, not a Python shim over CLI output. Install is r2pm -Uci r2mcp. It runs as a stdio server, an HTTP server with bearer-token auth and per-session multiplexing, or as a core plugin inside a live r2 session — the agent operates on whatever you already loaded and analyzed.

The security posture is the part other bridges should copy: read-only mode, sandbox lock, per-tool restrictions, and an approval supervisor before dangerous commands unless you explicitly flip "yolo" on. Smaller than ghidra-mcp and lower-level — r2 commands and r2js, no pseudocode decompiler unless you wire one in. If r2 is your engine, it's the tightest integration available.

mcp-windbg

Drives cdb.exe and kd.exe headless: open a .dmp with automatic triage (!analyze -v), attach to remote user-mode sessions, kernel targets over KDNET/pipe/serial, triage a folder full of dumps for a common signature. Session ids let several targets stay open at once, HTTP mode lets the agent drive a Windows box from elsewhere, and the no-Python path is a code-signed single binary with published SHA256s.

The detail I want everyone to steal: a --filter-script hook that redacts PII and secrets from debugger output before it leaves the machine.

The update the Reddit post missed: Microsoft now ships an official WinDbg MCP, starting with WinDbg 1.2610.1001.0. mcp-windbg's own README says so and draws its lane honestly — headless operation, non-Copilot MCP clients, driving across machines over HTTP, scripted batch triage. Copilot Chat inside WinDbg: use Microsoft's. An agent driving debugger sessions as infrastructure: use this one.

The repo that wasn't on the list: REA

  • morluto/rea · TypeScript · MIT · rea.tools · npm rea-agents
  • Created April 2026 · ~426k stars, ~106k forks as of November 3, 2026 · pushed hours ago

The one-line pitch: see a feature you want in your product, have an agent work out how the app that has it actually works — down to the binary level — and rebuild it in your codebase.

Structurally it's one MCP server and one CLI that npx rea-agents setup registers with Claude Code, Codex, Cursor, Gemini CLI, or Grok — or any MCP client by hand. It contains no decompiler. It routes: native binaries go to whichever of Hopper, Ghidra, IDA, or Kuna you already have installed; JavaScript/Electron and .NET get parsed statically by REA itself with no engine needed; Android goes through headless JADX, adb, or JEB; firmware through binwalk and unblob — it shells out to the layer-1 tools above itself. Then there's a long table of built-in static parsers: Go binaries (embedded module lists), Rust (cargo-auditable crate graphs), IL2CPP global-metadata.dat, Godot PCK, PyInstaller archives, WASM, PE certificates and imports, ELF notes, GGUF/safetensors headers, Apple .ips crashes, EVM bytecode, BEAM, even sigrok signal recordings.

What isn't plumbing is the discipline it puts on the agent:

  • Findings come back with the evidence and stated limitations attached. Not confident prose.
  • Every claim gets tagged seen, inferred, or unknown — observed and citable, strongly suggested but unconfirmed, or genuinely undetermined. This is the defense against an agent building a "clone" on top of a guess about how the original worked. It's the single most useful idea on this whole list of thirteen repos, and nothing else here enforces it.
  • Summary first. Analysis of a real app runs to gigabytes — one Loom analysis reportedly exceeded 1 GB. REA compresses that into a locally saved summary and drills into modules on demand, instead of the agent re-reading everything every turn.
  • Rebuild and test are one stage. The loop ends in your codebase with tests, not in a pile of pseudocode.

The showcases hold up: a DX-Ball sound-pan routine reconstructed to match all 63 compiled bytes across 3,205 test cases; a 16-bit PC-98 bullet-ring calculation recovered and diffed against the original compiler's output. There's also a strange side feature that's actually clever — record a web-app session (HAR), turn its API into tools, and export a runnable RL environment for training or evaluating agents.

Honest caveats:

  • It's young and moving fast: 1,700+ open issues, releases every few days, docs that tell you to update before filing a bug. Pin versions.
  • Commercial engines stay commercial. REA grants no licenses — the deep native paths want a legal Hopper/IDA/JEB install, and setup can install Hopper, which then asks for demo mode or activation. The README is blunt that cracked copies are not a supported path.
  • Star count measures the hype cycle, not maturity. 426k stars in seven months is unheard of; what held up under inspection was the docs, the evidence model, and the release discipline. Judge those, not the badge.
  • It overlaps the bridges. If ghidra-mcp already gives you 219 tools inside Ghidra, REA's Ghidra path is thinner than what you have. REA's bet is being one door into many target types.

The stack at a glance

Repo Layer Language Stars (Nov '26) Activity Wire it to an agent?
Ghidra Analysis engine Java ~97.5k Daily Yes — via ghidra-mcp
Apktool Android extraction Java ~27k Weekly For resources/manifest
Binwalk Firmware triage Rust ~14.6k Slow (Aug '26) Identification only
unblob Firmware extraction Python ~2.6k Daily Yes, recursive unpack
pwntools Interaction/exploit Python ~13.8k Daily As a scripting substrate
pwndbg Runtime inspection Python ~11.1k Daily Debugger output for agents
LIEF Format surgery C++ ~5.6k Daily Any binary writes
Detect It Easy File triage C++/JS ~11.9k Daily First step, cheap
ghidra-mcp MCP bridge Java/Python ~6.1k Daily The default native bridge
jadx-ai-mcp (+server) MCP bridge Java/Python ~3.0k Active The Android answer
radare2-mcp MCP bridge C ~0.35k Active Tightest, most safety-conscious
mcp-windbg MCP bridge Python ~1.6k Active Windows crashes/kernel
REA Orchestrator/router TypeScript ~426k Hyper Front door, pinned

How they actually combine

Firmware. DIE (what is this?) → binwalk (what's inside?) → unblob (get it all out) → Ghidra on the interesting ELF, driven through ghidra-mcp — batch-decompile, rename, document, score completeness — then pwndbg under QEMU if live state matters. With REA the first three steps collapse into one agent request: it shells out to binwalk and unblob and hands the extracted binary to the native engine itself.

Android. Apktool for manifest and resources, JADX plus jadx-ai-mcp for code the agent can read, search, xref, and rename live, the JADX debugger tools for runtime. The most complete vertical on the list.

Windows crash pile. mcp-windbg — or Microsoft's official WinDbg MCP if you live in Copilot — for dump triage, LIEF for preprocessing, Ghidra for the module that bugchecked.

CTF and exploit research. DIE and radare2-mcp or ghidra-mcp for recon and understanding, pwndbg plus pwntools for interaction, LIEF for patching.

Where REA sits: on top of all of it, as router and methodology. The bridges give depth inside one engine — ghidra-mcp especially, with 219 tools, debugger control, and convention enforcement. REA gives breadth across target types plus the evidence discipline. Both, not either: REA as the front door for "understand this thing," ghidra-mcp when an agent has to live inside one Ghidra project for a week.

Caveats that apply to the whole ecosystem

  1. Legal first. All of it is for software you own, are authorized to analyze, or are doing interop and preservation work on. The "clone that feature" pitch has real IP boundaries, and REA itself says the method is understanding behavior, not lifting code or assets.
  2. Isolation. Malicious or crashy targets belong in disposable VMs. An agent with a bridge into a live debugger has real reach — radare2-mcp's approval mode and mcp-windbg's redaction hook are the right instincts, and every bridge should have both.
  3. Binaries are untrusted input to your model. Strings, symbols, and comments in a target are text your agent will read. A crafted binary can bait a model the same way a crafted webpage can. Treat engine output as data, sandbox the agent's side effects, and use read-only modes on first contact.
  4. Verification is the job. The post's closing line is the correct takeaway: an agent-generated explanation is a claim — check it against the disassembly, the bytes, a test that reproduces the behavior. REA's seen/inferred/unknown tagging is the only thing on this list that builds that discipline into the tool itself.
  5. Supply chain. npx ... setup one-liners and MCP servers that write to your agent's config are themselves attack surface. Pin versions, read what setup writes before you let it write, and get REA from the official repo and package — its README warns about lookalike repos because lookalike repos exist now.

What I'd actually run

DIE, binwalk, and unblob installed for triage. Ghidra with ghidra-mcp for native work — 219 tools plus convention enforcement makes it the default bridge. The jadx pair for anything with an APK. mcp-windbg for Windows crash dumps, and Microsoft's official one if the whole shop lives in Copilot. REA as the front door, pinned to a release version, with its seen/inferred/unknown contract applied to everything that comes out the other end.

Comments