REA and the Reverse-Engineering Toolkit Landscape: How It Works, Tools Compared and a Learning Path (2026)

Short answer: REA ("Reverse Engineer Anything") is a free, MIT-licensed layer that lets an AI coding agent drive reverse-engineering tools such as Ghidra, Hopper and IDA. It doesn't replace them. This guide is the hub for our REA series. It explains how REA works in practice, maps the tools and repositories around it with licenses and GitHub numbers checked on 19 October 2026, and gives you a concrete end-to-end workflow and a learning path.

New: if your question is "so what do I actually do?", jump to The actual workflow: from binary to understanding to redesign.

REA series: start where you are

If you want...	Read
What REA is, the timeline and the Adobe/Excel clone confusion	What Is REA?
To install it for Claude Code, Codex or Cursor	Install guide
To pick Ghidra, Hopper or IDA as the backend	Backend setup guide
A hands-on walkthrough	Electron, .NET and APK tutorial
REA against single-tool MCP servers	REA vs GhidraMCP vs IDA Pro MCP vs Binary Ninja MCP
Fixes, token cost, privacy and legal limits	Troubleshooting and FAQ
The game-security side	AI game cheats, the PS5 jailbreak and AI-rebuilt games, Is reverse-engineering a game legal?, Xbox Labs vs PS5 lockdown

This page doesn't repeat those posts. It adds a step-by-step workflow, the wider tool map, the last week's news and a learning path.

How REA works in practice

Reverse engineering means studying software you don't have the source for, to understand what it does. The classic workflow is manual. You open a binary in a disassembler or decompiler, read assembly or pseudo-C, rename things as you learn, and test guesses in a debugger.

REA automates the legwork. Per its README:

1. You ask your agent a plain-English question ("how does this app's single-instance lock work?").
2. The agent calls REA through MCP (Model Context Protocol), or you run the same commands from a terminal.
3. REA drives existing tools on your machine: Ghidra, Hopper or IDA for native code, plus handlers for JavaScript/Electron, .NET, Android and websites.
4. Findings come back with evidence and limitations, and the agent explains, asks follow-ups, or writes and tests its own implementation.

Two points worth knowing:

• REA ships no decompiler of its own. Native analysis needs Ghidra, Hopper or IDA installed. Static JavaScript analysis needs no native engine.
• Analysis runs locally, but whatever the agent sees can reach your model provider. Keep that in mind for confidential targets.

Setup is one command, per the README: npx rea-agents setup. Our install guide covers the details.

What the showcases demonstrate

InfoQ (17 Oct 2026) reports the project's showcases include tracing Notion's Electron clipboard implementation, reconstructing a sound-panning function from the old game DX-Ball (tests matching all 3,205 original x86 cases), and recovering bullet-ring angle calculations from the 16-bit DOS game Touhou 4. These are the project's own showcases as reported by InfoQ. We haven't reproduced them.

A fair skeptical view

InfoQ also notes that some Hacker News commenters question what REA adds beyond asking an agent to install and use Ghidra, while others report better results than in earlier attempts. A third-party benchmark in the aicodeking/leanrea repo (below) makes the same point with numbers. Treat all of this as early and unsettled.

The actual workflow: from binary to understanding to redesign

The short version of what you do: open the program in a decompiler, let an AI agent help you read and label it, check its claims against what the program really does, then write down how it behaves and build your own version from that write-up. Here is that as eight concrete steps.

Step by step

