一条命令跑通真实引擎验证的完整指南：REA 真实 Provider 端到端验证怎么跑、怎么判成功-迪斯科星球

一条命令跑通真实引擎验证的完整指南：REA 真实 Provider 端到端验证怎么跑、怎么判成功

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

当你问一个逆向工具要函数列表或反编译片段，怎么判断结果可不可信？REA 是面向 AI Agent 的逆向工程 MCP 工具集，内置真实 Provider 端到端验证：用真装的 Hopper、Ghidra 和 IDA 跑真实分析、逐条核对、确认无残留进程。本文讲清三条泳道的启动方法与成功判定。

真实验证到底在验什么

"能不能启动"只是逆向工具的及格线。你真正要关心的是：函数列表是否完整、反编译是否真的来自引擎、会话关掉后机器上还留着什么。REA 把验证对象拆成两类：

结果保真：输出与你能独立核实的标准答案（oracle，即预先写好的"正确答案"）逐条一致；
生命周期：关闭后没有残留子进程、会话目录和还在跑的服务。

测试方法论按证据强度排序：优先真实生产 Provider 的完整端到端工作流，其次才是集成测试与黄金回归（见 docs/testing.md）。Hopper、Ghidra、IDA 的真实验证脚本各自是独立的npm run verify:*命令，不会混在普通单元测试里。

⚡ 快速启动命令速查

泳道	命令	前置条件	产出
Hopper	`npm run verify:hopper`	已安装 Hopper + 测试夹具	JSON 报告（含`cleanShutdown`、`targetHashes`）
Ghidra	`npm run verify:ghidra`	`GHIDRA_INSTALL_DIR`指向 Ghidra 12.1.4，64 位 JDK 21+	JSON 报告（25 个只读操作断言 + 清理结果）
IDA	`npm run verify:ida`	`REA_IDA_MCP_CONFIG`指向上游 MCP 注册 JSON，已装 IDA	JSON 报告（CLI / MCP / 清理三段断言）

每条泳道都会先执行build:cached构建产物，再启动验证脚本，保证被验证对象始终对应当前代码。

先跑哪条？按前置门槛从高到低看：Hopper 只需装好 IDE，无额外运行时；Ghidra 需要 JDK 21 就位；IDA 要有现成授权并手工配好上游ida-pro-mcp注册文件。三者都齐全就先跑 Hopper，它覆盖面最广；只有某一台引擎时，只跑对应泳道，其余跳过即可。

🧪 三条泳道各自做什么

Hopper 泳道：三个目标一路验到干净关闭

脚本入口 scripts/verify-real-hopper.mjs。

准备什么：装好 Hopper 的机器。跑verify:hopper时会先执行verify:fixtures准备夹具，无需手工下载。

它做什么：

加载主目标、次目标、大型符号目标共 3 个夹具，全部带 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 预言机源码编译成 debug 与 stripped 两个原生目标；
跑 25 个只读操作（清单、搜索、反编译、汇编、调用/被调用、引用、CFG、类型恢复）；
核对外部函数、解析后的 thunk、导出符号与 strip 后的符号行为；
核对间接调用（含无目标计算跳转）、多块 CFG、有界 P-code def-use 图；
覆盖取消、启动超时、序列化并发、畸形目标拒绝、进程/项目清理等边界场景。

成功的信号：JSON 报告断言全部通过且清理完成后才标记成功。需要更多覆盖时，还有verify:ghidra:cross-format（AArch64 ELF / x86-64 PE / Mach-O 跨格式）、verify:ghidra:switch、verify:ghidra:dos、verify:ghidra:nativeaot等扩展泳道。

IDA 泳道：复用你已有的 IDA，跑三段式检查

脚本入口 scripts/verify-real-ida.mjs。该泳道不安装任何工具链，直接复用你已有的 IDA 与上游ida-pro-mcp服务。

准备什么：按 docs/ida-provider.md 配好上游 MCP 注册 JSON，把文件路径写入REA_IDA_MCP_CONFIG，再用--target指定要分析的二进制。

它做什么（三段）：

CLI 段：用生产 CLI 跑rea function <target> <procedure> --provider ida --json，断言伪代码与汇编非空、Evidence 结构完整；
MCP 段：单条 MCP 连接内完成open_binary、analyze_function、xrefs、字符串搜索等，并确认 CLI 与 MCP 的函数身份、伪代码、汇编完全一致（parity）；
清理段：attached 模式验证 GUI 打开的仍是原始输入；headless 模式验证自建数据库已从上游会话消失、私有工作区已删除，且原始二进制全程未被修改、从未被执行。

成功的信号：passed为 true，且checks列表里出现 "original binary unchanged and never executed" 这类条目。

✅ 如何判定成功：报告字段清单

字段	证明什么	异常时怎么办
`passed`	整条泳道是否最终通过	为 false 时对照`checks`定位失败的断言
`cleanShutdown`	关闭会话后有无资源残留	为 false 时报告按失败处理；Hopper 泳道遇到残留会直接报错
`checks`	逐条通过的断言清单	与预期清单逐项对照，缺项说明对应步骤没跑成
`targets`/`targetHashes`	被分析目标及 SHA-256，证据可追溯	哈希与上次运行不一致，说明夹具文件变了
`verifier_run.process_lineage`	验证器自身子进程是否清理干净	必须为`verified`且无残留 descendants，有残留说明验证器自己泄漏了

报告遵循"证据先于结论"：每个断言都对应一次真实的 Provider 调用，而不是对 mock 的检查。

🚧 高频避坑

本地没有对应引擎？不必强行运行。verify:hopper这类泳道是为"已装好真实工具"的环境准备的，没有引擎就产不出证据。想完整复现，先克隆仓库：git clone https://gitcode.com/GitHub_Trending/rea2/rea。
为什么报告要在清理完成后才标记成功？因为"验证通过"必须包含"无残留"的证明，否则下一次运行的环境已经被污染。Hopper 泳道最典型：只要发现残留的 Hopper 资源，就会先写出cleanShutdown: false的报告再报错。
为什么每条泳道都以build:cached开头？让被验证的产物与当前代码保持一致，避免"新代码跑旧产物"的错位。

参考资料

测试方法论：docs/testing.md
Ghidra 契约与 IDA 接入指南：docs/ghidra-provider.md、docs/ida-provider.md
验证脚本目录：scripts/
Provider 适配器源码：src/hopper/、src/ghidra/、src/ida/
共享进程生命周期基础设施：src/process/

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

创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考

企业官网建设流程全解析