オンラインゲームで詐欺師と戦う：22の「必要」および「不可能」

不正行為者のいない、成功したマルチプレイヤーオンラインゲームを見つけることはほとんど不可能です（開発者の友人のみがプレイするゲームを除く）。 言い換えれば、公開ゲームに詐欺師がいない場合、それは十分に人気がないか、不正検出がうまく機能しません。 その他の場合はすべて、不正行為に対処する必要があります。 ゲーム詐欺との戦いで、必要な手順と実行しない手順のリストを調べてください（不正行為のトピックに関する詳細な議論は、3巻の本で説明されています。記事の最後にあるメモを参照してください）。

1.不正行為者をブロックする権利を使用条件に追加する

この権利を追加するだけでなく、そのような決定が「自分の裁量で」行われることを示すことも必要です。 ただし、ここで問題が発生する場合があります。

• 注：私は弁護士ではありません。この記事を法的助言と見なす必要はありません。 弁護士に相談してください。
  
  
  
  
• これは複雑な法的問題であり、その解決策は居住する国または地域によって異なります。 自分でこの問題について決定を下すのではなく、あなたの使用条件が法廷で有効な契約とみなされるかどうか弁護士に尋ねてください（彼はあなたの国から来た方が良いです）。 GDC 2016では、大企業の人と話をしていました。 彼らにとって最も難しかったのは、禁止された不正行為者の法的問題でした。
  
  
  
  
• ここでのポイントは簡単です-不正行為をした場合にプレイヤーを禁止できるようにすること。 ただし、裁判所で不正行為の事実を証明する必要がないことが明確になるように、利用規約を策定する必要があります。そうしないと、不正行為者の訴追は費用がかかりすぎます。 ここで最も重要な法的問題は「証拠の負担」です。不正行為者が不正行為を行っていることを証明する必要がありますか、それとも非難された不正行為者が無実であることを証明する必要がありますか？ ご存知のように、後者はあなたにとってはるかに有益であり、詐欺師にとってはより悪いものです。 この問題を解決する可能性のある方法の1つは、「このような決定は独自の裁量で行われる」という節を挿入することであることを既に述べました。 ただし、関連する管轄区域でそのような留保の有効性を検証することが不可欠です。
  
  
  
  
• 可能であれば、不正行為が利益をもたらさないように、払い戻しなしでプレーヤーをブロックできることが最善です。 しかし、これが不可能な場合、払い戻しでブロックすることは、一般的に不正行為者をブロックできないことよりもはるかに優れています。
  
  
  
  
• プレイヤーが使用に関してそのような言語について文句を言うことをあまり心配しないでください。 ほとんどのプレイヤーはまだ条件を読んでおらず、異なるゲームの条件を比較するとき、彼らはまだ一般大衆にとって互いにほとんど違いがありません。 ただし、この言葉遣いを乱用しないでください。さもないと、すぐに問題が発生します。

2.サードパーティの保護エンジンを使用している場合は、その上にできるだけ多くの保護を追加する必要があります（または、サードパーティと保護を組み合わせてください）

もちろん、セキュリティエンジンのサードパーティの開発者は、自分たちが何をしているのかをよく知っていますが、セキュリティによるセキュリティの原則のあるシステムをハッキングする状況では、そのようなエンジンはハッカーコミュニティ全体の標的になります。 したがって、上からの保護を追加すると、位置が大幅に改善されます。

3.最初から不正行為者と戦う必要がある

不正行為者のコミュニティがあなたのゲームのためにチートを売ってお金を稼いでいるとすぐに、あなたの側のどんな行動もより多くの抵抗を引き起こします。 言い換えれば、詐欺師を養わないでください。

4.権限のあるサーバーを使用する必要があります

これは本当に重要です。 さらに、すべてのロジックをサーバーに移動する必要があります。 理想的な状況では、クライアントで決定を行うべきではありません。 これは常に100％可能というわけではないので（主にゲームのペースが非常に速いため）、クライアントで行われたすべての決定と戦う必要があります。 クライアントでより多くの計算が実行されるほど、攻撃者はより多くの機会を得ます。 サーバー側に積極的にすべてを移植しないと、これは次第に非常に大きな問題になります（私はこれに遭遇し、GDC 2016でこのトピックに関するレポートが1つありました）。