1. Pick a target. Good first targets are a program you compiled yourself, an open-source tool, a CTF binary, a malware sample (in a sandbox VM), or an old utility you have the right to analyze. Start small: a few hundred lines of C is plenty.
2. Triage before you decompile. Find out what you have: file type and architecture (file), packers and compilers (Detect It Easy), readable strings (strings, or FLOSS for obfuscated ones) and capabilities (capa). Write down the imports and interesting strings. They tell you where to look first.
3. Load it into a decompiler and let it auto-analyze. Ghidra (free), IDA Free, or Binary Ninja. Import the file, accept the default analysis, and wait. You now have disassembly, pseudo-C, a function list and cross-references.
4. Connect an AI agent. Either use REA through MCP (see the install guide), use a single-tool MCP such as GhidraMCP, or give Claude Code, Codex or Cursor a skill that calls command-line tools. Then ask concrete questions. Examples:
   • "Map the entry point and the main subsystems of this program."
   • "List the functions that touch the file or network APIs and group them by purpose."
   • "Rename functions by what they do, and show me your evidence for each name."
   • "Explain this function and the data structure it reads and writes."
   • "Which function parses the input file format? Describe the header layout."
5. Annotate with AI assistance. Apply the good answers in the decompiler: rename functions and variables, define structs and enums, fix types. Ask the agent to draft a function and call graph and a written architecture note ("modules, key data structures, control flow"). Keep this in a plain Markdown file as you go. It becomes your spec.
6. Verify against real behavior. Decompiler output and AI explanations can be wrong. Run the program in a sandbox or VM and confirm with a debugger (x64dbg on Windows, gdb or lldb elsewhere) or with Frida hooks that log arguments and return values. Feed it known inputs and compare the outputs with what your notes predict. Fix the notes where they differ.
7. Redesign: spec first, then rewrite. Turn the verified notes into a behavior spec: inputs, outputs, file and message formats, edge cases and error handling. Then write a new implementation in a new codebase from that spec, in the language and architecture you prefer. Keeping analysis and implementation separate (ideally with the implementer working only from the spec) is the standard clean-room approach. Build tests that run the original and your version on the same inputs and compare results.
8. Document the findings. Keep the spec, the annotated project, the test inputs and a short list of what is confirmed, what is guessed, and what is unknown. Future you will need it.

Worked example on a harmless target

Suppose you write a small C program, csv2json, that converts a CSV file to JSON, then compile it stripped: gcc -O1 -s -o csv2json csv2json.c. Now pretend the source is lost.

1. Triage: file shows a 64-bit executable. strings reveals usage text and error messages such as a missing-file message. Those point at the argument handling and the file-reading code.
2. Load in Ghidra, run auto-analysis, find main from the entry point.
3. Ask the agent: "Explain main, name the helper functions it calls, and describe the data structure that holds one row."
4. Annotate: rename the helpers (for example parse_row, escape_json_string, write_output), and define a row struct.
5. Verify: run the program on three small CSV files, including one with quoted commas and one empty file. Compare its output with what the spec says. Use gdb or Frida to confirm which function handles the quotes.
6. Write the spec: "Reads a header line, then rows. Commas inside quotes don't split fields. Empty input produces an empty JSON array." (Whatever your tests confirm.)
7. Reimplement in another language, such as Python or Rust, from the spec only, and run both programs on a folder of test files. Any difference is a bug in either the spec or the rewrite.

You can do the same with any open-source command-line tool: build it, strip it, analyze it, and compare your findings with the real source afterwards. That is the fastest way to learn how far you can trust the AI's reading.

Common pitfalls

• Hallucinated names and purposes. Agents can confidently label a function wrongly. Ask for evidence (strings, calls, cross-references) and check by running the program.
• Obfuscation and packing. Packed or obfuscated binaries produce junk decompilation until they're handled. Triage with Detect It Easy first, and expect much harder work.
• Token cost. Large programs mean many tool calls and big outputs. Work subsystem by subsystem, and consider a lean setup. See the FAQ.
• Context limits. The agent forgets earlier findings in long sessions. Keep the Markdown notes file updated and point the agent at it.
• Privacy. Whatever the agent sees can reach your model provider, so be careful with confidential binaries.
• Compiler artifacts. Optimized code inlines and reorders things. A function that looks strange may be an ordinary compiler pattern.
• Reproducing instead of redesigning. A rewrite should match behavior, not copy decompiled code. Decompiler output isn't a finished program. It is a reading aid.

