web-js-reverse-master-flow

Web JS リバースエンジニアリング総合フロー

役割

このスキルは、複雑な Web／JS リバースエンジニアリングプロジェクトの総合制御の起点です。

専門スキルの代わりとなるものではなく、次の役割を担います。

• 現在のタスクの段階を標準化する
• 次に最適な専門スキルを選択する
• 切り替えの順序を制約し、「リクエストチェーンが確定する前に環境を補完する」といった誤操作を防ぐ
• 現在の段階、阻害要因、次に必ず更新するドキュメントを出力する

デフォルトでは、複雑なサイトの再現はすべてこのスキルから始め、複数の総合制御スキルを直接並行して起動しないでください。

責務の境界：

• このスキルは常にマクロレベルの総合制御を担い、特定のベンダー、サイト、またはシェルの事例集にはなりません。
• 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 またはその他の専門スキルに任せます。

現場の手がかりが明らかに特定の公開事例に合致する場合は、事例の事前ルーティングのために $1997-pro-web-reverse-casebook も同時に読み込みます。ただし、段階の選択は引き続きこのスキルが決定します。

MCP スタック

このスキルでは、デフォルトで3つの 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 への移行を検討してはいけません。

入力ブロック

以下の入力から始めます。

URL 或目标页面：
目标请求 / 字段 / cookie / 消息：
触发动作：
当前现象：
已有证据：
目标：
约束：

まず入力を補完してから、段階を決定します。

総則

• Hook を優先し、次にブレークポイントを使い、全量ダンプは最後にします。
• まず実際のリクエストチェーンを証明してから、純粋な計算、環境の補完、リプレイを検討します。
• まずセマンティクス層を復元してからランタイムを移行し、逆の順序にはしません。
• むやみな環境補完より、ランタイム差分を優先します。
• 一度に拡張する変数は1つだけにします。Hook ポイント1つ、サンプル1つ、パッチ1つ、分岐判定1つです。
• どの結論にも、ランタイムの証拠または中間状態のチェックポイントを添えます。
• 事例の手がかりは事前ルーティングの参考にしかならず、証拠の確認や段階判定の代わりにはなりません。

スパイラル防止プロトコル

このスキルの主要な目的の1つは、難しいサイトで「長時間、証拠が増えないまま深掘りを続ける状態」に陥るのを防ぐことです。

以下のいずれかに該当する場合、すでに同じところを回り始めていると見なします。

• 同じ層で似た操作を何度も繰り返しているのに、リクエストチェーン、書き込み境界、状態の格納先、チェックポイントのいずれも新たに得られていない
• Hook／ブレークポイント／パッチを次々に追加しているのに、最初の実際の分岐を説明できない
• beautify／AST 変換に多くの時間を費やしているのに、ロジックを実際の sink に結び付けられていない
• ローカル環境の補完がどんどん大規模になっているのに、どのオブジェクトまたは状態が結果に影響しているのか説明できない
• 最終値だけに注目し、中間状態を比較しなくなっている

強制ルール：

• 同じ段階で2回連続して新たな証拠が得られなかった場合、必ずアクションを切り替えます。同種の操作を3回目も繰り返してはいけません。
• 同じ問題を6回続けても収束しない場合、現在の手法を停止し、次のレベルの方針に切り替えます。
• 方針を切り替える際は必ず、現在の手法が失敗した理由、次に検証する内容、放棄した仮説を明記します。

切り替え先として認められる方向は、次のとおりです。

• locate で行き詰まった場合：実際のトリガー範囲を広げる、initiator を取得する、ブレークポイントのスタックを使う、またはブラウザー側から呼び出す
• recover で行き詰まった場合：復元の深さを下げて locate に戻り、境界を改めて確定するか、black-box reuse に切り替える
• runtime で行き詰まった場合：最初の安定したブラウザースナップショットに戻り、分岐表を再構築して、状態面を1つだけパッチする
• env-patch で行き詰まった場合：オブジェクトの補完を続けるのを止め、ブラウザー支援実行、リモート呼び出し、または最小限のプロキシ方式に切り替える

禁止事項：

• 新たな証拠がない状態でダンプ範囲をさらに広げる
• 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／ラッパーブリッジを確認します
• CAPTCHA／業務ロジックの手がかり：
  • 腾讯滑块、阿里滑块、_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 を作成または更新します。

完了条件：

• 実際のサンプルチェーンが少なくとも1つあること。
• 対象フィールドまたはメッセージが、実際のリクエストによって証明されていること。

禁止事項：

• 対象のリクエストが確定する前に、環境の補完を始めること。
• 対象フィールドが確定する前に、アルゴリズムの復元に直接取り掛かること。

停滞の兆候：

• 「特定のパラメーター／スクリプトかもしれない」としか言えず、実際のリクエストサンプルを提示できない
• トリガー操作が不安定で、操作を繰り返しても同じチェーンを取得できない

必ず切り替えるアクション：

• 最小限のトリガー操作に戻り、クリーンなサンプルを改めて取得します
• ページスクリプトが複雑すぎる場合は、まず 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