Navigate the dark waters, sail against the stream. 当 AI agent 面对一个 APK、一段 JS 加密混淆、一个 CTF 二进制题时，它往往不知道该调用 jadx、apktool、Frida 还是 IDA------工具和脚本散落各处，重复犯错、经验无法复用。reverse-skill 正是为解决这一痛点而生：它通过结构化路由规则自动匹配场景、检查工具链并自举执行，让逆向工程从"瞎猜命令"走向可复用的标准化工作流。
一、核心矛盾与架构理念
AI agent 在执行渗透测试和逆向任务时，最大障碍不是算力不足，而是决策路径的不确定性 。传统的"遇到 APK → 用 jadx"式的思维模式，在复杂场景下往往失效：需要先判断平台、再确认工具版本、再选择合适的模块组合。reverse-skill 将这一过程抽象为规则驱动的技能路由，通过 routing.json 维护一条从"输入信号"到"执行动作"的确定性映射链。
整个项目由四个核心层构成：
- 路由核心层：routing.json + RULES.md 定义场景分类与路由规则
- 技能模块层：44 个 tracked modules，每个模块封装特定场景的工具链和工作流
- 客户端适配层：各 AI agent（Claude Code、Codex、Cursor、OpenCode）的适配器，负责将路由结果转化为该客户端能执行的指令
- 保障层：回归测试套件 + CI 流水线，确保路由一致性不因版本迭代而漂移
核心与客户端之间采用契约式解耦：路由逻辑、回归测试、case 工作流不依赖任何特定 AI 客户端，客户端配置作为可选部分置于核心合同之外------这意味着换一套 Agent 平台，只需实现对应的适配器，而不需要改动核心路由逻辑。
二、43 条路由规则的场景覆盖
routing.json 中的 43 条规则（R0--R44）覆盖了 20+ 场景类别，大致可分为以下几组：
| 类别 | 典型规则 | 核心工具链 |
|---|---|---|
| APK / Android 逆向 | R0--R6 | jadx, apktool, Frida, BurpSuite MCP |
| iOS 逆向 | R7--R9 | class-dump, Frida, IDA Pro |
| 二进制分析 | R10--R17 | IDA Pro, radare2, Ghidra |
| .NET 逆向 | R18--R20 | dnSpy, ILSpy, dotPeek |
| 前端 JS 加密 | R21--R25 | Node.js, 混淆分析模块 |
| CTF 挑战 | R26--R32 | 综合路由，按需组合工具 |
| 恶意软件分析 | R33--R36 | 沙箱集成、行为分析报告 |
| 固件逆向 | R37--R39 | binwalk, firmware-mod-kit |
| EDR Bypass | R40--R43 | 行为检测规避路径 |
每条路由规则在路由时承担两层职责：场景识别 （"这是哪一类任务"）和工具可用性检查（"当前环境有哪些工具"）。如果某工具缺失，路由会自动降级到次优路径，而不是直接报错。
一个值得深挖的问题是：43 条规则在实际任务中如何动态组合？例如一个 CTF challenge 可能同时涉及 APK 逆向和前端 JS 混淆，此时路由系统是否支持多规则叠加？目前规范尚未公开优先级或冲突消解机制的具体设计，但从 173 个回归用例的存在可以推测，系统至少具备基础的顺序解析能力。
三、Client-Neutral 设计与适配器模型
reverse-skill 的 client-neutral 设计是其最具差异化的一点。传统安全工具链往往绑定特定终端或编辑器，而 reverse-skill 通过适配器模式实现了真正的平台无关性。
yaml
# 典型的客户端适配器配置示例
adapters:
claude_code:
config_path: .claude/skills/reverse-skill
cursor:
config_path: .cursor/rules/reverse-skill
codex:
config_path: .codex/plugins/reverse-skill
open_code:
config_path: .opencode/skills/reverse-skill每个适配器只需实现一个最小接口：接收路由结果，将其转换为该客户端可执行的上下文指令集。这种设计的代价是，某些客户端的高级特性（如 Cursor Rules 的深度集成能力）可能无法完全利用，但换来的是统一的规则库和测试体系。
对于追求极致集成的用户，开发者可以在适配器层之上叠加扩展模块，而不影响核心的路由逻辑。
四、173 个回归用例与 CI 保障
路由系统的可靠性是整个项目的基石。reverse-skill 提供了 173 个 hint→expected PRIMARY 的路由回归用例，覆盖了所有 43 条规则的核心路径。这些用例在每次 push 和 PR 时在 Windows + Ubuntu 双平台并行运行，确保跨平台的规则一致性。
CI 流程包含两个关键门禁：
- 结构连贯性验证：检查 routing.json 的语法合法性、规则的无环性、模块引用的完整性
- 供应链 pin 门禁：确保所有依赖版本被显式锁定，防止依赖漂移带来的安全风险
supply-chain pin gate 防止的核心风险是：当某个上游工具（如 jadx 或 Frida）发布了破坏性更新时，未 pin 的版本可能导致路由规则失效甚至工具行为异常。一旦 pin gate 触发，CI 会阻断合并，直到版本约束被明确标注------这在小团队维护的开源项目中尤其重要。
不过，173 个用例是否足以覆盖真实世界的复杂场景，仍是一个开放问题。特别是在 multi-scenario（多场景叠加）和 edge-case（边缘情况）方面，可能存在漏测风险。建议在实际使用中结合具体任务类型补充额外的验证用例。
五、标准化工作流：从路由到报告
reverse-skill 定义了一个完整的任务处理 pipeline，所有进入的任务必须遵循以下流程：
任务输入 → RULES.md 作用域确定 → 路由匹配 → 工具自举 → 执行技能模块 → 输出报告以一次 APK 逆向任务为例：
- 作用域确定：RULES.md 明确该任务的 auth 认证方式和 network_profile 网络配置
- 路由匹配：检测到 .apk 后缀，路由到 R0（APK 基础分析）或 R1（APK 混淆分析），根据输入信号进一步细化
- 工具自举：执行 refresh-tool-index 脚本，自动检测 jadx、apktool、Frida-server 等是否可用，生成 tool-index.md
- 技能执行：按模块化工作流逐步执行，每个步骤输出中间 artifact
- 报告输出：最终生成标准化的 Evidence→Finding→Path 证据链，以及 timeline 时间线
这种标准化输出的价值在于：同一份路由结果可以被不同的人或不同的 AI agent 复现，不再依赖个人的"经验直觉"。
六、跨平台工具链自举
初始化阶段，reverse-skill 要求用户根据操作系统运行对应的 refresh-tool-index 脚本：
- Windows：PowerShell 脚本，扫描 PATH 中的 jadx、apktool、Frida、BurpSuite MCP 等工具
- Linux：bash 脚本，执行相同的检测逻辑
脚本的输出是 tool-index.md，记录每个工具的路径、版本和可用性状态。这个索引文件是整个路由系统的前提------规则引擎在做路由决策时，首先查询 tool-index.md，对不可用的工具走降级路径。
工具链的自举设计还有一个隐含价值：它将"环境配置"这一通常由人工完成的工作，变成了可自动化、可版本化的流程，减少了"在我机器上能跑"的经典问题。
七、小结与展望
reverse-skill 的核心创新不在于单项技术的深度，而在于将逆向工程的决策过程本身结构化和可测试化。43 条路由规则、173 个回归用例、client-neutral 架构，构成了一个可验证、可扩展、可移植的技能分发系统。
当前版本仍存在若干值得探索的方向：多规则动态组合的策略、高级客户端特性的整合深度、真实世界场景的用例覆盖度，以及供应链安全机制的完善程度。对于从事 AI 辅助逆向工程和安全研究的团队而言，reverse-skill 提供了一个有价值的参考范式------将"经验"转化为"规则"，将"直觉"转化为"路由"。