What this does and doesn't do

This workflow explains and recreates behavior. It doesn't recover the original source, and the rewrite will differ in structure and naming. It isn't a way to defeat protections or to clone commercial apps.

What's new in the last week (12-19 Oct 2026)

All figures are from the GitHub API or the sources named, checked on 19 Oct 2026 (KST).

• Releases are fast. REA v6.5.0 shipped on 14 Oct, v6.6.0 and v6.7.0 on 18 Oct (GitHub releases). Our earlier comparison cited 6.4.0, so it's now a few versions behind.
• Stars and forks: morluto/rea showed about 321,600 stars and 81,500 forks, with about 1,200 open issues and PRs. That is up from about 168,000 stars in our 13 Oct comparison, and InfoQ's "over 200K" on 17 Oct is consistent with the climb. Star counts move daily.
• Press: InfoQ covered the project on 17 Oct, including the debate over dual use and the worries of independent developers who fear easier copying of their apps.
• A lean alternative: aicodeking/leanrea (created 17 Oct, MIT, about 625 stars) is a single 8 KB skill file that tells an agent to use plain command-line tools instead of an MCP server. Its README reports a benchmark where leanrea cost less and ran faster than REA at similar accuracy. This is the leanrea author's own test (4 tasks, 3 repetitions, one model setup), so treat it as a claim, not a verdict. It's worth reading if token cost bothers you.
• Awesome lists: many appeared within days, such as reacher-z/Awesome-REA (about 43 stars) and AIshihzong/awesome-reverse-engineer-anything (about 33 stars). The REA author's own list is morluto/awesome-reverse-engineering (about 830 stars, CC0). Quality varies, so check what you click.
• Add-ons and wrappers: examples include a Docker packaging of REA (alexmi256/rea-agent-docker, 4 stars), nemo22/retrokit (headless Ghidra for old DOS and Win32 games, about 25 stars, Apache-2.0), and Graphify-Labs/REAgraph (graph memory for RE, 7 stars). These are tiny and brand new. We haven't audited any of them.
• Hex-Rays and Binary Ninja moved too. Hex-Rays has an official IDA MCP server (HexRaysSA/ida-mcp, created 27 Aug 2026, MIT, about 1,270 stars), which needs IDA 9.4 or higher with idalib. Binary Ninja's free page now lists "MCP server for driving analysis with an LLM", and the page banner advertises Binary Ninja 6.0 with MCP.

Warning: lookalike repositories

Search results for "REA" are full of new repositories, and some have names like "unlock" or "restore any app". REA's README says to get it only from morluto/rea, rea.tools or the rea-agents npm package, and says a similar name or copied README doesn't make a download official. Fake "AI hacking tools" are a classic malware lure. Don't run installers from repos you can't vet.

The tool landscape: licenses, links and stars

GitHub stars and licenses were read from the GitHub API on 19 Oct 2026. Where GitHub's license detector returned "NOASSERTION", we read the license file ourselves. Stars measure popularity, not quality.

Disassemblers, decompilers and debuggers

