搞逆向工程的人都知道最近一年多AI编码客户端Cursor、Cline、Copilot这类在正向开发里杀疯了写业务代码、补测试、查文档样样在行。但你把一段二进制的反汇编丢给它让它帮忙还原控制流、识别结构体、推断协议格式它往往就开始一本正经地胡说八道——地址是编的偏移量是猜的连大小端都能给你搞反。我一开始以为是模型能力问题后来在GitHub上看到一个叫reverse-skill的项目思路才反应过来问题不止出在模型上更出在“技能路由”这个环节。今天就把我对reverse-skill这个方向的拆解、实践和调优记录整理出来希望能给在AI编码客户端里做安全研究、二进制分析和协议还原的朋友省点时间。1. 先聊聊我为什么给AI编码客户端做了一套逆向工程技能路由包1.1 正向开发如鱼得水逆向分析却频繁翻车先描述一个场景你可能也见过。我在本地用Ghidra分析一个嵌入式设备的固件把反编译出的C伪代码粘给AI编码客户端让它帮忙还原某个函数的逻辑。AI给出的回复看起来很专业读一遍下来仿佛确实懂了但对照反汇编去验证的时候就是哪儿都稳不住——它把某个结构体成员的偏移量算错了导致后面所有字段语义全歪。起初我以为是提示词写得不够详细于是加了更多约束结果只是从“错误地自信”变成了“错误地犹豫”。后来我统计了一下失败样本发现真正的问题不是AI不会做逆向而是AI没有一套可复用的逆向分析路径。它每次都在“零样本”状态下临场发挥想到哪分析到哪。这跟让一个刚入行的新人直接上手逆向是一样的——不是他不聪明而是没有操作流程和检查清单。1.2 逆向工程工作流的真实形态做过逆向的人都知道真正可靠的逆向分析从来不是一个线性的“读代码—写结论”过程而是一个多轮收敛过程先对目标做静态结构识别文件头、架构、编译器特征再定位关键函数、字符串引用、导入表然后还原数据结构和控制流过程中会不断提出假设每个假设都需要从多个角度验证某一步推理错了需要退回去修正之前的结论。这个工作流有两个显著特征高试错成本和强依赖上下文连续性。AI编码客户端默认的工作方式恰恰不擅长这两点——它倾向于一次对话给你一个“最优答案”而不是跟你一起迭代假设、验证、回退、再验证。1.3 用“路由”思路重构AI的逆向能力reverse-skill这个项目名给了我很大启发把逆向工程拆成一组“技能单元”每个技能单元有明确的触发条件、执行步骤和退出标准然后通过一套路由规则让AI编码客户端在处理任务时按需加载、调用、切换对应的技能。这个概念借鉴了计算机网络里的路由思想——我们不需要把整个互联网的路径都记在脑子里只需要知道去哪查、按什么规则转包。对应到AI编码客户端上就是要解决一个核心问题如何让AI在逆向分析时不依赖临场发挥而是根据手头的数据特征走一套可靠的技能路径。2. 路由包的整体设计技能不是提示词而是一套可路由的分析协议先明确一点reverse-skill并不等于“一堆Prompt模板”。单纯的提示词只是告诉AI该怎么说话而技能路由包要解决的是“AI什么时候该用什么技能、用什么顺序执行、达到什么标准才能继续下一步”。它有明确的协议层属性。2.1 顶层设计思路显式化“元认知动作”我设计路由包时的核心原则是把逆向分析中隐式的元认知动作变成AI可以显式执行的动作序列。比如一个熟练逆向工程师在看到函数时会下意识判断“这个函数是不是单纯的数学计算”“这个结构体是不是配置项”这些直觉其实是可以沉淀成可执行规则的。在reverse-skill里我把分析过程划分为几个阶段每个阶段对应一类技能单元。用网络术语类比的话每个技能单元相当于一个“路由节点”AI负责做“路由决策”根据当前的数据特征把请求转发给合适的节点。2.2 包体内部结构五段式技能描述我参考开源社区的一些做法把每个技能单元统一封装成五段式结构字段作用对着实际场景来说技能名称路由索引的关键词比如“PE结构指纹识别”“调用约定判定”触发条件何时激活该技能比如“当文件偏移0x3C处的小端值指向0x5045时”执行步骤具体的分析序列不写废话全部是可执行的指令退出标准什么算分析完成防止AI无限发散或过早收敛已知误区该技能下常见的错误假设这是调优过程中积累的负样本从我的使用体验来看退出标准往往比执行步骤更重要。AI在没有退出标准时会倾向于“解释到看起来合理为止”而不是“验证到证据闭合为止”。后者的思维方式和逆向工程的底层逻辑是一致的。2.3 路由判定逻辑与包的分层栈路由判断的依据应该分层设计我把reverse-skill按“基础层—分析层—验证层”三层组织基础层文件格式识别、架构判断、字节序判定、加壳/混淆检测、调试符号提取这些技能决定了AI后续所有判断的坐标系。分析层关键函数定位、交叉引用分析、结构体复原、协议字段推断、加密/压缩算法识别这些技能负责把二进制“翻译”成可理解的逻辑。验证层地址一致性校验、patch闭环、运行验证、差异比对这些技能负责把AI的推理结果拉回到现实世界中检查。路由执行的顺序通常是基础层先跑确认坐标系然后进入分析层最后用验证层来兜底。如果验证层发现假设不成立就需要回退到分析层甚至基础层。这个“回退机制”是路由包里最容易被忽略但最有价值的设计。3. 我实际配置的几组核心技能单元与通用模板下面拿出我在reverse-skill包中实际配置的几组技能单元每个都经过了几个项目的验证和调整。这些配置可以直接抄进你的AI编码客户端里但建议你结合自己的领域做修剪。3.1 技能单元一二进制结构指纹识别触发条件当拿到一个文件或固件尚未确认其文件格式和CPU架构时。执行步骤使用xxd或ImHex读取文件头特别关注前64个字节的魔数和特征值先判定文件格式ELF/PE/Mach-O/原始固件/压缩包再判定编译器和链接器特征检查程序头/节头里的架构字段如EM_X86_64、EM_ARM、EM_RISCV不要在读取之前预设架构输出格式化的结构摘要并标注每个关键字段的字节偏移。退出标准文件格式、目标平台、字节序三类信息全部确认为止。只要有一类不确定必须继续查找证据不能猜测。我在配置里反复跟AI强调一条规则“在没有读取到实际字节时任何架构判断都是伪命题。”这条规则来自一次真实翻车——AI基于程序入口地址的取值习惯把一个ARM程序判断成了x86导致后续所有反汇编全部无效。后来我把这个误区写进“已知误区”字段情况明显改善。3.2 技能单元二控制流与调用约定还原触发条件已确认架构和文件格式需要还原某个关键函数的控制流程时。执行步骤从函数入口开始先识别栈帧建立代码prologue确认栈帧大小和参数传递方式以块为单位分析基本块basic block之间的跳转关系特别注意间接跳转和switch跳转表对每个call指令确认被调用者是外部导入函数、内部函数还是函数指针并记录参数个数和返回值处理方式结合反编译伪代码交叉验证但以反汇编和指令特征为准伪代码只作参考。退出标准函数边界、调用关系中所有引用指向的具体地址均已确认且不存在无法解释的跳转目标。这个技能单元对AI特别容易踩坑的地方在于“伪代码依赖”。Ghidra和IDA的反编译结果在遇到混淆代码或非标准字节序列时会输出“看起来合理但实际错误”的伪代码。AI如果不检查伪代码对应的汇编指令就会被带偏。我在技能包里加了一条硬约束任何关于控制流的结论必须能对应到至少一条汇编指令或指令模式上。3.3 技能单元三结构体与数据流复原触发条件已经定位到某个数据结构频繁被访问但类型信息缺失或未知时。执行步骤收集所有访问该数据区的指令上下文记录偏移量的分布范围根据偏移量的使用模式推测字段宽度比如第8偏移处总是被当作指针使用则它是8字节指针检查是否有函数调用将数据区地址作为this指针或参数传递结合调用点反推构造约束尝试建立结构体骨架再用其他交叉引用验证字段之间的约束关系。退出标准每个字段的偏移、宽度、访问方式都有至少两个独立交叉引用支持。一个引用的推断不生效。我把这个技能单元比作“拼图时不只看拼图本身还要看盒子上的整体图样”。只盯着某一处访问是看不出来的必须把结构体的所有访问点拼起来才能形成可靠的轮廓。3.4 技能单元四验证闭环与Patch假设触发条件AI或人工给出了某个关于程序行为的假设需要验证真伪时。执行步骤记录假设涉及的函数地址、修改点、预期行为变化对二进制做备份在模拟器或调试器中对修改点打补丁让程序运行到修改点前检查寄存器、内存和栈状态是否与预期一致记录验证结果如果与假设不符明确列出哪些前提可能错误并回到对应技能单元继续分析。退出标准要么验证通过并输出可复现的步骤要么验证失败并形成新的假设。这一条技能是路由包后期加上去的。最初的版本只有分析和推理没有验证闭环于是AI经常跑出一个“自洽但无法在真实环境复现”的结论。补齐验证技能之后分析结果的可信度整体上了一个台阶。4. 把路由包接进AI编码客户端的三种方式与对比技能路由包拆解得再好最终还是要能被AI编码客户端读取和执行。目前市面上的AI编码客户端接入方式五花八门我这几个月试下来大致可以归成三类各有优劣。4.1 规则文件注入方式适合Cline、Copilot自定义指令把整个路由包写成规则文件注入到客户端的上下文系统中。例如Cline支持在项目根目录放CLAUDE.md或AGENTS.mdCopilot支持自定义指令文件。这种方式做起来最省事把技能描述按章节写好AI每次对话都会自动加载。我实际测试后发现规则文件注入的效果取决于模型对长上下文指令的遵循程度。上下文越长AI越容易“只看后半段”或“挑着执行”。所以规则文件不能写成百科全书而应该先写路由表和触发条件把详细步骤放到AI可以按需调用的外置文档里。4.2 外置技能库路径引用适合Cursor Rules等支持引用的场景我在Cursor里把reverse-skill拆成了多个独立Markdown文件按skills/基础层/结构指纹.md这样的目录组织然后在规则文件里只写路由表AI分析时根据任务类型去加载对应文件里的详细步骤。这种方式的好处是按需加载减少无效上下文占用。缺点是AI加载外置文件的意愿不稳定有时候你明确告诉它“去读skills/分析层/结构体复原.md”它会照做但分析进入深水区之后它经常会忘记继续引用。后来我通过给路由表加了一句“每次进入新的分析阶段前必须重新读取对应技能文件的开头三段”把这个问题的概率压低了。4.3 把技能封装成可调用的函数MCP/Function Calling方向这是最正统的“路由”形式目前也是我重点投入的方向。把技能单元封装成函数AI只负责根据分析目标发出调用请求具体执行交给函数内部定义好的脚本、命令行工具或分析服务。比如“结构指纹识别”可以封装成调用readelfrabin2自研魔数脚本的函数AI拿到结构化输出之后再做推理。MCP方式初期的配置成本确实高但对大型项目来说收益非常明显AI不再需要理解工具参数只需要理解工具输出工具本身可以不断升级优化而AI的推理和路由逻辑基本不用动这也正是路由设计的核心价值。随着AI编码客户端对MCP的支持越来越成熟我认为这会是reverse-skill后续的标准形态。三类方式的对比我整理了一张表接入方式配置成本按需加载能力技能复用性适合场景规则文件注入低差全程常驻上下文一般学习、小规模项目外置技能库路径引用中中依赖模型遵循能力好日常逆向分析技能封装函数/MCP高好按调用分发最好团队协作、项目常态化如果刚开始尝试我建议第一个项目先用规则文件注入跑通全流程从第二个项目开始迁到外置技能库确认技能单元稳定了再花时间封装成MCP函数。5. 实测里的坑与调优记录为什么技能路由包也会失效我最初以为把技能包做出来AI就能老老实实按路由走现实很快打脸。下面记录三个最典型的失效场景以及我最后是怎么修正的。5.1 案例一AI跳过了基础层直接做分析层推理有一次我让它分析一个ELF程序的某个函数调用关系它跳过了结构指纹识别直接从反汇编中间位置开读。结果它基于一段实际上是数据段的内容推断出了“函数入口”。排查之后发现问题出在路由表没有对“分析目标”和“启动技能”做硬绑定。我的路由表写的是“当需要还原控制流时调用控制流还原技能”但它没有规定“必须先完成基础层技能”。后来我把路由表改为强制前置条件“未完成结构指纹识别前不允许进入分析层技能如果目标是分析某个函数必须输出函数地址范围的确认依据。”这个修正之后跳层问题大幅度减少。5.2 案例二AI“看起来在做验证”实际上在做脑补这个坑最可怕。我问AI某个patch假设是否成立它回答“已通过逻辑验证”但实际没有调用验证技能只是在推理里“走了个过场”。事情的本质是语言模型倾向于生成一个看起来完整的流程而不一定真的执行流程中的工具调用。它认为“验证一下”就是自己在脑内做一次推理而不是去跑调试器。修正方式比较直接在技能路由包里验证层技能不再允许由AI凭空输出结论而是必须给出工具执行输出的关键片段——比如gdb的寄存器打印结果、某内存地址的十六进制转储。凡是验证类技能没有证据截图等同未执行。如果客户端不支持附证据就要求输出“执行了哪条命令、命令输出中哪几个字段支撑了结论”。5.3 案例三路由冲突导致技能反复横跳在分析一个带混淆的样本时我发现AI在“结构体复原”和“算法识别”两个技能之间反复横跳了七八轮上下文被无效推理塞满最后连之前已经确认的结论都忘了。这个问题出在技能优先级定义太弱。路由包只写了技能A和技能B各自的条件没有定义“出现冲突时怎么办”。后来我加了一条优先级规则“当数据流分析的结果与控制流分析冲突时以控制流为准当结构体布局与调用约定冲突时返回基础层重新核实架构而不是在分析层强行调和。”有了这条规则类似冲突就能快速收敛。5.4 三组调优参数的变化值记录从项目反馈来看每个技能单元的调用频率是不够的需要用统计数据推动调优。这里记录我用三个项目迭代后的调整结构指纹识别的触发条件从“文件头未知时”扩为“每切换一个分析目标文件时”因为一开始AI会在分析过程中把文件A的结构信息带到文件B上控制流还原的退出标准从“基本块覆盖率不低于70%”改为“核心函数覆盖率达100%”追根究底70%覆盖率的退出对风险场景无法兜底验证层的证据字段从“可选”改为“必填”。这一项改动最轻效果也最明显。6. 这套路由思维能延伸到的其他方向reverse-skill目前说的是逆向工程但其底层的“路由”设计思路完全是通用的。一旦你习惯了“把技能单元化、把流程路由化”你会发现它能自然扩展到多个相邻领域。6.1 流量协议逆向与物联网设备研究做物联网设备研究时经常需要从抓包文件和固件中还原私有协议格式。我的做法是把reverse-skill的“结构体复原”技能改造成“协议字段推断”技能触发条件从“访问某数据区”变成“某个端口反复出现固定格式报文”。AI在路由包的指导下会先统计报文长度分布和分隔符再尝试逐字段切分最后用校验字段约束整体结构。6.2 安全审计和样本分析场景对于样本分析路由表中的基础层多了“混淆特征检测”和“反调试检测”两个技能。分析样本时安全分析师的精力有限逆向前就得先让AI判断该往“脱壳/反混淆”走还是直接“静态逻辑梳理”走。这个路由决策的质量往往直接决定了后续分析的坑深坑浅。6.3 从个人技能包升级为团队共享技能库在不涉及敏感信息的前提下可以把团队里别人的日常逆向技巧沉淀成技能单元集中进共享技能库。比如团队里有人擅长处理某系列RTOS的任务结构体识别就可以把这个专项技能连同已验证过的偏移量和交叉引用证据一起记录到库里。后续AI在分析同系列固件时自动沿这条已验证路径走节省大量重复劳动。6.4 技能路由包的未来形态猜测随着各家的AI编码客户端开始支持工具调用和MCP路由包大概率会从“给AI看的提示词集合”演化成“AI能直接执行的分析工作流”。到那个时候逆向工程师的主要工作会从“自己动手分析”转向“设计更优的技能路由、沉淀更准的触发条件和更严的退出标准”。这本质上是一种分工转移而非岗位消失。最后再分享一个我个人的体会整套reverse-skill做下来最大的收获不是AI的分析准确率提高了多少而是它让我重新梳理了一遍自己的逆向分析流程。当你需要把一个隐性的分析过程显式地写成触发条件、执行步骤和退出标准时你会发现自己原以为“凭经验判断”的地方究竟依赖了哪些证据。这个过程本身和逆向工程一样是一场对“底层结构”的还原。也希望你手里的AI编码客户端在跑了路线正确的技能包之后真正成为你分析二进制时愿意背对背交付后背的那个人。