AI Mobile Reverse Skills

Skill: AI Mobile Reverse Skills

定位

本 Skill 是整套移动安全分析体系的根入口，也是唯一的阶段调度入口。

它面向以下典型场景：

• Android App 静态逆向分析
• 抓包结果与源码实现联动分析
• SO / JNI / native 通信与加密逻辑分析
• 弱加密、认证授权、组件安全、业务逻辑等高风险问题筛查
• 授权环境下的最小验证方案设计
• 渗透测试报告与交付物生成

它不替代具体阶段做细节分析，而是负责：

1. 识别用户当前要执行的阶段。
2. 识别当前已连接的 MCP、已提供的输入材料和已有的中间产物。
3. 检查当前阶段的最低启动条件是否满足。
4. 将任务路由到正确的阶段 Agent。
5. 约束各阶段按统一输入输出契约推进。

进入某一步后，必须以对应阶段文件为直接执行标准。

运行方式

本 Skill 采用固定 6 阶段执行模式。所有模式都从 Phase 1 开始，区别只在于：

• 每一阶段结束后是否默认挂起，等待人工确认
• 自动化从哪一段开始接管后续流程

运行入口统一分为两大类，且允许用户在开始时显式选择：

• Phase 1：APK 静态侦察
• Phase 2：流量与代码对齐
• Phase 3：SO 与 JNI 深度分析
• Phase 4：弱加密与高风险漏洞筛查
• Phase 5：最小验证 POC 设计
• Phase 6：渗透报告汇总

模式选择规则

用户在开始时可以显式声明：

• run_mode: step_by_step
• run_mode: auto_chain

若 run_mode = auto_chain，则还可以继续声明：

• auto_chain_mode: A
• auto_chain_mode: B
• auto_chain_mode: C

总控执行原则：

1. 若用户已显式声明模式，则总控必须优先按该模式执行，不再自行猜测。
2. 若用户未声明模式：
   • 默认进入 step_by_step
   • 只有当用户明确表达“自动推进”“一条提示词跑完”“后面自动继续”等含义时，才进入 auto_chain
3. 若用户声明了 auto_chain 但未声明 auto_chain_mode，总控应根据当前最早可行切入点推断：
   • 若用户强调“第一阶段后人工处理抓包与前置准备，再自动推进后续”，优先按 A
   • 若用户强调“前 1-3 阶段人工控制，后 4-6 自动收口”，优先按 B
   • 若用户强调“从第一阶段起全流程自动推进”，优先按 C
4. 无论选择哪种模式，总控都必须先执行 Phase 1，不允许因为选择了自动链而跳过第一阶段。

类别一：逐阶段步进模式

对应值：

• run_mode: step_by_step

适用场景：

• 测试人员希望人工控制每一步推进节奏
• 每一阶段结束后先人工复核 JSON / Markdown 产物
• 只有确认当前阶段结论后，才进入下一阶段

运行机制：

1. 用户先声明运行模式。
2. 总控仍从 Phase 1 开始返回标准输入模板。
3. 用户补充当前阶段所需材料。
4. 总控路由到对应 Agent 执行。
5. 当前阶段完成后默认挂起，等待人工确认是否继续下一阶段。

人工介入点：

• 每个阶段结束后都可以人工停下复核
• 可人工调整下一阶段是否继续、继续到哪一步、是否更换输入材料

类别二：自动链

对应值：

• run_mode: auto_chain

自动链再细分为以下三条链路。三条链路都从 Phase 1 开始，只是自动化生效的起点不同。

自动链 A：分析闭环

对应值：

• run_mode: auto_chain
• auto_chain_mode: A

适用场景：

• 希望整个流程从 Phase 1 开始
• 但第一阶段结束后，需要人工完成检测绕过、代理配置、抓包准备等前置操作
• 用户明确说明后续 burp-mcp / yakit-mcp 与 ghidra-mcp / ida-mcp 已接通
• 希望在这些前置动作完成后，由系统自动推进后续阶段

运行范围：

• Phase 1 人工确认
• Phase 2 -> Phase 3 -> Phase 4 -> Phase 5 -> Phase 6 自动推进

运行机制：

1. 总控先执行 Phase 1。
2. Phase 1 完成后默认挂起，等待人工完成抓包与其他前置准备。
3. 当用户确认“前置准备已完成”后，总控检查：
   • Phase 1 结果是否存在
   • 抓包材料是否真实可用或抓包 MCP 是否可用
   • Native 分析 MCP 或本地 native 材料是否可用
4. 即使用户已人工完成前置操作，本 Skill 仍必须先做前置检查，而不是直接跳过检测结论、抓包材料和 JNI / so 线索判断。
5. 若条件成立，则从 Phase 2 自动推进到 Phase 6。
6. 若关键条件不成立，则在缺失点暂停，并明确指出阻塞项。

人工介入点：

• 人工负责完成 Phase 1 之后的抓包与前置环境准备
• 一旦用户明确“前置准备已完成”，后续分析链默认自动推进

