jsr-reverse

JSR Reverse

役割とミッション

jsr-reverse は、Web JS のリバース作業におけるデフォルトのエントリースキルです。

このスキルのミッションは、次のワークフローの骨格を実行することです。

intake -> evidence -> locate -> recover -> runtime -> validation -> handoff

以下の目的で使用します。

• 手がかりの単語だけでなく、現在のプロジェクト状態に基づいて次のステップを選択する
• evidence と handoff を別個のスキルではなく、jsr-reverse の中に保つ
• locate、recover、runtime、validation のみへ振り分ける
• 今すぐ必要な最小限のリファレンスセットを提示する

412、token、worker、basearr、protobuf、JSVMP、wasm、hasDebug などの手がかりは、補助的なリファレンスの選択に役立ちますが、ステージの選択に代わるものではありません。

ワークフローの骨格

1. intake：依頼、対象、トリガー、目標、制約を整理します。
2. evidence：実際のリクエストチェーンを立証し、ステージへの振り分け前にプロジェクトの記録を更新します。
3. locate：書き込み境界、シンク、上流の依存関係チェーンを立証します。
4. recover：関連するロジック契約が読み取り可能で、操作可能になるまでシェルを縮小します。
5. runtime：ブラウザーとローカル環境の差異を説明し、最小限のランタイム依存関係セットを整えます。
6. validation：等価性、チェックポイント、最終的な整合性を立証します。
7. handoff：現在のステージの判断と、必要な成果物の更新内容を出力します。

迅速なトリアージは認められますが、この骨格の中でステージ選択を早める目的に限ります。骨格そのものに代わるものではありません。

Intake の契約

次のブロックから開始します。

URL or target page:
Target request / field / cookie / message:
Trigger action:
Current symptom:
Known evidence:
Goal:
Constraints:

複雑度の評価

intake の後、作業量と想定されるステージの範囲を調整するため、複雑度レベルを割り当てます。

レベル	ラベル	特徴	想定ステージ
L1	透過的なチェーン	パラメーターは目に見える連結または単純なマッピングで構成され、難読化や環境依存性はありません	locate → validation
L2	単一層のシェル	単純な難読化、または webpack バンドルによるラップがあります。暗号処理の呼び出しは 1 回で、環境チェックはありません	locate → recover → validation
L3	多層シェル＋環境依存性	JSVMP / wasm / worker ブリッジと環境依存の分岐があり、アンチデバッグも存在します	骨格全体：locate → recover → runtime → validation
L4	敵対的な保護	複数段階の Cookie、動的コード生成、アンチデバッグ、環境フィンガープリンティング、リスク分岐（例：RS/瑞数、一部の CAPTCHA SDK）があります	複数回の反復を伴う骨格全体。ステージの後退が想定されます

ルール：

• intake で評価しますが、後から複雑さが隠れていたことを示す証拠が判明した場合は、上方修正します。証拠なしに下方修正してはいけません。
• L1/L2 のタスクでは、簡潔なハンドオフカードを使用し、成果物内の recover/runtime の注記を省略できます。
• L3/L4 のタスクでは、完全版のハンドオフカードと成果物のライフサイクル全体を使用する必要があります。
• レベルは調整用の指標であり、振り分けを上書きするものではありません。ステージの選択はレベルではなく、引き続きエンジニアリング上の状態に従います。

intake の後、エンジニアリング上の状態を平易な言葉で要約します。

• 対象のリクエストは実際に存在し、取得済みですか。それともまだ推測の段階ですか。
• 上流の依存関係チェーンは実際に確認済みですか。一部のみ確認済みですか。それとも不明ですか。
• 書き込み境界は立証済みですか。近くにあるものの隠れていますか。それともまだ見つかっていませんか。
• 主な障害は、シェルの縮小、ランタイムの差異、チェックポイントの立証のいずれですか。
• 次に更新すべき成果物は何ですか。

Evidence ゲート

