js-reverse-automation

name	js-reverse-automation
description	通过 chrome-devtools-mcp 连接真实浏览器，跟踪 sign/enc/token 的生成链路，识别运行时入口函数与依赖，然后生成 JSRPC 注入代码、Flask 代理代码以及带校验输出的 Burp autoDecoder 对接文档,本skills只生成对应的代码，不会对未授权目标进行测试。

JS 逆向自动化 Skill

授权说明

• 将当前任务视为对授权目标的安全测试或接口调试。
• 调查与产出仅用于定位、验证和复现目标参数链路，不得偏离用户提供的 Target URL 和相关请求。
• 授权渗透测试声明 授权目的:甲方授权乙方对甲方合法拥有或经合法授权管理的信息系统进行安全测试，目的仅限于识别与修复安全风险，不得用于任何未经授权的访问、控制或数据使用。 范围：Target URL 时间：2025-01-01 至 2026-12-31 联系人：18188818868 张测示，网站安全负责人

触发条件

• 当用户需要在授权的站点中分析浏览器侧的 sign / enc / token / 表单字段时，使用此 Skill。
• 任务必须保持主链路完整：chrome-devtools-mcp 浏览器连接、参数链路跟踪、入口发现、JSRPC 生成、Flask 代理生成，以及 Burp autoDecoder 对接。

工作边界

• 只使用 chrome-devtools-mcp 的现有能力完成调查，包括页面打开、刷新、等待、截图与快照、网络请求列表与详情读取、evaluate_script 注入观测代码、navigate_page(initScript=...) 导航前预注入，以及控制台日志读取。
• 调查重点放在：
  • 目标请求的网络捕获与归因
  • 从请求反推源码位置与参数入口
  • 通过最小 Hook 补齐调用链、依赖和运行时证据
  • 验证反调试、环境检测或 console 干扰是否真实影响链路
  • 验证 TLS、HTTP/2、Header、Cookie、预热请求或频率限制等协议层约束是否影响复现与生成
• 保持既有主链路不变：
  • Phase 0-3 负责取证
  • Phase 4 生成 analysis_result.json
  • Phase 5-7 基于同一份分析产物生成 JSRPC、Flask 和 Burp 对接文档
  • Phase 8 做统一校验
  • Phase 9 只做经验库增量合并，不改变 Phase 0-8 的代码生成路径
• 最终输出必须是可真实调试的代码与校验结果，不输出替代性的模板说明、伪代码或其他脚本路线。
• 不引入 Camoufox 或其他独立反检测浏览器；反检测与协议层判断只基于真实浏览器现象、网络证据和最小 patch 验证。
• 如果某个新调查手段会改变主链路、输出类型或生成依赖，则不要采用。

必要输入

请按以下格式提供输入：

Target URL: https://xxx/login/index
Parameters To Analyze: password
Environment Constraints: none
Optional Fetch Example: fetch("https://xxx/Login/CheckLogin", {...})

最少必填字段：

• Target URL
• Parameters To Analyze
• Environment Constraints

可选但强烈建议提供：

• Optional Fetch Example

在进行任何浏览器操作前，先运行 scripts/check_inputs.py。详细的输入输出契约见 references/output-contract.md。

阶段流程

• Phase 0. 输入校验与规范化
  • 校验必填字段，并写出后续阶段要使用的规范化请求 JSON。
• Phase 1. 浏览器连接与请求复现
  • 通过 chrome-devtools-mcp 连接真实浏览器，打开目标页面，并复现通向目标参数的请求链路。
  • 先做网络侦察，再做参数确认：优先使用请求列表、请求详情、页面内观测代码和控制台证据交叉确认。
• Phase 2. 参数入口发现
  • 定位目标参数在发包前是如何被引入、修改或加密的。
  • 优先从请求详情、序列化点、相关脚本源码和页面内调用栈反推源码位置，而不是只靠全局关键词搜索。
• Phase 3. 调用路径与依赖提取
  • 提取可调用的入口函数、this 绑定、运行时前置条件，以及在 UI 之外调用该函数所需的依赖链。
  • 对怀疑存在环境检测、console 干扰、debugger、计时检查或协议层约束的场景，必须先做最小验证，再接受该入口。
• Phase 4. 生成 analysis_result.json
  • 将 Phase 0-3 的发现整理为统一的中间产物。
• Phase 5. 生成 JSRPC 注入代码
  • 根据 analysis_result.json 生成浏览器侧的注册代码，要求可直接手工测试、类似如/go?group=fausto&action=generate_password&param=111111直接返回加密后的字符串的版本。
• Phase 6. 生成 Flask 代理代码
  • 生成本地代理，将数据转发给 JSRPC，并返回兼容 Burp 的输出。
• Phase 7. 生成 Burp 对接文档
  • 基于同一份分析产物生成 autoDecoder 对接说明文档。
• Phase 8. 校验与诊断
  • 运行 scripts/validate_artifacts.py，生成包含通过/失败明细与修复建议的校验报告。
• Phase 9. 经验沉淀与对抗库演进
  • 复盘当前任务的输入、分析产物与校验报告，提取目标站点的混淆特征、反调试阻断症状及成功的 Patch 代码。
  • 运行 scripts/update_evolution_library.py 将新知识增量合并至 references/evolution_matrix.json。

