1. 为什么“能看懂”和“能复核”之间隔着一整条鸿沟很多人第一次接触 Agent 逆向工具时都会经历一个极其相似的阶段把目标程序丢进去看着工具自动跑出一堆函数调用链、字符串引用、控制流图然后拍着大腿说“哦原来是这样”。这个阶段我称之为“能看懂”——你能顺着工具给出的线索把整个逻辑在脑子里串起来甚至能对着输出结果给别人讲个大概。但问题在于能看懂不等于能复核。复核意味着什么意味着你能够独立地、不依赖工具当前那次运行结果重新走一遍分析路径并且每一步都能给出可验证的依据。换句话说工具告诉你“这里有个加密函数”你得能自己确认它确实是加密函数而不是工具把某个普通的内存拷贝误标成了加密。工具告诉你“这条路径不可达”你得能自己验证为什么不可达而不是盲信工具的剪枝逻辑。我见过太多人卡在这个鸿沟里。他们用工具跑出一个结果写进报告里结果被人问了一句“你怎么知道这个分支不会走进去”就彻底哑火了。原因很简单他们只完成了“看懂”这一步没有完成“复核”这一步。而 Agent 类逆向工具比如 REA 这类恰恰是在“看懂”这个环节做得非常出色以至于让人产生了一种“我已经完全理解了”的错觉。这篇文章想聊的就是我怎么用 REA 这类 Agent 逆向工具从“能看懂”推进到“能复核”。我会把整个使用过程拆开讲清楚每一步我在做什么、为什么这么做、以及哪些地方是工具帮不了你、必须自己上的。如果你也在用类似的工具或者正准备用希望这些经验能帮你少走一些弯路。2. REA 这类 Agent 逆向工具到底在帮你做什么2.1 从“静态分析”到“Agent 驱动”的转变传统的逆向工具无论是反汇编器还是反编译器本质上都是静态的你给它一个二进制它给你一堆汇编或伪代码剩下的全靠你自己读。后来出现了符号执行、污点分析这些技术工具开始能帮你推导一些数据流但整体上还是“你问它答”的模式。REA 这类 Agent 逆向工具不一样的地方在于它引入了一个主动的探索循环。你可以把它理解成一个不知疲倦的助手它会自己决定下一步去看哪个函数、去追哪条数据流、去尝试哪个分支。它的工作模式大致是这样的先对目标做一个全局扫描识别出关键的函数簇和数据结构然后针对你指定的目标比如某个网络协议的处理逻辑它会自动展开多轮探索每一轮都会产生新的假设然后去验证或推翻这些假设最后把整个探索过程整理成一份可读的报告。这个转变带来的最大好处是效率。以前你需要手动跟几十个函数才能理清的一条链路现在工具可能几分钟就给你跑出来了。但坏处也很明显你很容易把工具的“探索结果”当成“事实”。工具说“这个函数被调用了三次”你就信了工具说“这个缓冲区的大小是 256”你也信了。但工具也是基于启发式和概率的它给出的结论是有置信度的不是百分之百确定的。2.2 Agent 的“探索”和人的“复核”是两回事这里要区分两个概念Agent 的探索是广度优先的它追求的是在有限时间内覆盖尽可能多的可能性而人的复核是深度优先的你需要对每一个关键结论做到底层的验证。举个例子。假设 REA 在分析一个网络协议解析器时告诉你“这个字段的长度由前一个字节决定最大不超过 512”。这个结论是怎么来的可能是 Agent 在多个执行路径上都观察到了类似的内存访问模式然后归纳出来的。但归纳法本身就有风险它可能漏掉了某个边界条件比如当长度字节为 0xFF 时实际走的是另一条完全不同的路径。如果你只是“看懂”你会把这个结论直接写进报告。但如果你要“复核”你就得自己去找到那个长度字段的读取点手动跟踪它的使用方式确认在所有可能的输入下这个 512 的上限是否真的成立。这个过程工具帮不了你因为工具已经把它“认为”的结论给你了你需要做的是反向验证。2.3 工具的输出是“线索”不是“答案”我刚开始用 REA 的时候犯过一个很典型的错误把工具生成的调用图直接当成了程序的真实调用关系。后来才发现Agent 在构建调用图时对于间接调用比如通过函数指针的调用的处理是启发式的。它可能会根据类型签名或者上下文来猜测目标函数但这个猜测不一定对。所以我现在使用这类工具时心态上有一个根本性的转变工具的输出是线索不是答案。它告诉你“这里可能有一个间接调用目标可能是这几个函数之一”你需要自己去确认到底是哪一个。它告诉你“这个循环的迭代次数看起来是固定的”你需要自己去验证是否存在提前退出的条件。这个心态转变听起来简单但实际操作中很容易被忽略。因为 Agent 工具的输出往往做得很“像”最终答案——格式整齐、逻辑清晰、还有置信度标注。你一不小心就会把它当成结论来用。3. 我的复核工作流从 Agent 输出到可验证结论3.1 第一步把 Agent 的探索路径当成“假设集”每次 REA 跑完一轮探索我不会直接去看它的最终报告而是先看它的探索路径。所谓探索路径就是 Agent 在分析过程中走过的每一步它先看了哪个函数发现了什么线索然后决定下一步去看哪里为什么这么决定。这个路径信息非常宝贵因为它暴露了 Agent 的推理过程。如果 Agent 在某一步的决策依据很薄弱比如“根据函数名猜测”那后面基于这个决策的所有结论都需要打问号。如果 Agent 的每一步都有扎实的依据比如“根据交叉引用确认”那结论的可信度就高很多。我通常会做一件事把 Agent 的探索路径整理成一个假设列表。每一条假设都写成“如果 X 成立那么 Y 成立”的形式。比如假设 1如果函数 A 的第三个参数是输出缓冲区那么函数 A 会向该缓冲区写入至少 16 字节。假设 2如果函数 B 的返回值是错误码那么返回值为 0 表示成功。假设 3如果结构体 C 的偏移 0x10 处是长度字段那么该字段的类型是 16 位无符号整数。整理完假设列表之后我的工作就变成了逐条验证这些假设。验证的方法因假设类型而异但核心思路是一样的找到独立的证据来支持或推翻这个假设。3.2 第二步用“最小可复现单元”验证每个假设验证假设的关键是构造一个最小可复现单元。什么意思就是你要找到一个最小的、可控的输入使得这个假设的真假能够被明确地观察到。举个例子。假设 Agent 告诉你“函数 A 会对输入做 Base64 解码”。你要怎么验证最直接的方法当然是找到调用函数 A 的地方构造一个 Base64 编码的输入看输出是不是解码后的结果。但很多时候你没有那么好的条件——可能函数 A 是内部函数你没法直接调用可能整个程序是一个嵌入式固件你没法动态运行。这时候就需要用静态的方法来构造最小可复现单元。比如你可以手动模拟函数 A 的执行找到它使用的 Base64 解码表确认这个表确实是标准 Base64 的编码表然后跟踪它对输入的处理逻辑确认它按照 4 字符一组的方式读取输入并且按照标准算法查表、拼接、输出。如果这些都对上了那“函数 A 做 Base64 解码”这个假设就可以被确认。这个过程听起来很繁琐但实际操作中你不需要对每一条假设都做这么细致的验证。优先验证那些对最终结论有决定性影响的假设。如果一条假设错了整个分析结论就站不住脚那这条假设就必须验证。如果一条假设只是锦上添花那可以暂时放一放。3.3 第三步交叉验证——用不同路径到达同一个结论单条证据链有时候会有盲区。比如你通过静态分析确认了某个函数的行为但静态分析可能漏掉了运行时才确定的值。这时候就需要交叉验证用不同的方法、从不同的角度去验证同一个结论。我常用的交叉验证手段有这么几种静态与动态结合如果条件允许我会在沙箱环境里实际运行目标程序观察它的行为是否与静态分析结论一致。比如静态分析说“这个函数会发送一个 16 字节的包”那我就抓包看看实际发出来的包是不是 16 字节。多工具对比用不同的逆向工具分析同一个目标看看它们对同一个函数的识别结果是否一致。如果 REA 说这是一个加密函数而另一个工具说这是一个哈希函数那就需要进一步确认。正向与反向推导从输入推导输出再从输出反推输入看看两条路径是否能在中间汇合。如果正向推导说“输入 A 会导致输出 B”反向推导说“输出 B 只能来自输入 C”而 A 不等于 C那就说明至少有一条推导有问题。交叉验证的价值在于它能帮你发现那些“看起来对但实际上错”的结论。单一证据链很容易被误导但多条独立的证据链同时指向同一个结论时这个结论的可信度就大大提高了。3.4 第四步把复核过程本身记录下来这一步经常被忽略但我觉得它是最重要的。复核过程本身必须被记录下来否则你的“复核”就只是一次性的、不可追溯的。我通常会为每个关键结论写一份简短的复核记录内容包括结论是什么我用了哪些证据来支持这个结论这些证据是怎么获得的用了什么工具、什么方法、什么输入有没有反例或者不确定的地方如果结论错了最可能错在哪里这份记录不需要很长但必须足够详细使得另一个人或者几个月后的你自己能够按照记录重新走一遍验证过程。这才是“可复核”的真正含义你的结论不仅你自己能验证别人也能验证。4. 那些 Agent 帮不了你、必须自己上的关键环节4.1 理解“为什么这个分支不可达”Agent 工具在做路径探索时经常会告诉你“这条路径不可达”。它的依据可能是符号执行发现约束不可满足也可能是启发式规则判断某个条件永远为假。但“不可达”这个结论恰恰是最需要人工复核的。原因很简单不可达的判断依赖于对程序语义的精确理解而 Agent 对语义的理解往往是近似的。比如Agent 可能认为某个分支的条件是x 10 x 5因此不可达。但如果x是一个有符号整数并且存在整数溢出的可能那这个条件在某些情况下可能是可达的。Agent 如果忽略了溢出语义就会得出错误的“不可达”结论。我复核“不可达”结论时通常会做这几件事找到判断不可达所依赖的所有条件表达式确认这些表达式中每个变量的类型和取值范围检查是否存在类型转换、溢出、未定义行为等可能改变条件真假的因素如果条件涉及外部输入确认输入的约束是否真的如 Agent 所假设的那样只有把这些都确认了我才会接受“不可达”这个结论。否则我会把它标记为“待确认”并在后续分析中保持警惕。4.2 识别 Agent 的“过度概括”Agent 工具在归纳规律时很容易犯“过度概括”的错误。比如它观察到三个不同的函数都用了同样的加密算法就得出结论说“这个程序的所有加密都用的这个算法”。但实际上可能还有第四个函数用了完全不同的算法只是 Agent 没有探索到。过度概括的根源在于 Agent 的探索是有偏的它倾向于沿着它认为“重要”的路径走而忽略那些看起来“不重要”的角落。但逆向工程中恰恰是那些角落最容易藏东西。我应对过度概括的方法是主动寻找反例。当 Agent 给出一个概括性结论时我会刻意去找那些可能不符合这个结论的地方。比如 Agent 说“所有网络通信都走 TLS”我就会去找有没有明文通信的代码路径Agent 说“所有配置都从注册表读取”我就会去找有没有从文件读取配置的代码。这个过程有时候会很耗时但它是保证结论可靠性的必要代价。毕竟一个“所有”开头的结论只要找到一个反例就被推翻了。4.3 处理 Agent 的“置信度盲区”REA 这类工具通常会给每个结论标注一个置信度比如“高置信度”“中置信度”“低置信度”。这个置信度是有用的参考但不能完全依赖。问题在于Agent 的置信度评估是基于它自己的模型而这个模型可能和你的实际需求不匹配。比如Agent 可能对“这个函数是加密函数”给出高置信度因为它在多个路径上都观察到了加密相关的特征。但如果你关心的是“这个加密函数是否可以被绕过”那这个高置信度对你来说意义不大——你需要的是关于“绕过可能性”的置信度而 Agent 可能根本没有评估这个维度。所以我的做法是把 Agent 的置信度当成一个输入而不是一个结论。我会结合自己的分析目标重新评估每个结论的重要性。对于那些对最终目标有决定性影响的结论无论 Agent 给的置信度多高我都会自己再验证一遍。对于那些影响不大的结论即使置信度低我也可以暂时接受。4.4 当 Agent 的结论与你的直觉冲突时这种情况我遇到过好几次Agent 给出一个结论但我的直觉告诉我“不对劲”。这时候怎么办我的经验是不要轻易否定直觉但也不要盲目相信直觉。直觉往往是基于经验的模式识别它可能捕捉到了 Agent 忽略的某些线索。但直觉也可能是错的尤其是当你面对的是一个不熟悉的领域时。正确的做法是把直觉当成一个待验证的假设。如果直觉说“这个函数不像是加密函数”那就去找证据来支持或推翻这个直觉。比如你可以检查这个函数是否使用了加密算法典型的查表操作、是否处理了密钥相关的数据、是否在调用链中处于加密应该出现的位置。如果这些检查都支持“不是加密函数”那你的直觉可能就是对的如果检查结果模棱两可那就需要更深入的分析。5. 从复核到复现让分析结果经得起时间考验5.1 复核的终点是“可复现”复核的最终目标是让你的分析结果可复现。什么叫可复现就是给定同样的目标程序和同样的工具另一个人能够按照你记录的方法独立地得到同样的结论。可复现性有几个层次结论可复现别人能得出和你一样的结论过程可复现别人能走和你一样的分析路径证据可复现别人能获得和你一样的原始证据大多数人的分析只做到了第一个层次甚至第一个层次都没做到——他们的结论是“黑箱”的别人不知道这个结论是怎么来的。要做到第二个和第三个层次就需要在分析过程中有意识地记录和整理。我自己的做法是每完成一个阶段的分析都会花时间把这一阶段的输入、操作、输出整理成一份文档。输入包括目标程序的版本、工具的配置、我使用的命令操作包括我执行了哪些分析步骤、每一步的目的是什么输出包括我得到的原始数据、我的解读、以及我基于这些数据做出的判断。这份文档不需要很正式但必须足够详细使得别人能够按照它重新执行一遍。我经常用这份文档来检验自己的结论如果我发现某一步的操作无法被清晰地描述出来那说明我对这一步的理解还不够透彻需要回去重新分析。5.2 把 Agent 的输出转化为“可审计”的证据链Agent 工具的输出通常是“结论导向”的它告诉你“这个函数是做什么的”但不太关心这个结论是怎么来的。而复核需要的是“证据导向”的你需要把结论拆解成一条条可验证的证据并且理清证据之间的依赖关系。我通常会把 Agent 的输出转化成一个证据图。图中的节点是各种证据比如“函数 A 调用了函数 B”“函数 B 的第三个参数是输出缓冲区”“输出缓冲区的大小是 16 字节”边是证据之间的推导关系。然后我会检查这个图有没有孤立的证据没有其他证据支持它有没有循环依赖A 支持 BB 又支持 A有没有薄弱的环节某条关键证据只有单一来源这个证据图的好处是它让整个分析过程变得可审计。如果后来发现某个结论有问题你可以顺着证据图往回追找到是哪条证据出了问题以及这个问题影响了哪些其他结论。5.3 定期“回访”旧结论人的记忆是不可靠的工具的输出也可能随着版本更新而变化。所以我有一个习惯定期回访旧的分析结论。具体来说我会每隔一段时间比如几个月把之前做过的分析拿出来重新看一遍。重点看那些当时标记为“待确认”或者“低置信度”的结论看看有没有新的证据出现或者有没有新的工具和方法可以用来验证。这个习惯帮我发现过好几次错误。有一次我在回访一个旧分析时发现当时认为“不可达”的一条路径实际上在某个特定条件下是可达的。当时之所以判断错误是因为我忽略了一个整数溢出的边界情况。如果我没有回访这个错误可能就一直留在报告里了。回访的另一个好处是它能帮你发现分析模式的变化。比如你可能会发现自己在某个时期特别容易犯某类错误比如过度信任 Agent 的间接调用识别那就可以在后续分析中有意识地加强这方面的验证。6. 一些实操中的细节和踩过的坑6.1 不要跳过“手动确认”这一步Agent 工具最危险的地方在于它让“手动确认”变得看起来不必要。工具已经告诉你答案了为什么还要自己去看一遍但我的经验是凡是跳过手动确认的结论后来出问题的概率都明显更高。手动确认不一定要很深入。有时候只需要打开反汇编视图找到 Agent 提到的那个地址看一眼实际的指令就能确认 Agent 的结论是否靠谱。这个过程可能只需要几分钟但它能帮你避免很多后续的麻烦。我现在的习惯是对于每一个要写进最终报告的关键结论我都会至少做一次手动确认。确认的方式可以很简单——看一眼原始的反汇编、检查一下交叉引用、或者手动跟踪一小段数据流。关键是不要让自己完全脱离原始数据。6.2 注意 Agent 的“上下文窗口”限制REA 这类工具在分析大型目标时会面临上下文窗口的限制。它不可能同时把所有信息都放在“脑子”里所以它会做取舍优先保留它认为重要的信息丢弃它认为不重要的信息。这个取舍过程对你来说是不透明的。你不知道 Agent 丢弃了哪些信息也不知道它为什么觉得这些信息不重要。但那些被丢弃的信息里可能恰恰藏着关键的线索。我应对这个问题的方法是分段分析主动控制上下文。不要一次性把整个目标丢给 Agent而是把它拆成若干个相对独立的模块逐个分析。这样每个模块的分析都在 Agent 的上下文窗口之内信息丢失的风险就小很多。另外我会在分析过程中定期“保存进度”把当前的分析结论和证据整理成文档然后清空 Agent 的状态重新加载目标继续分析下一个模块。这样做虽然麻烦一点但能保证每个模块的分析都是“新鲜”的不会受到之前分析的干扰。6.3 当 Agent 给出“不确定”时不要强行让它给答案有时候 Agent 会说“我不确定这个函数是做什么的”或者“这个结论的置信度较低”。这时候很多人会尝试调整参数、换一种问法试图让 Agent 给出一个更明确的答案。但我的经验是Agent 的“不确定”往往是有道理的。如果 Agent 对某个结论不确定那通常意味着它掌握的证据不足以支持一个明确的判断。这时候强行让它给答案得到的很可能是一个错误的答案。更好的做法是接受这个“不确定”然后自己去找更多的证据。可能你需要手动分析一段代码可能你需要用另一个工具来交叉验证可能你需要实际运行程序来观察行为。无论哪种方式都比让 Agent 猜一个答案要好。6.4 记录“失败”的分析路径同样重要我们通常会记录成功的分析路径怎么一步步找到关键函数的怎么确认加密算法的怎么理清协议格式的。但失败的分析路径同样值得记录。失败路径告诉你哪些方法是行不通的哪些假设是被推翻的哪些工具在这个场景下不好用。这些信息在你下次遇到类似目标时非常有用——它可以帮你避免重复走弯路。我自己的分析笔记里有一个专门的“死胡同”章节记录那些我尝试过但没走通的分析路径。比如“尝试用符号执行分析这个函数但因为存在大量间接跳转约束求解器超时了”“尝试用动态调试跟踪这个协议但程序检测到了调试器并改变了行为”。这些记录看起来是“负面”的但它们帮我节省了大量时间。7. 关于工具与人的边界我的一些个人体会用了这么久的 Agent 逆向工具我越来越觉得工具的价值不在于它替你做了什么而在于它让你能做什么。REA 这类工具确实能帮你快速理清一个复杂目标的轮廓但它不能替你理解这个轮廓的含义也不能替你验证这个轮廓是否准确。“能看懂”是一个很低的门槛任何有一定基础的人借助工具都能达到。“能复核”才是真正的分水岭它要求你不仅理解结论还要理解结论的推导过程并且能够独立地验证这个过程。从“能看懂”到“能复核”中间隔着的不是工具的使用技巧而是一种分析习惯不盲信任何单一来源的结论对每一个关键判断都追问“为什么”并且把追问的过程记录下来。这个习惯的养成需要时间也需要刻意练习。但一旦养成了你会发现自己的分析质量有一个明显的提升。你不再只是“跑工具的人”而是真正“做分析的人”。最后分享一个我自己的小技巧每次分析结束后我会问自己一个问题——“如果明天有人质疑我的结论我能不能在五分钟内找到支持这个结论的原始证据”如果答案是“不能”那说明我的复核工作还没做到位需要回去补课。这个简单的自检问题帮我避免了很多“看起来很美但经不起推敲”的结论。