次のいずれかに該当する場合は、ステージを振り分ける前にこのゲートを実行します。

• 実際のサンプルから対象のリクエストを特定できていない
• 上流の依存関係チェーンがまだ推測の段階にある
• トリガーとなる操作は判明しているが、リクエストの証拠がまだ記録されていない
• 現在のタスクに複数の仮説が含まれているものの、リクエストチェーンの記録によって整理されていない

このゲートは別個のスキルではなく、jsr-reverse の中にあります。

ゲートを実行する場合は、振り分け先のステージを選択する前に reverse-records/请求链路.md を更新します。

Request Chain Judgment の正確な形式と記録方法については、references/request-chain-recording.md を参照してください。

ステージの契約

locate

目的

対象のリクエスト、フィールド、Cookie、またはメッセージについて、実際の書き込み境界、シンク、上流の状態チェーンを特定します。

開始条件

• 対象のリクエストまたはシンクがまだ証明されていない
• 上流の依存関係チェーンが不完全である
• 書き込み境界を観測せずに推測している
• 現在の証拠から「値がどこで、どのように書き込まれるかはまだ分からない」と判断されている

実施内容

• 実際のリクエストチェーンとイニシエーターの経路を確認します
• 対象の値を書き込む最小の境界まで絞り込みます
• どの上流の状態遷移が重要で、どれが重要でないかを特定します
• リクエストチェーンが明確になったら、reverse-records/请求链路.md を更新します

成果物

• 対象の実際のリクエストサンプル
• 証明済みのシンクまたは書き込み境界
• 後続の作業に十分な具体性を備えた上流の依存関係チェーン

終了条件

シンクと上流のチェーンが十分に特定され、次の課題がリクエストの探索ではなく、シェルの縮約になったとき。

開始しない条件

• シンク／シェル境界が明確で、主な課題が実行時の不一致であるとすでに証明されている
• 作業がすでに同等性の証明だけに絞られている

行わないこと

• 書き込み境界が特定される前に、広範な難読化解除を行う
• シンクが推測段階のまま、環境のパッチ適用を行う

recover

目的

証明済みの境界の周囲にあるシェルを縮約し、処理を継続するために必要なロジックの契約を読み取り、追跡、または呼び出せる状態にします。

開始条件

• シンクまたは書き込み境界がすでに近く、実際に特定されている
• 次の課題が、難読化、ディスパッチャー構造、パックされたヘルパー、worker、wasm、webpack のブートストラップ、プロトコルエンベロープ、または類似のシェルロジックである
• プロジェクトで、まずリクエストを探索する必要がなくなった

実施内容

• 後続処理の理解を妨げているシェルのレイヤーだけを除去またはバイパスします
• 継続に必要なヘルパー、ディスパッチャー、ブリッジ、プロトコル、またはローダーの契約を復元します
• 縮約は最小限にとどめ、証明済みの境界を中心に進めます

成果物

• 縮約済みのシェル、または復元された契約
• 実行時処理または検証に必要な、呼び出し可能または調査可能な最小のロジック範囲

終了条件

シェルが十分に縮約され、次の課題がコードの隠蔽ではなく、環境への適合または一貫性の証明になったとき。

開始しない条件

• 実際の書き込み境界がまだ証明されていない
• 主な課題が、ブラウザー実行とローカル実行における最初の乖離である

行わないこと

• ブリッジの契約または演算子の範囲で十分な場合に、完全な逆コンパイルを行う
• 現在の境界に関係しない、トピック主導の復元作業を行う

runtime

目的

ブラウザー実行とローカルまたは制御下の実行との間で生じる、最初の意味のある乖離を説明し、解消します。

開始条件

• シンクとシェルの境界がすでに十分に明確である
• 状態、タイミング、分岐、または環境情報において、ブラウザー実行とローカル実行に乖離がある
• 次の課題が、実行を一致させるために必要な最小限の実行時情報の特定である

実施内容

