reverse-skill技能路由包：安全技能路由与AI Agent集成实践

1. 从“reverse-skill”说起一个安全技能路由包到底在解决什么问题第一次看到“reverse-skill”这个命名我的直觉是这不是某个单点工具而是一个技能路由包。所谓路由就是把不同来源、不同格式、不同触发条件的技能请求分发到对应的处理模块上。放到安全领域它要处理的就是逆向、渗透、代码审计、协议分析这些细分方向之间的调度问题。我接触过不少安全团队普遍存在一个尴尬工具一大堆IDA、Frida、Burp Suite、Kali 里的各种脚本、自己写的 Python 小工具散落在不同机器和目录里。新人来了不知道从哪下手老人换个项目又要重新配环境。reverse-skill 这类路由包的核心价值就是把这些能力收敛成一套可调用、可组合、可复用的技能接口让“我想做 JS 逆向”和“我想做固件分析”都能通过统一的入口找到对应的方法链。它适合谁三类人最值得关注一是刚入行做渗透测试或逆向分析的新手需要一条清晰的学习路径而不是一堆零散教程二是安全团队的技术负责人想给团队搭一套内部技能库三是做 AI Agent 方向的开发者想把安全能力封装成 Agent 可调用的工具集。这篇文章我会从设计思路、核心模块、实操落地到踩坑经验完整拆一遍这类技能路由包该怎么理解和搭建。2. 技能路由包的整体设计与选型逻辑2.1 为什么是“路由”而不是“工具箱”工具箱的思路是“我有一堆工具你自己挑”。路由的思路是“你告诉我目标我帮你选工具并串起来”。这两者的差别在实战中非常明显。举个例子面对一个 Android App 的登录协议分析需求。工具箱模式下你得自己判断先用 jadx 反编译看 Java 层发现关键逻辑在 native 层再换 IDA 看 so发现用了 Frida 检测又要写 hook 脚本绕过。每一步的选型都依赖个人经验。而路由包模式下你输入“分析某 App 登录协议”路由层根据文件类型、保护特征、目标平台自动给出推荐链路静态分析优先 jadxnative 层转 Ghidra 或 IDA动态调试挂 Frida检测绕过走对应脚本模板。注意路由不等于全自动。它的价值在于把“选型决策”标准化而不是替你做所有判断。最终的分析结论仍然依赖人的经验。2.2 技能分类的维度设计一个可用的技能路由包分类维度不能太粗也不能太细。我实践下来按“目标类型 技术手段 输出形态”三个维度交叉分类最实用。维度取值示例作用目标类型Web、App、固件、协议、二进制决定基础工具链技术手段静态分析、动态调试、Hook、模糊测试决定操作方式输出形态报告、脚本、补丁、PoC决定交付物格式这样分类的好处是任何一个技能请求都能映射到唯一的三维坐标上。比如“JS 逆向”落在“Web 静态分析 脚本”这个格子里“固件程序逆向分析”落在“固件 静态分析 报告”这个格子里。路由层只需要维护一张坐标到技能模块的映射表。2.3 与 AI Agent 的结合点现在很多人在做 AI Agent 方向想把安全能力接进去。reverse-skill 这类路由包天然适合做 Agent 的“技能后端”。Agent 负责理解用户意图路由包负责把意图翻译成具体的工具调用序列。我试过的一种做法是把每个技能模块封装成带标准输入输出的函数输入是目标描述和参数输出是结构化结果。Agent 只需要知道有哪些技能可用、每个技能需要什么参数不需要关心底层用的是 Frida 还是 Xposed。这样换工具、加工具都不影响上层 Agent 的逻辑。提示给 Agent 用的技能模块输入输出一定要结构化。返回一堆自然语言日志的模块Agent 很难做后续决策。3. 核心模块拆解与实操要点3.1 Web 方向JS 逆向与前端分析模块Web 方向的逆向核心场景是分析前端加密参数、签名算法、验证码逻辑。这类需求在爬虫、渗透测试、接口分析中都很常见。实操链路通常是抓包定位关键请求找到加密参数搜索参数名定位 JS 代码格式化后分析算法最后用 Python 或 Node.js 复现。我拿一个典型的登录签名场景来说。假设某个请求带了一个sign参数值是 32 位十六进制。第一步在浏览器开发者工具里搜索sign找到生成它的函数。常见的情况是代码被混淆过变量名都是_0x开头。这时候不要急着逐行读先用格式化工具展开然后搜索关键字符串比如md5、sha、encrypt。// 混淆后的典型形态 var _0x4a2b [\x6d\x64\x35, \x73\x69\x67\x6e]; function _0x3c1d(_0x5e2f) { return _0x4a2b[0]; }解码十六进制字符串后能看到md5和sign。接下来就是定位参数拼接顺序。这一步最容易出错因为拼接顺序往往和代码书写顺序不一致需要动态调试确认。实操心得JS 逆向里静态分析定算法动态调试定参数顺序。两者缺一不可。我见过太多人静态读完代码直接写复现结果参数顺序错了调试半天。对于 hcaptcha、datadome、akamai 这类风控产品的逆向难度会高一个量级。它们通常有环境检测、行为检测、代码虚拟化等多层防护。这类目标的处理思路是先过环境检测再处理代码逻辑。环境检测常见的有navigator属性校验、canvas指纹、WebGL指纹等。处理方式是补环境把缺失的浏览器对象用 Node.js 模拟出来。3.2 App 方向Java 逆向与 Native 分析模块App 逆向分两层Java 层和 Native 层。Java 层相对友好Native 层难度陡增。Java 层的标准流程是apk 解包dex 转 jar用 jadx 或 jeb 反编译定位关键类和方法。如果遇到加固先脱壳。脱壳工具的选择取决于加固厂商常见的有 frida-dexdump、youpk 等。Native 层的分析就复杂多了。so 文件通常是 ARM 指令集需要 IDA 或 Ghidra 加载。关键函数的定位方法有几种一是从 Java 层的 native 方法声明入手找到对应的 JNI 函数二是搜索字符串常量三是动态调试跟踪。# frida 挂载并 hook native 函数的典型命令 frida -U -f com.example.app -l hook.js --no-pause// hook.js 示例打印 native 函数参数 Interceptor.attach(Module.findExportByName(libnative.so, Java_com_example_Native_sign), { onEnter: function(args) { console.log(arg1: Memory.readUtf8String(args[2])); }, onLeave: function(retval) { console.log(ret: Memory.readUtf8String(retval)); } });Frida 和 Xposed 的选择上Frida 更灵活适合分析和调试阶段Xposed 更适合做持久化的功能修改。逆向工具比较中IDA 的交互和插件生态最好Ghidra 免费且反编译质量不错Binary Ninja 的 API 设计最现代。选哪个看团队预算和个人习惯。注意动态调试 native 层时要注意反调试检测。常见的检测手段有 ptrace 自附加、调试端口检测、时间差检测。绕过方式对应有 ptrace 绕过、端口隐藏、时间戳修正。3.3 渗透测试方向从信息收集到内网横向渗透测试的技能模块和逆向有重叠但侧重点不同。逆向侧重“看懂”渗透侧重“打通”。一个完整的渗透链路包括信息收集、漏洞扫描、漏洞利用、权限提升、内网横向、痕迹清理。每个环节都有对应的技能模块。信息收集阶段子域名枚举、端口扫描、目录爆破是基础操作。Kali 里的工具很全但关键是知道什么时候用什么。比如目标有 CDN 时直接扫端口没意义要先找真实 IP。找真实 IP 的方法有查历史 DNS 记录、看 SSL 证书、分析邮件头等。漏洞利用阶段Web 渗透软件的选择上Burp Suite 是标配但它的主动扫描在实战中要慎用容易触发告警。手工测试配合 sqlmap、nuclei 这类工具更稳妥。内网渗透是很多人的短板。拿到一个 shell 之后怎么横向到域控这中间涉及大量技能点凭据抓取、票据传递、端口转发、代理搭建。这部分我建议在靶机环境里反复练raven2 这类靶机就是专门练内网链路的。实操心得渗透测试实战中信息收集占 60% 的时间但决定 80% 的结果。我见过太多人急着上工具打点结果连目标的基本架构都没摸清打进去也是盲人摸象。3.4 固件与 IoT 方向单片机固件程序逆向分析固件逆向是安全领域里相对小众但需求稳定的方向。IoT 设备、路由器、智能硬件都涉及。基本流程是获取固件官网下载或从设备 flash 读取用 binwalk 分析固件结构提取文件系统分析启动脚本和服务程序定位漏洞点。# binwalk 分析固件 binwalk -e firmware.bin # 查看提取出的文件系统 ls -la _firmware.bin.extracted/squashfs-root/固件分析中最常见的问题是架构不熟悉。MIPS、ARM、PowerPC 都有指令集和调用约定各不相同。用 IDA 加载时要选对处理器类型否则反汇编结果全是错的。另一个坑是固件里的程序往往是静态编译的没有符号表函数识别全靠手动。这时候字符串搜索和交叉引用就是主要手段。4. 实操过程搭一个最小可用的技能路由包4.1 目录结构与技能注册我以 Python 为例搭一个最小可用的路由包骨架。核心是一个技能注册表和一张路由映射表。# skill_router.py import importlib from typing import Dict, Callable, Any class SkillRouter: def __init__(self): self.skills: Dict[str, Callable] {} self.routes: Dict[str, str] {} def register(self, name: str, func: Callable): self.skills[name] func def add_route(self, target_type: str, skill_name: str): self.routes[target_type] skill_name def dispatch(self, target_type: str, **kwargs) - Any: skill_name self.routes.get(target_type) if not skill_name: raise ValueError(f没有为 {target_type} 注册技能) return self.skills[skill_name](**kwargs)这个骨架很简陋但已经能跑通“输入目标类型路由到对应技能”的核心逻辑。实际使用中路由映射可以从配置文件加载技能模块可以动态发现。4.2 技能模块的标准接口设计每个技能模块统一实现三个方法check判断是否适用prepare准备环境run执行主逻辑。# skills/js_reverse.py class JsReverseSkill: name js_reverse target_type web def check(self, target: str) - bool: return target.endswith(.js) or javascript in target.lower() def prepare(self): # 检查 Node.js 环境、安装依赖 pass def run(self, target: str, **kwargs): # 执行 JS 逆向分析 return {status: ok, result: ...}这种设计的好处是路由层不需要知道技能内部怎么实现只需要按标准接口调用。新增技能时只要实现这三个方法并注册即可。4.3 与 AI Agent 的对接方式把技能路由包暴露给 AI Agent有两种方式。一种是函数调用Agent 通过 function calling 直接调用技能函数。另一种是 HTTP 接口路由包起一个本地服务Agent 通过请求调用。函数调用方式更简单适合 Agent 和路由包在同一进程或同一台机器上。HTTP 方式更灵活适合分布式部署。# 暴露给 Agent 的技能描述 skill_descriptions [ { name: js_reverse, description: 分析 JavaScript 代码中的加密、签名、混淆逻辑, parameters: { type: object, properties: { target: {type: string, description: JS 文件路径或 URL}, focus: {type: string, description: 关注点如 sign、encrypt} }, required: [target] } } ]Agent 拿到这份描述后就能在需要时自动调用对应技能。我实测下来这种对接方式对 Agent 的友好度最高因为描述清晰、参数明确。提示给 Agent 的技能描述里description 字段要写清楚“什么时候用这个技能”而不只是“这个技能是什么”。这直接影响 Agent 的调用准确率。5. 常见问题与排查技巧实录5.1 环境类问题问题一Frida 连接不上设备。排查顺序先确认frida-ps -U能否列出进程。如果不行检查 frida-server 是否在设备上运行、版本是否匹配、端口是否被占用。Android 高版本还要注意 SELinux 权限。问题二Node.js 补环境时缺少浏览器对象。常见缺失的有window、document、navigator、location。补环境时不要一次性全补而是根据报错逐个补。补的时候要注意属性描述符有些属性是 getter直接赋值不生效。5.2 分析类问题问题三反编译代码可读性差。这是常态。应对方法先看字符串常量再看函数调用关系最后看具体逻辑。不要一上来就逐行读效率极低。问题四动态调试时程序崩溃。常见原因是 hook 点选得不对或者参数类型不匹配。先用Interceptor.attach只打印不修改确认 hook 生效后再做修改。5.3 速查表问题现象可能原因排查方向Frida 连接超时frida-server 未运行或版本不匹配检查进程和版本补环境报错缺少浏览器对象按报错逐个补反编译乱码处理器类型选错确认架构后重新加载hook 不生效函数名或偏移错误用枚举导出函数确认路由找不到技能映射表未注册检查注册逻辑5.4 独家避坑技巧第一个技巧技能模块的日志要分级。DEBUG 级别记录详细过程INFO 级别记录关键节点ERROR 级别记录失败原因。Agent 调用时只看 INFO 和 ERROR人工排查时开 DEBUG。第二个技巧路由映射表要支持优先级。同一个目标类型可能匹配多个技能按优先级排序先试高优先级的失败了再降级。这在处理未知目标时特别有用。第三个技巧技能模块要能独立运行。不要设计成必须通过路由才能调用。独立运行能力方便调试和测试也方便在路由出问题时快速定位是技能本身的问题还是路由的问题。6. 技能路由包的扩展方向与个人体会这类路由包后续可以往几个方向扩展。一是增加技能之间的组合能力比如“先脱壳再反编译再 hook”这样的链路可以定义成复合技能。二是增加结果缓存同一个目标分析过一次后结果存下来避免重复劳动。三是增加技能市场机制团队成员各自贡献技能模块路由包负责统一管理和分发。我在实际搭建和使用过程中的体会是路由包的价值不在于技能多而在于接口稳。技能可以慢慢加但接口一旦定下来就不要轻易改。接口稳定了上层 Agent、下层技能模块才能各自独立演进。另外不要追求大而全先把一个方向做透比如先把 Web 逆向这条链路跑通再扩展到 App 和固件。贪多嚼不烂这是我在多个项目里反复验证过的教训。最后分享一个小技巧技能模块的命名用“目标_手段”的格式比如web_static、app_dynamic、firmware_static。这样在路由映射和日志里一眼就能看出技能的作用范围比用skill_01、skill_02这种命名强太多。