1つの層だけでは足りない理由
多くのファイブエム アンチチートは、検知を1つの層に頼っています。注入されたDLL、フックされたAPI、既知のメニューのシグネチャを監視するクライアント側のスタックか、イベントを検証してあり得ないゲーム状態の遷移を拒否するサーバー側のスタックのどちらかです。それぞれに既知の弱点があります。クライアント側だけのACは、チートがローダーをシグネチャチェックから隠した瞬間に破られます。サーバー側だけのACは、チートが正規のイベント面だけを使い、サーバーイベントを一切発生させないクライアント側のハック（サイレントエイム、ESP、ウォールハック）に切り替えた瞬間に破られます。二層構造の検知なら、チートが見えている層がそれを捕まえ、見えていない層も管理者が確認できる挙動上のシグナルを残します。
クライアント層が監視するもの
クライアント側では、Ravenは注入されたモジュール、フックされたエンジン関数、NUI DevToolsの状態、自身のリソースファイルの整合性、そして既知のチートローダーが動いていないかを監視します。最も活発なMODメニュー系統（Eulen、Redengine、HamMafia、Susano、TZ、TZX、Skript、Phaze、Lumia）のシグネチャは、1〜7日の出荷サイクルで最新に保たれます（/changelogを参照）。既知のシグネチャが反応すると、証拠（スクリーンショットと検知トレース）が取得され、クラウドパネルにアップロードされます。シグネチャは反応しないが異常だけが出た場合は、そのプレイヤーの信頼スコアが下がり、管理者のレビュー用にライブマップへ表示されます。
サーバー層が監視するもの
サーバー側では、プレイヤーが発生させるすべてのサーバーイベントに対して、Ravenがイベント検証のパスを走らせます。クライアントから来るはずのないイベント名は、その場でブロックされます。妥当な範囲を超えるイベントのペイロード（アイテムの数量、所持金の増減、1分あたりの車両スポーン数）は拒否され、ログに残ります。Redengineの亜種が使うイベント連鎖のような既知のエクスプロイトのパターンに一致するイベント列は、パターンの段階でブロックされます。サーバー側の検知は、クライアント側のチェックがすべてバイパスされても動きます。だからこそサーバー側のカバーは譲れません。
2つの層はどう連携するか
ハートビートのループが2つの層を結びます。クライアントは、重要なランタイム状態の署名付きハッシュを定期的にサーバーへ報告します。ハートビートが止まれば、サーバーはそのクライアントを改ざんされたものとして扱い、設定された対応（警告、KICK、自動BAN）を実行します。ハートビートは届き続けているのにペイロードが期待値と一致しなくなった場合は、サーバーがその差分をログに残し、信頼スコアのモデルへ送ります。いずれにしても、サーバーはクライアント層がまだ機能しているかを常に把握しているので、クライアント層を無効化するチートはすぐにサーバー側から見えるようになります。
「バイパスされにくい」がなぜ重要か
バイパス不可能なアンチチートは存在しません。単層のACをバイパスするには、1つのスタックを破ればすみます。二層構造のRavenをバイパスするには、2つのスタックを同時に破り、さらにハートビートと、挙動の異常を表に出す信頼スコアのモデルも突破する必要があります。検知されないバイパスを成立させるコストは目に見えて高くなり、パッチが出るまでの時間も短くなります。チートに気づいた側の層が、そのキャプチャデータを次のシグネチャ更新を出すチームへ渡すからです。