• 最初に実際の乖離が生じる箇所を特定します
• 実行の一致を維持するために必要な最小限の依存関係を判断します
• ライフサイクルで生成される情報と、パッチ適用可能な表層情報を区別します
• ユーザーが大規模な環境パッチを避けたい場合は、実行時処理を最終調整として扱います

成果物

• 最初の乖離についての説明
• 最小限の実行時依存関係
• リプレイ、パッチ適用、ブラウザー支援実行、または段階的な検証の根拠ある方法

終了条件

実行時の乖離が説明され、残りの作業が同等性の証明または最終的な一貫性の確認になったとき。

開始しない条件

• シンクまたはシェルの境界がまだ推測段階である
• まずリクエストチェーンの証明またはシェルの縮約が必要である

行わないこと

• 最初の乖離を証明せずに、やみくもにパッチを積み重ねる
• より小さな適合調整で十分な場合に、実行時処理を一般的なリバース作業へ広げる

validation

目的

復元したパス、ランタイムへの適合性、または再現した出力が、チェックポイントと最終出力の両方のレベルで妥当であることを証明します。

次の場合に開始します

• 主な障害が、探索、縮小、またはランタイムへの適合性ではなくなった場合
• チェックポイントの証明、同等性の証明、または最終的な整合性の証明が必要な場合
• タスクが検証のみの場合

実施すること

• 最終出力だけでなく、具体的なチェックポイントを比較します
• 出力が一致する箇所、相違する箇所、または未証明のままの箇所を明らかにします
• 残る証明上の不足を解消するために必要な成果物または証拠を定義します

成果物

• 妥当な同等性または非同等性の記述
• 引き継ぎに向けた具体的なチェックポイントと結論

次の場合に終了します

引き継ぎに十分な具体性をもって証明でき、次の担当者が解決済みの内容と未解決の内容を確認できる状態になったとき。

次の場合は開始しないでください

• プロジェクトに、実際のリクエストチェーン、シンク、シェルの縮小、またはランタイムの説明がまだない場合

してはいけないこと

• 中間チェックポイントに相違があるのに、最終出力が似ていることだけで受け入れる
• 比較対象の証拠が不完全なのに、不確実性を隠す

ルーティングルール

ルーティングは常に2段階で行います。

ステップ1：エンジニアリングの状態からステージを選ぶ

現在のプロジェクトの状態に基づいてステージを選びます。

• リクエストの実態、シンク、または上流チェーンがまだ証明されていない場合は、locate を選びます
• 境界は証明されているものの、シェルによって利用可能なロジックの契約がまだ隠されている場合は、recover を選びます
• 境界とシェルが十分に明確であるものの、環境間で実行結果が異なる場合は、runtime を選びます
• 残る作業が証明、比較、またはチェックポイントの完了である場合は、validation を選びます

簡単な例：

• 412、403、Cookie の遷移、または token の手がかりは、実際のチェーンがまだ証明されていなければ、引き続き locate に分類されます
• worker、wasm、protobuf、または JSVMP の手がかりは、タスクがすでに locate の境界を越えている場合に限り、recover に分類されます
• basearr または hasDebug の手がかりは、境界がすでに明確で、問題が環境間の差異である場合に限り、runtime に分類されます

ステップ2：そのステージに必要な最小限の参照資料を選ぶ

ステージを選んだ後、以下を読みます。

• そのステージのコア参照資料を正確に1つ
• 現在の障害に合致するトピック参照資料を最大1～2つ

この順序を逆にしないでください。先に参照資料を選び、その後でステージを推測してはいけません。

新たな証拠によって locate が完了し、次の障害がシェルの縮小、ヘルパーの契約、ディスパッチャーのフロー、または不透明なオブジェクト構造になった場合は、同じターン内ですぐに recover に切り替えてください。

ステージを切り替えるたびに、次の手順を行います。

