web-reverse

Web リバースエンジニアリングスキル（WEB）

中核原則：まずレベルを判定してからツールチェーンを選ぶ。まず事実を確認してから推論する。まずアンパックしてから分析する。中国語のレポートを必ず提出する。

§ 目標とトリガー

• 本スキルは Webフロントエンドのリバースエンジニアリングと署名／暗号化の再現に使用します。
• トリガー条件は前置きの description を参照してください。条件を満たさない場合はトリガーしないでください。

§ タスク入力（不足があれば補完）

次の4項目を必ず収集してください：target、objective、requirements、boundaries。

共通項目

項目	説明
target	URL またはファイルパス。種類：WEB
objective	鍵の復元 / 認証のバイパス / プロトコルの再構築 / API署名のリバースエンジニアリング / CTF flag / WASMの仮想化解除 / JS-VMの仮想化解除
requirements	深度：quick / standard / deep。出力形式。時間予算
boundaries	能動的なトリガー Y/N。レート制限。禁止操作

WEB 専用項目

項目	説明
url scope	ベースURL、ページ一覧、ログイン状態、必要なロール
interface scope	対象APIエンドポイント、HTTPメソッド／パス、APIバージョン
runtime constraints	能動的なトリガー Y/N。レート制限。禁止操作
evidence requirements	Headers Y/N。ペイロードサンプル Y/N。タイミングウォーターフォール Y/N。token/cookieの追跡 Y/N
js protection type	圧縮のみ / 変数名の変更 / 文字列の暗号化 / CFGの平坦化 / ob-fuscator.io / JSFuck / eval-pack / JS-VMP / カスタムVM / 不明
bundle system	Webpack / Vite / Rollup / Parcel / Browserify / ESBuild / 不明
wasm present	Y/N。Yの場合：独立した.wasm / emscripten / wasm-pack / AssemblyScript
source map available	Y/N。内包 / 外部.map / Header内に隠蔽
anti-debug in browser	DevTools検出 Y/N。タイミング検出 Y/N。debugger文 Y/N

CTF 専用項目

項目	説明
CTF type	web / crypto / rev
flag format	FLAG{...} / CTF{...} / カスタム正規表現
known hints	問題文／ヒント
solver output	flag文字列 / 使用可能なexploit / 署名リプレイスクリプト

§ セキュリティと認可の境界

• 認可された範囲内でのみリバースエンジニアリングを行い、権限を越えたり、範囲を拡大したりしないでください。
• ペイロードサンプルの実行、オンラインの脆弱性悪用のトリガー、サンドボックス外への認証情報のエクスポートは禁止です。
• 外部プラットフォーム／環境の権限境界については、必ず確認を求めてください。

§ 出力要件（必須）

• 必ず作成するファイル：web_replay.js、Reverse_Report_CN.md。
• 必要に応じて追加：deobf_clean.js、vm_opcodes.txt、wasm_analysis.wat、solver.py、crypto_params.json、token_flow.md。

§ 証拠と結論のルール

• 信頼度の高い結論は、独立した2種類以上の証拠で相互検証する必要があります。
• 単一ツールによる結論には LOW CONFIDENCE と記載してください。
• 各結論に証拠のアンカーを添えてください：bundleのchunk／行番号、ネットワークリクエストURL、JS関数名、xref。
• 出力は FACTS、INFERENCES、UNKNOWNS の各セクションに分けてください。

§ 保護レベル（T0–T7）と対処方針

レベル	パターン	主な手法
T0	圧縮のみ	整形 + 静的解析
T1	変数名の変更 / デッドコード注入	ASTによる変数名変更 + 静的解析
T2	ob-fuscator.io / 文字列の暗号化 / CFGの平坦化	難読化解除ツール + ランタイムhook
T3	eval-packing / JSFuck / JJencode / aaencode	アンパック → T1/T2の処理
T4	JS-VMP / カスタムVM	VMディスパッチャーのマッピング + opcodeの追跡
T5	WASMコア	wasm-dis + IDA/Ghidra + ランタイムhook
T6	T4+T5の混合	順序：JS-VMの仮想化解除 → WASMのリバースエンジニアリング
T7	多重ネスト（T2+T4+T5）	階層的に剥離：外層の難読化→VM→WASM

