- 現代のカーネルベースのアンチチートシステムは、Windows環境において最も複雑なセキュリティソフトウェアの1つであり、ゲーム実行中もカーネルレベルでメモリとシステムイベントを監視する
- ユーザーモード保護の限界を克服するためにカーネルドライバーを活用し、プロセス・スレッド生成、イメージ読み込み、レジストリ変更などをリアルタイムで監視する
- BattlEye, EasyAntiCheat, Vanguard, FACEIT AC などの主要システムは、カーネルドライバー・サービス・ゲームDLLの3層構造で動作し、起動時に読み込まれるVanguardは最も強力な制御権を持つ
- メモリスキャン、フック検知、ドライバー整合性検証、DMA攻撃対策、行動ベース検知 など多層的な防御を組み合わせてチート行為を遮断する
- 最終的には TPMベースのリモート認証とハードウェア信頼性検証 がゲームセキュリティの中核基盤として台頭している
1. ユーザーモード保護の限界とカーネルへの移行
- ユーザーモードのプロセスはカーネルの権限下にあるため、カーネルドライバーやハイパーバイザーレベルのチート に容易に回避される
- 例:
ReadProcessMemory 呼び出しはカーネルフックによって偽装可能
- カーネルモードのチートはゲームメモリを直接操作し、ユーザーモードの検知を回避できる
- これに対応するため、アンチチートはカーネルレベルへ移行し、同じ権限レベルで監視を行う
2. チートとアンチチートの「軍拡競争」
- ユーザーモード → カーネル → ハイパーバイザー → DMAへと続く 権限昇格競争 が続いている
- アンチチートは ドライバー遮断、ハイパーバイザー検知、IOMMUベースのDMA防御 で対抗する
- この過程はチート制作のコストと難易度を引き上げ、一般ユーザーの参入を阻む効果 を持つ
3. 主なカーネルアンチチートシステム
- BattlEye:
BEDaisy.sys カーネルドライバーを中心に、プロセス・スレッド・イメージ読み込みコールバックを登録
- EasyAntiCheat(EAC): Epic Games傘下で、類似の3層構造
- Vanguard: 起動時に
vgk.sys を読み込み、ドライバーホワイトリストモデル で強力な制御を行う
- FACEIT AC: カーネルレベル監視で高い信頼性を確保
- ARES 2024論文は、これらのシステムが ルートキットに類似した技術的構造 を持つが、目的は防御であると明記している
4. カーネルアンチチートの3層構造
- カーネルドライバー: システムコールフック、メモリスキャン、アクセス制御を実行
- ユーザーモードサービス: ネットワーク通信、BAN管理、テレメトリ送信を担当
- ゲームDLL: ゲームプロセス内部の検証とサービスとのIPCを実行
- IOCTL, Named Pipe, Shared Memory を通じて相互通信する
5. 起動時ロードとランタイムロードの違い
- BattlEye/EAC: ゲーム実行時にドライバーをロードし、終了時にアンロード
- Vanguard: 起動時にロードされ、その後に読み込まれるすべてのドライバーを監視する
- このため システム再起動が必要 であり、起動段階から保護できる
6. カーネルコールバックベースの監視
- ObRegisterCallbacks: プロセスハンドルへのアクセス制御、外部プロセスのメモリアクセスを遮断
- PsSetCreateProcessNotifyRoutineEx: チートプロセスの生成を遮断
- PsSetCreateThreadNotifyRoutine: ゲームプロセス内の異常スレッドを検知
- PsSetLoadImageNotifyRoutine: 許可されていないDLL読み込みを検知
- CmRegisterCallbackEx: レジストリ変更を監視
- ミニフィルタードライバー: ファイルシステムレベルでチートファイルへのアクセスを遮断
7. メモリ保護とスキャン
- ハンドルアクセス制限 により外部メモリの読み書きを遮断
- コードセクションのハッシュ検証 でコードパッチを検知
- VADツリー走査 により手動マッピングされた実行メモリを検知
- 匿名実行メモリ、手動マッピングDLL、シェルコード をヒューリスティックに識別
8. インジェクション検知
- CreateRemoteThread, APC, NtMapViewOfSection, Reflective DLL など多様な注入手法を検知
- スタックフレーム解析(RtlWalkFrameChain) により異常なコード実行の有無を確認
9. フック検知
- IATフック: インポートアドレステーブルの改ざんを検知
- インラインフック: 関数先頭のJMP命令を比較してパッチ有無を確認
- SSDT, IDT, GDT整合性検査 でカーネルレベルのフックを防止
- 直接syscall使用の検知 により
ntdll 回避の試みを遮断
10. ドライバーレベルの保護
- 署名されていないドライバーおよびテスト署名モード を検知
- BYOVD(脆弱ドライバー悪用) 攻撃を遮断するためのブロックリストを運用
- PiDDBCacheTable, MmUnloadedDrivers, BigPool などカーネル内部構造を監視し、手動マッピングドライバーを検知
11. アンチデバッグと解析妨害
- NtQueryInformationProcess でデバッガーの存在を確認
- KdDebuggerEnabled変数 でカーネルデバッガーを検知
- ThreadHideFromDebuggerフラグ で隠されたスレッドを検知
- RDTSCベースのタイミング検査、ハードウェアブレークポイント、ハイパーバイザーの有無 で解析環境を遮断
12. DMAベースのチートと対策
- PCIe DMAデバイス はCPU介在なしでメモリ読み取りを実行する
- IOMMU はDMAアクセスを制限するが、無効化や誤設定時には無力化されうる
- FPGAデバイスの正規デバイス偽装 により検知は困難
- Secure Boot, TPM 2.0 による起動整合性検証で一部緩和可能
13. 行動ベース検知と機械学習
- マウス入力解析 により人間的な動きと自動照準を区別
- CNN・Transformerモデル を活用したトリガーボット・エイムボット検知
- グラフニューラルネットワーク によりチームベースの不正行為（ウォールハック・共謀）を検知
- テレメトリパイプライン: カーネル入力キャプチャ → 暗号化送信 → サーバーML解析 → BAN決定
14. 仮想環境と解析回避
- CPUIDハイパーバイザービット とベンダー文字列でVMを検知
- VMware, VirtualBox, Hyper-V のレジストリ・デバイス痕跡を確認
- 二重仮想化環境 は命令実行遅延で識別可能
15. ハードウェア識別とBAN執行
- SMBIOS, ディスク, GPU, MAC, MachineGuid などでHWIDを生成
- HWIDスプーフィング はレジストリ・ドライバー・物理的改変で試みられるが、
識別子の不一致や異常なフォーマット により検知可能
16. 今後の動向と技術的転換
- DMAの次の段階はファームウェアベースのチート であり、検知難易度が極限まで高まる
- AIベースのハードウェア照準ボット は人間入力との区別が難しい
- TPMベースのリモート認証とクラウドゲーミング が長期的代替案として台頭
- カーネルアンチチートは依然として実質的な最前線 だが、
ハードウェア信頼性検証とサーバー側検証 が究極的な方向性として示されている
1件のコメント
Hacker Newsの意見
要するに、現代のチートはハイパーバイザーやBIOSパッチ、DMAデバイスなどを使ってアンチチートを回避する
ハードウェアレベルで保護が強化されるほど、チート制作者もそれに応じて進化する
しかしAIベースのプレイ分析が登場したことで、チーター自体を検出する方式が効果を見せている
結局、未来はカーネルモードではなくユーザーモードのアンチチートとゲームプレイ分析にある
むしろ、それだけアンチチートがうまく機能している証拠に見える
昔はプログラムを1つ落とせばすぐにチートできたが、今は参入障壁が高くなって、試そうとすらしない人が多い
ただ、記事の前半ではこうした防御策が無力化され得ると言っていたので、では信頼できないのではないかという疑問が残る
私も2つのアカウントがBANされたが、カスタマーサポートで解除された
ただ、AIがサポート業務に使われているようで、不当なBANは多いのではないかと思う
こうした行動ベースのBANシステムは、熱心なユーザーまで誤って処罰する危険があり、信頼しにくい
つまり、誰でも簡単にチートを作れるわけではなくなるので、アンチチートはある程度成功している
ただし、ゲームプレイ分析は露骨なチーターしか捕まえられず、単純なESP系は見逃す可能性が高い
こうしたチーターはコミュニティをじわじわ壊していくので、より危険だ
カーネルに手を入れるのは、OSのセキュリティモデル全体を無視する行為だ
実際、バグのあるアンチチートが原因でroot権限を奪取された事例もある
OSのサンドボックス機能やブート段階の信頼チェーンを活用するべきだ
そのためOS機能だけに依存するのは難しく、attestationも現実的には適用範囲が狭い
完璧ではなくても、チーター数を統計的に減らせるなら意味はある
選択式アンチチートマッチングシステムのあるゲームを見てみたい
アンチチートを有効にした人同士だけがマッチングされ、無効にした人たちはコミュニティの自主規制で運営される構造だ
こうした実験はValveくらいの規模の会社でないと難しそうだ
ただし、コミュニティの自主規制は大規模では決して効率的ではない
個人的には、チーターがいたらゲームを閉じて外に出て風に当たるほうがいいと思う
カーネルレベルの「マルウェアみたいな」アンチチートをインストールするくらいなら、むしろコンソールで遊ぶほうがましだ
チーターは本質的に異常な行動パターンを示すので、サーバーで全入力を記録して機械学習ベースの異常検知を適用すれば見つけられる
また、「ハニーポット」オブジェクトを作って、チーターだけが反応するよう誘導する方法もある
p-hackingのように、偶然の変動を意味のあるシグナルだと勘違いする可能性がある
実際、Dota 2はクライアント内部の異常なデータ領域を読んだアカウントをすべてBANした
関連パッチ告知
単にMLを投げ込めば解決する問題ではない
行動分析はコミュニティの変化の速度に追いつきにくい
チーターはたいてい、プロより100msほど速く反応する
私はゲーマーではないが、オンラインゲームのチート防止問題は技術的に興味深い難題だと思う
単に「すべてをサーバー側で処理しろ」という助言は現実的ではない
ゲームはオリンピックではなく草野球リーグのようなもので、完璧な公平性より楽しさのほうが重要だ
チーター同士でマッチングさせれば、一般ユーザーへの影響は減る
しかし大手ゲーム会社はこうした人員を置かない
アンチチートは参入障壁を上げる役割しか果たせない
オンラインでチートする人を「負け犬」と見る空気が必要だ
カーネルレベルのアンチチートはクライアントを可能な限りロックダウンする方式だが、それでもチーターは存在する
結局、サーバーはクライアントを完全には信頼できないということだ
ネットワークコードでも完全には解決できない
最近の競技ゲーム文化は、企業がユーザーを友人ではなく見知らぬ相手と競わせる構造になっている
だが、そこまでしなければならないのかと思う
スポーツやチェスのように、実力を競うのは人間の本能的な欲求だ
カーネルアンチチートが「最も精巧なソフトウェア」だという表現は誇張に聞こえる
システムコールをフックすること自体は特別な技術ではない
競技ゲームをやったことのない人が多いように見える
Kernel-level anti-cheat(KLAC) は実際に効果がある
VAC/VACNetベースより、FACEITやVanguardのようなカーネル型のほうがチート率はずっと低い
もちろん完璧ではないが、参入障壁を大きく引き上げる
DMAデバイスだけでも数百ドルかかるし、高度なチートはサブスクリプション型で高価だ
ゲームは選択肢なので、KLACが嫌ならやらなければいい
だがそれを拒否するなら、チーターが跋扈する環境を受け入れなければならない
TPMベースのブート測定とUEFI Secure Bootでリモート認証が可能だと聞いていたが、攻撃者がこれを改ざんできるというのは驚きだ
私たちはデバイスの所有権を完全に保証されながらも差別されない自由を持つべきだ