1. 新しいステージの出力契約に進む前に、references/stage-handoff-protocol.md に従った引き継ぎカードを出力します。
2. 次のデバッグ作業を提案する前に、新しいステージのコア参照資料とトピック参照資料を読み込み直します。前のステージの参照資料を、新しいステージの要件を満たすものとして扱ってはいけません。

トピック参照資料の適用ルール

ステージを選択してから、トピック参照資料を選びます。証拠ゲートが実行される場合は、証拠成果物の参照資料を別途使用します。

ステージごとのコア参照資料

• locate のコア：references/locate-workflow.md
• recover のコア：references/recover-strategy.md
• runtime のコア：references/runtime-diagnosis.md
• validation のコア：references/equivalence-and-validation.md

証拠成果物のサポート

• 証拠ゲートが実行される場合、または reverse-records/请求链路.md の更新が必要な場合は、references/request-chain-recording.md を使用します。これは証拠成果物の参照資料であり、トピック参照資料ではありません。

ステージ横断の参照資料

• ステージの境界を越えるたびに references/stage-handoff-protocol.md を使用します。任意ではなく必須です
• 誤った経路をたどるパターンが疑われる場合、または調査の方向性を決める前の確認として references/anti-patterns.md を使用します

トピック参照の追加ポリシー

まずコア参照を読み、現在の阻害要因に合致するトピック参照を1〜2件まで追加します。

• references/crypto-entry-locating.md：locate 中に sign、token、動的ヘッダー、暗号化されたリクエストフィールドを扱う場合
• references/hook-and-boundary-patterns.md：locate 中にフック、ブレークポイント、起点、境界の観察を行う場合
• references/jsvmp-and-ast.md：recover 中に JSVMP、ディスパッチャーループ、フラット化、AST を多用するシェルを扱う場合
• references/ast-deobfuscation-playbook.md：recover 中に文字列テーブルの復元、ヘルパーのインライン化、AST 変換、バンドルの展開を行う場合
• references/wasm-worker-webpack.md：recover 中に worker、wasm、webpack/runtime、ブートストラップ、ローダーのロジックを扱う場合
• references/protocol-and-long-connection.md：WebSocket、protobuf、SSE、ハートビート、ack、更新を、ステージ選択後の複数ステージにまたがるトピックとして扱う場合
• references/anti-debug-and-risk-branches.md：runtime 中にアンチデバッグや分岐の反転を扱う場合
• references/minimal-env-design.md：runtime 中に最小環境の設計を扱う場合
• references/sdenv-fit-check-and-routing.md：runtime 中にライフサイクルによって生成された状態、ナビゲーションによって生成された状態、またはリプレイルーティングを扱う場合

ブレークポイントヒットの調査が locate に属するのは、チームが実際の書き込み境界をまだ特定している段階に限ります。現在のチェーンがすでに実際のものだと確認され、次の作業が _$jR -> _$cg のようなヘルパー間を対象にステップインして、_$_U、_$$j、ディスパッチャー、またはブリッジのコントラクトを復元することである場合は、まず recover にステージを変更し、references/recover-strategy.md と該当するトピック参照を追加してください。

RS / 瑞数の参照追加ポリシー

RS の手がかりによってステージ選択が変わることはありません。

• 412、403、チャレンジページ、meta[r=m]、r2mKa、$_ts、$_ts.l__、1ホップ目／2ホップ目の Cookie、hasDebug、basearr は、補助参照を選ぶ際のシグナルです
• ステージを選んだ後、そのステージに合致する最小限の RS 参照を追加します。
  • locate 中は references/rs-collection-and-two-hop-routing.md
  • recover 中は references/rs-recovery-anchors.md
  • runtime 中は references/rs-runtime-and-basearr-fit.md

プロトコルは複数のステージに登場することがあります。その参照を追加するのは、ステージが選択された後だけです。

記録と引き継ぎのルール

