Does REA replace Ghidra?

No. For native binaries REA uses a deep-analysis provider — Hopper, Ghidra or IDA — and drives it for your agent. For static JavaScript and .NET it needs no native engine at all. So REA can be a wrapper around Ghidra rather than an alternative to it.

Is Ghidra free and is REA free?

Ghidra is a free, open-source disassembler and decompiler. REA is MIT-licensed TypeScript shipped as the rea-agents npm package. The cost hides in the other providers: Hopper, IDA and JEB are commercial and must be legally obtained — REA grants no licence, key or activation entitlement.

Which should a beginner learn first?

If your goal is understanding how a feature behaves so you can rebuild it, start with REA against a JavaScript or Electron target, because there is no engine to configure. If your goal is reading assembly and becoming a binary analyst, learn Ghidra directly — an agent will not teach you the instruction set.

Can they be used together?

That is the normal case. Point REA at a native target with Ghidra as the provider, let the agent narrow the functions worth reading, then open Ghidra yourself for the instruction-level work. For large binaries, raise REA_GHIDRA_STARTUP_TIMEOUT_MS so the provider has time to load.

HomeComparedREA vs Ghidra

JudgementRead 18 Oct 2026

REA vs Ghidra: the question is badly formed

Ghidra is a disassembler you operate. REA is an MCP server that lets an agent operate Ghidra, Hopper or IDA for you. Asking which is better is a bit like asking whether a mechanic is better than a wrench — but the honest version of the question is real, and it has a different answer per target.

Compared against the project README and capability table as read 18 Oct 2026. Ghidra belongs to its maintainers; nothing here is an official statement from either project.

The difference in one table

Dimension	REA	Ghidra
What it is	MCP server + CLI that routes an agent to analysis tools, and the same workflows from a terminal	A standalone disassembler / decompiler with its own UI, loaders and script console
Native binaries	Drives Hopper, Ghidra or IDA; also caller-supplied GNU objdump and Rizin for offline work	Is one of those engines
JavaScript / Electron	Static analysis: modules, imports, source maps, routes, IPC, native add-on relationships — no engine needed	Not its job
.NET	Metadata, CIL instructions, declared native dependencies, build comparisons	Not its job
Websites, captures, devices	Chrome-family observation, HAR/SAZ and pcap inspection, adb, APK via JADX, firmware via Binwalk/Unblob	Out of scope
Output	Findings with evidence and stated limits, fed back into an agent that can then write and test a rebuild	Pseudocode, listings, xrefs you read and interpret yourself
Cost	MIT, shipped as rea-agents on npm. Hopper, IDA and JEB licences are yours to obtain	Free and open source
What it cannot do	Recover private source code; work without a provider on native formats outside the provider's support; install its own providers	Nothing about an agent's intent — you supply the questions and the reading

Pick by target, not by brand

Electron / JS

REA, no engine

Static analysis is built in and runs without executing the app. Ghidra cannot help you here.

Setup →

Native binary

Both — nested

REA narrows the functions worth reading through Ghidra, Hopper or IDA; you drop to the disassembler for instruction-level truth.

The loop →

Android

REA's lane

APK manifest, classes, decompiled methods and references via headless JADX plus a JDK. Flutter APK facts can be parsed statically.

Learning RE

Ghidra directly

If the goal is becoming able to read assembly, an agent will only make you worse at it. Stay in the disassembler.

Retro / 16-bit

Ghidra engine

There is a documented 16-bit DOS analysis path — which is how a PC-98 bullet-ring calculation got recovered at all.

Unattended job

Both caveats

macOS may raise a Hopper first-run dialog you must answer in the same session, and large binaries need a raised startup timeout.

What the “agent” part actually saves

Not the hard part — the reading is still the hard part. What shrinks is the loop between question and evidence. In a published case study, a sound-pan calculation in a DOS game was followed from a call into its position-to-pan helper, pseudocode was reconstructed to C, and the rebuild then passed 3,205 original x86 cases and reproduced all 63 compiled function bytes. Another traced a clipboard feature through renderer, preload and IPC into the main process of an Electron app. Those numbers are the point: the agent proposes, and behaviour either matches or it does not.

That is also why claims that a project “cloned itself” are misleading. It recovers observable behaviour — rules, thresholds, data flow — with evidence attached, and stops at private source code it cannot see.

Three honest reasons to skip REA

01
You want to learn reverse engineering.
Delegation is the opposite of skill acquisition. Ghidra, a manual, and patience.
02
Your target is one tiny function you can already find.
Opening the disassembler yourself is faster than describing it to an agent.
03
You cannot legally examine the target.
No tool choice fixes that. Licence terms and your jurisdiction decide first.

Also worth comparing

REA is not the only agent-facing reverse-engineering toolkit — discussion around it notes many have appeared since. Per-tool capability tables matter more than star counts, so compare what each can actually inspect on your platform before switching.

FAQ

Does REA replace Ghidra?	No — for native binaries it uses Ghidra, Hopper or IDA as a provider. For static JavaScript and .NET it needs no native engine.
Do I need a paid tool?	Not to start: static JS and .NET need nothing, and Ghidra is free. Hopper, IDA and JEB are commercial and must be legally obtained.
Beginner path?	REA plus an Electron or JS target you own. No engine, no runtime risk, real evidence output.
Can I use them together?	Normal case. Let the agent narrow scope, then read the disassembly yourself.