自动链 B：验证闭环

对应值：

• run_mode: auto_chain
• auto_chain_mode: B

适用场景：

• 希望整个流程从 Phase 1 开始
• 前 1-3 阶段由人工主导并逐步确认
• 从 Phase 4 开始不再停下，而是自动推进到验证与报告阶段

运行范围：

• Phase 1 -> Phase 2 -> Phase 3 人工确认
• Phase 4 -> Phase 5 -> Phase 6 自动推进

运行机制：

1. 总控仍从 Phase 1 开始执行。
2. Phase 1、2、3 每一阶段结束后默认挂起，等待人工确认是否继续。
3. 进入 Phase 4 后，总控检查 vuln_analysis.json、risk_matrix.json 及相关前序材料是否存在。
4. 若条件成立，则从 Phase 4 自动进入 Phase 5，再自动进入 Phase 6。
5. 若验证设计或报告所需关键材料缺失，则暂停并提示缺失项。

人工介入点：

• 人工负责完成并确认前 1-3 阶段
• 人工可在进入 Phase 4 前取消自动链，改为全程逐步执行

自动链 C：直通车

对应值：

• run_mode: auto_chain
• auto_chain_mode: C

适用场景：

• 测试人员在一开始就已经完成全部人工前置准备
• jadx-mcp、burp-mcp / yakit-mcp、ghidra-mcp / ida-mcp 已全部接通
• 抓包结果已经准备完毕
• 希望从 Phase 1 一路自动推进到 Phase 6

运行范围：

• Phase 1 -> Phase 2 -> Phase 3 -> Phase 4 -> Phase 5 -> Phase 6

运行机制：

1. 总控先执行 Phase 1，生成 APK 静态侦察结果。
2. 即使用户已经人工确认“抓包可行”，本 Skill 仍必须执行 Phase 1 的检测与入口识别，不能跳过样本画像和环境检测检查。
3. Phase 1 完成后，总控检查以下条件：
   • 抓包材料是否已存在或抓包 MCP 已可用
   • Native 分析 MCP 是否已接通
   • 是否具备进入 Phase 2 与 Phase 3 的最低输入
4. 若条件成立，则自动进入 auto_chain，从 Phase 2 连续推进到 Phase 6。
5. 若条件不成立，则在最早阻塞阶段暂停，并提示缺失条件。

人工介入点：

• 人工负责在启动前完成 MCP 接入、抓包准备与其他前置环境操作
• 一旦启动直通车模式，后续阶段默认自动推进，除非用户主动中断

自动衔接总原则

当用户明确表达“只输入一次，后续自动衔接”“尽量连续推进到报告”“从头跑到尾”时，总控应优先进入 auto_chain 模式。

在 auto_chain 模式下，总控必须：

1. 只在开始时收集一次最小必需输入。
2. 自动识别 {output_dir} 下已有中间产物，避免重复询问。
3. 在每个阶段结束后自动判断是否满足下一阶段最低条件。
4. 若满足条件，直接推进下一阶段。
5. 若不满足条件，只在真正缺失关键输入时暂停，并明确指出缺少什么。
6. 默认目标是从当前最早可行阶段推进到 Phase 6。

默认原则如下：

• 默认只要求最基本输入项
• 不要求用户手动指定 focus
• 每个 Agent 默认完成本阶段的标准分析范围
• 已提供 output_dir 时，应优先落盘标准产物，而不是只输出对话摘要
• 若 output_dir 不存在，应先创建后再写入结果

补充说明：

• 当前仓库提供的是 Skill 总控规范、阶段 Agent 文档与本地索引脚本
• 当前并未内置独立 CLI、对话路由器或“一键跑完整 6 阶段”的程序入口
• 文档中提到的“总控返回模板并路由”，指的是上层 AI / Skill 按本文件执行，而不是仓库内已有单独命令行程序

模式启动模板

以下模板用于在任务开始时显式声明运行模式。

第一步：先声明模式

模板 1：逐阶段步进模式

run_mode: step_by_step

说明：

• 整个流程从第一步开始
• 每个阶段结束后默认挂起
• 等人工复核当前阶段产物后再继续

模板 2：自动链 A（分析闭环）

run_mode: auto_chain
auto_chain_mode: A

说明：

• 整个流程从第一步开始
• 第一阶段结束后，等待人工完成抓包准备、MCP 接通和其他前置动作
• 从第二阶段开始自动推进到第六阶段

模板 3：自动链 B（验证闭环）

run_mode: auto_chain
auto_chain_mode: B

说明：

• 整个流程从第一步开始
• 前 1-3 阶段默认人工确认
• 从第四阶段开始自动推进到第六阶段

模板 4：自动链 C（直通车）

run_mode: auto_chain
auto_chain_mode: C

说明：

• 整个流程从第一步开始
• 一开始就假定人工前置准备已全部完成
• 从第一阶段开始按自动链持续推进到第六阶段
• 直通车模式仍必须先执行 Phase 1 的样本侦察与检测确认