決定的ロックステップアーキテクチャ（入力データを送信することによってのみ同期が発生するアーキテクチャ）に準拠しないでください。 決定的ロックステップアーキテクチャを備えたゲームは、クライアント側の決定に苦しむ可能性は低いものの、情報漏洩攻撃（WallhackやMaphackなど）に対して非常に脆弱です。クライアントを必要な情報のみに制限する方法については、以下のセクションを参照してください。

5.トラフィックを暗号化するために必要

トラフィックの暗号化により、プロキシ（それ以外の場合はほとんど処理できない）や一部のボットに基づくものなど、いくつかの種類の攻撃から身を守ることができます。



これに関するコメント：

• いいえ、UDPを使用することは、トラフィックを暗号化しないことの言い訳にはなりません。 DTLSと他のいくつかのプロトコルがここで助けになります。
• OpenSSLライブラリを静的にバインドする必要があります。 OpenSSL.DLL（またはDLLを介した他の暗号化実装）は、暗号化を回避するための保証された方法を攻撃者に提供します。
• 匿名Diffie-Hellmanプロトコル（ADH）を使用しないでください。 はい、これはすべての本に書かれていますが、開発者がそれを使用するゲームがまだあります（少なくとも1つのゲームは、AboutウィンドウでADHに言及していました！）。
• クライアント側で保存されたルート証明書を検証することが必要です（はい、一部の開発者はまだ検証していません）。
• ユーザーのマシンの証明書を使用しないでください。 代わりに、独自の認証局を作成し、ルート証明書をクライアントに埋め込みます（そうしないと、MITM攻撃の可能性が高まります）。
• クライアント実行可能ファイルのルート証明書を難読化します。そうしないと、異なるタイプのMITM攻撃を受けます。

6.公的に入手可能なチートを追跡する必要があります

それらを見つけ、分析し、できるだけ早く修正をリリースします。 ゲームが十分に成功した場合は、このために別のチームを強調する価値があります。



チートを分析するときは、次の原則を忘れないでください。



明らかに、チートの人気が高いほど、修正リストの上位に表示されるはずです。

• さらに明白なことは、自分のネットワーク内でチートを実行しないでください（そうでなければ、非常に多くの詐欺師の夢が実現します）。 代わりに、ファイアウォールで安全に囲まれたサンドボックスを作成します（内部ネットワークとサンドボックスの間にVPNがない理想的な場所に配置するのが理想的です）。

7.有名な詐欺師を雇わないでください

このルールには実際には例外があります。 まず、ホワイトハットハッカーには適用されません。 第二に、次の条件のすべてを条件として、有名な詐欺師を雇うことは許容される場合があります。

• プログラムの「内部」（特にソースコード）への特別なアクセス権はありません。
• ブラックボックスハッキングのみを実行する必要があります（とにかく実行します）。 唯一の違いは、ハッキングの結果を報告し、使用しないことです。
• 雇われた詐欺師とのすべての通信は、別の電子メールアカウントから維持する必要があります（システムの他の部分から完全に隔離されています）。
• この別のアカウントからのすべての情報へのアクセスは、チートプログラムを分析するように構成された「サンドボックス」内でのみ行う必要があります。

8.ロックポリシーについて考える必要がある

詐欺師を永久に禁止するのですか、それとも数日間禁止するのですか？ 繰り返しの犯罪者についてはどうでしょうか（GDC 2016では、不正行為者の72％が再び不正行為を試みると言われました）？ 不正行為者が新しいアカウントを開くことに対してどのような保護がありますか（ヒント：PC上のF2Pゲームにはそのような保護はほとんどありません）。

9.チェックされたルール：不正行為の苦情についてプレイヤーに依存しないでください

さらに、プレイヤーが不正行為について不平を言うことを奨励することはできません。 いずれにせよ、彼らは自分たちが不正行為だと考えていることについて不平を言うでしょうが、苦情を押し付けると、かなり多くのプレイヤーが妄想に簡単に変わる可能性があります。 場合によっては、投票のブロックが必要になる場合がありますが、プレイヤーが対戦相手を蹴ることを許可することはめったにありません。



一方、不正行為に関する苦情を真剣に受け止め、そのようなレポートの情報を手動で表示することは必要です。 これを行うには、ゲームが成功した場合に別のチームが必要です。 そして、そのような分析を実行するのに十分な情報（統計およびその他）を収集する必要があります。 このような情報をデータベースに保存し、不正対策チームの要求に応じてレポートを追加することが必要です。

