Skip to content
All posts

The AI Reverse-Engineering Studio: 20 Open-Source Tools Around REA, Explained

October 27, 2026 · PlayCISO
TL;DR

The "AI reverse-engineering studio" doing the rounds is 20 GitHub projects in five layers: an analysis core (REA, Ghidra, GhidraMCP, ida-pro-mcp), mobile and managed-code decompilers (jadx, Apktool, Frida, ILSpy), binary and low-level tools (radare2, x64dbg, ImHex, angr), network and runtime tools (mitmproxy, dnSpyEx, rizin, RAD Debugger), and a "rebuild and verify" layer (curated lists, REA's workflow prompts, and a clean-room SPEC.md-plus-oracle loop). Almost all of these tools are long-established, legitimate, and used every day by malware analysts and vulnerability researchers. What is new is the glue: MCP servers like REA, GhidraMCP and ida-pro-mcp let an AI agent drive a decompiler and debugger directly, which collapses hours of manual reverse engineering into minutes. That is a big win for defenders and a real shift in risk for anyone who ships secrets or business logic inside a client app. Two of the bundle's claims (a "122 graded repos" list and REA itself shipping a clean-room rebuild loop) we could not verify; REA's own README says it does not recover original source or clone apps.

This post references: https://github.com/morluto/rea

A post calling it "f*cking dangerous" has been doing the rounds: the creator of REA (Reverse Engineer Anything) lists 20 GitHub repos that together make "a reverse-engineering studio." Point it at any app, the pitch goes, "and watch it explain itself." Strip away the hype and it is a genuinely useful map of the open-source reverse-engineering toolchain, plus one new ingredient that does change the game. Here is what each piece is, how they fit, what we could not verify, and what it means for defenders. (New to REA itself? Start with our REA explainer.)

What is actually new: the MCP glue

Almost every tool in the list has existed for years. Ghidra was released by the NSA in 2019; radare2, Frida, jadx and x64dbg have been staples for a decade. The shift is the Model Context Protocol (MCP) bridges — REA, GhidraMCP and ida-pro-mcp — that let an AI coding agent drive a decompiler, read pseudocode, rename functions, set breakpoints and query the results itself. Work that took an analyst hours of clicking now happens in a conversation. REA installs with npx rea-agents setup, registers with agents such as Claude Code, Codex, Cursor and Gemini CLI, and installs matching workflow instructions.

The 20 tools, layer by layer

LayerToolWhat it doesNote
01 Analysis coreREAMCP server + CLI giving an agent RE tools for binaries, Electron/JS, .NET, APKs, websites, firmwareMIT; says it does not recover source or clone apps
GhidraFull disassembler + decompiler suiteFree; released by the NSA
GhidraMCPLets an agent drive Ghidra over MCPBy LaurieWired
ida-pro-mcpLets an agent drive IDA Pro over MCPNeeds a licensed IDA Pro
02 Mobile & appsjadxDecompiles Android DEX/APK to JavaFree
ApktoolDecodes and rebuilds APK resources/smaliFree
FridaDynamic instrumentation — hook functions in a running appExecutes the target
ILSpyDecompiles .NET assemblies to C#Free
03 Binary & low-levelradare2Terminal-first RE frameworkFree
x64dbgWindows user-mode debuggerExecutes the target
ImHexHex editor with a pattern language for file formatsFree
angrBinary analysis + symbolic execution (from UC Santa Barbara)Python framework
04 Network & runtimemitmproxyInteractive HTTPS proxy to read/modify trafficFree
dnSpyEx.NET debugger + assembly editorMaintained fork; original dnSpy was archived
rizinRE framework forked from radare2Powers the Cutter GUI
RAD DebuggerNative graphical debugger from Epic GamesMIT; alpha; Windows x64 only
05 Rebuild & verifyawesome-ai-reverse-engineeringCurated list of AI RE repos"122 repos, every one graded" — not verified by us
awesome-reverse-engineeringCurated RE list by REA's authorNot independently reviewed
REA workflowsInvestigation instructions installed by REA setupConfirmed: setup installs workflow instructions
Clean-room loopSPEC.md → rebuild → oracle checks → retryA method, not an REA feature we could confirm — see our deep dive

How it chains together

The post's one-liner is binary → REA → SPEC.md → rebuild → oracle → retry. In practice a session looks like this:

  1. Triage. The agent identifies what the target is (native, .NET, Electron, APK) and picks the right tool — jadx for an APK, ILSpy for a .NET DLL, Ghidra or IDA for native code.
  2. Static analysis. Through GhidraMCP or ida-pro-mcp the agent reads decompiled pseudocode, follows cross-references and renames functions as it understands them; angr can answer "what input reaches this branch?" questions.
  3. Dynamic confirmation. Frida hooks, x64dbg or RAD Debugger breakpoints, and mitmproxy traffic capture confirm what the code actually does at runtime.
  4. Explanation. The agent writes up behaviour with the evidence it gathered — which is where REA's README stops: it explains, it does not recover source.
  5. (Optional) Rebuild. The clean-room loop turns the explanation into a behavioural spec and an independent implementation checked against the original as an oracle. That step is where most of the legal risk lives.

Is it "f*cking dangerous"?

It is a capability shift, not a new class of attack. Determined reverse engineers could always do this; the cost just dropped from days of expert time to an afternoon with an agent. That cuts both ways:

  • For defenders it is a gift. Malware triage, patch diffing, firmware audits and third-party binary reviews all get dramatically faster.
  • For software vendors it is a warning. Anything shipped to a client — API keys, license checks, pricing or fraud logic, proprietary algorithms — should now be assumed readable by anyone with a laptop.
  • For the agent operator it is a new attack surface. An agent reading a hostile binary is reading attacker-controlled strings, so prompt injection from inside a sample is a real risk. Dynamic tools execute the target, so isolation is mandatory.

How to use it responsibly

  1. Authorization first. Only analyze software you own, have written permission to test, or are researching under a legal exception. Read the EULA — many prohibit reverse engineering.
  2. Isolate. Run dynamic analysis in a disposable, network-restricted VM. Never debug unknown samples on your workstation.
  3. Narrow the agent. Give the MCP agent only the tools it needs, no ambient credentials, and review its actions — treat sample content as untrusted input.
  4. Keep evidence. Log what was analyzed, why, and under what authority. It protects you if questions come later.
  5. Turn it on yourself. Point the studio at your own release builds and see what an attacker would learn. Move whatever you find to the server.

These are third-party open-source projects; PlayCISO is not affiliated with any of them. Tool descriptions reflect public repositories as of October 2026. Not legal advice.

Frequently asked questions

What is the AI reverse-engineering studio?

It is not one product. It is a viral curation of about 20 open-source GitHub projects grouped into five layers (analysis core, mobile and apps, binary and low-level, network and runtime, rebuild and verify), built around REA (Reverse Engineer Anything, github.com/morluto/rea), an MIT-licensed MCP server that connects an AI coding agent to reverse-engineering tools. The other tools are mostly established projects like Ghidra, radare2, Frida and jadx; the new part is that MCP bridges let an agent drive them.

Is it legal to use these tools?

The tools themselves are legal and widely used for malware analysis, vulnerability research, interoperability and software preservation, which are the legitimate uses REA lists. Whether a particular use is legal depends on what you analyze and where: your licence terms (many EULAs prohibit reverse engineering), copyright and anti-circumvention law (for example DMCA section 1201 in the US, with an interoperability exception), and your jurisdiction. Only analyze software you own or are explicitly authorized to analyze, and get legal advice for anything commercial. This is not legal advice.

Can REA clone or recover the source code of an app?

No, by its own description. REA gives an agent access to decompilers, disassemblers and runtime tools to investigate native binaries, Electron/JavaScript apps, .NET assemblies, APKs, websites, firmware and more, and to explain how something works. Its documentation states it does not recover the original source code or clone apps. A decompiler produces pseudocode that approximates behaviour, not the original source, and rebuilding a feature from an explanation is a separate step with its own legal questions.

Which of these tools need a paid licence?

IDA Pro is commercial, so ida-pro-mcp needs a licensed IDA install. Everything else in the list is free and open source: Ghidra (released by the NSA), radare2 and its fork rizin, x64dbg, ImHex, angr, jadx, Apktool, Frida, ILSpy, dnSpyEx, mitmproxy, and Epic Games' RAD Debugger (MIT, currently alpha, Windows x64 only). REA itself is MIT-licensed and installs with npx rea-agents setup.

How should defenders respond to AI-accelerated reverse engineering?

Assume anything shipped to a client device will be read. Keep secrets (API keys, signing keys, pricing logic, anti-fraud rules) on the server, not in the app bundle; treat obfuscation as a speed bump, not a control; enforce authorization server-side so understanding the client gains an attacker nothing; and use the same tools yourself, on your own builds, to see what an attacker would find. On the blue-team side, these tools make malware triage dramatically faster.

Is it safe to point an AI agent at a malware sample with these tools?

Only inside an isolated analysis environment. Dynamic tools like Frida, x64dbg and RAD Debugger execute the target, so a malicious sample must run in a disposable, network-restricted VM, never on your workstation. Also remember that an agent reading attacker-controlled strings is exposed to prompt injection: a sample can contain text crafted to steer the agent. Keep the agent's own permissions narrow and review what it does.

Check the safety of an AI reverse-engineering setup
Before you wire an agent into a decompiler and a debugger, score the setup: authorization, sandboxing, data handling and legal exposure.
Open the AI RE Safety check →

Ready to practise the decisions these articles describe?

Run a free War Room →
🎉 New here? Use code WELCOME10 for 10% off any plan at checkout
The AI Reverse-Engineering Studio: 20 Open-Source Tools Around REA, Explained · PlayCISO