---
title: "使用 Claude Code、REA 和 Ghidra 构建 AI 驱动的逆向工程环境"
url: "https://reamcp.dev/zh-cn/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-cn"
content_locale: "zh-cn"
---

# 使用 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