必須： ツールチェーンを選ぶ前に、T0–T7のレベル判定を完了してください。アンパック／難読化解除／仮想化解除が済んでいない状態では、結論を出してはいけません。

§ 自動振り分け（JS Protection Triage）

1. DevTools → Sources：すべての.js/.mjs bundleを列挙
2. 単一bundleが500KB超 → Webpack/Rollupの可能性あり
3. 可読性をサンプル確認：読みやすい変数名=圧縮のみ。_0x...=難読化／変数名変更
4. パターンを検索：debuggerループ／JSFuck／eval pack／CFGの平坦化
5. .wasm fetch / WebAssembly.instantiate を確認
6. 大きなswitchとopcode配列 → JS-VMP／カスタムVM
7. sourceMappingURL を検索
8. フレームワークの指紋を特定：React/Vue/Angular
9. Service Workerの登録を確認
10. WebSocketのバイナリフレームを確認

§ ツールの編成

第一候補： chrome-devtools-mcp

• ネットワークキャプチャ、JS source mapping、APIリプレイ、storage/token/WebSocketの追跡、DevToolsへのhook注入

優先チェーン

• WEBの基本：chrome-devtools-mcp → 静的なJSの整形 → APIリプレイ
• WEBの難読化：chrome-devtools-mcp → 難読化解除 → ランタイムhook → 静的検証
• Webpack/Vite：chrome-devtools-mcp → bundleの分割 → chunkのマッピング → エントリーポイントの追跡
• JS-VMP/VM：chrome-devtools-mcp → VMディスパッチャーの特定 → opcodeのマッピング → AST変換 → ランタイム追跡
• WASM：chrome-devtools-mcp → wasm-dis/wasm2c → IDA/Ghidra → ランタイムhook
• 問題文／サーバー側の挙動が変わった疑いがある場合：オンラインリソースの指紋確認 → 過去の解法のエントリーポイントと照合 → 実際のクリックフローを検証 → プロトコルフローを検証

フォールバック

• DevToolsを利用できない場合：ブロッカーとして明示 → プロキシログ/HARを依頼

§ 標準手順（6ステップ）

Step 1 — コンテキストの分解： 経路を評価（実現可能性／シグナル／リスクを0-3で評価）→ 主経路 + フォールバックを選択。 Step 2 — 環境の確認： DevToolsの利用可否、対象範囲／ログイン状態／レート制限を確認。 Step 3 — 全体の三角測量： T0–T7のレベルを判定し、bundleを特定、APIを列挙し、source map/WASM/SW/フレームワークの指紋を確認。 Step 4 — 重要な経路： ページ読み込みJS → 初期化 → 認証／暗号化モジュール → sign() の呼び出し箇所。 Step 5 — 詳細分析： 難読化解除／仮想化解除後のデータフローとパラメーター生成ロジック。 Step 6 — 動的検証： hookで捕捉 + リプレイスクリプトで署名の一貫性を検証。

§ 専用手順：Drift Check

ユーザーから過去の解法や過去のスクリプトパスが提示された場合、または「現在のオンライン動作と公開されている解法が明らかに一致しない」ことを確認した場合は、クライアントをさらに詳しく調べる前に、必ずドリフト検証を実行してください。

Drift Checkの最小アクション

1. 現在の問題ページのHTML指紋を取得
2. 現在読み込まれているscript/link/APIリソースを列挙
3. 過去の解法でよく使われるエントリーポイントと旧リソースパスに直接リクエスト
4. 現在のリソースパスと過去の記事／スクリプトパスが一致するか照合
5. 実際のクリックフローとプロトコルフローを実行し、現在のオンライン環境で実際に失敗する箇所を確認

Drift Checkの成果物

• 現在の問題ページURLとHTMLハッシュ
• 現在のscript/APIリソース一覧
• 旧エントリーポイントの利用可否マトリクス：200 / 404 / 500 / redirect
• 結論の分類：
  • NO DRIFT SIGNAL
  • POSSIBLE DRIFT
  • HIGH PROBABILITY DRIFT

Drift Checkの判定ルール