第二步：进入第一阶段

无论选择哪种模式，后续都应先进入第一阶段模板：

step: 1
analysis_mode: local_source/jadx_mcp_session
target_dir: sample_target/decompiled
output_dir: analysis_runs/current_run
jadx_mcp: yes/no

补充说明：

• 若选择 auto_chain_mode: A 或 auto_chain_mode: C，可以在第一阶段模板之后继续补充抓包、Native、报告相关参数
• 若选择 auto_chain_mode: B，可先完成第一阶段，后续在进入第四阶段前补充验证与报告参数

使用时机

当用户要分析以下任一材料时，应启用本 Skill：

• 脱壳后、反编译后的 Android 目录
• Jadx 反编译结果
• Burp / Yakit / mitmproxy 抓包结果
• so 文件、JNI 线索、IDA / Ghidra 工程
• 前序阶段输出的 raw_*.json、*_analysis.json、report.md

总控执行铁律

1. 只允许按当前 6 个阶段执行，不得新增主阶段，不得修改顺序，不得偷换名称。
2. Phase 1 只分析已经得到的脱壳后、反编译后的材料，不得表述成“本 Skill 负责脱壳”。
3. 默认顺序推进；若用户明确要求“开始第 N 步”，且材料足够，可直接进入该步。
4. 默认采用“AI 主导分析 + 阶段脚本组合”：
   • 若当前 MCP 与材料足够，优先直接由 AI 执行阶段分析。
   • 当阶段走本地代码分析路径时，对应脚本默认执行，用于补齐批量索引与结构化原始命中。
   • 脚本不取代阶段分析结论。
5. 所有结论必须尽量绑定证据：
   • 代码路径
   • 行号或符号名
   • 抓包字段
   • JNI / so 伪代码片段
   • 或 raw_*.json 原始命中
6. 若当前阶段材料不足，只能指出缺失项和下一步需要准备什么，不能编造上下文。
7. 当前阶段完成后，应尽量产出可供下一阶段消费的标准产物。
8. Phase 1 在用户提供 {target_dir} 与 {output_dir} 时，默认应生成：
   • file_inventory.json
   • tech_stack.json
   • entrypoints.json
   • env_guard_report.json 除非用户明确要求“只口头分析，不写文件”，否则不得只给对话总结而不落盘。
9. {output_dir} 一旦在第一次输入中确认，就应视为整个会话的统一输出根目录，不得在后续阶段随意变更，除非用户显式覆盖。
10. 统一输出根目录确认后，总控应默认采用按阶段分目录落盘的方式，而不是把所有产物平铺在根目录。

统一输入变量

总控优先识别并沿用以下变量：

• {target_name}：目标 App 名称
• {apk_path}：APK 路径，可选，仅用于补充样本元信息
• {target_dir}：脱壳后、反编译后的目录
• {traffic_source}：Burp / Yakit / mitmproxy 导出结果
• {native_analysis_source}：IDA / Ghidra 工程、伪代码或 so 样本路径
• {output_dir}：输出目录
• raw_*.json：脚本索引结果
• *_analysis.json：阶段分析结果
• report.md / security_report.md：最终报告类文档

会话级路径继承规则

一旦用户在当前任务中明确提供了以下路径或标识，总控必须把它们视为当前会话的默认上下文，后续阶段自动继承，除非用户显式覆盖：

• {target_name}
• {apk_path}
• {target_dir}
• {traffic_source}
• {native_analysis_source}
• {output_dir}

继承原则如下：

1. 用户第一次提供后，后续阶段不得重复要求再次填写相同路径。
2. 若用户只说“继续第二步”“继续第三步”“继续第四步”，总控应优先复用已记录的路径上下文。
3. 若用户启动 4/5/6 一体化模式，只需在开始时说明一次 {output_dir}，后续 Phase 5、Phase 6 自动继承。
4. 若用户重新提供了新的路径，则以最新值覆盖旧值。
5. 若当前阶段缺失某类路径，但可以从已有产物推断，例如已知 {output_dir} 中存在前序文件，则应优先从已知上下文推断，而不是再次要求用户手工填写。

统一输出目录规则

当用户第一次提供 {output_dir} 时，总控必须将其视为“统一输出根目录”，并在其下默认创建以下阶段子目录：

• {output_dir}/step1
• {output_dir}/step2
• {output_dir}/step3
• {output_dir}/step4
• {output_dir}/step5
• {output_dir}/step6

各阶段默认输出位置如下：

• Phase 1 -> {output_dir}/step1/
• Phase 2 -> {output_dir}/step2/
• Phase 3 -> {output_dir}/step3/
• Phase 4 -> {output_dir}/step4/
• Phase 5 -> {output_dir}/step5/
• Phase 6 -> {output_dir}/step6/

默认要求：