10.必要な情報のみをクライアントに転送する必要がある

つまり、いわゆる「利益管理」システムを実装します。 クライアントのデータはハッキングされる可能性があるため、公開すべきではない機密情報を送信することは非常に悪い考えです。 インタレスト管理を実装しない場合、ゲームをチートし、壁を透明にし（Wallhacks）、戦争の霧を除去する（Maphacks）だけでなく、ESPチート（敵の健康やその他のパラメーターを見ることができます）がほぼ保証されます。

11.クライアントでC ++を使用する必要があります

C ++はハッキングできますが、通常は「クラッキング」と「本格的なリバースエンジニアリング」を分離します。 私の経験では、C ++プログラムは「クラック」される可能性があります（つまり、限られたチェックセットを見つけて無効にし、限られた数のメモリロケーションを見つけて変更できます）が、C ++の本格的なリバースエンジニアリングはC＃/ Javaよりもはるかに複雑です（EmscriptenをコンパイルせずにJavaScriptについても話していない）。



すでにこれについて言及している場合、この目的のためにEmscriptenはC ++とほぼ同じくらい優れていることに注意する必要があります。 今は何でも言葉を確認できませんが、私が知っていることから判断すると、すべてがまさにそのように見えます。

12.デバッグ情報を内部に含むゲームをリリースしないでください。

これを説明する必要がありますか？

13.コードを調べて、すべてのエラーメッセージを除外する必要があります

つまり、あなた以外の誰にとっても重要ではないすべてのメッセージを取り除く必要があります（それらを保存したい場合は、いつでも対応するハッシュに置き換えることができます）。



使用したアルゴリズムがサードパーティのライブラリからの無害なメッセージから復元されたケースを覚えています。これにより、ほとんどハックの作成が簡素化されました。 繰り返しますが、クライアントに対して特定の情報を使用できるため、すべてをクライアントで難読化する必要があります（はい、これはミランダのルールに非常に似ています）。

14.あなたの人生としてソースコードを保護する必要がある

ソースがハッカーに流れる場合、99％の難読化は意味がありません。



特に、大企業の場合は、ソースコードを複数のパーツに分割して、各パーツが対応するチームのみが利用できるようにします。 とりわけ、これはあなたのチームに対する標的型フィッシング攻撃によるダメージを軽減するのに役立ちますが、そこから防御することはほとんど不可能です。

15.クライアントの整合性を検証する必要があります（リソースや構成を含む）

これは、少なくともクライアントを起動するときに実行する必要があります（理想的には、その作業の途中ですが、それは別の話です）。



また、クライアントが危険にさらされた場合にレポートがサーバーに送信されるようにします-これがチートでない場合、それは間違いなくアラームです。

16.クライアントの不正行為者に「トラップ」を設定する必要がある

典型的なトラップの例を次に示します。

• 同じ値がクライアントのメモリに2回保存され、その時々で同等かどうかがチェックされます。 このようなトラップを有効にするには、少なくとも1つのストレージ位置でメモリを難読化する必要があります（たとえば、XORを一定の値にすると、もっと複雑に実装できます）。 値が同じでない場合、これは非常に邪魔な信号ですが、そのような矛盾の1つのケースが説得力のある証拠と見なされたという事実に反対します。 ゲームに100万人のプレイヤーがいる場合、非常に奇妙なことが時々起こることがあります。
• クライアントコードの重要な部分の整合性をチェックし、疑わしい埋め込みDLLの存在をチェックします。
• コードの実行時間を測定して、クライアントのデバッグを示す異常に長い遅延を検索します。 この場合、x86 / x64プラットフォーム用のRDTSC命令は興味深いオプションです。これは、カーネルデバッガーを使用しても時間を測定できることが多いためです。
• 別の特別なタイプのトラップはハニーポットです。 技術的には、ハニーポットは通常のトラップとは異なり、詐欺師のために人工的な標的が作成されます。

17.あなたが彼を捕まえたことをすぐに読者に知らせないでください。

不正行為者を即座にブロックする代わりに、通常は禁止を延期することが常に最善です。 個人的に、私は「ロックの波」の大ファンではなく、各プレイヤーにランダムな遅延を好みますが、ロックの波でさえ即時の禁止よりもはるかに優れています。

18.ほとんどすべての遅延補償が時間ベースのチートの機会を提供することを忘れないでください。

