Skip to main content

​
工作原理

deobf-all 作为调度器（Dispatcher），不会一次性加载全部 9 个子 skill，而是先分类、再按需加载，最大限度节省上下文空间和工具调用次数。

​
执行契约

目标：每次调用不超过 5 次 read_skill，除非目标类型完全未知。

​
分步流程

​
Step 1: 分类（Triage）— 0–1 次工具调用

检查目标，确定：
  1. 目标类型：原生二进制 / JavaScript / 字节码 / 其他
  2. 混淆家族：CFF、VM 保护、字符串加密、加壳、JS 混淆器
  3. 是否有反调试 / 反逆向层
  4. 上下文：CTF 挑战？生产分析？快速清理？
输出：分类行，例如 TRIAGE: native PE, VMProtect, has anti-debug → P0:code-obfuscation-deobfuscation P1:vm-and-bytecode-reverse,anti-debugging-techniques

​
Step 2: 加载 P0 — 1–2 次工具调用

根据分类结果加载核心 skill：
  • 原生二进制 → read_skill code-obfuscation-deobfuscation
  • JavaScript → read_skill ast-deobfuscation

​
Step 3: 按需加载 P1/P2 — 0–3 次工具调用

仅当路由矩阵标记 ✓ 时才加载。空单元格的 skill 不要加载。

​
Step 4: 反混淆（Deobfuscate）

  • 优先静态：模式匹配、CFF 还原、字符串解密、dispatcher 内联
  • 受阻时切换动态：调试器脚本、仿真、符号执行
  • JavaScript：先运行 scripts/detect-patterns.js，再应用匹配的流水线
  • 原生二进制：先识别保护器类型，再选择策略

​
Step 5: 验证（Validate）

  • 将反混淆输出与原始特征对比
  • 验证代码功能等价
  • 检查是否有残余/嵌套混淆层

​
Fallback — 分类不确定时

如果检查后仍无法确定目标类型：
  1. read_skill 加载 deep-analysis（P2）
  2. 遵循 deep-analysis 方法论对目标分类
  3. 回到路由矩阵，根据分类结果加载对应 P0/P1 skill
这是唯一应先加载 P2 再加载 P0 的场景。