構造体に背負わされた冤罪：INPUT の 28 対 40、fdeb パッチの VM 死路判決、そして仮想兵システムへの方向確立

長く冷えたままの懸案が一つ、小夜明けに雪辱された。そして同じ小夜明けに、一本の遠征路線が正式に棺に納められた——二つの出来事が合わさって、魔域単機化の地図を引き直したのである。

一、冤罪の雪辱：28 対 40

「クリックが効かない」という報告の事件簿をどれほど繰っても、思いがけない真犯人が現れる。INPUT 構造体が 32 ビット配置の 28 バイトで書かれ、x64 の正身は 40 バイトだった——SendInput は 0 を返し err 87（パラメータ無効）、鍵盤は keybd_event という旧 API が部分的に効いていたせいで捜査の視線を誤導し続け、冤罪は一代の道具にわたって引き延ばされた。40 バイトに修正した途端、鍵盤注入は全開で機能し（メモ帳への HELLO が証拠）、マウスの move も効く。ただしマウスの down/up だけは届くのに応答がない——ある安全層がクリックを呑んでいる。修復産物 bots/input64.py が正しい 64 ビット注入庫として定まり、ゲーム操作は全面的に鍵盤へ移行した（WASD 移動、スキルのホットキー）。

二、死路の確定：fdeb の VM 二重錠

別の戦線からは確定文書が届いた。fdeb の vt28 関数五百十二バイトのダンプに成功——これは VM 化された関数の本物の標本を初めて手にした瞬間である。逆アセンブルが読み下した判詞は冷たく明瞭だった。標準的なプロローグ、mov rbx,rcx のあと、まっすぐ VM セグメントへの jmp。さらに深い論理には上訴の余地がない。fdeb に対する VM 検証の存在意義は、後続のストリーム鍵を導出することにある——鍵を知らなければクライアントは後続の流を復号できない。VM 検証とサーバー RNG の二重錠は、原理的にパッチ不能である。fdeb パッチ路線は正式に死路と判決され、プロトコル層の単機化（擬似サーバーによる偽造）はここに幕を閉じた。

三、新しい旗：メモリ注入の仮想兵システム

閉ざされた道の対面に、新しい旗が立つ。メモリ注入式の仮想兵システム——プロトコルを偽造するのではなく、ゲームの論理を直接呼び出す。深夜の二発の検証が相次いで当たった。Frida RPC による 0x33031d0（conn、構築フレーム、len）の呼び出しは rc=1 を返し、送信組包——ではなく組枠入口は注入フレームを受け入れた。新しいセッション上に注入された偽造ハートビートは完全な送信鎖を通過し、本物のハートビート暗文と構造的に一致した。二十年の老王庭の門は正面からはこじ開けられなかったが、攻城者はすでに丁番の反対側に立っている。城の内側から、門閂を替えて回しているのである。

四、転換点の歴史学

この日の価値は二度の「承認」にある。28 バイトの書き間違いが、クリックすべてを一代分の道具にわたって冤罪に陥れうること。そしてプロトコル層の道が終わりまで来たこと。工程史で最も難しいのは新しい道を見つけることではなく、旧道に死亡診断書を発行することであり、fdeb の VM 二重錠はまさにその診断書である。TASK-QUEUE の優先度はただちに組み替えられた。活動セッション注入の検証、移動フレーム、攻撃フレーム、仮想兵の統合——以後の一歩一歩は、他人の城壁を登ろうとするのではなく、自分たちの兵士の肩の上に乗る。