来源：GitHub (★865)
URL: https://github.com/2akouwu/reverify
精读日期：2026-09-05
模型：DeepSeek V4 Flash（AI 生成，人工未审校）
正文获取：全文

一、核心论点/事实

  • Reverify 的核心主张是“反幻觉”：针对读取二进制文件的 AI 智能体，模型只负责提出假设，确定性工具负责裁决，每个声明都必须对照真实字节流验证为 VERIFIED 或 REFUTED，并附带证据。
  • 在 71 个真实 Windows 系统文件上，AI 的“教科书式”逆向答案在 CI（Linux/macOS，每次 push 运行）中被证明是错误的，独立的 aarch64 运行也得到相同结果。
  • 语言模型擅长阅读代码，但在逆向工程上不可靠——模型会自信地虚构偏移量、结构体大小和行为，二进制分析中的幻觉问题比通用文本生成更严重。
  • 工具链覆盖 PE/ELF/Mach-O 解析、x86/x64/ARM/ARM64 反汇编、AOB 模式扫描、CPU 模拟、Protobuf/TLV 解析、Frida hook 生成，核心为纯 Python 实现。
  • 项目以 MCP 服务器形式发布，支持 Claude Code、Cursor 等智能体调用；同时提供 CLI，可零依赖（纯标准库）运行。
  • 验证器由独立裁判检查：解析器对照 lief、反汇编器对照 capstone/binutils/手写 Intel 向量、模拟器对照 Unicorn、语义引擎对照导出表；CI 在 Linux/Windows/macOS 上运行，夜间任务模糊测试 2 万输入。
  • 基准测试在每次 push 的 CI 上运行，使用各平台自身的系统二进制文件，若单个错误声明被 VERIFIED 则构建失败。

二、方法/架构拆解

  • 架构模式：“模型提议，工具裁决”（Model proposes, tools decide）——模型对结构或算法的假设，只有在被工具验证（模式匹配、交叉引用或模拟器执行）后才被报告，输出锚定在真实二进制上。
  • 验证机制：确定性工具作为裁判，返回证据时附带实际观察到的字节。例如反汇编输出包含 "mnemonics": ["push", "mov", "sub"], "note": "function prologue"；模拟验证输出包含 "kind": "emulate_result", "code": "b805000000b90300000001c8c3", "arch": "x86", "expect_registers": {"eax": 8}。
  • 地址语义：偏移量默认指文件偏移（file offset），除非声明指定其他语义；验证器通过节表（section table）进行翻译，并在证据中回显全部三种地址（文件偏移、虚拟地址等）。
  • 信息量加权（FActScore 的 CORE 精化）：每个验证通过的声明按信息量加权——对模型已见事实表的复述、重复声明、未出现在二进制中的内联代码/数据（自引用）、以及工具自身先前输出的回声，权重为零；否则按内容在文件中出现的频率和熵值计算权重。零填充、通用函数序言或到处匹配的模式即使验证通过也几乎不贡献权重；模拟必须实际执行代码路径。
  • 可复现性：基准测试是上述数字背后的可复现度量；所有验证不依赖作者信任——验证器由独立裁判检查，模糊测试确保畸形文件不会导致崩溃、错误声明永远不会被 VERIFIED。
  • 部署形态：MCP 服务器（供智能体调用）+ CLI（python reverify/cli.py auto sample.bin --json 等）；安装可选 reverify（纯 Python 核心）或 reverify[full]（含 capstone+unicorn+lief）。
  • 应用场景：恶意软件分析、CTF、互操作性研究、以及自有或获准分析的软件逆向。

三、值得注意的局限/争议

作者承认的局限：

  • 适用范围限定于“软件逆向工程”场景（恶意软件分析、CTF、互操作性研究、自有或获准分析的软件），并非通用反幻觉方案。
  • 工具链依赖可选引擎（capstone/unicorn/lief），纯 Python 模式下功能降级（如无反汇编引擎时回退到基础解析）。

AI 判断的局限/争议：

  • “每个声明已验证”的可达性存在琐碎化风险：作者指出若仅断言文件以某字节开头即可通过验证，因此引入信息量加权——但加权公式（频率×熵）可能低估某些“低熵但高语义价值”的声明（如特定 API 调用序列）。
  • 验证器本身由独立裁判检查，但裁判（lief/capstone/unicorn）自身也可能存在对特定二进制格式的盲区，形成“验证链的信任传递”问题。
  • 71 个 Windows 系统文件的基准规模有限，且未披露这些文件的选取标准——若偏向于“教科书式”结构明显的文件，可能高估幻觉率。
  • 模拟验证要求代码路径实际执行，对依赖外部环境（系统调用、动态链接）的代码段可能无法有效验证，存在验证盲区。
  • 信息量加权中“模型已见事实表的复述”权重为零，但如何判定“模型已见”依赖上下文追踪，在长会话或多轮交互中可能失效。

四、与 RRLab 研究的关联

  • Harness 工程：Reverify 的“模型提议、工具裁决”模式是典型的 Agent 工具编排范式——确定性工具作为事实锚点，模型仅做假设生成。RRLab 的 Harness 工程可借鉴其“验证结果附带原始字节证据”的设计，让 Agent 的每一步推理都有可审计的 grounding。
  • 多模型协同：Reverify 展示了“模型+工具”而非“模型+模型”的协同路径——用确定性工具替代第二模型做裁判，成本更低且可复现。RRLab 若探索多模型辩论/评审，可考虑混合架构：模型间辩论用于开放性问题，确定性工具用于可验证事实。
  • 模型评测：Reverify 的基准设计（CI 每次 push 运行、独立裁判交叉验证、模糊测试防崩溃、错误声明 VERIFIED 即构建失败）是高质量的评测工程范例。RRLab 的模型评测可借鉴其“评测即 CI 门禁”的思路，以及“用独立工具交叉验证评测器自身”的元评测方法。
  • Agent 落地：Reverify 以 MCP 服务器形态交付，直接对接 Claude Code/Cursor 等主流 Agent 平台，是 Agent 工具落地的参考范式。RRLab 的 Agent 落地项目可参考其“纯 Python 零依赖核心 + 可选全功能引擎”的分层设计，降低集成门槛。
  • AI 原生产品：Reverify 解决的是“AI 在专业领域（逆向）的信任问题”，其“声明-验证-证据”的产品交互模式（每个输出附带可核验证据）可泛化到 RRLab 的 AI 原生产品设计中——尤其在法律、金融、医疗等需要可追溯性的场景。

本笔记由 DeepSeek V4 Flash 自动生成，未经人工审校。原文链接：https://github.com/2akouwu/reverify