ログイン握手の水中聴取：C2S 全暗文の確認、送信経路の真相、そして 128 バイト密文の MITM 聴取

老いた王庭の門は、夜になると一つの言語しか話さない。暗文である。本日の五回の聴取は、いずれもこの言語の文法を聞き取るために開かれた。

一、全暗文の確認：パケットごとの違いが意味するもの

ws2_32!send のフック（ret は send_wrapper 内部に正確に釘付け）が最初の証言をもたらした。すべての C2S 出力バイトは暗文である——32 バイトのハートビートも 96 バイトの操作も、無作為分布で平文は一つもない。しかも 32 バイトのハートビートの暗文は毎回異なる。同じ平文が異なる暗文を産むということは、これが ECB の機械的な写しではなく、IV かカウンタの関与する状態つきストリーム暗号だということを意味する。暗号点は逆コンパイル済みのどの関数にもいない——データが 0x10020 バッファに入る時点ですでに暗文であり、稼働中の stream_encrypt_fn は零命中だった。

二、送信経路の真相：三層の分業と、身を隠す写経者

呼び出し鎖の鉄証（ws2send ← send_wrapper ← tick_main_loop ← 外部スレッド）が構造を厘清した。アプリ層のメッセージはまず大域キューに入る（タイムスタンプと超時監視つきのリング配列）。tick_main_loop がデキューし、[(u16 len)(u16 msgID)][payload] に従って解釈し、msgID の検索表を経て handler の vtable+0x30 に回送する。最後に send_wrapper が 0x10020 バッファをソケットへ flush する。暗号は msgID ルーティングの handler の内部で起こる——写経者は官署名簿のどこかの頁に潜んでいる。そして C2S のログインパケットはそもそもこの配送線を通らない（フック零命中）。独立したログイン経路を通るのである。

三、擬似サーバーへの行動学：三回とも同じ三拍子

擬似サーバーに対するクライアントの挙動は三回の再現で完全に一致した。接続、三十フレームの S2C 突発を受領（3ec/463/7f4/3f7/3f9/e9f/408/b07/d72……）、七十一秒の静寂、唯一の一包の 128 バイト密文を発射、さらに七十秒の無応答を待ち、CLOSED。128 バイトとは ACC チケットの引き渡し、すなわちログイン要求である。soul.exe の暗号定数の点呼も同時に整列した。TEA delta 五箇所（多アルゴリズム実例）、AES sbox 一箇所、MD5 K 表二箇所、SHA1 五箇所、CRC32 三箇所——128 バイトの密文と TEA 家族は、合わせて高度に疑わしい。

四、水中聴取：MITM の初回完全サンプル

排除法が収束したのち、MITM プロキシ経路は最初の完全聴取を果たした。ゲーム→33115→公式→応答→ゲーム、全通——公式のログインは 128 バイト密文の対称応答と確認された（一秒以内に応答、五秒後に RST——公式側は永遠に来ない第三の握手を待ち続けている）。途中、未決事件が一件解決した。redirect 脚本が「33115 と印字し、33114 に書く」というハードコードの残滓を抱えており、かつての「ゲームは 33114 に繋ぐ」というすべての謎は、ログが嘘をついていたことに帰着した。王庭の門は初めて傍聴席に開かれた。席にはまだ誰も一言も理解していない——だが少なくとも、発せられた一言一句が、一字も違わず調書に書き取られている。