Tool	What it is	License / price	GitHub (stars, 19 Oct)	Notes
Ghidra	Full disassembler and decompiler suite from the US NSA	Apache-2.0, free	NationalSecurityAgency/ghidra, ~90,900	Latest release 12.1.4 (21 Sep 2026). REA's free native backend
IDA Free	Hex-Rays' free tier	Free for non-commercial use only	Closed source	Per Hex-Rays: x86-32 and x86-64, cloud-only decompiler, no SDK or IDAPython
IDA Pro and Home	The industry standard	Commercial	Closed source	Hex-Rays' table lists 60+ disassemblers for Pro. Needed for the official IDA MCP server
Binary Ninja	Commercial RE platform	Paid. Free edition for non-commercial use; free cloud version	Open API repo: Vector35/binaryninja-api, ~1,330, MIT	Per Binary Ninja: the free edition decompiles x86, x86_64, ARMv7 and AArch64, and has no API or plugin access. The cloud version requires uploading your binaries to Vector 35
Hopper	Mac-native disassembler (site describes it as affordable)	Commercial, with a demo	Closed source	The site lists an integrated MCP server, Objective-C/Swift support and Python scripting
radare2	Scriptable command-line RE framework	Mostly LGPL-3.0, per its COPYING.md (some components differ)	radareorg/radare2, ~25,100	Steep learning curve, very scriptable
Rizin	A fork of radare2	LGPL-3.0	rizinorg/rizin, ~4,000	Cutter is its GUI
Cutter	GUI for Rizin	GPL-3.0	rizinorg/cutter, ~20,100	Last push 11 Sep 2026, so quieter than Rizin itself
x64dbg	Open-source Windows debugger	GPL-3.0 (LICENSE file)	x64dbg/x64dbg, ~49,900	Windows only. Debug your own builds or analyze malware in a VM
Frida	Dynamic instrumentation toolkit	wxWindows Library Licence 3.1 (COPYING file)	frida/frida, ~22,400	Hooks running apps to observe behavior. Use on test apps and devices
angr	Python binary-analysis and symbolic-execution framework	BSD-2-Clause	angr/angr, ~9,200	Strong for research and CTFs

Helper tools you'll meet constantly

Tool	Use	License	Stars
jadx	Android APK decompiler	Apache-2.0	~51,100
ILSpy	.NET decompiler	MIT	~26,700
dnSpy	Older .NET debugger and editor	No license detected	~29,700. Archived, last push Dec 2020
Detect It Easy	Identify file types, packers and compilers	MIT	~11,800
capa	Lists what a program can do (malware triage)	Apache-2.0	~6,250
FLOSS	Extracts obfuscated strings	Apache-2.0	~4,200
binwalk	Firmware unpacking	MIT	~14,500
LIEF	Parse and inspect ELF, PE and Mach-O files	Apache-2.0	~5,600

MCP servers and AI add-ons (the "AI layer")

Project	Targets	License	Stars (19 Oct)	Notes
morluto/rea (REA)	Ghidra, Hopper, IDA, plus Electron, .NET, APK, web	MIT	~321,600	Official sources are listed above. v6.7.0 on 18 Oct
LaurieWired/GhidraMCP	Ghidra	Apache-2.0	~11,400	Last push 10 Oct 2026
symgraph/GhidrAssistMCP	Ghidra	MIT	~780	The old jtang613 URL now redirects here
cyberkaida/reverse-engineering-assistant	Ghidra	Apache-2.0	~880	Created in 2023, so it predates the MCP wave
mrexodia/ida-pro-mcp	IDA Pro	MIT	~13,000	Per earlier checks, its README points users to the official Hex-Rays server
HexRaysSA/ida-mcp	IDA 9.4+	MIT	~1,270	Official, from Hex-Rays
fosdickio/binary_ninja_mcp	Binary Ninja	GPL-3.0	~455	Community project. Several others exist, such as mrphrazer/binary-ninja-headless-mcp (~258, GPL-2.0)
radareorg/r2ai	radare2	MIT	~490	Radare2's own AI integration
aicodeking/leanrea	Plain CLI tools	MIT	~625	Skill file instead of an MCP server, created 17 Oct

We didn't find a verified, widely used x64dbg MCP or Frida MCP in this pass, so we aren't listing one. They may exist. Verify before you trust any.

Which tool for which job?

Goal	Good starting point	Why
Learn the basics for free	Ghidra	Free, full decompiler, huge community
Analyze malware safely	Ghidra, capa, FLOSS, Detect It Easy, in an isolated VM	Free static triage without running the sample
Mac and iOS software	Hopper or Ghidra	Hopper has native Objective-C and Swift support
Android apps	jadx, then Ghidra for native libraries	jadx recovers Java/Kotlin-like code
.NET assemblies	ILSpy	Near-source decompilation
Debug a Windows build	x64dbg	Free, popular
Instrument a mobile app	Frida	Observe functions at runtime
Research and CTF automation	angr, pwntools	Scriptable analysis
Let an agent drive the tools	REA, or a single-tool MCP	See our comparison
Keep tokens and cost low	A single-tool MCP, or an 8 KB skill like leanrea	REA's full catalog is large. See the FAQ

