★ FEATURED ARTICLE 1. 逆向工程 Agent 到底在做什么1.1 从一个真实需求说起去年下半年开始我陆续接触到几个做安全研究的朋友他们不约而同地提到同一件事手头需要分析的二进制样本越来越多但人手根本没变。以前一个熟练的逆向工程师一天能啃完一个中等复杂度的样本就算高效了现在批量样本涌过来靠人力堆时间已经完全跟不上节奏。这就是逆向工程 Agent 热度不降反升的核心背景。它不是某个新概念突然火了而是需求端出现了巨大的缺口而大语言模型恰好在这个时间点具备了补上这个缺口的能力。所谓逆向工程 Agent简单说就是把大语言模型作为推理内核配合反汇编工具、调试器、沙箱等外部工具构建一个能自主分析二进制程序的智能体系统。你给它一个可执行文件它能自己决定先看什么、用什么工具看、看到结果之后下一步怎么走最终输出一份人类能看懂的分析报告。这跟以前那种丢给 AI 一个反汇编片段让它解释的用法有本质区别。以前是你干活AI 打下手现在是 AI 干活你在关键节点做判断。1.2 为什么偏偏是现在我梳理了一下这波热度背后有三个条件同时成熟了第一模型的长上下文推理能力跨过了及格线。逆向分析一个函数往往需要同时看反汇编代码、控制流图、字符串引用、导入表信息这些信息拼在一起轻松超过几万 token。两年前的模型根本吃不下这么多上下文现在主流模型动辄 128K 甚至更长的窗口才让一次性理解一个完整函数成为可能。第二工具调用协议标准化了。不管是哪种函数调用格式本质上都让模型能像人一样使用工具——调用反汇编器拿伪代码、调用调试器读内存、调用字符串提取工具看常量。这个能力是 Agent 化的前提。第三也是最现实的推动力样本量爆炸。不管是做恶意代码分析、漏洞挖掘还是固件安全审计需要处理的二进制文件数量都在指数级增长。IoT 设备固件、供应链组件、各种编译产物人工根本看不过来。我个人的判断是逆向工程 Agent 不是要替代逆向工程师而是把工程师从重复性体力劳动中解放出来让他们专注于真正需要人类直觉和创造力的部分。1.3 它适合谁如果你属于以下几类人这个方向值得认真投入时间安全研究员日常需要批量分析样本希望提升吞吐量漏洞挖掘工程师需要快速定位可疑代码区域缩小人工审计范围固件/嵌入式安全从业者面对大量不同架构的固件需要自动化初筛对 AI Agent 感兴趣的后端/算法工程师想找一个有真实落地场景的 Agent 应用方向不太适合的情况也说清楚如果你只是偶尔看看某个小工具的内部实现手动用现成工具几分钟就搞定了没必要上 Agent。Agent 的价值在于规模化和自动化单次简单任务反而是杀鸡用牛刀。2. 核心架构拆解一个逆向 Agent 由什么组成2.1 整体架构设计思路我参考了几个开源实现和论文里的方案结合自己的实践把逆向工程 Agent 的架构归纳为四层。这个分层不是拍脑袋定的每一层对应一个明确的职责边界层与层之间通过标准化接口通信方便替换和调试。层级职责典型组件替换难度感知层从二进制中提取结构化信息反汇编器、反编译器、字符串提取、导入表解析低工具可插拔推理层决策下一步做什么、如何解读结果大语言模型 提示词编排中换模型需调提示词执行层实际调用工具、管理状态工具调用框架、沙箱环境、状态管理器中取决于框架交互层输出报告、接受人类反馈报告生成、可视化、人工确认节点低格式灵活这个架构的核心设计原则是推理与执行分离。模型只负责想不负责做工具只负责做不负责想。这样做的好处是模型换了不影响工具链工具升级了不影响推理逻辑调试的时候也能明确定位问题出在哪一层。2.2 感知层给 Agent 装上眼睛感知层是整个系统的输入端口。二进制文件对人类来说就是一堆字节Agent 需要的是结构化的、有语义的信息。这一层要解决的核心问题是把不可读的机器码转换成模型能理解的中间表示。我实际用下来以下几类信息对 Agent 的推理最有价值反汇编代码最基础的表示但信息密度低适合精确定位反编译伪代码信息密度高接近 C 代码模型理解起来最轻松控制流图CFG帮助理解函数内部的跳转逻辑交叉引用XREF谁调用了这个函数、这个函数调用了谁字符串和常量往往藏着关键线索比如 URL、错误信息、加密密钥导入/导出表快速判断程序用了哪些库、可能是什么类型的程序这里有个实操中的关键取舍反编译伪代码虽然好读但不是所有架构都有成熟的反编译器。x86/x64 上反编译质量很高但遇到 MIPS、ARM 某些变体、或者冷门架构反编译结果可能惨不忍睹。我的做法是优先用反编译质量不行就退回反汇编同时把 CFG 和 XREF 作为补充信息一起喂给模型。注意事项感知层提取信息时一定要做去重和裁剪。一个稍微大点的程序全量反汇编可能几十万行直接塞给模型既浪费 token 又干扰推理。常见做法是按函数粒度切分只把当前分析目标相关的函数及其上下文送进推理层。2.3 推理层Agent 的大脑怎么思考推理层是决定 Agent 好不好用的关键。同样一套工具提示词设计得好和差效果能差出好几倍。我总结了几个在实践中验证有效的设计要点。第一给 Agent 一个明确的分析框架。不要让模型漫无目的地看代码而是给它一个结构化的分析流程。比如先看文件类型和架构确定分析策略看导入表和字符串快速判断程序功能定位入口点和关键函数逐个分析关键函数的逻辑汇总形成整体判断这个框架不是硬编码的流程而是作为提示词里的思考指引让模型知道大概该往哪个方向走但具体每一步怎么做由模型自己决定。第二强制模型解释推理过程。我要求 Agent 在每次调用工具之前先用自然语言说明我为什么要调这个工具、我期望得到什么结果。这个要求看起来简单但效果非常明显——它迫使模型把隐性的推理显性化既方便人类审查也减少了模型乱调工具的情况。第三设置置信度和不确定性标记。逆向分析中很多判断是概率性的比如这个函数大概率是加密函数。我让 Agent 在输出判断时附带置信度低置信度的判断会被标记出来提示人类重点复核。这比让模型强行给出确定答案要靠谱得多。2.4 执行层工具调用与状态管理执行层负责把推理层的决策落地。这部分看起来是纯工程问题但实际踩坑不少。工具调用的原子性很重要。每个工具调用应该是独立的、可重放的。什么意思就是给定相同的输入和相同的二进制文件工具调用应该产生相同的结果。这样才能在出问题的时候复现和调试。我见过一些实现把多个操作揉在一个工具里结果出了问题根本不知道是哪一步导致的。状态管理要区分事实和推断。事实是工具返回的客观结果比如地址 0x401000 处有一条 mov 指令推断是模型基于事实做出的判断比如这个循环在做 XOR 解密。两者必须分开存储因为事实是可靠的推断可能出错。当后续分析发现矛盾时要能追溯到是哪一步推断出了问题。沙箱隔离是必须的。分析未知二进制文件尤其是恶意样本绝对不能直接在宿主机上跑。我通常用轻量级容器做隔离限制网络访问和文件系统权限。Agent 如果需要动态分析比如跑起来看行为必须在沙箱里执行。2.5 交互层人类在环的设计完全无人值守的逆向 Agent 目前还不现实人类在环Human-in-the-Loop是更务实的选择。关键是在哪些节点让人类介入。我的经验是设置三类介入点高风险操作前确认比如 Agent 要执行二进制文件、要修改分析状态时需要人类确认低置信度判断时求助Agent 对某个判断把握不大时主动请求人类给出方向阶段性成果审查每完成一个分析阶段输出中间报告供人类检查这样设计的好处是人类不需要全程盯着只在关键节点花几分钟做判断整体效率提升依然显著。3. 实操落地从零搭一个可用的逆向 Agent3.1 环境准备与工具选型先说工具选型。这部分我踩过不少坑直接给结论。反汇编/反编译引擎我主要用两个组合。一个是开源的 Capstone 做反汇编配合 Ghidra 的无头模式做反编译。选 Ghidra 的理由是它支持架构多、反编译质量在开源方案里属于第一梯队而且有无头模式可以脚本化调用。另一个组合是 objdump 自己写的解析脚本适合快速处理简单场景。Agent 框架不用太纠结核心需求就是工具调用和状态管理。我试过自己从零写一个轻量框架大概几百行代码就能跑起来好处是完全可控、调试方便。如果用现成框架注意选那种支持自定义工具、支持中断恢复的。模型选择这是影响效果最大的变量。我的实测经验是代码理解能力强的模型在逆向场景下优势明显。具体选哪个不展开原则是优先选在代码任务上表现好的上下文窗口至少 64K 起步支持函数调用。沙箱环境Docker 就够了。基础镜像选一个精简的 Linux装上必要的分析工具。注意把网络禁掉文件系统挂载成只读除了分析工作目录。环境准备清单# 基础依赖以 Ubuntu 为例 apt-get install -y python3 python3-pip binutils file pip install capstone keystone-engine # Ghidra 无头模式需要 Java 环境 apt-get install -y openjdk-17-jdk # 沙箱基础镜像建议基于 alpine 或 debian-slim # 分析工具按需安装保持镜像精简3.2 核心流程的实现细节整个分析流程我拆成五个阶段每个阶段有明确的输入输出。阶段一文件识别与预处理。拿到二进制文件后先做基础识别——文件格式ELF/PE/Mach-O、架构x86/ARM/MIPS、位数32/64、是否加壳。这一步用file命令和readelf/objdump就能完成。如果是加壳的Agent 需要先判断壳类型决定是脱壳还是直接静态分析。阶段二静态信息提取。提取字符串、导入表、导出表、节区信息。这一步的关键是过滤噪音。一个正常程序可能有几千个字符串大部分是编译器生成的或者库函数的真正有分析价值的可能就几十个。我的做法是让 Agent 先看全部字符串的统计特征比如按长度、按字符集分类再重点看可疑的比如含 URL、IP、可疑路径、加密相关关键词的。阶段三函数级分析。这是最耗时的阶段。Agent 需要逐个分析关键函数理解其逻辑。实操中不可能分析所有函数需要先做函数重要性排序。排序依据包括被调用次数、是否包含敏感 API 调用、函数大小、是否在入口点附近等。阶段四跨函数关联分析。单个函数看懂了不代表理解整个程序。这一步要把函数之间的调用关系、数据流串起来形成对程序整体行为的判断。比如发现 A 函数解密数据B 函数把解密结果发到网络C 函数负责接收指令——串起来就是一个完整的远控行为链。阶段五报告生成。把分析结果整理成结构化报告。我要求报告包含程序概述、关键行为列表、可疑点及置信度、分析过程记录、未解决的问题。最后一项很重要——明确告诉人类哪些问题 Agent 没搞定而不是假装什么都懂。3.3 提示词设计的关键技巧提示词是逆向 Agent 的灵魂。我分享几个经过反复迭代验证有效的技巧。技巧一用角色任务约束三段式开头。比如你是一名经验丰富的逆向分析工程师。你的任务是分析给定的二进制文件 判断其功能和行为。你可以调用提供的工具来获取信息。 约束 - 每次调用工具前先说明你的推理和预期 - 对不确定的判断标注置信度高/中/低 - 不要臆测所有结论必须有工具返回的证据支撑 - 遇到无法判断的情况明确说明并请求人类协助技巧二给 few-shot 示例。在提示词里放一两个完整的分析案例展示好的分析长什么样。这比单纯描述要求有效得多。示例要覆盖如何从字符串推断功能、如何识别常见算法、如何串联行为链。技巧三动态注入上下文。不要一次性把所有信息塞进去而是根据当前分析目标动态注入相关上下文。比如分析某个函数时只注入这个函数的反编译代码、它的调用者和被调用者信息、它引用的字符串。这样既节省 token又减少干扰。技巧四设置反思环节。每完成一个阶段让 Agent 回顾一下目前的判断有没有矛盾有没有遗漏的重要线索下一步最该做什么这个反思环节能显著减少一条路走到黑的情况。3.4 一个完整的分析案例演示拿一个模拟的样本举例这里用虚构的简化场景说明流程。假设 Agent 拿到一个 ELF 文件初步识别是 x86-64 架构、动态链接、没加壳。第一步Agent 看导入表发现调用了socket、connect、send、recv、fork。Agent 推理这些是网络编程相关 API程序可能涉及网络通信且用了 fork 说明可能有并发处理。第二步Agent 看字符串发现一个 IP 地址、一个端口号、几个看起来像命令的字符串shell、exec、download。Agent 推理结合网络 API 和这些字符串高度怀疑是远控类程序。置信度中高。第三步Agent 定位到调用connect的函数请求反编译。看到它先拼接 IP 和端口然后建立连接连接成功后进入一个循环循环里调用recv接收数据根据接收到的命令字符串执行不同操作。Agent 推理确认是 C2 通信逻辑接收指令并分发执行。第四步Agent 追踪命令分发逻辑发现exec分支调用了systemdownload分支调用了文件写入。Agent 推理具备远程命令执行和文件下载功能行为链完整。第五步Agent 生成报告包含行为描述、关键函数地址、IOCIP、端口、字符串特征、置信度评估。整个流程下来Agent 调用了大约 15-20 次工具消耗的 token 量在可控范围内产出的报告质量接近初级分析师的水平。当然复杂样本需要更多轮次和人工介入。4. 踩坑实录与常见问题排查4.1 模型幻觉最危险也最常见的问题问题表现Agent 信誓旦旦地说某个函数是 AES 加密但实际上只是普通的字节操作。或者编造出一个根本不存在的函数调用关系。根因分析模型在信息不足时会脑补这是语言模型的固有特性。逆向场景下反编译代码往往不完整、变量名无意义、控制流复杂更容易触发幻觉。解决方案强制证据链要求 Agent 的每个结论都必须引用具体的工具返回结果作为证据。没有证据的结论一律标记为推测。交叉验证对关键判断要求 Agent 用不同方法验证。比如判断是 AES就要求它找到 S-box 常量或者密钥扩展逻辑。人工复核低置信度结论前面提到的置信度标记在这里发挥作用低置信度的结论必须人工确认。我实测下来加了证据链约束之后幻觉率能降一半以上。但完全消除不现实所以人工复核环节不能省。4.2 上下文溢出与信息丢失问题表现分析到一半Agent 突然忘记了前面的分析结果开始重复劳动或者得出矛盾结论。根因分析上下文窗口被填满早期信息被挤出。或者状态管理没做好关键信息没有持久化。解决方案分层摘要每完成一个阶段让 Agent 生成该阶段的摘要后续只带摘要不带原始数据。摘要要包含关键结论和证据引用。外部记忆把分析过程中的关键事实存到外部存储比如一个结构化的 JSON 文件需要时按需检索注入。控制单次注入量前面提到的动态上下文注入每次只注入当前任务相关的信息避免一次性塞太多。4.3 工具调用失败与异常处理问题表现反编译超时、工具返回格式异常、沙箱环境崩溃。排查思路问题类型常见原因排查方法解决方向反编译超时函数过大或混淆严重看函数大小和复杂度设置超时超时后降级用反汇编返回格式异常工具版本不兼容对比工具版本和解析代码固定工具版本加格式校验沙箱崩溃资源限制或恶意行为看沙箱日志和资源使用调整资源限制加强隔离调用无响应死锁或网络问题看进程状态加超时和重试机制我的经验是工具调用一定要有超时和降级策略。反编译超时就退回反汇编反汇编失败就退回原始字节分析。宁可分析得粗糙一点也不能卡死。4.4 分析效率优化别让 Agent 做无用功问题表现Agent 花大量时间分析无关紧要的函数真正关键的部分反而没深入。优化策略优先级排序前面提到的函数重要性排序让 Agent 先分析高优先级函数。剪枝对于明显的库函数比如标准 C 库函数直接跳过不浪费 token。增量分析不要每次都从头分析利用之前的分析结果。比如已经确认某个函数是标准的内存拷贝后续就不用再看了。并行化独立的函数分析可以并行进行多个 Agent 实例同时工作最后汇总。这个在样本量大时效果明显。实操心得我一般会设置一个分析预算比如最多调用 50 次工具、最多消耗 100K token。达到预算就强制输出当前分析结果避免无限循环。这个预算根据样本复杂度动态调整。4.5 常见问题速查表症状可能原因快速排查解决动作Agent 反复分析同一函数状态未持久化检查状态存储修复状态管理加去重逻辑结论前后矛盾上下文丢失或幻觉检查上下文长度加摘要机制强制证据链分析速度极慢工具调用过多或模型响应慢统计工具调用次数优化优先级换更快的模型漏掉关键行为函数排序不合理检查排序依据调整排序权重加人工提示报告质量差提示词不够具体审查提示词加 few-shot 示例明确报告结构5. 效果评估与持续优化5.1 怎么判断一个逆向 Agent 好不好用评估逆向 Agent 不能只看能不能跑通要从多个维度衡量。我常用的评估框架包含四个指标准确率Agent 得出的结论中正确的比例是多少。这个需要人工标注一批样本作为基准。实操中我一般抽 20-30 个样本人工分析出标准答案然后对比 Agent 的输出。召回率程序的关键行为中Agent 发现了多少。这个比准确率更重要——漏掉一个关键行为比如漏了一个后门逻辑的后果比多报几个误报严重得多。效率提升相比纯人工分析节省了多少时间。我的实测数据是对于中等复杂度的样本Agent 辅助能把初筛时间从几小时压缩到几十分钟但深度分析还是需要人工。可解释性Agent 的分析过程人类能不能看懂、能不能复核。这个直接决定了人类敢不敢信任 Agent 的结论。5.2 迭代优化的方向用了一段时间之后我总结了几个持续优化的方向扩充工具集初期可能只有反汇编和反编译后续可以加入动态分析工具调试器、沙箱行为监控、符号执行引擎、模式匹配工具等。工具越丰富Agent 能做的事情越多。积累分析模式库把常见的分析模式沉淀下来比如如何识别加密算法、如何识别网络通信逻辑、如何识别反调试技术。这些模式可以作为提示词的一部分也可以做成专门的工具。反馈闭环人类复核 Agent 结论时把修正结果反馈回去用于优化提示词和工具配置。这个闭环跑起来之后Agent 的表现会持续提升。多 Agent 协作单个 Agent 能力有限可以设计多个专职 Agent——一个负责静态分析、一个负责动态分析、一个负责报告生成它们之间通过消息传递协作。这个方向目前还在探索阶段但潜力很大。5.3 我对这个方向的一些个人判断最后说几句个人看法不一定对供参考。逆向工程 Agent 目前处于能用但不够好用的阶段。在简单样本上表现不错复杂样本还是需要大量人工介入。但这个进步速度很快每隔几个月就能看到明显提升。我觉得短期内最现实的落地场景不是全自动分析而是人机协作提效。把 Agent 当成一个不知疲倦的初级分析师让它做初筛、做重复劳动、做信息整理人类专注于需要经验和直觉的判断。这个定位下Agent 的价值已经足够大了。另外这个方向对从业者的技能结构提出了新要求。以前逆向工程师的核心竞争力是看得懂汇编、玩得转调试器未来可能还要加上会设计提示词、会搭 Agent 系统、会评估 AI 输出质量。这不是坏事工具在进化用工具的人也得跟着进化。我在实际使用中最大的体会是不要指望 Agent 给你一个完美答案而是把它当成一个能帮你快速缩小范围的助手。它帮你把一百个函数筛到十个可疑的你只需要深入看这十个效率提升就已经很可观了。剩下的判断还是得靠人。
阅读完成 · 觉得有帮助？
