---
title: "Claude Code, REA, Ghidra로 AI 기반 리버스 엔지니어링 환경 구축하기"
url: "https://reamcp.dev/ko/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: "ko"
content_locale: "ko"
---

# 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