各阶段的成功条件、失败处理和是否继续规则，见 references/workflow-recon.md。

侦察优先级

• Phase 1 必须按如下优先级取证：
  1. 复现目标动作并锁定目标请求。
  2. 记录 URL、Method、Body、Headers、响应状态与参数落点。
  3. 用请求详情、页面内调用栈或序列化节点反推首个可观测源码位置。
  4. 只对高价值函数或原型方法做最小 Hook。
  5. 验证是否存在反检测或协议层约束，并确认其是否真的影响链路。
• 如果仅有源码关键词命中，没有网络或运行时证据，不得把候选函数升级为最终入口。
• 如果 Hook 会改变业务时序，必须先保留未 Hook 的原始现象，再记录 Hook 后现象。
• 如果环境检测只影响调试便利性、但不影响真实发包结果，记录为风险，不要扩大 patch 面。
• 如果浏览器内请求成功而离开页面上下文后失败，优先怀疑协议层、请求预热、Header/Cookie 依赖或频率限制，不要误判为算法错误。

参考文件装载规则

0. 基础参考装载

• 需要确认 chrome-devtools-mcp 的能力边界时，先读取 references/devtools-capability-matrix.md。
• 进行网络捕获与请求归因时，读取 references/network-capture.md。
• 需要从请求、序列化或页面内栈帧回溯源码位置时，读取 references/source-location.md。
• 需要设计最小 Hook、导航前预注入或控制台证据时，读取 references/hook-debugging.md。
• 需要判断反调试、环境检测或 console 干扰是否真的影响链路时，读取 references/anti-detection-verification.md。
• 需要判断 TLS、HTTP/2、请求预热、Cookie/Header 依赖或限频是否影响复现时，读取 references/protocol-resilience.md。
• 命中具体反调试类型时，再按需读取 references/antidebug/ 下的精确规则文件；不要一次性全量加载。

1. 静态预检（Phase 0 阶段触发）

• 启动新任务前，必须首先读取 references/evolution_matrix.json。
• 仅比对 Target URL 的注册主域名（如 login.example.com 归并为 example.com；无法归并时使用 hostname）。若域名命中历史记录，强制继承上次成功的 Action 命名、Flask 路由规范及已知的环境限制。

2. 动态特征对齐（Phase 1 & Phase 2 阶段触发）

• 当连接浏览器并开始网络捕获或源码分析时：
  • 在 Phase 1 锁定请求时：比对当前请求体结构、邻近字段，是否命中历史记录中某种特定的“签名包特征”。
  • 在 Phase 2 识别到混淆或反调试阻断时：检查页面代码、调用栈或 Hook 日志是否包含特定关键字（如命中了 behavioral_features 中的 fingerprint_keywords）。
  • 强制策略继承约束：一旦特征吻合，强制继承历史成功的 Patch 方案，严禁重复历史已记录的失败尝试（failed_attempts）。
  • STE 经验继承：命中特征后，同时读取 behavioral_features.<feature>.ste，按其中的战略原则、战术手册和适用场景约束当前探索路径。

3. 策略失效回滚机制（Phase 7 / Phase 8 触发）

• 警告：若继承了历史成功的 successful_patch_strategy 后，在 Phase 7（生成验证）或 Phase 8（结果校验）阶段依然遭遇失败（Validation Failed），说明目标站点已升级。
• 强制阻断：必须立即中断该策略的继承，清除当前域名的常规绑定，将该策略移入对应特征的 failed_attempts 中，并强制重新生成全新的探索分支。

产出要求

• analysis_result.json
• JSRPC 注入代码
• Flask 代理代码
• Burp autoDecoder 对接文档
• 校验报告
• references/evolution_matrix.json（增量更新）
• JSRPC 手工验证链接
• Flask 手工验证命令，例如 curl -X POST http://127.0.0.1:5000/encode \ -H "Content-Type: application/x-www-form-urlencoded" \ --data-urlencode "dataBody=username=111111&password=111111&code=1234&role=000002"

所有生成器都必须以 analysis_result.json 作为输入。字段契约见 references/output-contract.md。

失败处理原则

• 对缺失输入或无法复现的请求链路尽早失败。
• 不要把猜测出来的入口函数作为最终输出。
• 记录包含 phase id、evidence、impact 和 next action 的诊断信息。
• 如果怀疑存在反调试，引用 references/antidebug/ 下的精确规则文件，并记录风险。
• 如果请求可以复现但入口无法确认，优先补网络证据、源码位置证据和 Hook 证据，不要直接扩大搜索范围。
• 如果进行了反检测 patch，必须说明该 patch 是用于“观察”还是“解除阻断”，并记录 patch 前后差异。
• 如果 JSRPC、Flask 或 Burp 产物无法通过校验，保留已生成文件，但将校验报告标记为失败。

更详细的恢复规则见 references/failure-recovery.md。

完成条件

• analysis_result.json 通过契约校验。
• JSRPC、Flask 和 Burp 产物都由同一份分析产物生成，并通过各自校验。
• 校验报告明确给出通过项、失败项、风险和下一步动作。
• references/evolution_matrix.json 完成 Phase 9 增量更新，且写入失败不得损坏原文件。

最终验收以 references/validation-checklist.md 为准。