web-js-reverse-master-flow

# Web JS Reverse Master Flow ## 角色 这个 skill 是复杂 Web/JS 逆向项目的总控入口。 它不替代专项 skill，而是负责： - 归一化当前任务阶段 - 选择下一步最合适的专项 skill - 约束切换顺序，避免“还没坐实请求链就去补环境”这类误操作 - 输出当前阶段、阻塞点、下一份必须更新的工具 默认情况下，复杂网站还原一律从这个 skill 起手，而不是直接并行触发多个总控 skill。 职责边界： - 这个 skill 始终是宏观总控，不下沉成某个厂商、某个站点或某种壳的案例库。 - 即使出现 `Akamai/Kasada/PX/reese84/同盾/a_bogus/腾讯滑块/阿里滑块/JSVMP/227/226/wasm/protobuf/rid/fuid/fs/bx-pp/run_js/storage.estimate/animationend` 这类强线索，也只是帮助预路由，不改变它“先判阶段、后选专项”的总控角色。 - 具体站点、厂商和技术经验，应交给 `$1997-pro-web-reverse-casebook` 或其他专项 skill 提供。 如果现场线索已经明显命中某类公开案例，应同步加载 `$1997-pro-web-reverse-casebook` 做案例预路由，但阶段选择仍由本 skill 决定。 ## MCP 栈 这个 skill 默认采用三 MCP 协同，不把它们视作可选项： - `chrome-devtools-mcp` 负责浏览器接管、页面级调试、Network/DOM/Runtime/CDP 断点与调用栈观察，是最直接的现场取证面。 - `js-reverse` 负责逆向工作流级别的源码搜索、Hook、断点、代码采集、运行时证据沉淀、WebSocket/Storage/Session 状态分析。 - `jshook` 负责更重的 JS 逆向分析、反混淆、Stealth、Hook、浏览器自动化、调试器与代码理解增强。 使用规则： - 先用 `chrome-devtools-mcp` 和 `js-reverse` 拿真实样本与现场证据。 - 进入重混淆、恢复语义层或高级 Hook/Stealth 阶段时，再显式引入 `jshook`。 - 不允许只凭静态阅读跳过浏览器现场证据。 - 不允许在没有浏览器基线样本时直接讨论 Node 迁移。 ## 输入块 从以下输入开始： ```text URL 或目标页面： 目标请求 / 字段 / cookie / 消息： 触发动作： 当前现象： 已有证据： 目标： 约束： ``` 先补齐输入，再决定阶段。 ## 总原则 - Hook-first, Breakpoint-second, Full-dump-last。 - 先证明真实请求链，再讨论纯算、补环境或重放。 - 先恢复语义层，再迁运行时，不要反过来。 - 运行时差分优先于盲补环境。 - 每次只扩大一个变量：一个 hook 点、一个样本、一个补丁、一个分支判断。 - 任何结论都要附带运行时证据或中间态检查点。 - 案例锚点只能帮助预路由，不能代替证据门与阶段判定。 ## Anti-Spiral Protocol 这个 skill 的首要目标之一，是防止在难站点里陷入“长时间没有证据增量的深挖漩涡”。 以下任一情况出现时，视为已经开始打转： - 连续多轮都在同一层做相似操作，但没有新增请求链、写入边界、状态载体或检查点 - 不断追加 Hook / 断点 / patch，却解释不了第一个真实分叉 - 花大量时间 beautify / AST 变换，但仍然没把逻辑绑回真实 sink - 本地补环境越补越大，却说不清到底是哪一个对象或状态在影响结果 - 只盯最终值，不再比较中间态 强制规则： - 同一阶段连续两轮没有新增证据，必须切换动作，不允许第三次重复同类操作。 - 同一问题连续六轮仍无收敛，必须停止当前打法，升级到下一层策略。 - 任何升级都必须写明：为什么当前打法失败、下一步准备验证什么、放弃了哪些假设。 允许的升级方向只有这些： - `locate` 卡住：扩大真实触发范围、改抓 initiator、改用断点栈或浏览器侧调用 - `recover` 卡住：降低恢复深度、退回 `locate` 重新坐实边界，或改 black-box reuse - `runtime` 卡住：回退到第一个稳定浏览器快照，重建分叉表，再只 patch 一个状态面 - `env-patch` 卡住：停止继续补对象，改走浏览器辅助执行、远程调用或最小代理方案 禁止： - 在没有新证据时继续加大 dump 范围 - 在没证明 builder / writer 边界前做全量反编译 - 在没证明首个分叉点前做全量浏览器环境迁移 - 用“这个站很难”代替阶段判断和停止深度判断 ## 案例锚点预路由 以下线索出现时，不要先猜算法；先把它们映射到更可能的阶段： - 厂商 / 产品锚点： - `Akamai`、`Kasada`、`PX`、`PX3`、`reese84`、`Incapsula`、`同盾`、`BlackBox`、`a_bogus` - 默认怀疑：`Phase 1` 的请求链 + `Phase 3` 的风控 / 指纹 / 挑战分叉 - 字段 / 协议锚点： - `rid`、`protobuf`、`x-s3-s4e`、`desc`、`bx-pp` - 默认怀疑：`Phase 1` 的 builder / writer 边界，必要时进入 `Phase 2` 看 `wasm` / 封装桥 - 验证码 / 业务锚点： - `腾讯滑块`、`阿里滑块`、`_rand`、`fuid`、`fs` - 默认怀疑：位置链与加密链双线并存，通常会同时触发 `Phase 1`、`Phase 3` - 壳层锚点： - `JSVMP`、`227`、`226`、`while(true)+switch`、`dispatcher`、`basearr` - 默认直接怀疑 `Phase 2` - 运行时锚点： - `run_js`、`storage.estimate`、`animationend`、`postMessage`、`worker` - 默认先做 `Phase 3` 的运行时差分，再决定是否进入 `Phase 4` 如果这些线索同时出现，优先顺序固定为： `证据门 -> 写入边界 -> 壳层恢复(必要时) -> 运行时差分 -> Node 迁移` ## 主流程 ### Phase 0: 证据门 目标： - 证明目标请求、字段和触发动作都来自真实样本，而不是猜测。 要做： - 先按 `$mcp-js-reverse-playbook` 跑最小链路。 - 强制使用 `chrome-devtools-mcp` 或 `$js-reverse` 建立浏览器基线样本。 - 创建或刷新 `reverse-records/总览.md`。 - 如果请求链、状态链、样本链还不完整，立即创建或刷新 `reverse-records/请求链路.md`。 退出条件： - 至少有一条真实样本链。 - 目标字段或消息已由真实请求证明。 禁止： - 目标请求还没坐实就开始补环境。 - 目标字段还没坐实就直接做算法还原。 卡住信号： - 只能说“怀疑是某个参数 / 某个脚本”，但拿不出真实请求样本 - 触发动作不稳定，重复操作拿不到同一条链 必切动作： - 回到最小触发动作，重新抓一条干净样本 - 若页面脚本太乱，优先用 `chrome-devtools-mcp` 的 Network / 调用栈现场，而不是先读源码 ### Phase 1: 写入边界与请求链 主 skill： - `$find-crypto-entry` - `$jsr-locate` - 搜不到时可加 `$js-reverse-trace-hook` MCP 优先级： - `chrome-devtools-mcp`：Network、DOM 触发点、调用栈与断点现场 - `js-reverse`：请求 initiator、Hook、代码采集、storage/session/websocket - `jshook`：当普通搜索/断点不足以稳定定位时，补充更重的 Hook 与逆向分析 目标： - 找到真实 sink、`entry -> builder -> writer` 关系和上游依赖链。 适用： - 参数名明确。 - 请求链还没完全闭合。 - 怀疑有 `Set-Cookie`、挑战、session、response-driven 依赖。 退出条件： - 最终写入边界已坐实。 - 当前阻塞已经从“找链”变成“代码读不懂/壳太重/运行时分叉”。 切换到 Phase 2 的信号： - `while(true) + switch` - 大量花指令、真假分支 - `JSVMP` - `227/226/basearr/opcode/ip/g` - `worker/wasm/webpack runtime` - `_0x` 字符串表、动态 `eval/Function` - `LL()[XX(XX)]()`、多套字符串解密器、动态回填字符串 - `Akamai/Kasada/PX` 类动态字符串与桥接壳 - `bx-pp`、`rid`、`protobuf builder` 的真实 builder 被 dispatcher 遮住 - 只能看到 dispatcher，看不到真实 builder 卡住信号： - 能看到目标值，但无法说明是谁最后写入 - Hook 命中很多函数，但没有一个能稳定回到真实请求 - 反复在同一 bundle 搜关键词，没有把字段绑到请求边界 必切动作： - 改抓请求 initiator 与调用栈，不继续盲搜源码 - 把问题收缩到 `entry -> builder -> writer` 三段，不再讨论全链路 - 若 builder 被壳遮蔽，立即切 `Phase 2` ### Phase 2: 壳层恢复与重混淆压缩 主 skill： - `$jsr-recover` 补充 skill： - `$js-controlflow-truth-sampling-prune` - `$js-ast-binding-alias-deobf` MCP 优先级： - `js-reverse`：collect_code、trace、断点、Hook、源码级证据 - `jshook`：反混淆、Stealth、复杂 Hook、调试器控制、脚本级语义压缩 - `chrome-devtools-mcp`：保留浏览器现场，验证 dispatcher/bridge 在真实页面中的执行路径 目标： - 把壳压到“足以继续 locate / runtime / replay”的程度，而不是一次性全还原。 要做： - 识别 container、dispatcher、state carrier、bridge、core operator、write-back layer。 - 对平坦流或 dispatcher 做真实样本裁剪。 - 只恢复当前任务需要的最小 slice。 - 对 `JSVMP/227/226` 至少补齐：入口、状态变量、关键 `opcode` 家族、桥接合同。 - 对 `wasm` 至少补齐：下载点、实例化方式、imports、exports、JS 到 wasm 的调用桥。 - 对 `Akamai/Kasada/PX` 类重混淆，先冻结样本，再提字符串解密映射与最小执行片段。 退出条件： - 下游工作不需要重新扒开同一层壳。 - 已能回到 `$jsr-locate` 坐实 sink，或进入 `$jsr-runtime` 处理运行时分叉。 铁律： - 先 recover，再 runtime。 - 不要在 dispatcher 和 state carrier 还没搞清时就盲补 `window/document/navigator`。 卡住信号： - 代码越来越可读，但仍然解释不了目标字段 - 一直在补 case / opcode，却没有把它们绑到目标写回路径 - 反混淆产物越来越大，但没有新增可验证检查点 必切动作： - 降低恢复深度，先只保留关键 `opcode` 家族或 bridge - 若 sink 关联性变弱，退回 `Phase 1` - 若桥接合同已经清楚但结果仍不一致，切 `Phase 3` 停止纪律： - 默认只允许做到“足以继续”的深度，不允许因为代码脏就自动升级到最小解释器 - `worker/wasm/JSVMP/227/226` 复合壳场景里，若 black-box reuse 已能支撑下游，不再继续全量 lifting ### Phase 3: 浏览器与本地差分诊断 主 skill： - `$jsr-runtime` 补充 skill： - `$js-runtime-diff-env-patching` - 有反调试时加 `$js-reverse-env-antidebug` MCP 优先级： - `chrome-devtools-mcp`：建立浏览器正常路径与运行时现场 - `js-reverse`：抓 storage/session/network/websocket/hook 中间态 - `jshook`：反调试、Stealth、环境对抗、运行时行为补充验证 目标： - 解释为什么浏览器能跑、本地跑不通，并输出最小运行时依赖清单。 优先分类： - 缺对象 - 缺状态 - 反调试 - 指纹/风控分支 - 时间/随机数/seed 漂移 - `sign lane` 与 `token lane` 混杂 - 浏览器特性通道：`storage.estimate`、`animationend`、`postMessage`、`worker` - 自动化摩擦：`run_js`、格式化检测、DevTools 开启即漂 退出条件： - 已找到第一个真实失配检查点。 - 已说清哪些依赖必须迁、哪些依赖不能迁。 铁律： - 先比中间态，再比最终值。 - 先 patch state，再 patch object。 - 先证明浏览器特性通道被真实消费，再 patch 浏览器对象表面。 卡住信号： - 一直在补对象，但首个分叉点仍不清楚 - 最终值持续不一致，但没有中间态对照表 - 每次改动都影响很多面，无法知道是哪一项生效 必切动作： - 回到浏览器正常态，重建“首个分叉点对比表” - 每次只 patch 一个状态面：`cookie/storage/channel/style/time/random` - 如果六轮内还不能解释分叉，停止补环境，改走浏览器辅助执行或代理复用 ### Phase 4: Node 最小迁移 主 skill： - `$env-patch` MCP 优先级： - `chrome-devtools-mcp`：冻结浏览器基线样本 - `js-reverse`：提取可迁移入口、中间态与依赖 - `jshook`：在需要更重的 Hook/Stealth/分析时辅助本地迁移判断 目标： - 把浏览器真实需要的依赖迁到 Node，只迁最小集合。 进入条件： - 入口已知。 - dispatcher / builder / bridge 基本清楚。 - 浏览器与本地差分已经归因。 退出条件： - 本地能稳定走到目标 builder。 - 中间态可与浏览器对齐。 铁律： - `env-patch` 是迁运行时，不是替代 `recover`。 - 不要一次性搬完整浏览器环境。 卡住信号： - 本地补丁清单越来越长，但中间态没有更接近浏览器 - 只能靠堆对象让代码不报错，却仍进不了真实 builder - 每次修一个对象都会引出更多对象，但没有证据证明它们被消费 必切动作： - 停止补对象，回到 `Phase 3` 只看状态与分叉 - 若入口已知但本地仍跑不稳，改用浏览器远程调用 / browser-assisted replay - 若 Node 迁移成本明显高于收益，保留 browser-side black-box reuse，不强行本地化 ### Phase 5: 稳定复现与回归 主 skill： - `$js-reverse-sign-replay` MCP 优先级： - `chrome-devtools-mcp`：对照真实浏览器结果 - `js-reverse`：验证中间态与状态依赖是否闭合 - `jshook`：对复杂混淆或高级算法段做补充分析 目标： - 把链路固化成可维护、可回归的本地复现脚本。 要做： - 切分 `normalize -> concat -> hash/encrypt -> encode` - 固化输入契约与阶段检查点 - 提供 baseline 与 regression 退出条件： - 固定输入稳定一致 - 变体输入行为可解释 - 后续版本漂移时能快速定位断点 卡住信号： - 最终值能对上，但无法解释哪些中间态必须一致 - 输入略变就漂，但没有记录哪个阶段先漂 必切动作： - 把回归拆回阶段检查点，不再只看最终值 - 若漂移来自运行时依赖，退回 `Phase 3/4` ## 复杂场景分支 ### 分支 A：普通参数站 特征： - 参数名明确 - 没有明显 VM 或 dispatcher 壳 - 代码仍可直接追 流程： - Phase 0 - Phase 1 - Phase 5 ### 分支 B：重混淆 / 花指令 / 平坦流 / JSVMP 特征： - 大 `switch` - dispatcher - `JSVMP` - `227/226` - `basearr/opcode/ip/g` - 大量真假分支 - `worker/wasm/runtime` 壳 - 厂商壳：`Akamai/Kasada/PX/reese84` 流程： - Phase 0 - Phase 1 - Phase 2 - 回到 Phase 1 坐实 sink - Phase 3 - Phase 4 - Phase 5 ### 分支 D：验证码 / 浏览器特性通道题 特征： - `腾讯滑块`、`阿里滑块` - `_rand`、`fuid`、`fs` - `animationend`、CSS 动画、样式终态取值 - `run_js`、自动化检测、浏览器与本地行为差异 流程： - Phase 0 - Phase 1 - Phase 3 - 必要时回 Phase 2 恢复桥接层 - Phase 4 - Phase 5 ### 分支 E：风控指纹 / 厂商挑战题 特征： - `Akamai`、`Kasada`、`PX`、`reese84`、`Incapsula` - `同盾`、`BlackBox`、`a_bogus` - `abck`、`sensor_data`、`bm_sz`、`TLS/JA4` - 浏览器可过，本地 `403` 或 challenge 持续跳 流程： - Phase 0 - Phase 1 - Phase 3 - 必要时 Phase 2 - Phase 4 - Phase 5 ### 分支 F：协议封装 / Wasm / Builder 题 特征： - `protobuf`、`jspb` - `rid`、`x-s3-s4e`、`desc`、`bx-pp` - `wasm`、`compileStreaming`、imports/exports - builder / writer 被 VM 或 wasm 桥遮蔽 流程： - Phase 0 - Phase 1 - 必要时 Phase 2 - Phase 3 - Phase 4 - Phase 5 ### 分支 G：Hard Site 复合场景 特征： - 同时出现 `JSVMP/平坦流/worker/wasm` - 同时存在 `run_js/storage.estimate/animationend` 一类浏览器特性通道 - 同时有 `Akamai/Kasada/PX/reese84/同盾/a_bogus` 一类风控分支 - Node 与浏览器差异巨大，且本地 patch 快速发散 流程： - Phase 0 - Phase 1 - Phase 2，只恢复最小桥接切片 - 回到 Phase 1 重新坐实 sink - Phase 3，先找第一个分叉点 - Phase 4，只在依赖清单已稳定时进入 - Phase 5 额外纪律： - 这种场景禁止直接从 `Phase 2` 跳到“全量本地还原” - 任何时候一旦失去边界锚点，优先退回 `Phase 1` ## Hard-Site Escalation Ladder 困难站点统一按这个升级梯子推进，不允许乱跳： 1. 浏览器最小样本 - 坐实真实请求、触发动作、目标字段 2. 写入边界 - 坐实 `entry -> builder -> writer` 3. 最小壳层恢复 - 只恢复挡路的 dispatcher / bridge / imports / opcode 4. 首个分叉点诊断 - 做浏览器 vs 本地对比表 5. 最小运行时迁移 - 只迁被证明会影响结果的依赖 6. 浏览器辅助执行或 black-box reuse - 当本地化成本过高时接受 browser-side 方案 7. 稳定回归 - 再做纯算、代理或回放固化 升级条件： - 上一层已经产出稳定工具，但仍不能支撑下一步 禁止跨级： - 没有第 2 步就做第 5 步 - 没有第 4 步就宣称本地环境已经足够 - 没有第 6 步评估就强行追求“必须纯本地” ### 分支 C：浏览器与 Node 差异很大 特征： - 浏览器正常，本地失败 - 本地能生成值，但服务端持续 `403` - 调试一开就漂 - 指纹、时间、随机数、风控敏感 流程： - Phase 0 - Phase 1 - Phase 3 - Phase 4 - Phase 5 ## 切换规则速查 - 参数名明确且未重混淆：先走 Phase 1。 - 看到 `JSVMP/227/226/平坦流/basearr/opcode`：先切 Phase 2。 - 看到 `wasm/bx-pp/protobuf builder/动态字符串壳`：通常先走 Phase 1，再视遮蔽程度切 Phase 2。 - 看到 `run_js/storage.estimate/animationend/postMessage/worker`：优先做 Phase 3。 - 看到 `Akamai/Kasada/PX/reese84/同盾/a_bogus`：优先检查 Phase 1 与 Phase 3 的混合阻塞。 - 看到 `腾讯滑块/阿里滑块/_rand/fuid/fs`：优先按验证码双链与浏览器特性通道处理。 - 浏览器和 Node 出现首个真实分叉：切 Phase 3。 - 差分已归因、准备本地执行：切 Phase 4。 - 链路稳定、准备交付：切 Phase 5。 ## MCP 执行纪律 - `chrome-devtools-mcp` 负责“真实页面现场”，没有它就没有可靠浏览器基线。 - `js-reverse` 负责“逆向工作流证据”，没有它就没有稳定的 Hook/代码/状态记录。 - `jshook` 负责“高级逆向与对抗补强”，在重混淆、反调试、Stealth、复杂 Hook 时默认加入。 - 任何阶段如果三者之一没有提供增量证据，要明确说明为什么此阶段暂不需要它，而不是静默跳过。 ## 交付物 每轮至少维护这些文件： - `reverse-records/总览.md` - `reverse-records/请求链路.md` - `reverse-records/恢复记录.md` - `reverse-records/运行时依赖.md` - `reverse-records/验证记录.md` - `reverse-records/状态载体卡.md` - `reverse-records/环境依赖清单.md` - `reverse-records/升级记录.md` 没有这些工具时，不要长时间继续深挖。 最少要写清： - 当前 phase - 当前阻塞 - 当前最强锚点 - 最近一轮新增证据 - 若无新增证据，下一步准备切换到哪一层 ## 一句话版本 复杂网站还原统一流程： `证据门 -> locate -> recover(必要时) -> runtime diff -> env-patch -> sign-replay` 其中： - 壳重就提前 recover - 分叉明显就先 runtime diff - Node 迁移只用 env-patch 收尾 - 最终交付再进 sign-replay