使用 Claude Code、REA 和 Ghidra 构建 AI 驱动的逆向工程环境

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