• 旧エントリーポイントが404/500であり、実際のクリックフローが過去に公開された解法の想定と一致しない場合は、少なくとも POSSIBLE DRIFT と判定してください。
• クライアント側の明示的な状態を最小限まで圧縮しても失敗を説明できず、かつ旧エントリーポイントが無効な場合は、HIGH PROBABILITY DRIFT と判定してください。

§ 参考資料（必要に応じて読み込み）

• references/hooks.md：ネットワーク／ストレージ／デバッグ対策／WebCrypto／CryptoJS の hook コード
• references/deobf.md：T1–T3 の難読化解除とアンパックの手順
• references/vm_wasm.md：JS-VM／WASM の仮想化解除手順
• references/replay.md：プロトコルの再構築と web_replay.js テンプレート
• references/ctf.md：CTF の迅速なトリアージと成果物の要件

§ 成果物テンプレート

Reverse_Report_CN.md の構成

1. タスクの概要
2. 主な発見（≤5項目）
3. 証拠表
4. 呼び出しチェーン
5. リスクと影響
6. FACTS / INFERENCES / UNKNOWNS
7. 次のアクション
8. 成果物一覧
9. 再現手順

web_replay.js の要件

• node web_replay.js で直接実行できること
• 署名アルゴリズムの復元とリクエストのリプレイを含むこと
• 主要パラメーター（key/token/nonce/ts）の出所を明記すること

§ 再利用可能な実験テンプレート

1. Signer Export + Minimal Trace

適用対象：runtime signer は特定済みだが、読み取っている入力が不明な場合。

手順：

• eval／動的バンドルに最小限のパッチを適用する
• signer のエントリーポイントと少数の helper をエクスポートする
• 記録するのは次の項目のみ：
  • signer の入力
  • signer の出力
  • リクエスト送信前の cookie／URL／少数の動的グローバル
• 最初から opcode をすべてログに記録することは禁止し、軽量な trace を優先する

成果物：

• trace_*.py
• trace_*.out.json

2. Dynamic Global Injection Experiment

適用対象：サーバーの応答で k／nonce／動的グローバル名が返され、これらの値が次のリクエストに影響する可能性がある場合。

手順：

• 実際のクリックフローで、各ページの応答から返される動的な値を収集する
• 候補値をそれぞれ注入する
• fresh URL を再生成する
• リクエスト結果のマトリックスを記録する

成果物：

• experiment_*_variants.py
• experiment_*_variants.out.json

3. Scope Snapshot Diff

適用対象：window／storage／cookie はすべて確認済みだが、モジュールの状態またはクロージャーの状態が残っている可能性がある場合。

手順：

• 実行時に最小限のスナップショットインターフェースを注入する
• スナップショットの範囲：
  • アクセス可能なモジュールレベルの primitive／string／array の要約
  • 主要なクロージャーの戻り値の要約
• 重要なリクエストの直前のみスナップショットを取得する
• 隣接するページまたはリクエスト間の差分を自動比較する

成果物：

• trace_scope_snap.py
• trace_scope_snap.out.json

4. Browser / Protocol Consistency Matrix

適用対象：「ブラウザーでは成功するが、プロトコル層では失敗する」または「自動化スタックが実際のクリックフローと一致しない」可能性がある場合。

手順：

• 少なくとも次の3つの経路を比較する：
  • 実際のクリックフロー
  • browser-native fetch
  • プロトコル層の replay
• 3つが一致する場合は、「ネットワークスタックの差異」の分岐を優先的に除外する

結論の要件：

• どの経路が一致し、どの経路が一致しないのかを明確に記述すること
• 単一の経路だけを根拠に結論を出してはならない

§ 結果の記載ルール

• 未確認の項目は UNKNOWNS に記載し、次のアクションを提示すること。
• 時間内に結果が得られなかった場合：結果が得られなかったこと、確認済みの内容、次善の方法を明記すること。

§ 品質基準（完了条件）

• 防御レベルの判定が完了しており、重要な層のアンパック／難読化解除／仮想化解除が完了していること。
• リプレイスクリプトの署名がブラウザーの署名と一致すること。
• 証拠のアンカーがそろっており、再現可能であること。
• 過去の解法または古いエントリーポイントがある場合、Drift Check を1回実施したことを明記し、段階別の結論を提示していること。