REA 如何在 IDA 上做只读分析而不碰你的数据库:attached 与 headless 双生命周期完整链路
【免费下载链接】reaReverse engineer anything with agents, from app behavior down to native binaries.项目地址: https://gitcode.com/GitHub_Trending/rea2/rea
REA 是一个通过 MCP 把 AI Agent 接到逆向工程引擎的开源项目,它的 IDA 适配器有一个反直觉的设定:attached模式下它实时分析你正在 IDA GUI 里编辑的数据库,却从不保存、也从不关闭它——close_binary只是断开 REA 自己的 MCP 连接;headless模式走得更极端,分析结束连它生成的私有.idb都不允许留在磁盘上。这两个承诺都由代码路径保证,而不是口头约定。
REA IDA 适配器入口:注册文件与 mode 默认值
这个适配器不安装 IDA、不激活许可、不启动 GUI、不捆绑任何 IDA 组件,它做的事只有一件:把你已配置好的上游 IDA MCP 服务接入 REA 统一的只读操作集——函数列表、字符串搜索、反编译、交叉引用、函数档案(清单见 IdaProviderCapabilities.ts)。入口是注册 JSON 文件:把路径写入环境变量REA_IDA_MCP_CONFIG,再用REA_ANALYSIS_PROVIDER=ida或 CLI 的--provider ida选定适配器;文件里的mode字段决定进入哪条生命周期,默认是attached,解析规则与 64 KiB 体积上限在 IdaConfiguration.ts。
attached 模式:启动、双重校验与断开的完整链路
启动时,会话先拉取上游tools/list,与 legacy 1.4 工具清单逐一比对,缺get_metadata、list_functions中任何一个就列出缺失项直接失败(IdaSessionClient.ts)。运行时它像实时观察者:每个请求先调用get_metadata,把 IDA 内部记录的原始输入二进制 SHA-256与镜像基址和 REA 准入的目标比对,请求完成后再取一次元数据做后校验;哈希不符或在会话期间切了目标,立即抛AnalysisProtocolError并给出恢复指引。因为绑定的是记录在 IDA 里的哈希而非路径,REA 跑在 WSL、GUI 开在 Windows 也互不干扰。结束时close只释放 MCP 连接,GUI 数据库原样保留,你中途追加的注释下一次查询直接可见——结果是实时读取,没有本地快照回放。
headless 模式:私有工作区与无痕清理的完整步骤
启动链路每一步都可验证:先把准入的二进制拷进mkdtemp创建的私有临时目录(POSIX 下 owner-only 权限),边拷边算 SHA-256,源文件哈希与准入值不符就中止(IdaWorkspace.ts);随后以force_headless调idb_open,响应里session_id与input_path必须等于 REA 申请的私有副本,否则按"收养了用户数据库"直接报错;再查idb_list,确认该会话owned、backend: worker、is_active三项齐全(IdaSessionClient.ts)。运行时每个请求经server_health确认 worker 仍绑定私有副本且副本摘要未变。结束是三步闭环:idb_close强制save: false,上游若报告saved: true判为协议违规;idb_list确认会话消失;最后才删私有目录(IdaSessionClient.ts)。
| 对比维度 | attached(附着 GUI) | headless(无头分析) |
|---|---|---|
| 上游 API 画像 | legacy 1.4 GUI 工具 | 数据库监管idb_open/idb_list/idb_close |
| 数据库归属 | 100% 归用户,REA 只读旁观 | REA 以force_headless创建并独享 |
| 身份校验 | IDA 记录的输入哈希+基址,请求前后双重校验 | 私有副本摘要 + worker 输入路径 + 会话状态 |
| close 行为 | 仅断开 MCP 连接 | save: false释放→idb_list确认→删私有目录 |
| 直接调用者 callers | 支持 | 无法证明调用边,如实报告 unknown |
| 运行环境 | 可跨 WSL/Windows | REA 与监管进程须共享同一宿主文件系统 |
IDA 只读分析三条红线:REA 为什么从不保存数据库 🔒
决策一:永不保存或关闭 GUI 数据库。理由:数据库是用户的资产,你正在手工注释、重命名,REA 若触发保存,等于往你正在编辑的文件里强制落盘,会固化半成品状态并干扰并行工作。官方文档原文:"It never saves or closes the existing GUI database"(docs/ida-provider.md)。
决策二:无法验证的关闭就是失败。idb_close响应不可解析、或会话仍残留在idb_list中,REA 不假装清理干净——保留私有工作区并抛IdaCleanupError,错误里逐条列出未确认释放的会话(IdaSessionClient.ts)。
决策三:身份不匹配就不出结果。请求前后任一校验失败直接报错并指引重开目标,动机是把 A 程序的证据安到 B 程序头上的风险降为零(IdaSessionClient.ts)。
亲手实测 IDA 双模式:预检命令与 verify:ida 验证入口
动手前先跑注册文件预检(不会启动 IDA):rea doctor --provider ida --json。两种模式共用同一套 CLI:rea function /absolute/path/to/program main --json、rea decompile /absolute/path/to/program main --json。Agent 侧一次连接即可:open_binary(指定provider_id: "ida")→analyze_function/search_strings→close_binary。环境就绪后跑官方验证入口npm run verify:ida -- --target /absolute/path/to/program --procedure main,它会校验输出契约、原始输入保全与会话清理。
输入哈希校验证明的是"REA 看到的就是你准入的那个二进制",而不是数据库未被手工修改;空白的档案字段代表"未知",不是"不存在"。完整覆盖范围与证据边界见 docs/ida-provider.md。
【免费下载链接】reaReverse engineer anything with agents, from app behavior down to native binaries.项目地址: https://gitcode.com/GitHub_Trending/rea2/rea
创作声明:本文部分内容由AI辅助生成(AIGC),仅供参考