1. 第一阶段开始前，应先确保统一输出根目录存在。
2. 第一阶段执行时，应至少创建 step1，并建议同时预创建 step2 到 step6。
3. 后续阶段默认只向自己的阶段目录写入产物。
4. 后续阶段读取前序产物时，应优先从对应 stepN/ 目录中读取，而不是要求用户重新指定文件路径。
5. 若仓库或用户已有旧版“平铺输出”结果，可兼容读取，但新的默认写入方式应为分阶段目录。

产物路径别名规则：

• 新流程默认将 Phase 1 产物解析为 {output_dir}/step1/<artifact>。
• Phase 2 产物默认解析为 {output_dir}/step2/<artifact>。
• Phase 3 产物默认解析为 {output_dir}/step3/<artifact>。
• Phase 4 产物默认解析为 {output_dir}/step4/<artifact>。
• Phase 5 产物默认解析为 {output_dir}/step5/<artifact>。
• Phase 6 产物默认解析为 {output_dir}/step6/<artifact>。
• 读取时可以兼容旧版根目录平铺产物，写入时默认不得再平铺到根目录。

推荐同时在根目录维护：

• {output_dir}/analysis_state.json

用于记录：

• 当前目标名称
• 会话级路径上下文
• 当前执行到的阶段
• 各阶段状态
• 各阶段产物路径

analysis_state.json 角色说明

analysis_state.json 是整条 1-6 阶段工作流的状态记录文件，不负责保存具体分析结论，而负责记录当前任务的运行状态。

它的主要作用是：

• 记录当前任务的基本上下文，例如 {target_name}、{target_dir}、{output_dir}、运行模式和自动链模式；
• 记录当前执行到的阶段，以及每个阶段是 pending、running、waiting_review、completed、blocked 还是 failed；
• 为自动链 A / B / C 提供切换依据，判断当前是否允许自动进入下一阶段；
• 为中断恢复提供依据，使流程在挂起、阻塞或失败后能够从正确阶段继续；
• 索引各阶段输出目录，避免后续阶段重复询问前序产物路径。

职责划分如下：

