AI 逆向 Agent 的产出你敢信吗？REA 真实引擎验证实操指南-迪斯科星球

AI 逆向 Agent 的产出你敢信吗？REA 真实引擎验证实操指南

【免费下载链接】reaReverse engineer anything with agents, from app behavior down to native binaries.项目地址: https://gitcode.com/GitHub_Trending/rea2/rea

REA（Reverse Engineer Anything）是一套面向 AI Agent 的逆向工程 MCP 工具集，本文讲清楚它内置的 REA 真实 Provider 验证机制：如何用真实安装的 Hopper、Ghidra、IDA 跑端到端测试，以及验证报告里各字段的含义。

为什么 mock 不够看：按证据强度排序

逆向工具最大的风险不是"能不能启动"，而是结果可不可信：函数列表是否完整、反编译是否真出自引擎、会话关掉之后有没有残留进程。因此 REA 的测试体系按证据强度排序（见 docs/testing.md）：真实生产 Provider 的完整端到端工作流最有说服力，其次是集成测试与黄金回归，mock 单测只能排最后。这也是为什么每个真实引擎（Hopper、Ghidra、IDA 等）的验证声明都放进独立的npm run verify:*验证流程，而不是混进普通单元测试里。

🚀 如何跑起来：三个引擎的命令与前置条件速查

三条核心入口都定义在 package.json 中：

命令	验证目标	前置条件
`npm run verify:hopper`	真实 Hopper 全流程	已安装 Hopper + 测试夹具
`npm run verify:ghidra`	真实 Ghidra 12.1.4	设置`GHIDRA_INSTALL_DIR`+ JDK 21
`npm run verify:ida`	真实 IDA Pro（GUI 或 headless）	设置`REA_IDA_MCP_CONFIG`

三条验证流程的节奏一致：先执行build:cached构建产物，再启动对应的验证脚本（如 scripts/verify-real-hopper.mjs），最后输出一份 JSON 报告——而且报告只有在资源清理全部完成之后才会被标记为成功。

到底验证了什么：共享流水线与引擎差异

无论选哪个引擎，脚本都跑同一条五步流水线：加载带哈希校验的夹具目标 → 核对工具清单 → 与标准答案比对真实分析结果 → 切换目标 → 确认清理，差异集中在各自的侧重点上。

Hopper：覆盖面最广，关得最"干净"

Hopper 是检查项最多的一条。它加载主目标、次目标与大型符号目标三个夹具，全部做 SHA-256 校验；要求 MCP 会话声明的工具可用性与服务端实际工具清单完全一致；随后调用list_procedures、read_bytes、xrefs、batch_decompile、analyze_function等真实操作，并与带 oracle（即预先写好的标准答案）的 C 夹具逐条比对。目标切换环节确认从目标 A 切到 B 时文档被正确替换、重复打开同一目标不会产生重复文档。最后一步是"干净关闭"证明：Hopper 自带 MCP 服务无残留、无关 Hopper 实例未受波及、临时会话目录全部清除、进程谱系（验证器派生的子进程家族树）归零。任何一步失败，脚本都会先写出带失败信息的报告再退出，便于定位断点。

🎯 Ghidra：12.1.4 + JDK 21，现场编译测试目标

scripts/verify-real-ghidra.mjs 要求GHIDRA_INSTALL_DIR指向解包好的Ghidra 12.1.4，并由JAVA_HOME（或 PATH）提供 64 位 JDK 21+。它先在现场用cc把版本化的 C 语言 oracle 源码编译出debug 版与 stripped 版（剥离符号信息）两个原生目标，再覆盖：25 个只读操作（清单、搜索、反编译、汇编、调用/被调用、引用、CFG、类型恢复）；外部函数、解析后的 thunk、导出符号及被 strip 后的符号行为；间接调用（含无目标的计算跳转）、多块 CFG、有界的 P-code def-use 图；以及取消、启动超时、序列化并发、畸形目标拒绝、进程/项目清理等异常路径。此外还提供verify:ghidra:cross-format（AArch64 ELF / x86-64 PE / Mach-O 跨格式）、verify:ghidra:switch、verify:ghidra:dos、verify:ghidra:nativeaot等扩展命令，完整边界与语义契约见 docs/provider-evaluation.md。

IDA：复用现成环境，三段式并断言一致性

IDA 验证不安装任何工具链——直接复用你机器上已有的 IDA 与上游ida-pro-mcp服务。操作很简单：按 docs/ida-provider.md 配好上游 MCP 注册 JSON，把路径写入REA_IDA_MCP_CONFIG，再指定--target <二进制路径>。随后 scripts/verify-real-ida.mjs 执行三段检查：CLI 阶段用生产 CLI 跑rea function <target> <procedure> --provider ida --json，断言伪代码与汇编非空、Evidence 结构完整；MCP 阶段在单条 MCP 连接内完成open_binary、analyze_function、xrefs、字符串搜索等，并确认 CLI 与 MCP 两路的函数身份、伪代码、汇编完全一致（parity，即两个入口的结果分毫不差）；清理阶段在 attached 模式下确认 GUI 打开的仍是原始输入，在 headless（无图形界面）模式下确认自建数据库已从上游会话中消失、私有工作区已删除，且原始二进制全程未被修改、从未被执行。

📄 验证报告怎么看：关键 JSON 字段含义

每条流程结束都会输出 JSON 摘要，重点核对：

passed/cleanShutdown：总体结果，以及是否干净关闭（Hopper 流程中资源未清理会直接报错）；
checks：逐条列出的通过项，例如 "original binary unchanged and never executed"；
targets/targetHashes：被分析目标及其 SHA-256，让每一份证据都能回溯到具体文件；
verifier_run.process_lineage：验证器自身的进程谱系，必须为verified且无残留。

这套报告的设计取向是让断言可被追溯：每一条通过结论背后都对应一次对具体引擎的真实调用，而不是对着 mock 数据打勾。

提示：本地没装对应引擎时不必纠结——verify:hopper等验证流程是为"已装好真实工具"的环境准备的。想完整复现，可先克隆仓库：git clone https://gitcode.com/GitHub_Trending/rea2/rea

企业官网建设流程全解析