REA 與 Ghidra：一週實測比較

Disclosure: I run reaguide.online, an independent, lab-verified tutorial site for REA. It is not affiliated with the REA project (morluto) or the Ghidra project. Every REA-side claim below comes from runs I executed myself on 2026-10-12 in my own lab; Ghidra-side facts come from its developer-published documentation, cited inline.

Every "REA vs Ghidra" take I've seen so far is written by people who already live in disassembly view. I'm not here to relitigate that. Two weeks ago I knew neither tool, so I ran both from zero on a clean Linux box — same machine, same day, one week of actual use. This is the comparison I wish I'd found: two dimensions that matter — the evidence each tool gives you, and what its analysis output can actually resolve — plus the honest install experience.

If you want the full beginner-oriented version with checklists, the companion page is Ghidra vs REA for beginners. What follows is the condensed, evidence-first version.

The one-paragraph setup

Ghidra is a free, open-source reverse-engineering suite: disassembler, decompiler, interactive GUI, scripting, headless analyzer. Originally developed by the NSA, released as open source in 2019. [Source: Ghidra project documentation]

REA (the rea-agents npm package, MIT) is not a rival on the same layer. It's an agent orchestration layer: you describe a goal in your AI coding agent, REA plans the tool calls, runs analysis engines — including Ghidra itself — and returns structured, citable results over MCP. Installed in one npm install rea-agents, no engine required for first use.

That layer difference resolves half the "vs" before it starts. The interesting question is what each one hands you when you ask it a question.

Dimension 1: the evidence trail (the sharpest difference)

This is about trust, not power.

REA stamps every result. In my lab runs, each output carried a content-addressed evidence_id, the analyzed input's sha256, and the exact provider + library versions. On a 4.5 MB system library (libcrypto.so.3, OpenSSL 3.0.12 — Apache-2.0 explicitly permits decompilation for research), the CLI returned the full result: 30 sections, 11 segments, each record verifiable. When a result is too large to return over MCP, REA refuses with resource_constraint and points you at an exportable evidence bundle — it never silently truncates.

Ghidra reports what its analyzers find in its own UI and exports. There is no built-in, cross-run, content-addressed audit artifact of the kind REA emits — and that's not a defect. Ghidra was built as an analyst's workbench, where the analyst is the chain of custody. But if your output has to convince someone else — a report, a ticket, a reproducible claim — REA's trail does that out of the box.

One concrete moment sold me on the design: with no engine installed, REA's analyze command fails closed — provider_unavailable, plus a per-engine diagnosis (ghidra: not_configured / hopper: executable_missing / ida: not_configured). It refuses to guess rather than fabricating a plausible-looking answer. Anyone who has watched an LLM hallucinate a function name from a mangled decompilation knows why that matters.

Dimension 2: what the analysis output actually resolves

I ran the same minimal target through both: a tiny hello.c I compiled myself (the lawful first target — you own it, you can analyze it).

Reading the binary by hand (Ghidra's home turf): the classic loop is file → readelf -h → readelf -s → objdump -d, and the payoff is real. The symbol table shows a function named secret; the disassembly shows imul eax, eax, 0x539 then add eax, 0x7. You infer secret(x) = x·1337 + 7, run the binary to confirm (42 → 56161), and you've closed the loop: hypothesis, evidence, verification. Ghidra's decompiler window industrializes exactly this reading skill — that's its superpower, and it's the vocabulary every RE course assumes.

Asking an agent (REA's home turf): same binary, one natural-language request — "inspect this ELF's layout" — and REA returns the section table, entry point 0x400320, and an evidence ID whose sha256 I recomputed afterward to confirm it matched the input. The result agreed with the manual readelf numbers line by line. The workflow you learn is different: phrasing goals, reading evidence records, auditing what the agent claims.

Honest limits, from the same runs: REA's free built-in engine (pwntools-elf) covers ELF layout only. Ask it to decompile with no engine installed and it refuses — by design. Point it at a Ghidra install (GHIDRA_INSTALL_DIR) and the decompiler comes along with the evidence contract intact. The strongest configuration is both: Ghidra as the engine, REA as the auditable agent driving it.

The install experience, day one

• REA: npm install rea-agents, then rea doctor. Install finished clean, zero vulnerabilities; doctor printed a plain-language checklist — including flagging that my distro wasn't on the supported-host list, before I wasted an hour. Working CLI in minutes.
• Ghidra: download the release archive, install a supported JDK, extract, launch the GUI. [Source: Ghidra installation guide] None of it is hard, but there are more steps, and the first GUI session assumes you already know what you're looking at.

For a complete beginner the sequencing that worked for me: REA first for momentum and the evidence-first habit, Ghidra second when you want to read disassembly yourself.

Verdict

• Need your conclusions to be auditable by someone else → REA's evidence trail is the differentiator.
• Want to learn classic RE and read decompiled code by hand → Ghidra, full stop.
• Doing serious agent-driven analysis → both, wired together.

Neither is "better." They're on different layers — and the search results that told me otherwise cost me a weekend.

Facts, versions and numbers above reflect lab runs on 2026-10-12 and will age. Full setup walkthrough with terminal sessions: realearn setup guide. Use every tool discussed only on software you have the right to analyze.