実際の遅延を、ハッキングされたクライアントによって導入された遅延（人工的な遅延）と区別することはほとんど不可能です。 一方、十分にすっきりしている場合は、そのようなチートがゲームプレイに与える影響を制限できます。

19.コンピューターを識別する手段に依存しないでください

それらを実装することはできますが、コンピューターの識別が簡単であることを忘れないでください（マーケティング/収益化/ビジネスインテリジェンス部門もこれを知っていることを確認してください。そうでなければ、広告の悪用を防ぐために識別に依存します）。

20.不正行為に関連する可能性のある統計を収集する必要がある

たとえば、プレイヤーが95％の時間で体の5％を占める敵の重心に落ちた場合、何かが疑われる可能性があります。



鉄則：統計は直接的な証拠として使用すべきではありません。これは単なる警告です。 この信号で何をすべきかを理解する方法は別の話です。



最後になりましたが、クライアントによってコンパイルされた統計のみに依存しないでください。 つまり、サーバー側で可能な限り多くの統計を収集します。

21.研削ボットを認識するためにキャプチャを考える必要がある

不要なボット（通常はグラインドによって占有されている）に対して非常にうまく機能する保護のタイプの1つはCAPTCHAです。 私はそれがかなり迷惑であることを認めなければなりませんが、開発者がプレイヤーのコミュニティにCAPTCHAの必要性を説明する方法の例を見て、彼らはそれが時々ユーザーをチェックするだけなら「必要な悪」として認識しました。



動作することを忘れないでください。すべての人にとってキャプチャではなく、アラームの1つがトリガーされたときにのみアクティブ化される必要があります。

22.既知の不正ソフトウェアについてプレイヤーのコンピューターをスキャンする準備をする必要があります

これはかなり議論の余地のある問題ですが、この機能を実装する可能性はそうではありません。 ほとんどのゲームでは、プレーヤーのコンピューターをスキャンすることは、チェックされていない不正行為よりもはるかに害が少なくなります（プレーヤーにとってのプロセスの面白さを破壊します。



一般に、このようなスキャンの実装は非常に複雑です（独自のウイルス対策を作成するのと非常に似ています）。ここでいくつかのヒントを示します。

• このようなスキャンの右側のセクションを使用条件に追加する必要があります。
• チートの認識に必要な情報以外は受信しないでください。
• この戦いで詐欺師に負けた場合、デバイスドライバーに基づくソリューションを検討する必要があります（ヒント：そのような商用製品があります）
• スキャンを使用する場合、仮想マシンの開始を認識しなければなりません（VMはソフトウェアを隠すためによく使用され、通常はアラームと見なされる必要があります）
• 2つの認識レベルの必要性を考慮する必要があります。 最初のレベルは、最も明白で人気のあるチートの単純な認識であり、「あなたはルールで禁止されているものを使用しています。 これをする必要はありません。 第2レベルでは、全面的な認識が行われ、禁止に至ります。 ここでのアイデアは、可能であればプレーヤーを失うことなく、手遅れになる前に潜在的な詐欺師を止めることです。 かなり大規模なマルチプレイヤーゲームでこのアプローチがどのようにうまく機能するかの例を見てきました（しかし、ここでは、彼らが言うように、保証はありません）

おわりに

もちろん、上記のリストは完全ではありません。 ゲームが成功した場合、途中で何か新しいことを学ぶ必要があります（非常に難しい場合もあります）。 ただし、この点で私たちを大いに助けた最も重要な原則は次のとおりです。

「熊から逃げるには、彼より速く走る必要はありません。 隣の人より速く走れば十分です。」

ジム・ブッチャー

この場合、これは次のように言い換えることができます。

「不正行為からゲームを保護するために、100％不正行為を防ぐ必要はありません。 競合他社よりも優れていれば十分です。」

バグはありません

チートの経済（特にお金で売られているもの）は、2つの目標があり、1つは非常に魅力的であるが十分に保護され、もう1つは中程度に魅力的であるが保護が不十分な場合、商業的な詐欺師が間違いなく後者を選択することを示しています。 結局のところ、それは単なるビジネスであり、個人的なものではありません。





この記事では、 「マルチプレイヤーオンラインゲームの開発と展開」 （「マルチプレイヤーオンラインゲームの開発とリリース」）の資料に基づいた不正行為のトピックについて簡単に説明します。