REA 真实 Provider 验证Hopper、Ghidra 与 IDA 三条泳道如何跑端到端测试完整指南【免费下载链接】reaReverse engineer anything with agents, from app behavior down to native binaries.项目地址: https://gitcode.com/GitHub_Trending/rea2/rea用逆向工具分析过别人程序的人大概都怀疑过同一件事反编译结果到底可不可信函数列表是不是完整的伪代码是不是真的由引擎生成会话关掉之后有没有偷偷留下后台进程这些问题光看单元测试回答不了——mock 再漂亮也只是在对着一张纸考卷子。REA 的真实 Provider 验证real provider verification就是为了解决这件事让测试直接跑在已安装的 Hopper、Ghidra、IDA 上用真实引擎的输出来断言把能启动升级为结果可信。先说 REA 是什么一套面向 AI Agent 的逆向工程 MCP 工具集把应用行为到原生二进制的分析能力统一暴露给 Agent 使用。本文只讲它的验证侧——三条核心泳道各自查什么、跑之前要备什么、跑完之后报告里的字段怎么读。三条泳道的分工与前置条件验证入口都集中在 package.json 的verify:*脚本里每条泳道先执行build:cached构建产物再启动对应的验证脚本最后落一份 JSON 报告报告只有清理动作全部完成后才会标记为成功。命令验证对象前置条件入口脚本npm run verify:hopper已安装的 Hopper 全流程Hopper 测试夹具verify:fixturesscripts/verify-real-hopper.mjsnpm run verify:ghidra解包好的 Ghidra 12.1.4GHIDRA_INSTALL_DIR 64 位 JDK 21JAVA_HOME或 PATHscripts/verify-real-ghidra.mjsnpm run verify:ida已有的 IDA Pro 与ida-pro-mcpREA_IDA_MCP_CONFIG指向注册 JSON --targetscripts/verify-real-ida.mjs为什么不用 mockRE A 的测试分层是明确的证据强度从高到低依次是真实 CLI/MCP 端到端工作流、生产边界集成测试、真实生产方捕获的黄金回归。真实 Provider 的声明被强制归入各自独立的泳道不允许混进普通单元测试里充数依据见 官方测试文档。Hopper 泳道从夹具加载到干净关闭的全程检查这是三条泳道中覆盖面最广的一条验证过程覆盖以下几类行为夹具与目标准备。脚本加载三个夹具目标——主目标、次目标、一个大型符号目标——每个都带 SHA-256 校验确保分析的是你以为的那个文件。工具目录核对。MCP 会话里声明的可用工具必须与服务端实际工具清单一一对应多一个少一个都不放行。真实分析结果比对。list_procedures、read_bytes、xrefs、batch_decompile、analyze_function等操作逐个执行输出与带标准答案oracle的 C 夹具逐条比对。注意这里比的不是格式对不对而是内容是否和已知正确的引擎结果一致。目标切换语义。从目标 A 切到目标 B 时文档要被正确替换重复打开同一目标不能产生重复文档。这是会话状态管理的常见翻车点。干净关闭证明。结束后检查四件事Hopper 自带的 MCP 服务没有在跑、与验证无关的 Hopper 实例没被打扰、临时会话目录全部清掉、子进程谱系归零。任何一项不满足脚本会先写出带失败上下文的报告再退出方便你定位卡在哪一步。Ghidra 泳道现场编译预言机25 个操作全部过一遍Ghidra 泳道的门槛在环境GHIDRA_INSTALL_DIR必须指向解包完成的Ghidra 12.1.4并提供 64 位 JDK 21。环境就绪后验证器会现场调用cc把一份版本化的 C 语言预言机源码编译成debug 版和stripped 版两个原生目标——标准答案和目标同场生成不存在版本漂移的问题。验证内容可以分为四层只读操作全集共 25 个操作覆盖清单、搜索、反编译、汇编、调用/被调用、引用、CFG、类型恢复符号与边界行为外部函数、解析后的 thunk、导出符号以及符号被 strip 之后引擎应有的表现复杂控制流间接调用含无法静态确定目标的计算跳转、多块 CFG、有界的 P-code def-use 图失败路径与资源管理取消请求、启动超时、序列化并发、畸形目标拒绝、进程与项目清理。主力泳道之外还有一组扩展开关verify:ghidra:cross-format覆盖 AArch64 ELF / x86-64 PE / x86-64 Mach-O 三种跨格式目标需要clang、LLD、lld-link另有verify:ghidra:switch、verify:ghidra:dos、verify:ghidra:nativeaot等各自独立的场景。完整边界与语义契约写在 Ghidra Provider 文档 里。IDA 泳道零安装的三段式校验IDA 这条泳道有个鲜明特点它不装任何东西。它复用的是你机器上已有的 IDA 和上游ida-pro-mcp服务REA 只负责把上游注册 JSON 接进自己的工具链。你需要做的准备就两步按 IDA 接入指南 写好上游 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 模式下验证自建数据库已从上游会话消失、私有工作区已被删除。最后用 SHA-256 对比前后两次摘要证明原始二进制全程未被修改、也从未被执行这一条会直接写进报告的checks里。验证报告四个字段读懂结果每条泳道跑完都会打印 JSON 摘要建议养成先看这四个字段的习惯passed/cleanShutdown总体结论以及资源是否干净释放。Hopper 泳道里只要有一项资源没清干净这里会直接报错而不是静默通过checks逐条列出已经证实通过的项目例如 original binary unchanged and never executed每一条都对应一次真实的 Provider 调用targets/targetHashes本次被分析的目标路径及其 SHA-256保证事后可以回溯当时分析的到底是哪个文件verifier_run.process_lineage验证器自身的子进程谱系观测状态必须是verified且无残留谱系观测逻辑在 scripts/lib/verifier-run.mjs。这套报告背后的设计原则一句话证据先于结论——你看到的每个通过项背后都是一次真实引擎调用而不是对桩数据的断言。延伸阅读与源码位置想深入某条泳道从对应的入口脚本读起最直接Hopper 适配器 / Ghidra 适配器 / IDA 适配器三条泳道对应的 Provider 实现docs/testing.md测试分层方法论与泳道划分的完整规则docs/ghidra-provider.mdGhidra 泳道的操作边界与清理契约docs/ida-provider.mdattached 与 headless 两种 IDA 模式的注册配置src/process/三条泳道共用的进程生命周期与谱系观测基础设施。提醒这三条泳道是为已经装好真实引擎的环境准备的本机没有对应工具时跑不通属于预期行为不影响日常使用 REA 的其余功能。想完整体验验证流程先克隆仓库即可git clone https://gitcode.com/GitHub_Trending/rea2/rea【免费下载链接】reaReverse engineer anything with agents, from app behavior down to native binaries.项目地址: https://gitcode.com/GitHub_Trending/rea2/rea创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考 REA 真实 Provider 验证：Hopper、Ghidra 与 IDA 三条泳道如何跑端到端测试（完整指南）
REA 真实 Provider 验证Hopper、Ghidra 与 IDA 三条泳道如何跑端到端测试完整指南【免费下载链接】reaReverse engineer anything with agents, from app behavior down to native binaries.项目地址: https://gitcode.com/GitHub_Trending/rea2/rea用逆向工具分析过别人程序的人大概都怀疑过同一件事反编译结果到底可不可信函数列表是不是完整的伪代码是不是真的由引擎生成会话关掉之后有没有偷偷留下后台进程这些问题光看单元测试回答不了——mock 再漂亮也只是在对着一张纸考卷子。REA 的真实 Provider 验证real provider verification就是为了解决这件事让测试直接跑在已安装的 Hopper、Ghidra、IDA 上用真实引擎的输出来断言把能启动升级为结果可信。先说 REA 是什么一套面向 AI Agent 的逆向工程 MCP 工具集把应用行为到原生二进制的分析能力统一暴露给 Agent 使用。本文只讲它的验证侧——三条核心泳道各自查什么、跑之前要备什么、跑完之后报告里的字段怎么读。三条泳道的分工与前置条件验证入口都集中在 package.json 的verify:*脚本里每条泳道先执行build:cached构建产物再启动对应的验证脚本最后落一份 JSON 报告报告只有清理动作全部完成后才会标记为成功。命令验证对象前置条件入口脚本npm run verify:hopper已安装的 Hopper 全流程Hopper 测试夹具verify:fixturesscripts/verify-real-hopper.mjsnpm run verify:ghidra解包好的 Ghidra 12.1.4GHIDRA_INSTALL_DIR 64 位 JDK 21JAVA_HOME或 PATHscripts/verify-real-ghidra.mjsnpm run verify:ida已有的 IDA Pro 与ida-pro-mcpREA_IDA_MCP_CONFIG指向注册 JSON --targetscripts/verify-real-ida.mjs为什么不用 mockRE A 的测试分层是明确的证据强度从高到低依次是真实 CLI/MCP 端到端工作流、生产边界集成测试、真实生产方捕获的黄金回归。真实 Provider 的声明被强制归入各自独立的泳道不允许混进普通单元测试里充数依据见 官方测试文档。Hopper 泳道从夹具加载到干净关闭的全程检查这是三条泳道中覆盖面最广的一条验证过程覆盖以下几类行为夹具与目标准备。脚本加载三个夹具目标——主目标、次目标、一个大型符号目标——每个都带 SHA-256 校验确保分析的是你以为的那个文件。工具目录核对。MCP 会话里声明的可用工具必须与服务端实际工具清单一一对应多一个少一个都不放行。真实分析结果比对。list_procedures、read_bytes、xrefs、batch_decompile、analyze_function等操作逐个执行输出与带标准答案oracle的 C 夹具逐条比对。注意这里比的不是格式对不对而是内容是否和已知正确的引擎结果一致。目标切换语义。从目标 A 切到目标 B 时文档要被正确替换重复打开同一目标不能产生重复文档。这是会话状态管理的常见翻车点。干净关闭证明。结束后检查四件事Hopper 自带的 MCP 服务没有在跑、与验证无关的 Hopper 实例没被打扰、临时会话目录全部清掉、子进程谱系归零。任何一项不满足脚本会先写出带失败上下文的报告再退出方便你定位卡在哪一步。Ghidra 泳道现场编译预言机25 个操作全部过一遍Ghidra 泳道的门槛在环境GHIDRA_INSTALL_DIR必须指向解包完成的Ghidra 12.1.4并提供 64 位 JDK 21。环境就绪后验证器会现场调用cc把一份版本化的 C 语言预言机源码编译成debug 版和stripped 版两个原生目标——标准答案和目标同场生成不存在版本漂移的问题。验证内容可以分为四层只读操作全集共 25 个操作覆盖清单、搜索、反编译、汇编、调用/被调用、引用、CFG、类型恢复符号与边界行为外部函数、解析后的 thunk、导出符号以及符号被 strip 之后引擎应有的表现复杂控制流间接调用含无法静态确定目标的计算跳转、多块 CFG、有界的 P-code def-use 图失败路径与资源管理取消请求、启动超时、序列化并发、畸形目标拒绝、进程与项目清理。主力泳道之外还有一组扩展开关verify:ghidra:cross-format覆盖 AArch64 ELF / x86-64 PE / x86-64 Mach-O 三种跨格式目标需要clang、LLD、lld-link另有verify:ghidra:switch、verify:ghidra:dos、verify:ghidra:nativeaot等各自独立的场景。完整边界与语义契约写在 Ghidra Provider 文档 里。IDA 泳道零安装的三段式校验IDA 这条泳道有个鲜明特点它不装任何东西。它复用的是你机器上已有的 IDA 和上游ida-pro-mcp服务REA 只负责把上游注册 JSON 接进自己的工具链。你需要做的准备就两步按 IDA 接入指南 写好上游 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 模式下验证自建数据库已从上游会话消失、私有工作区已被删除。最后用 SHA-256 对比前后两次摘要证明原始二进制全程未被修改、也从未被执行这一条会直接写进报告的checks里。验证报告四个字段读懂结果每条泳道跑完都会打印 JSON 摘要建议养成先看这四个字段的习惯passed/cleanShutdown总体结论以及资源是否干净释放。Hopper 泳道里只要有一项资源没清干净这里会直接报错而不是静默通过checks逐条列出已经证实通过的项目例如 original binary unchanged and never executed每一条都对应一次真实的 Provider 调用targets/targetHashes本次被分析的目标路径及其 SHA-256保证事后可以回溯当时分析的到底是哪个文件verifier_run.process_lineage验证器自身的子进程谱系观测状态必须是verified且无残留谱系观测逻辑在 scripts/lib/verifier-run.mjs。这套报告背后的设计原则一句话证据先于结论——你看到的每个通过项背后都是一次真实引擎调用而不是对桩数据的断言。延伸阅读与源码位置想深入某条泳道从对应的入口脚本读起最直接Hopper 适配器 / Ghidra 适配器 / IDA 适配器三条泳道对应的 Provider 实现docs/testing.md测试分层方法论与泳道划分的完整规则docs/ghidra-provider.mdGhidra 泳道的操作边界与清理契约docs/ida-provider.mdattached 与 headless 两种 IDA 模式的注册配置src/process/三条泳道共用的进程生命周期与谱系观测基础设施。提醒这三条泳道是为已经装好真实引擎的环境准备的本机没有对应工具时跑不通属于预期行为不影响日常使用 REA 的其余功能。想完整体验验证流程先克隆仓库即可git clone https://gitcode.com/GitHub_Trending/rea2/rea【免费下载链接】reaReverse engineer anything with agents, from app behavior down to native binaries.项目地址: https://gitcode.com/GitHub_Trending/rea2/rea创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考