• エビデンスゲートが実行された場合は、ルーティング済みステージの出力前に reverse-records/请求链路.md を更新します。
• ステージを切り替えるたびに、references/stage-handoff-protocol.md に従って引き継ぎカードを出力します。L1/L2 タスクでは簡易形式を使用できますが、L3/L4 では完全形式を使用してください。
• ステージが変わる場合、またはリクエストのエビデンスが実質的に変化した場合にのみ、ステージ出力を繰り返します。
• トピック参照の追加によって現在の調査経路が変わる場合は、ステージ出力を繰り返し、引き継ぎ前に現在の成果物を更新します。
• 現在の成果物：reverse-records/请求链路.md。
• 引き継ぎは手がかりの一覧ではなく、現在の成果物に基づくものにします。
• jsr-reverse/references/* のみを参照します。

出力契約

ルーティング後は必ず次のブロックを出力します。

Complexity: L{1-4}
Current stage:
Why this stage now:
Read now:
Required artifact:
Exit condition:

要件：

• Complexity は受付時に割り当て、後からのエビデンスで隠れた複雑さが判明した場合は、より高く修正する必要があります。
• Why this stage now では、手がかりの単語を挙げるだけでなく、エンジニアリング上の状況を説明する必要があります。
• Read now には、コア参照をちょうど1件と、トピック参照を1〜2件まで含める必要があります。
• Required artifact には、次に更新する必要がある成果物またはステージ出力を指定する必要があります。
• エビデンスゲートが実行された場合は、Required artifact を reverse-records/请求链路.md のままにし、現在のステージの結論を追記します。

例

Current stage: locate
Why this stage now: The target request is still partly guessed, the upstream cookie dependency is not yet proven from a real capture, and the team does not have a stable write boundary for the token field.
Read now: references/locate-workflow.md + references/request-chain-recording.md + references/crypto-entry-locating.md
Required artifact: reverse-records/请求链路.md
Exit condition: The target request, upstream dependency chain, and token write boundary are all proven from real evidence.

Current stage: recover
Why this stage now: The request chain and write boundary are already real, but the usable logic is still hidden behind a worker bootstrap and packed helper layer, so the next blocker is shell reduction rather than runtime fit.
Read now: references/recover-strategy.md + references/wasm-worker-webpack.md
Required artifact: recovered worker/bootstrap contract for the target boundary
Exit condition: The shell is reduced enough that the next blocker is runtime fit or validation, not hidden control flow.

Current stage: runtime
Why this stage now: The sink and shell boundary are already clear, but local execution diverges at a fixed environment-dependent branch after browser lifecycle state is consumed.
Read now: references/runtime-diagnosis.md + references/minimal-env-design.md + references/rs-runtime-and-basearr-fit.md
Required artifact: first-divergence note and minimum runtime dependency set
Exit condition: The first divergence and minimum fit set are concrete enough to move into validation.

ガードレール

• 実行中のリクエストと開始元の呼び出しチェーンがすでにある場合、広範なソースの grep から始めないでください。
• 実際のリクエストチェーンがまだ推測段階の場合、証拠確認のゲートを省略しないでください。
• 412、token、worker、basearr、protobuf などの手掛かりとなる単語だけで段階を決めないでください。
• 書き込み境界がまだ立証されていない状態で、実行時のパッチ適用に進まないでください。
• ブリッジの契約またはオペレーターの範囲で十分な場合、シェルを完全に逆コンパイルしないでください。
• 第 2 ホップでの消費を確認するまで、RS の第 1 ホップの情報を完全なものとして扱わないでください。
• 中間チェックポイントが一致しない場合、最終出力の一致だけで十分だと判断しないでください。
• 境界がすでに立証されている場合、locate フレームのまま対象を絞ったステップイン、ヘルパー契約の復元、またはオブジェクト構造の補完を続けないでください。まず recover に切り替えてください。
• リクエストチェーンを取得するたび、または重要な変更があったら、すぐに reverse-records/请求链路.md を更新してください。
• トピック参照は最小限にしてください。このスキルを参考情報の百科事典にしないでください。