rea trace 命令实战：从一行字符串线索到功能实现代码的三步闭环
【免费下载链接】reaReverse engineer anything with agents, from app behavior down to native binaries.项目地址: https://gitcode.com/GitHub_Trending/rea2/rea
拿到一个程序，想搞清楚"search"这个功能到底在哪段代码里实现的——手动来，你得搜字符串、记地址、逐个查交叉引用（xrefs，即"谁引用了这个地址"）、再反查每个引用点属于哪个函数。rea 的trace命令把这整条链路压成一次操作：给它一个字符串线索，它直接回给你"字符串在哪、谁在用它、用它的函数是谁"，而且每个结论都带证据。
一条 trace 命令，替代四步手动操作
最简可运行的形态长这样：
rea trace /absolute/path/to/program "search" --provider ghidra --json逐段拆开看：
trace：命令名，内部执行trace_feature工作流（搜字面量 → 查引用 → 解析所属函数）；/absolute/path/to/program：待分析的二进制文件绝对路径；"search"：字面量查询串，也就是你手里那行字符串线索；--provider ghidra：指定分析引擎，ghidra或hopper均可，换成你环境里实际可用的那个；--json：以 JSON 输出，方便管道处理或贴给 AI 客户端。
命令注册逻辑可以看 src/cli/coreBinaryCommands.ts，完整的 CLI 参考在 docs/cli.md。
可复制的最小跑通路径
执行前先花十秒确认引擎真的可用，再走"概览 → 追踪"两步：
# 1. 确认分析引擎可用（Hopper/Ghidra 至少一个 OK） rea providers --json # 2. 概览分析，确认引擎能识别目标 rea analyze /absolute/path/to/program --provider ghidra --json # 3. 用字符串线索发起追踪 rea trace /absolute/path/to/program "search" --provider ghidra --json第一条会列出各 provider 的支持状态，后面两条跑完后你会看到一段 JSON：matches里是命中的字符串及其地址，references里是引用它的代码位置，truncated和residual_unknowns告诉你结果是否完整。
输出的三个字段，对应三类可信度
示意输出（地址为占位示例）：
{ "query": "search", "search_mode": "literal", "matches": [ { "type": "string", "address": "0x1000f3a0", "value": "search" } ], "references": [ { "target_address": "0x1000f3a0", "source_address": "0x10021c44", "containing_procedure": "0x10021b80" } ], "truncated": false, "residual_unknowns": [] }| 类别 | 字段 | 含义 | 看到它该做什么 |
|---|---|---|---|
| 观察到的事实 | matches（type/address/value） | 直接从二进制读到的命中文本、地址与类型（string 或 procedure） | 可直接引用；后续所有结论以这里的 address 为锚点 |
| 推断出的结论 | references（target_address/source_address/containing_procedure） | 由 xrefs + 所属函数解析拼出的"使用点 → 函数"映射 | 拿containing_procedure地址跑rea decompile，用伪代码二次确认逻辑 |
| 尚未解析的未知项 | residual_unknowns、truncated | provider 报告引用被截断、可能存在未列出的引用 | 明确保留，不要脑补"不在列表里 = 不存在" |
注意 💡 如果truncated为true，residual_unknowns里会写明是哪个地址的引用被截断——这种情况下，"没找到更多引用点"不等于"没有其他调用者"。
拿到containing_procedure后，用这两条命令闭合证据链：
rea decompile /absolute/path/to/program 0x10021b80 --provider ghidra --json rea xrefs /absolute/path/to/program 0x10021b80 --provider ghidra --json前者返回伪代码，后者列出该函数的交叉引用，配合matches里的地址，"字符串 → 使用点 → 实现逻辑"就闭环了。
四个真正会用到的选项
--case-sensitive→ 排查ok/OK、id/ID这类短串 → 默认忽略大小写会混入无关命中，开精确匹配排除误报；--snapshot /absolute/path/to/analysis/program.json→ 反复查询同一个目标 → 精确命中结果直接走本地缓存，不重复启动引擎，快照机制细节见 docs/cli.md；--query=<value>→ 线索本身以-开头时 → 避免被解析成命令行选项；--provider hopper→ 目标同时被多个引擎支持时 → 显式指定，跳过自动选择的歧义报错。
另外一条不是选项的经验：线索选得越独特越快。错误提示、网络字段这类近乎唯一的字符串，比 "search" 这种高频词命中少、噪音低。
trace 不覆盖什么，下一步去哪
trace只走"字面量 → 引用"这条静态路径：它不会告诉你值在运行时如何被计算和传递（动态行为），也不做跨模块的数据流分析。需要更深一层时，接上这两个命令：rea trace-native-values构建 def-use 数据流图（跟踪一个值从定义到使用），rea trace-native-ui-action从 UI 动作出发联合接线与有界调用引用，用法见 docs/native-investigation.md；引擎本身的环境准备参考 docs/installation.md。
整条工作流记三句就够：analyze 打底，trace 追线索，decompile 和 xrefs 闭环确认。
【免费下载链接】reaReverse engineer anything with agents, from app behavior down to native binaries.项目地址: https://gitcode.com/GitHub_Trending/rea2/rea
创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考
