REA vs Ghidra: Which Reverse Engineering Workflow Fits?

Use Ghidra when you want to explore and edit a native binary analysis project directly; use REA when you want a coding agent or CLI to investigate software and return findings with evidence. REA can use Ghidra as a native analysis provider, so the two tools can be parts of the same workflow.

This is an independent community comparison. The REA repository and Ghidra repository are the primary sources for current capabilities and requirements.

What is the difference between REA and Ghidra?

Ghidra is a software reverse engineering framework with disassembly, decompilation, graphs, scripting, and interactive or automated analysis. Ghidra's own analysis environment gives an analyst direct control over the investigation. The official Ghidra README describes its processor, executable-format, and extension support.

REA is an MCP server and CLI spanning several target families, including native binaries, JavaScript/Electron applications, browser pages, and managed assemblies. A coding agent calls REA's tools, receives findings and limitations, and decides what to inspect next. For deep native analysis, REA connects to a supported installation of Ghidra, Hopper, or IDA. REA's native guide explains that provider relationship.

What do you need?	Better starting point	Input	Output or advantage
Manually follow binary functions and graphs	Ghidra directly	Supported binary	Full interactive analysis environment and direct project control
Ask an agent why a native feature behaves a certain way	REA with a supported native provider	Binary plus focused question	Agent-guided findings, evidence, and explanation
Keep and develop an analysis project over time	Ghidra directly	Imported program and analyst changes	Persistent project workflow under your control
Inspect an Electron module or IPC path	REA's JavaScript workflow	App folder or ASAR	Modules, relationships, and source locations without a native engine
Script repeatable native analysis	Either, depending on control needed	Binary and analysis script or CLI request	Ghidra scripting or REA's structured CLI results

When is Ghidra the stronger choice?

Choose Ghidra directly when the work depends on continuous visual exploration, detailed analyst changes, custom scripts, or a persistent program database. Ghidra's native interface exposes the analysis project itself. An experienced analyst can inspect instructions and graphs without translating each action into an agent request.

Using REA with Ghidra does not expose every Ghidra feature through MCP. The REA provider documentation describes verified operations and host restrictions. REA's documented headless workflow uses an ephemeral project; it does not open your existing user project. Prefer Ghidra's direct interface when maintaining that existing project is a requirement.

Ghidra also has its own automated and scripting workflows. A claim that Ghidra is only manual would be incorrect. REA's useful distinction is its shared agent and CLI interface across target types, rather than exclusive access to automation.

When is REA the stronger starting point?

REA is useful for a focused question that crosses from inspection to implementation. For example, an agent can investigate a calculation, identify relevant instructions and references, explain a rule, then write a small implementation for you to test. The agent's conclusion still needs checks against the original behavior.

The official DX-Ball case study follows a sound call into a position-to-pan helper and reconstructs that calculation in C. The project reports 3,205 original-x86 test cases and a match for all 63 compiled function bytes. Those results belong to that specific worked example; they do not establish a general success rate for REA or a performance advantage over Ghidra.

REA also provides workflows outside native decompilation. For an Electron application, static JavaScript analysis can identify modules and IPC relationships without starting Ghidra. That makes REA a convenient entry point when your investigation spans application packaging, JavaScript, and selected native components. REA's target table lists the separate prerequisites.

How do you use Ghidra through REA?

Install a Ghidra release and JDK that the REA provider documentation supports, then configure REA to use that installation. REA setup can record verified existing paths; setup does not download or install Ghidra or Java for you. The official setup guide contains the current configuration instructions.

Do not assume the latest Ghidra release is automatically compatible with your installed REA package. Ghidra's own current release requirements and REA's tested provider range serve different purposes. On the date of this article, REA's main-branch installation guide describes a Ghidra 12.1.x provider check; consult that guide and the installed server's capabilities before choosing versions.

After configuring the provider, a scoped diagnostic is:

npx -y rea-agents@latest doctor --provider ghidra --json

Ghidra-backed operations may need time for import and auto-analysis on the first query. Large binaries can require a longer provider startup deadline, while an MCP client can have its own shorter request deadline. Use the documented deadline and recovery guidance when diagnosing that situation.

What limits should affect your decision?

REA's provider support varies by host and target. Its Windows Ghidra P0 boundary is explicitly experimental and narrower than Ghidra's overall platform and format support. Read the Windows provider guide rather than inferring compatibility from Ghidra's ability to import a file manually.

The REA main branch may also describe newer features than the npm package installed by @latest. A working package version alone does not establish that every main-branch operation is available. Check the release boundary and the connected tool schemas.

Both workflows require judgment. Decompiled pseudocode is not original source, indirect behavior can remain unresolved, and a coding agent can misinterpret correct evidence. Confirm important conclusions with relevant instructions, references, and a controlled behavior check.

What questions do people ask about REA and Ghidra?

Does REA replace Ghidra?

REA can use Ghidra as an engine and does not replace Ghidra's full interactive environment. Choose the interface that fits the task, or combine them.

Is either tool free?

REA-authored code is MIT licensed. Ghidra is an open-source project with its published license and third-party notices. Coding-agent model access and optional commercial providers such as Hopper or IDA have separate terms. See REA's license and Ghidra's license.

Can I inspect JavaScript without Ghidra?

Yes. REA's static JavaScript/Electron workflow uses Node.js and npm, not a native decompiler. A native add-on in that app is a separate analysis target with its own requirements.

Which tool should a beginner try first?

For learning assembly and manual binary analysis, begin with Ghidra's own materials. For learning a question-led agent investigation, start with REA's Notes example or our REA setup guide. A smaller target and a checkable question make either path easier to evaluate.