---
title: "使用 Claude Code、REA 和 Ghidra 建置 AI 驅動的逆向工程環境"
url: "https://reamcp.dev/zh-tw/cases/you-can-now-build-a-serious-ai-powered-reverse-engineering-e-2c8782"
source: "https://x.com/i/status/2115223519202038095"
source_type: "resource"
author: "𝓑𝓲𝓬_𝓡𝓮𝓿𝓮𝓵𝓪𝓽𝓲𝓸𝓷"
author_handle: "Bic_Revelation"
stars: 0
category: "工具與整合"
categories: ["tools-integrations"]
tags: ["claude-code", "differential-testing", "ghidra", "mcp", "reverse-engineering", "static-analysis"]
added: "2026-10-28T02:07:07.328Z"
updated: "2026-10-27T23:26:00.000Z"
locale: "zh-tw"
content_locale: "zh-tw"
---

# 使用 Claude Code、REA 和 Ghidra 建置 AI 驅動的逆向工程環境

一份逐步指南，說明如何將 REA 作為分析介面，與 Claude Code、Ghidra、JADX、ILSpy 及相關工具搭配使用，並強調證據收集、行為規格與差異測試。

## Description

本文說明如何透過 `npx rea-agents setup` 安裝 REA、依目標格式選擇分析引擎、一次調查一個功能、從結構化證據產生 SPEC.md，並以差異測試驗證淨室重新實作。文章將 REA 定位為 AI 程式碼代理與逆向工程工具之間以 MCP 為基礎的橋樑。

## Original README

You can now build a serious AI-powered reverse engineering environment using Claude Code, REA, Ghidra, and a few specialized open-source tools.

But installing 20 reverse engineering repositories doesn't automatically give you a system that understands any application.

The real advantage comes from combining static analysis, runtime observation, evidence collection, and independent testing.

Here's how I'd build it.

START WITH REA AS THE ANALYSIS INTERFACE

REA (Reverse Engineer Anything) connects AI coding agents to software analysis tools through the Model Context Protocol.

Install it using:

npx rea-agents setup

Select Claude Code during setup, review the proposed configuration changes, and restart Claude.

REA can investigate supported applications and return structured evidence that Claude can use for further analysis.

But it doesn't magically recover the original source code of every application.

The available evidence depends on the software format, its protections, and the analysis tools being used.

SELECT THE RIGHT ANALYSIS ENGINE

This is where I'd improve the original setup.

Don't install every reverse engineering tool.

Choose according to your target.

Native Windows or Linux binaries:

Ghidra for disassembly, decompilation, function references, and control-flow analysis.

GhidraMCP when you want Claude to interact directly with Ghidra.

IDA Pro is another option, with an official Hex-Rays MCP server available for agent integration.

Android applications:

JADX for recovering Java-like code from DEX bytecode.

Apktool for examining application resources, manifests, and Smali.

Frida for authorized runtime instrumentation when static analysis cannot explain the observed behavior.

.NET applications:

ILSpy for examining assemblies and reconstructed C# code.

Native debugging and advanced analysis:

x64dbg, radare2, Rizin, or angr when the task requires debugging, lower-level inspection, or symbolic execution.

These tools have different responsibilities.

Adding more of them doesn't necessarily improve analysis quality.

INVESTIGATE ONE FEATURE AT A TIME

Imagine you're modernizing a legacy desktop application and need to reproduce its search functionality.

Instead of telling Claude to reverse engineer the entire application, give it a narrow objective:

"Analyze the search feature in this application.

Identify the relevant entry points, functions, data flow, inputs, outputs, and observable behavior.

Provide evidence for important conclusions.

Clearly separate observed facts from inferred behavior.

Document anything that cannot be established from the available evidence."

Now Claude has an investigation target instead of an unlimited exploration task.

And that makes the findings much easier to verify.

TURN THE EVIDENCE INTO A BEHAVIORAL SPECIFICATION

This is the step I'd consider most valuable.

Don't immediately ask Claude to recreate the feature.

First, produce a SPEC.md file describing:

Expected inputs and outputs.

State changes.

Error handling.

Edge cases.

Relevant timing or performance requirements.

Known behavior.

Unresolved questions.

Every important claim should reference the evidence behind it.

If a behavior cannot be established, mark it as unknown instead of allowing Claude to invent an explanation.

REBUILD AND VERIFY INDEPENDENTLY

Now use Claude Code to implement the required behavior in a separate project.

For a strict clean-room approach, the implementation team should receive only the approved behavioral specification, not the original application's code or decompiler output.

Then create independent tests using observations recorded before implementation.

For example:

Input A → Expected Output A.

Invalid Input B → Expected Error B.

Empty Input → Expected Behavior C.

Compare the new implementation with the reference application under controlled conditions.

If behavior differs, investigate the mismatch.

Update the implementation or specification according to the evidence.

Then test again.

This is differential testing.

And it's much stronger than asking an