What people use it for

• Malware analysis: work out what a suspicious sample does, extract indicators and write detections. Use a disposable VM with no network.
• Interoperability: understand an undocumented file format or protocol so your own software can work with it.
• Security research: find and report vulnerabilities through coordinated disclosure.
• Recovering lost source: rebuild understanding of a program when the source is gone.
• Capture-the-flag (CTF) contests and training labs: purpose-built practice binaries.
• Learning: study how compilers turn C into machine code, using open-source programs and your own builds.
• Auditing what you run: check what an app you installed actually does with your data.

Setup pointers for open-source tools

These are pointers, not a full tutorial. Use each project's official docs.

1. Ghidra: download from the official releases page. It needs a JDK, and the docs list the supported version. Create a project, import a small binary, accept auto-analysis.
2. Rizin and Cutter: use your package manager or the official download pages at rizin.re and cutter.re.
3. x64dbg: Windows only. Download from x64dbg.com. Run risky samples in a VM, never on your main machine.
4. Frida: install from the official instructions at frida.re and begin with a test app you built.
5. angr: a Python package. See angr.io for install steps and tutorials.
6. REA on top: after Ghidra works by hand, follow our backend guide and install guide.

Always download from the project's own site or repository. Don't use mirrors or "pre-activated" builds, which are malware vectors.

A learning path

1. Foundations (weeks 1-2): learn C basics and what a compiler does. Compile small programs yourself, then open them in Ghidra and match source to disassembly.
2. Tool fluency (weeks 3-4): practice naming functions, reading strings, following cross-references and using the decompiler. Try an open-source program you built.
3. Structured practice: the free OpenSecurityTraining2 courses, pwn.college and picoCTF give you practice targets and curricula. We checked that these sites respond, but we haven't reviewed every course.
4. Dynamic analysis: use x64dbg or Frida on your own builds to compare what you read with what actually happens.
5. Add an agent: run REA or a single-tool MCP on a small target, then verify its claims by hand. Agents can sound confident while wrong.
6. Specialize: malware triage (capa, FLOSS), mobile (jadx, Frida), firmware (binwalk) or vulnerability research (angr).

Use the electron/.NET/APK tutorial for your first agent-assisted session.

A short note on legality

This is a tool guide, not legal advice. Copyright, license terms and reverse-engineering exceptions (for example for interoperability) differ by country, so check the rules where you live and the terms of the software you analyze. Understanding how something works is not the same as copying it, and this guide doesn't cover bypassing licenses, DRM or anti-cheat, or building cheats. For games specifically, see Is reverse-engineering a game legal?.

What we couldn't verify

• Star and fork numbers change hourly. Treat every figure as a snapshot from 19 Oct 2026, KST.
• We haven't run every tool. Setup notes come from official pages, and licenses from GitHub and project files.
• We didn't audit the new third-party REA add-ons, awesome lists or lookalike repos.
• The leanrea benchmark and the showcase test counts are the authors' own claims, as reported.
• We don't know who is behind REA beyond the handle morluto. InfoQ says the real name hasn't been publicly identified.
• Prices for commercial licenses change often. Check the vendor pages (Hex-Rays, Binary Ninja, Hopper) before buying.

Sources checked 19 Oct 2026: GitHub API (stars, licenses, release dates), the REA README and rea.tools, the Hex-Rays IDA Free page and IDA MCP README, Binary Ninja's free-version page, the Hopper site, InfoQ (17 Oct 2026), AICoder and Code&Chain (8-9 Oct), Libraries.io (npm release list), the radare2, x64dbg and Frida license files, and each project's official site.

---

← Back to all posts