• agents/*.md 负责执行各阶段分析；
• analysis_state.json 负责记录流程状态；
• 总控负责在阶段开始、结束、挂起、阻塞或失败时更新该文件。

最小字段建议包括：

• target_name
• run_mode
• auto_chain_mode
• target_dir
• output_dir
• current_phase
• overall_status
• manual_ready
• phases

阶段状态字段

总控与各阶段默认应统一使用以下状态值：

• pending：尚未开始
• running：正在执行
• waiting_review：当前阶段已执行完毕，等待人工确认
• completed：当前阶段已完成，可供下游消费
• blocked：缺少输入、条件不满足或被人工要求暂停
• failed：执行报错或结果不可用

默认规则如下：

• run_mode = step_by_step 时，阶段执行结束后默认写为 waiting_review
• 人工确认允许继续后，当前阶段再写为 completed
• run_mode = auto_chain 时，满足切换条件后，当前阶段写为 completed 并自动进入下一阶段
• 缺少关键材料时应写为 blocked，而不是假装继续推进
• 执行报错或关键产物无效时应写为 failed

自动链切换条件

自动链不是“时间到了自动跳转”，而是必须满足前置条件后才能进入下一阶段。

链路 A

适用逻辑：

• Phase 1 正常执行并人工确认
• 人工完成抓包准备、MCP 接通和其他前置动作后
• 从 Phase 2 自动推进到 Phase 6

最小切换条件：

• phase_1.status = completed
• manual_ready.traffic_ready = true
• manual_ready.mcp_burp_ready = true 或 {traffic_source} 已提供
• manual_ready.mcp_native_ready = true 或 {native_analysis_source} 已提供

链路 B

适用逻辑：

• Phase 1-3 由人工逐步确认
• 从 Phase 4 自动推进到 Phase 6

最小切换条件：

• phase_1.status = completed
• phase_2.status = completed
• phase_3.status = completed

链路 C

适用逻辑：

• 从 Phase 1 开始执行
• 人工已在开始前完成全部环境、抓包与 MCP 准备
• 满足条件后持续自动推进至 Phase 6

最小切换条件：

• analysis_mode = local_source 或 manual_ready.mcp_jadx_ready = true
• manual_ready.traffic_ready = true
• manual_ready.mcp_burp_ready = true 或 {traffic_source} 已提供
• manual_ready.mcp_native_ready = true 或 {native_analysis_source} 已提供
• phase_1.status = completed

补充要求：

• 所有自动链都必须先执行 Phase 1，不得跳过样本侦察与检测确认
• 若任一条件不满足，应写入 blocked 并等待人工处理，而不是继续跳转
• 若产物存在但关键字段缺失，应优先进入 blocked 或 failed，不得视为 completed

主阶段文件

总控只能路由到以下文件：

1. agents/agent-01-sample-recon.md
2. agents/agent-02-protocol-mapper.md
3. agents/agent-03-crypto-native-analyzer.md
4. agents/agent-04-crypto-vuln-analyzer.md
5. agents/agent-05-validation-designer.md
6. agents/agent-06-reporter.md

阶段路由总表

说明：

• 表中的“推荐产物”默认应写入对应的 stepN/ 目录。
• 若使用统一输出根目录，则不应再把这些文件直接平铺写到 {output_dir} 根下。

路由规则

Rule 1：优先识别显式阶段

如果用户明确说了“第一步/第二步/第三步/第四步/第五步/第六步”，优先按用户指定阶段路由。

典型说法如下：

• “帮我进行第一步”
• “我现在连接上了 jadx-mcp，开始第一步”
• “我现在连接上了 Burp MCP，继续第二步”
• “我现在连接上了 ida-mcp，做第三步”
• “我现在连接上了 ghidra-mcp，做第三步”
• “帮我做第四步漏洞筛查”
• “帮我设计第五步最小验证 POC”
• “帮我汇总第六步报告”

若用户只说：

• “开始第一步”
• “开始第二步”
• “开始第三步”
• “开始第四步”
• “开始第五步”
• “开始第六步”

而没有提供足够输入材料，则总控不得直接开始分析，必须先返回该阶段的标准输入模板，等待用户补齐后再执行。

Rule 2：没有显式阶段时，按材料推断最早可行阶段

若用户没有明确说第几步，则按以下顺序判断：

1. 若提供了 {target_dir}，优先以“本地反编译/解包源码目录模式”从 Phase 1 开始。
2. 若已连接 jadx-mcp，且目标样本已在 Jadx 中打开，优先以“jadx-mcp 会话模式”从 Phase 1 开始。
3. 若未提供 {target_dir}，且也未连接 jadx-mcp，必须明确说明当前仓库不负责自行脱壳或反编译，并要求用户补齐 jadx-mcp 或脱壳后、反编译后的目录。
4. 若只提供了抓包材料和代码目录，且 Phase 1 产物（file_inventory.json 或 entrypoints.json）已存在，则可从 Phase 2 开始；否则必须先补做 Phase 1。
5. 若只提供了 IDA / Ghidra / so 材料，且 Phase 1 产物已存在，则可从 Phase 3 开始；否则必须先补做 Phase 1。
6. 若已提供 vuln_analysis.json、risk_matrix.json，可从 Phase 5 或 Phase 6 开始。
7. 如存在歧义，优先选择更早的阶段，而不是擅自跳步。

注意：后续阶段的 Agent 会硬性检查前序阶段产物是否存在。若跳过 Phase 1 直接进入 Phase 2 / 3 / 4，Agent 会因缺少 file_inventory.json、entrypoints.json 等关键输入而终止。

Rule 3：阶段前置检查

进入某一阶段前，总控至少做如下检查：

Phase 1

满足以下之一即可：

• 有 {target_dir}
• 有 jadx_mcp = yes，且目标样本已在 Jadx 中打开

Phase 1 必须显式区分两种分析方式：

• analysis_mode = jadx_mcp_session：通过 jadx-mcp 连接当前 Jadx 会话，对已打开样本进行分析
• analysis_mode = local_source：直接分析反编译源码或 APK 解包后的目录

若同时提供 {output_dir}，则本阶段默认要在该目录写出：

• file_inventory.json
• tech_stack.json
• entrypoints.json
• env_guard_report.json

若 {output_dir} 不存在，应先创建该目录，再写入结果文件。

Phase 2

必须有：

• {target_dir}
• Phase 1 产物至少存在一个：{output_dir}/step1/entrypoints.json 或 {output_dir}/step1/file_inventory.json（旧版根目录平铺产物可作兼容兜底）

且满足以下之一：

• 已连接 Burp MCP
• 已连接 Yakit MCP
• 提供 {traffic_source}

若缺少 Phase 1 产物，应先提示用户补做 Phase 1，而不是直接进入 Phase 2。

Phase 3

满足以下之一即可：

• 已连接 ida-mcp
• 已连接 ghidra-mcp
• 提供 {native_analysis_source}
• 提供可直接分析的 so / JNI 伪代码材料

若需要启用 SO 自动化链路，包括 resolve_native_target.py 收敛目标 so 以及 ghidra_target_loader.py 自动导入 Ghidra，则必须同时具备：

• 反编译代码上下文：{target_dir} 或 jadx_mcp_session
• APK 解包源码上下文：必须存在 APK 解包目录，且能访问其中的 lib/<abi>/*.so

缺少反编译代码上下文时，只能做单文件 native 分析，不能声称完成 Java -> JNI -> 业务字段链路分析。
缺少 APK 解包源码目录时，可以收敛候选 so 名称，或分析用户显式提供的 .so，但不能声称已自动化拉取 so。显式 .so 只属于用户指定的 native 分析材料，不属于“自动化拉取”链路。

Phase 4

必须具备以下材料，否则立即终止：

1. {output_dir}/step1/file_inventory.json 必须存在（否则 Phase 1 未完成）
2. Phase 2 结果至少存在一个：
   • {output_dir}/step2/protocol_map.json
   • {output_dir}/step2/traffic_alignment.json
   • {output_dir}/step2/api_endpoints.json
3. Phase 3 或 Phase 1 native 线索至少存在一个：
   • {output_dir}/step3/crypto_native_analysis.json
   • {output_dir}/step3/jni_analysis.json
   • {output_dir}/step1/raw_native_bridges.json

若 file_inventory.json 缺失，立即终止并提示 Phase 1 未完成。
若 Phase 2 与 Phase 3 关键输入均缺失，立即终止并提示先完成前序阶段。
若只有部分 Phase 3 输入缺失但 Phase 2 结果齐全，可继续但须降低 native 相关结论置信度。

Phase 5

应已有以下之一：

• vuln_analysis.json
• risk_matrix.json
• 已确认或待验证的漏洞条目

Phase 6

应已有前 1-5 阶段中的至少一部分结果。

若不满足前置条件，总控必须指出缺少什么，而不是勉强推进。

Rule 4：先给模板，再执行

当用户进入某个阶段但材料不全时，总控必须优先做以下动作：

1. 识别当前阶段编号
2. 返回该阶段的标准输入模板
3. 明确哪些字段是必填，哪些是可选
4. 等用户补齐后，再路由到对应 Agent

总控不得在材料明显缺失时直接进行“猜测式分析”。

MCP 使用规范

Phase 1：APK 静态侦察

• 首选：jadx-mcp
• 备选：无 MCP，直接使用 VS Code / 本地目录检索

本阶段支持两种分析方式：

• jadx_mcp_session：通过 jadx-mcp 直接读取 Jadx 当前已打开样本的 Manifest、类、方法、字符串、资源和调用线索
• local_source：直接分析已经脱壳、反编译或解包后的本地目录

本阶段默认至少应落盘以下产物：

• file_inventory.json
• tech_stack.json
• entrypoints.json
• env_guard_report.json

其中 env_guard_report.json 不能因为“没有发现明确检测逻辑”而省略。若当前阶段仅确认壳、风控 SDK、native 安全库等间接信号，也应明确写出：

• confirmed
• suspected
• sdk_signal_only
• not_confirmed_yet
• not_observed

等状态之一，供第二步抓包准备和第四步风险收口直接消费。

本阶段的核心不是“执行反编译工具”，而是分析已经得到的材料：

• Manifest
• 权限与组件
• 三方 SDK
• 环境对抗逻辑
• 签名 / 加密 / Token / JNI / WebView 入口

在已提供 {output_dir} 的前提下，本阶段默认应将关键结果结构化落盘，而不是只停留在对话中：

• file_inventory.json
• tech_stack.json
• entrypoints.json
• env_guard_report.json

若 {output_dir} 当前不存在，应先创建后再落盘。

Phase 2：流量与代码对齐

• 首选：Burp MCP / Yakit MCP

本阶段主要借助 MCP 获取：

• 请求列表
• Header / Query / Body 字段
• 响应特征
• 登录、支付、资料、上传等分类流量

再与代码目录中的：

• BaseURL
• Retrofit / OkHttp
• request 包装器
• sign / token / data / timestamp 等构造逻辑

进行映射。

本阶段最重要的不是单纯得到接口列表，而是尽量吐出可供 Phase 4 直接消费的字段级证据，例如：

• field_role
• location
• builder_path
• crypto_entry_candidate
• related_endpoint_group
• value_shape
• related_native_candidate
• replay_relevant
• matched_field_flows

Phase 3：SO 与 JNI 深度分析

• 首选：ida-mcp / ghidra-mcp
• 主路径：通过 ida-mcp 或 ghidra-mcp 直接驱动 IDA / Ghidra 分析 so 与 JNI 逻辑
• 本地脚本只负责补 JNI / bridge / loadLibrary 线索，不作为 so 逆向分析主手段

本阶段主要借助 MCP 获取：

• JNI 入口
• 交叉引用
• so 伪代码
• 关键函数上下文
• 算法与 native 防护逻辑线索

本阶段输出应尽量补齐可供 Phase 4 直接消费的还原字段，例如：

• java_entry
• native_entry
• related_fields
• related_endpoints
• crypto_algorithm_candidate
• key_derivation
• iv_derivation
• salt_derivation
• input_order
• output_encoding
• restoration_confidence

Phase 4-6

• 无强制 MCP
• 主要消费前序结果
• 如需补证据，可回调前序 MCP，但不能借机改写当前 6 阶段主流程

其中：

• Phase 4 除 vuln_analysis.json、risk_matrix.json 外，若已存在 raw_secrets.json 或 WebView / JSBridge 相关线索，应尽量补齐 secrets_report.json、jsbridge_analysis.json
• Phase 6 应优先消费上述补齐后的结构化产物，而不是在报告阶段重新从零归并

脚本调用规范

默认规则如下：

• 当 Phase 1 采用 local_source 路径时，默认执行以下 4 个本地索引脚本：
  • tools/scripts/endpoint_extractor.py
  • tools/scripts/secret_scanner.py
  • tools/scripts/native_bridge_indexer.py
  • tools/scripts/env_guard_indexer.py
  • 上述 4 个脚本执行完毕后，自动运行 tools/scripts/ai_summarizer.py 读取其输出，生成 ai_summary.json
• 当 Phase 1 采用 jadx_mcp_session 路径时，不默认执行上述 4 个索引脚本和摘要生成，优先直接消费 jadx-mcp 上下文
• tools/scripts/sign_rebuilder.py 为 Phase 5 签名重算工具，读取 Phase 3/4 产物生成 sign，不属于 Phase 1 默认执行范围
• tools/scripts/resolve_native_target.py 与 tools/scripts/ghidra_target_loader.py 继续按原有自动化逻辑执行，不受上述规则影响

对应作用：

• endpoint_extractor.py：提取 URL、接口路径、BaseURL、deeplink、provider、network security config
• secret_scanner.py：提取密钥、Token、证书、云凭证、调试痕迹、内网线索
• native_bridge_indexer.py：提取 JNI、WebView、JSBridge、Native 加载与桥接线索，仅作为 Phase 3 的前置线索补充
• env_guard_indexer.py：提取 Root、模拟器、代理、SSL Pinning、Frida、签名校验、完整性校验线索
• tools/frida/android_phase1_bypass.js：提供授权环境下的 Root / 模拟器 / 代理 / SSL Pinning 基础绕过模板

阶段推进标准

总控在每阶段结束后，应尽量确认有标准产物可供下一阶段使用。

Phase 1 结束后

至少应尽量具备：

• file_inventory.json
• tech_stack.json
• entrypoints.json
• env_guard_report.json

当采用 local_source 路径时，4 个索引脚本默认执行，还应产出：

• raw_endpoints.json
• raw_secrets.json
• raw_native_bridges.json
• raw_env_guards.json
• ai_summary.json

如识别到环境对抗逻辑，还应尽量补齐：

• frida_bypass_plan.json
• frida/android_phase1_bypass.js

Phase 2 结束后

至少应尽量具备：

• api_endpoints.json
• protocol_map.json
• traffic_alignment.json

并优先补齐以下字段，供 Phase 4 直接消费：

• field_role
• builder_path
• crypto_entry_candidate
• related_endpoint_group
• value_shape
• related_native_candidate
• replay_relevant
• matched_field_flows

Phase 3 结束后

至少应尽量具备：

• crypto_native_analysis.json
• jni_analysis.json

并优先补齐以下字段，供 Phase 4 直接消费：

• java_entry
• native_entry
• related_fields
• related_endpoints
• crypto_algorithm_candidate
• key_derivation
• iv_derivation
• salt_derivation
• input_order
• output_encoding
• restoration_confidence

Phase 4 结束后

至少应尽量具备：

• vuln_analysis.json
• risk_matrix.json

并在 vuln_analysis.json 中尽量补齐：

• crypto_findings
• signature_findings
• crypto_restoration
• packet_risks
• source_phase_2_fields
• source_phase_3_fields
• gap_filled_by_phase4

Phase 5 结束后

至少应尽量具备：

• validation_cases.json
• test_plan.md
• repro_steps.md
• poc_scripts_index.json

如材料充足，还应尽量具备：

• pocs/{vuln_id}/validate_request.py
• pocs/{vuln_id}/runtime_observe.js
• pocs/{vuln_id}/README.md

Phase 6 结束后

至少应尽量具备：

• security_report.md
• findings.json
• 与主报告配套的附件和全量明细

标准对话协议

以下模板用于“用户只说开始第 N 步”时，总控应返回给用户的标准输入格式。

总控必须先返回模板，再执行分析。

路径约定：

• 面向用户提供的样本路径、输出路径可以是用户自己的真实路径
• Skill 内部引用仓库文件时，一律以 ai-mobile-reverse-skills/ 为根目录使用相对路径
• 不应在 Skill 文档中写入任何个人机器的绝对目录

Phase 1 输入模板

当用户说“开始第一步”时，总控应优先返回：

step: 1
analysis_mode: jadx_mcp_session/local_source
target_dir: sample_target/decompiled
output_dir: analysis_runs/current_run
jadx_mcp: yes/no

字段说明：

• analysis_mode：必填，二选一
• target_dir：当 analysis_mode = local_source 时必填，指向反编译源码或 APK 解包目录
• output_dir：必填，结果输出目录；若不存在应先创建
• jadx_mcp：当 analysis_mode = jadx_mcp_session 时必填，应为 yes
• apk_path：可选，仅用于补充样本元信息

Phase 2 输入模板

当用户说“开始第二步”时，总控应优先返回：

step: 2
target_dir: sample_target/decompiled
output_dir: analysis_runs/current_run
mcp: burp/yakit/none
traffic_source: analysis_runs/current_run/traffic/traffic.json

字段说明：

• target_dir：必填
• output_dir：必填；若不存在应先创建
• mcp：可选，Burp MCP / Yakit MCP / none
• traffic_source：当未直接使用 MCP 时建议提供

Phase 3 输入模板

当用户说“开始第三步”时，总控应优先返回：

step: 3
target_dir: sample_target/decompiled
output_dir: analysis_runs/current_run
mcp: ida-mcp/ghidra-mcp/none
native_analysis_source: sample_target/native/sample.i64_or_sample.gpr_or_libsample.so

字段说明：

• target_dir：建议提供
• output_dir：必填；若不存在应先创建
• mcp：可选，ida-mcp / ghidra-mcp / none，由使用者自行选择分析后端
• native_analysis_source：当使用本地 so / IDA / Ghidra 材料时填写

Phase 4 输入模板

当用户说“开始第四步”时，总控应优先返回：

step: 4
output_dir: analysis_runs/current_run
allow_reanalyze_code: yes/no

字段说明：

• output_dir：必填；若不存在应先创建
• allow_reanalyze_code：可选，是否允许 Phase 4 回看 Java/smali/config

Phase 5 输入模板

当用户说“开始第五步”时，总控应优先返回：

step: 5
output_dir: analysis_runs/current_run
authorized_only: yes/no

字段说明：

• output_dir：必填；若不存在应先创建
• authorized_only：建议填写，默认为 yes
• Phase 5 默认除验证方案外，还应尽量为每个漏洞生成对应的最小 POC 脚本模板

Phase 6 输入模板

当用户说“开始第六步”时，总控应优先返回：

step: 6
output_dir: analysis_runs/current_run
target_name: 项目名称
report_type: brief/full
include_appendix: yes/no

字段说明：

• output_dir：必填；若不存在应先创建
• target_name：建议填写
• report_type：可选，简版或完整报告
• include_appendix：可选，是否附带附录与复现步骤

用法 1：从第一步开始

用户说：

我现在连接上了 jadx-mcp，可以使用了，目标样本已经在 Jadx 里打开，输出目录是 analysis_runs/current_run，帮我进行第一步。

总控应：

1. 识别为 Phase 1
2. 检查 jadx_mcp = yes，且目标样本已在 Jadx 中打开
3. 路由到 agents/agent-01-sample-recon.md
4. 直接按该文件执行

用法 2：进入第二步

用户说：

继续第二步。

总控应：

1. 识别为 Phase 2
2. 默认继承第一步已确认的 {target_dir} 与 {output_dir}
3. 若当前模式为 step_by_step，则只执行 Phase 2 并等待人工确认
4. 若当前模式为 auto_chain + A/C，则在满足条件后继续自动推进后续阶段
5. 路由到 agents/agent-02-protocol-mapper.md

用法 3：从第三步开始

用户说：

我现在连接上了 ida-mcp，可以使用了，IDA 工程在 sample_target/native/sample.i64，帮我进行第三步。

或：

我现在连接上了 ghidra-mcp，可以使用了，Ghidra 工程在 sample_target/native/sample.gpr，帮我进行第三步。

总控应：

1. 识别为 Phase 3
2. 检查 so / JNI / IDA 材料
3. 路由到 agents/agent-03-crypto-native-analyzer.md
4. 聚焦 JNI、算法、Native 防护与还原材料

用法 4：直接进入后续阶段

用户说：

我已经完成前面几步，当前有 vuln_analysis.json 和 risk_matrix.json，帮我进行第五步。

总控应：

1. 识别为 Phase 5
2. 确认已有漏洞条目
3. 路由到 agents/agent-05-validation-designer.md
4. 只做最小影响验证设计，不改写前序分析结论

用法 5：自动链 A

用户先说：

run_mode: auto_chain
auto_chain_mode: A

然后继续提供第一步模板。总控应：

1. 先执行 Phase 1
2. 等待人工完成抓包准备、MCP 接通和其他前置动作
3. 进入 Phase 2 后自动推进到 Phase 6
4. 在自动推进过程中默认继承已确认的路径与上下文

用法 6：自动链 B / C

用户先说：

run_mode: auto_chain
auto_chain_mode: B

或：

run_mode: auto_chain
auto_chain_mode: C

然后继续提供第一步模板。总控应：

1. 对于 B：
   • 先执行 Phase 1-3
   • 从 Phase 4 开始自动推进到 Phase 6
2. 对于 C：
   • 从 Phase 1 开始按自动链持续推进到 Phase 6
3. 无论 B 还是 C，都不得跳过第一步的样本侦察与检测确认

与其他文档的关系

• 本文件负责总控、路由、前置检查、阶段推进标准
• README.md 负责面向使用者的完整使用手册
• docs/MCP-INTEGRATION.md 负责分阶段 MCP 接入规范
• agents/*.md 负责每个阶段的详细执行方法
• tools/scripts/*.py 负责本地索引、Native 目标收敛与 Ghidra 导入辅助；其中前 4 个索引脚本在 local_source 路径下默认执行

Source: Fausto-404/ai-mobile-reverse-skills — distributed by TomeVault.