---
title: "Claude Code、REA、Ghidra で AI を活用したリバースエンジニアリング環境を構築する"
url: "https://reamcp.dev/ja/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: "ja"
content_locale: "ja"
---

# 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