Call of Dutyアンチチートのリバースエンジニアリング分析
(ssno.cc)- Black Ops Cold War の TAC（Treyarch Anti-Cheat） は Ricochet のカーネルドライバーを持たないユーザーモードのアンチチートだが、最新の Call of Duty 系列とかなり似たコード構造を持つ
- 保護レイヤーは Arxan の実行ファイル暗号化・チェックサム・jmp 難読化・エントリーポイント難読化と、Treyarch/IW 系列のポインタ暗号化をあわせて使用している
- TAC はランタイム API ハッシュ参照、API フックパターン検査、デバッグレジスタ確認、Windows テスト署名検出、コンソール割り当て検出、DirectX/オーバーレイ検出など、複数の ユーザーモード検出 を実行する
- 外部オーバーレイはウィンドウスタイル・位置・表示アフィニティ・プロセスのモジュール一覧を収集してサーバーへアップロードし、Cheat Engine 系のメモリスキャナーは 仮想メモリのハニーポット で検出されうる
- 最も特徴的な手法は暗号化されたカスタム syscall スタブで、
ntdllフックを回避し、syscall の発信元を別のntdll関数のように見せかけることで監視を難しくしている
分析対象と範囲
- 分析対象は Black Ops Cold War 内部のユーザーモードアンチチートで、名称は TAC（Treyarch Anti-Cheat） として使われている
- Black Ops Cold War には Modern Warfare 2019 およびそれ以降のタイトルにある Ricochet の カーネルモード構成要素 が存在しない
- 最新の Call of Duty との大きな違いはカーネルモードドライバーであり、アンチチートコードの大部分はユーザーモードで、TAC と非常によく似ている
- 関数の疑似コードは、実際の逆コンパイル結果が難読化や解決コードで複雑なため、再構成された形になっている
- 一部内容はチートや回避の宣伝を避けるため削除されている
Arxan と実行ファイル保護
- Arxan は Black Ops 3 以降の多くの Call of Duty ゲームで使われている難読化・保護ツールである
- ランタイム実行ファイル復号
- ゲーム実行ファイルはパックされ暗号化されている
- Arxan は起動処理にコードを挿入し、実際のゲーム実行ファイルをアンパック・復号する
- 実行ファイルチェックサム
- Arxan はゲーム実行ファイルのパッチを継続的に監視する
- デバッガまたはチェックサム不一致が検出されるとプロセスを終了する
- jmp 難読化
- 関数の命令のあいだに多数の
jmpを挿入し、静的解析を難しくする - 大きな関数に数百個のジャンプが挿入されると IDA の解析が壊れ、外部ツールが必要になる
- 関数の命令のあいだに多数の
- エントリーポイント難読化
- 保護された Arxan コードが実際のエントリーポイントをアンパックして実行する
- この区間にも jmp 難読化が入ることがあり、フロー追跡が難しい
ポインタ暗号化
- 重要なポインタは使用直前に暗号化・復号される
- 現在のゲームグローバルオブジェクト
- エンティティ配列
- オブジェクトポインタなど
- 同じ暗号化方式には 16 個の変種 があり、現在の PEB アドレスがどの方式を使うかを決める
- この方式は Cheat Engine のポインタスキャンを妨害する
- グローバル値には暗号化された値しか保存されない
- 復号済みの値はスタック上にしか存在しない
- 復号されたポインタを得るには、復号命令の追跡ツールを使うか、ゲームがすでに復号した地点にフックを仕掛ける方法が必要になる
ランタイム API 参照とフック検出
- TAC はインライン化された ランタイム API 参照 関数を使用する
- モジュールハッシュと API 名ハッシュを受け取る
- ロード済みモジュール一覧を巡回しながら名前をハッシュ化する
- モジュールの export 関数を巡回し、コンパイル時ハッシュと比較する
- ハッシュ識別はゲームプロセスのロード済みモジュール一覧とゲームのハッシュ関数を使って進める
- モジュール名と export 名のハッシュを計算する
- 逆コンパイル結果から base hash と function hash を手作業で取り出し、どの API を呼んでいるか対応付ける
- ハッシュはゲームバージョンごとに同一ではない
- 関数ポインタがグローバル変数に保存されるため、仮想アドレスをロード済み DLL の export 関数と比較する方法でも識別できる
- TAC の API フック検出は現時点で 7 パターン だけを確認する
push/movabs/xchg/ret系スタブpush immの後にretcalljmp [rip+x]
- すべての重要 API を検査するわけではなく、自分が使用する API に対するフックを検査する
デバッグレジスタとドライバーテスト署名検出
- デバッグレジスタは Arxan の
.textパッチ監視を回避する非コードパッチ型フック手法として使われうる - TAC はスレッドコンテキストで DR0～DR3 の値を確認する
- 値があれば、現在のプロセス内部かどうかに応じて別のメッセージでコールバックを呼び出す
- その後、終了関数へフローが移る
- DR0～DR3 は privileged register なので一般的なアセンブリでは直接読めず、Windows カーネルまたは例外配送を通じて取得する必要がある
- Windows テストモードは正規署名のないカーネルモードドライバーの実行を許可する
- TAC は
NtQuerySystemInformationでテスト署名が有効かを確認する- この検出だけで直接 ban されるわけではないが、アカウントにはフラグが付く
プロセス終了方式
- TAC は 2 つの方式でプロセスを終了する
- 1 つ目の方式はレジスタを消したあと
NtTerminateProcessを呼び出すRCXを-1に設定するNtTerminateProcessがフックされていると検出された場合、この方式は使わない
- 2 つ目の方式はレジスタを消したあと
0x0へジャンプしてプロセスをクラッシュさせる - どちらの方式も重要レジスタを消すため復旧が難しい
コンソール・可視化・オーバーレイ検出
- 内部チートはログ出力やメニュー実装のために
AllocConsoleを使うことがある - TAC はコンソールウィンドウまたは PEB の
ConsoleHandleを確認してコンソール割り当てを検出する - 内部可視化は主にグラフィックス API フックで画面に描画される
- 最新の Call of Duty は DirectX 12 を使用する
- よくあるフック対象は
IDXGISwapChain::Present - DirectX 12 では command queue が必要で、
ID3D12CommandQueue::ExecuteCommandListsがよく使われる取得地点である
- OBS Studio、Streamlabs OBS、Discord ゲームオーバーレイ、Steam ゲームオーバーレイも似た位置で動作することがある
- Steam と Discord は描画を行う
- OBS 系はゲームキャプチャ使用時にレンダリング画像をキャプチャする
- TAC は現時点で DXGI present 関数自体をスキャンせず、vtable の present ポインタを確認する
外部チートとウィンドウベース検出
- 外部チートはゲームウィンドウの上を覆う overlapped window を作る可能性が高い
- TAC はすべてのウィンドウを巡回し、
GetWindowLongAで WS_EX_LAYERED スタイルを確認する - その後
GetWindowRectでゲームウィンドウと重なるか比較する- 重なり率が
0.5以上でキャッシュ数が 8 個未満なら、そのhwndを保存する - 例として
1920x1080の画面サイズに対応する値が現れる
- 重なり率が
- キャッシュされたウィンドウは別関数で追加調査される
GetWindowTextWでウィンドウテキスト確認GetClassNameAでクラス名確認GetWindowDisplayAffinityで表示アフィニティ確認
SetWindowDisplayAffinityとWDA_EXCLUDEFROMCAPTUREを使って録画・スクリーンショットツールから隠している場合も TAC は確認する- ウィンドウ関連情報は暗号化バッファに保存され、サーバーへアップロードされる
- ウィンドウテキスト
- クラス名
- ウィンドウ位置とスタイル
- display affinity
- 重なったウィンドウのプロセスのモジュール一覧と exe 名
- 重なったウィンドウのプロセスは
OpenProcess(PROCESS_VM_READ | PROCESS_QUERY_INFORMATION)で開き、K32EnumProcessModulesとK32GetModuleFileNameExWでモジュール名を収集する
Cheat Engine 系メモリスキャナー検出
- Cheat Engine は Windows 仮想メモリの動作のため検出しやすい
- プログラムが
VirtualAllocで仮想メモリを割り当てても、アクセス前は物理メモリで backing されない - ゲームはメモリを割り当てたあと使わないことがある
- Cheat Engine または Process Hacker のメモリタブがその領域をスキャンするとアクセスが発生し、メモリが valid 状態になる
- TAC 式のハニーポットは
K32QueryWorkingSetExでその仮想アドレスが実際にアクセスされたかを確認し、メモリスキャナーを検出する
シグネチャスキャン妨害
- ゲームハッカーはアップデート後もチートを自動動作させるため、signature scanning をよく使う
- Treyarch のアイデアは、再度呼ばれない関数で return address 周辺を PAGE_NOACCESS で保護する方式である
- signature scanner は実行ファイルのバイト列を先頭から末尾まで読み、パターンを探す
- 各バイトごとにアクセス可否を問い合わせると非常に遅いため、
PAGE_NOACCESS領域に到達するとプロセスがクラッシュしうる - この方式は完全な防止策ではないが、多くの解析者を困らせることができる
アンチデバッグ
- TAC 自体のアンチデバッグ検査は単純だが、Arxan も別個のアンチデバッグ手法を提供する
- TAC は現在のプロセスのすべてのスレッドを巡回する
CreateToolhelp32Snapshotと thread snapshot を使う- 各スレッドの TEB で
DbgSsReservedを確認し、DebugObject の存在を検出する
- 異常なメモリへの書き込みを行って access violation を起こす手法もある
- コードが例外後の地点まで到達した場合、デバッガが例外を処理したか回避したと判断する
CheckRemoteDebuggerPresentも使用するThreadHideFromDebuggerは例外をデバッガではなくプロセスへ送るようにする- デバッガがプロセスを停止しようとすると
STATUS_BREAKPOINT例外が発生し、プロセスが終了する可能性がある - ユーザーモードではこのフラグを unset できない
- この戦術は実行ファイルのエントリーポイント以前の TLS callback で実行される
- デバッガがプロセスを停止しようとすると
ネットワークトラフィック監視
- TAC はすべてのアクティブ接続を保存するのではなく、特定条件だけを探す
- 検出対象はゲームプロセス内部にローカルネットワークサーバーを作る方式である
- チーターが shellcode をゲームプロセスへ書き込む
- ゲームプロセス内でネットワークサーバーを起動する
- 外部アプリケーションがこのローカルサーバーと情報をやり取りする
- TAC は
GetTcpTable2で TCP テーブルを取得し、現在のプロセスが作成した接続と他プロセスのポート関係を比較して条件を検出する
暗号化されたカスタム syscall スタブ
ntdllの export API の多くは内部で syscall を実行する- カスタム syscall スタブを使えば、ユーザーモードチートが
ntdll関数をフックしていても回避できる - syscall は instrumentation callback に露出することがある
- instrumentation callback は syscall 後に呼び出される
- return address は syscall 命令の直後になる
- TAC は暗号化された syscall スタブで静的解析を難しくしている
- スタブは
.textセクションに割り当てられた大きな領域を write/execute で保護したあと構成される NtReadFileから syscall 命令を探し、CPU 時間値を乱数要素として使って位置を変える- 監視側からは syscall が任意の
ntdll関数から発生したように見えることがある- 実際の syscall は
NtReadFileではない可能性がある eaxの syscall index を確認できなければ、どの syscall か判断しづらい
- 実際の syscall は
- 再実行時に syscall 命令位置が変わる例がある
アンチデバッガ隠蔽回避検出
ThreadHideFromDebuggerを設定するにはNtSetInformationThreadが呼ばれる必要がある- チーターはこの API をフックし、成功を返すように見せかけることができる
- するとアンチチートは隠蔽設定が成功したと信じるが、実際には何も起きていないことがある
- TAC は作りの甘いフックを見つけるため、不正な引数 を入れて呼び出し結果を確認する
- 長さ引数が合わず失敗すべき呼び出しが成功したら検出する
- デバッガ環境と ScyllaHide 環境で異なる戻り値になった例がある
- 偽ハンドルを入れて
ThreadHideFromDebugger要求に無条件で成功を返すフックも確認している
リモートスレッド生成の遮断
- TAC は
STATUS_PRIVILEGED_INSTRUCTION例外で、現在のスレッドにTerminateThreadを呼ぶ例外ハンドラを設置する - 手動マッピング DLL はリモートプロセスで shellcode を実行する方法が必要で、一般的な方法が
CreateRemoteThreadである - Windows PE の TLS callback はスレッド作成時、スレッドエントリーポイントより先に呼ばれることがある
- TAC は新しいスレッドコンテキストで開始アドレスを確認する
NtQueryInformationThreadで Win32 start address を取得する- ロード済みモジュール一覧を巡回し、開始アドレスが正規モジュール範囲内にあるか確認する
- 開始アドレスがどのロード済みモジュール範囲にも入っていなければ検出を保存し、privileged instruction 例外を発生させてそのスレッドを終了する
その他の検査と結論
- 不明な検査として、
NtQuerySystemInformationのAllocationGranularityが0x10000かを確認するコードがある- 仮想マシンやカスタム Windows バージョンにフラグを付けるように見える
- TAC は接続済みモジュール一覧に大きく依存するため、PEB の
InMemoryOrderModuleListが空一覧かどうかも確認する- 空一覧にするとプロセス自体が壊れる可能性がある
- 最終的に TAC は次の機能を持つユーザーモードアンチチートである
- ランタイム API 参照
- 作りの甘いフック検出
- 外部オーバーレイ検出
- 内部 DirectX フック検出
- 使用 API のフック検査
- デバッガとデバッグ痕跡の確認
AllocConsole検出CreateRemoteThread検出- spoofed・encrypted syscall スタブ
- Arxan は強力な難読化、静的解析妨害、IDA Pro を壊す手法、
.text修正監視、独自のアンチデバッグ機能で TAC を補助する - TAC に類似したコードは現代の Call of Duty ゲームでも使われている
1件のコメント
Hacker Newsの意見
2021年にLinuxのCS:GOアカウントで信頼度指標に問題が発生し、黄色、のちに赤へと落ちた。公式なBANではないものの、実質的には制裁のように機能していた
その結果、チーターとばかりマッチングされ続け、チームメイトを見つけるのが難しくなった
後になって、Radeon GPUと16GB以上のVRAMを使う他のLinuxユーザーも似た問題を経験していることが分かり、問題追跡のためにGitHub Issueを作成した: https://github.com/ValveSoftware/csgo-osx-linux/issues/2630
調べてみると、Valveが特定のハードウェア構成、特に当時としてはかなり新しかった16GB以上のVRAMを持つRadeonカードを搭載したLinuxユーザーに制裁を加えていたように見えた
最終的に、あるユーザーがgabenに直接連絡した後に問題が修正された: https://github.com/ValveSoftware/csgo-osx-linux/issues/2630#...
Steam Deckの発売を準備していたValveが、Linuxユーザー体験を気にした結果だったのかもしれない、と推測している
それでも興味深くはある
ゲームの品質が悪くなったことから推測したのか、それとも確認する方法があったのか分からない
理解している限りでは、信頼度指標は悪用を防ぐために隠されている
チートは結局のところ人間の問題である
記事で説明されている安全策やヒューリスティックで、露骨なチーターの90%は検出できるし、そうしたアンチチートは基本的に良い方向だと思う
ただしアンチチートは保守的に動作すべきで、最終的にはプレイヤーと管理者が解決すべきだ
オンラインマルチプレイゲームは必ず人が管理するサーバー上で動くべきであり、プレイヤーが接続している時間の大半で管理者がいるべきだ
可能なら、プレイヤーが認識している管理者ならなおよく、管理者がいないときは投票キックや投票BANのような緩やかなモデレーションも可能であるべきだ
チーターを追い出すことと、チャットを悪用する人を追い出すことの間に本質的な違いはない
結局、オンラインマルチプレイゲームで実現可能なサーバー形態は私設サーバーやコミュニティサーバーだけだと思う
チーターや悪用者を制御する過程は、通報システムで受け付けて非同期に処理する方式であってはならず、ゲーム管理者が素早くキックやBANを行うべきだ
オンラインプレイがパブリッシャーのマッチメイキングサーバーでしかできず、チーターやチャット悪用者への対処がWebフォームでの通報だけというゲームなら、買ったりプレイしたりせず、財布で投票すべきだ
審判だけを監視する別組織まで置くこともできるだろうが、普通にゲームをすればいい
Apex Legendsは強力な通報とアンチチートシステムでうまく回っているし、Rocket Leagueもほとんど自動化されたモデレーションが効果的に機能している
電話番号、写真による手動認証、ランク戦前に10時間のプレイを要求すること、他プレイヤーからの推薦、あるいはこうした条件に加えて5ドルの買い切りゲームパスのような方式もあり得る
まだ見ていないなら、ValveのAIアンチチート発表を勧める
取り組みはかなり興味深く、チーターの99%を捕まえると主張している
もちろん、非常に微妙なチート方法も依然として存在する
Activisionの誤った永久BANを覆すために2年にわたる法廷闘争を行い、Activisionはチートの証拠を一つも出せず敗訴した: https://antiblizzard.win/2025/01/18/my-two-year-fight-agains...
チートをしたことは一度もないのに説明なくBANされ、3つのアカウントを定期的にプレイしていたが、残り2つのアカウントはBANされなかった
サポートはずっと「審査の結果、BANは正当」と言うだけで、何を間違えたのか修正できるような情報は一切くれなかった
ゲーム内で最も希少なスキンをいくつか持っており、2009年から数千時間プレイしていて、ARAMしかやらないのに、最もカジュアルなモードで感情的価値の大きいアカウントを賭けてチートしたというのは筋が通らない
ゲーム関連でこれ以上ストレスを受けたことはなく、業界の知人が内部確認をしてくれたおかげで、理由もなくBANが解除された
まだプレイはしているが、ほぼ毎回その誤BANを思い出すし、Leagueが時間を費やす最後の競技系マルチプレイゲームになりそうだ
また同じことが起きるのが怖くて、もうやりたくない気持ちもある
コンソールではチートはほぼ不可能で、ランクでようやく平凡なゴールド1に到達するまで非常に時間がかかり、どんな行動についても警告や通報を受けたことがないのに、説明なく永久BANされた
筆者のように戦う代わりに、Activision製品には二度と金を使わないことにしたし、全員がそうすべきだと思う
米国ではおそらくもっと難しいだろうが、英国やイングランドでは、被告がそれが事実であることを証明しなければならないと理解している
マルチプレイシューターをほとんどやっていなくて幸いだし、膨大なSteamライブラリを失うことになったら本当に嫌だと思う
ジャンプ難読化がとても気になる
もっとリバースエンジニアリングをしたことのある人が答えてくれるとありがたい
無条件ジャンプが、特定の事前条件で絞り込むのが難しいほど一般的なのか、関数の終端にはリターンがあるので見つけやすそうに見えるが、スタックを解析して関数がどこへ戻るのかを把握し、戻りアドレスの直前にある呼び出しを探す方法が可能なのか気になる
x86アセンブリプログラミングをあまりやっていないので、動作の仕組みを誤解しているかもしれない
IntelのPINフレームワークでも興味深い解析ができる
参考になりそうな記事はこちら: https://calwa.re/reversing/obfuscation/binary-deobfuscation-..., https://www.nccgroup.com/us/research-blog/a-look-at-some-rea...
多くの関数は
retで終わらない一部のジャンプは偽物で、一部のジャンプは命令の内部に入る
デコンパイラは同じ位置に2つの命令がある状況を処理できない
例えば
jmp 0x1234でjmpオペコードを飛ばし、0x1234を有効な命令だと仮定するようなやり方だある分岐ではスタックが壊れているが、意図的に例外を起こすためかもしれない
そのため
lea RAX, [rsp + 0x99999999999]のような命令をnopに置き換えてデコンパイルを直すことはできるが、意図された例外を見逃す可能性もあるIDAはこういうものをうまく扱えないのでBinary Ninjaのライセンスを使っており、デコンパイラ用に関数をインライン化するスクリプトも簡単に作れる
IDAではジャンプ間のコード片が1つの関数にしか属せないため、ジャンプ群がコード片を相互に再利用する状況を適切に扱うのは難しいと思う
Binary NinjaはBlizzardのゲームでバグがあったため利用者が少ないようだが、1年ほど前のバグレポートで修正された
一般的な既製ツール、特にIDA Proユーザーを面倒にさせるための難読化だ
ほとんどの難読化は、人々が別のプロジェクトへ移る程度に面倒にすることを目的としている
販売後に製品機能を取り上げる行為は、契約やEULAに書かれていても法律で禁じるべきだ
BANがゲームの所有権そのものを奪ってはならず、そうなるなら返金すべきだ
判決まで行かなければ返金を促せないなら、ライセンス費用、弁護士費用、裁判費用に加えて3倍賠償まであるべきだ
例えばSteamでBANされてすべての購入が無効化されるような形は、法的に不可能であるべきだ
アカウントログインがブロックされても、アイテムとインベントリは取引可能であるべきで、これはお金を払った顧客が実際の時間をかけて得たものだからだ
マルチプレイヤーゲームで倫理規定を執行したいなら、ゲームに料金を取れないようにするか、有料ユーザーはBANに対して権利を持つべきだ
BANは比例原則に従うべきで、人が関与し、費用がライセンス価格に制限され、敗訴した場合にのみ負担する不服審査手続きと記録があるべきだ
最悪の場合、VAC対象ゲームでアカウントに公開の晒し表示が付く程度だ
人々は楽しみ、他人と交流するためにマルチプレイヤーゲームをするので、チートであれ他の悪質行為であれ、他人に影響を与えるならマルチプレイヤーサービスの利用はBANされるべきだ
社会に迷惑をかけたら代償を払うというのは、かなり普遍的な原則だ
実際にお金を失ってもよいと思う
ただし誤ってBANされるのは別問題だ
それにBANされるのはSteamアカウント全体ではなく、もうプレイできなくなるそのゲームだけではないのか？
他のプレイヤーたちもお金を払っている
CODでは、わざわざチートする必要すらない
バグが多すぎて、ゲームが代わりにやってくれる
ランク戦でナイフの代わりに銃をロードすることもあり、ランク戦の武器装備チェックに明らかに間違った
caseやif-elseがあるためそういうことが可能で、装備セレクターに表示されている銃が許可されていない場合はXM4がデフォルトに設定されるようだ自分が知るゲームの中で、ランク版がカジュアル版より壊れている、ほぼ唯一のゲームだ
こういうのはどこで学んだのか気になる
記事の半分でも理解できるくらい、もっと学びたいのに、どこから始めればいいのか分からない
古い本だが優れていて、さまざまな手法や実習を追っていける
最新のツールは当時とは少し変わっているが、x86 命令セットやアセンブリ全般は大きく変わっていない
大きな収穫の一つは
crackmeを知ったことだったリバースエンジニアリングを学ぶために作られた小さな挑戦用バイナリで、ピッキングコミュニティにおける練習用の錠前のような存在だ
記憶では、本には CD-ROM で複数収録されていて、オンラインでも探せばたくさんある
こうした練習を実際にやってみることが学ぶ道だ
最初から COD をリバースエンジニアリングしようとしてはいけず、段階的に積み上げる必要がある
UnknownCheats や cs.rin.ru などを見ていた人たちに挨拶したい
自分もそこで活動していて、特に Linux ユーザー空間のアンチチート、その中でも VAC がどう動くのかにより関心がある
人気のある Horde/Alliance ベースの MMO を少しリバースエンジニアリングしてみたが、ほぼ同じ手順を踏んでいて、FNV32 のエクスポートハッシュも含まれていた
非常によく似たトリックを使っているのを見て、ほとんど同じ方式のように見える
同じ保護技術でパックされているのか気になる
シグネチャスキャン は本当に強力だ
リバースエンジニアリングで自分にとって最も中毒性のある部分でもある
シグネチャ一覧を作り、その関数ポインタを呼び出せるようにスクリプト言語バインディングを書く過程が楽しい
多くのサードパーティ製 Mod プラットフォームの基盤でもある。というのも、一次開発元が公開していない意味のある API を Modder に提供する必要があるからだ
いくつかの Source エンジンプラグインも、必要に応じてこの方式を使っていると理解している
ただし大半は仮想関数テーブルポインタのオフセットを使っているようだ
定期的にゲーム状態へ電子署名したり、何らかの プルーフ・オブ・ワーク を入れたりしてチートを防ぐことは可能、あるいは意味があるのではないかと思う
チートは防ぐのがあまりにも難しい問題だと思い始めている
小規模で安価なオンライン FPS を作っているが、アンチチートソフトウェアを置くより、ユーザー同士で信頼し、チーターを自分たちで見つけてもらうか、Valve のように AI を使う方向を考えている
プレイヤー自身にサーバーを管理・運営させることになりそうだ
携帯電話番号の連携、他プレイヤーからの評判スコア、身分証やほかの強力な認証手段、デーティングアプリのような写真による手動認証、ランク戦前に10時間プレイといった条件を設けられる
ハードコアプレイヤーはチーターを減らすためなら、こうした手続きを進んで行うと思う
気に入らないプレイヤーを通報してBANさせようとする社会的な悪用もある
そういうシステムでは、どんなアンチチートよりも誤検知がはるかに多くなるだろう