35

ゲームを作成している場合は、不正行為者について考え、不正行為を防止する方法を検討する必要があります。

私は、mmo マルチプレイヤー ゲームだけでなく、シングルプレイヤーまたは「自作」の p2p mp ゲームもそうだと思います。

ゲームが完全にサーバークライアントアーキテクチャに基づいている場合、仕事はほぼ完了していると思いますが、ウォールハックなどもあります.

私は自分の P2P ゲームを作ったのですが、しばらくすると詐欺師が現れました。彼らは、チート エンジンを使用し、スピードハックやメモリ ハックを試みたスクリプトキディだけでした。

ほとんどのスピードハック フックは gettickcount です。私は次の簡単な方法でスピードハッカーを選別しました。私は値を追跡しているだけtime()-GetTickCount()で、差が変わると不正行為があります。

メモリの破損は、ハッシュされたコピーをどこかに保持し、常に移動し、常にランダムな値で再ハッシュすることで整理できます。不一致はクラッシュを引き起こします。

チートエンジンを完全に整理するには、次を確認してください。

if (OpenFileMapping(FILE_MAP_READ,false,'CEHYPERSCANSETTINGS')!=0)
{
   // Cheat Engine runs.
}

(友人が私にこれを教えてくれました、私はまだそれをテストしていません。)

これらのトリックは、ほとんどの詐欺師を選別しました。しかし、もちろん、より多くの不正行為のテクニックがあります。このウィキを開いて、別の不正行為のテクニックとそれらを回避する方法について話し合いました。

4

3 に答える 3

58

シングルプレイヤーゲームでの不正行為をやめるために何もすべきではないと思います。ユーザーがゲームを購入した場合、他のユーザーと対戦していない限り、必要に応じてチートできるはずです。

これが私がしたことのいくつかです。これらは主にトーナメントゲームのアンチチートシステムのために行われ、そこではお金が危機に瀕しており、ユーザーのシステムへの特定のレベルの侵入は許容できると考えられています。ゲームが安定していないと、システムに問題が発生する可能性があるため、カジュアルゲームでこのようなことを行う場合は注意が必要です。

1)可能な場合は、「クライアントを絶対に信用しない」が最も安全な原則です。サーバー上ですべてのアクションを実行し、クライアントがいつでも画面に表示できるはずのものをレンダリングするために必要な知識だけをクライアントに提供します。つまり、クライアントが壁の後ろに隠れているプレーヤーの位置を知らない場合、ウォールハックはユーザーに何の役にも立ちません。高速アクションゲームの場合、これは非常に難しい場合があります。特に、リアルタイムの影などが標準になっているため、ユーザーの体が見えても影を見る必要がある場合がありますが、常にそうする必要があります。オプションの上部にあります。また、ピアツーピアゲームで行うのは非常に困難ですが、ピア間の知識を制限する方法があります。それが法外なパフォーマンスになったとき、またはあなたの時間/お金の予算の外になったときだけ、

2)他のすべてのプロセスを開き、WriteProcessMemory関数をフックして、ゲームのプロセスのメモリに書き込めないようにします。この1つのステップを正しく実行すると、すべてのチートとチートエンジンの90%がブロックされます。

3)同じことを行い、さまざまなマウスとキーボードのエミュレーション機能をフックします。これにより、多くのエイムボットやその他のタイプの自動化ボットを防ぐことができます。

4)ゲーム独自のプロセスのVirtualProtectEx / VirtualAllocEx / etc関数に接続し、どのモジュールが保護レベルを変更しているか、新しいメモリチャンクを割り当てているかを監視します。ゲームが多くの割り当てを行うときにCPUを集中的に使用しないようにするには、これを巧みに使用する必要がありますが、それは可能です。

5)LoadLibrary関数に接続し、動的にロードされているDLLを監視して、DLLインジェクションを防ぎます。

6)ゲーム接続で軽量のポリモーフィックエンコーディングを使用します。

7)いくつかのアンチデバッグ手法を使用して、デバッガーがプロセスに接続しないようにします。グーグルのアンチデバッグとあなたはたくさんのものを見つけることができるはずです。

8)カスタムの独自のPEパッカーを使用して、ゲームの有用な分解を防ぎます。

9)透明度とアルファブレンディングを処理するOpenGLまたはDirect3Dの関数とメソッドに接続します。

10)シェーダーを使用している場合は、シェーダーとシェーダー定数値をチェックサムします。

11)プレイヤーキャラクターに追加のオクルージョンカリングテクニックを使用して、他のジオメトリによって視線が遮られたときにキャラクターがレンダリングされないようにします。それはあなたのパフォーマンスにも役立つかもしれないし、役に立たないかもしれませんが、それは多くのウォールハックを防ぎます。

于 2009-06-06T22:25:20.407 に答える
16

チートプルーフゲームプロトコルに関するこの論文は興味深いと思うかもしれません。これらはすべて同じアイデアのバリエーションです。ハッシュを約束として使用し、他のプレイヤーの行動の条件が満たされたときにハッシュされた約束の意味を明らかにします。これは複雑で、パフォーマンスに影響を与えますが、一部のアイデアは、特にピアツーピアゲームに役立つ場合があります。

于 2009-06-07T03:04:29.750 に答える
5

ゲームが完全にサーバークライアントアーキテクチャに基づいている場合、仕事はほぼ完了していると思いますが、ウォールハックなどもあります.

ほとんどのロジックをサーバー側で実行するように移動できない場合は、少なくとも、各ゲーム プレイ フェーズで現実的に可能な限り少ない状態を共有するようにしてください。つまり、各プレイヤーのアクティブなゲーム モードを考慮に入れ、必要な情報のみを共有します。その時点で実際に関連しています。

これにより、チートの可能性が減るだけでなく、プロトコルによって引き起こされるトラフィックも減ります。つまり、効率が向上します。

これは、大規模な 3D シーンをレンダリングする際の効率を向上させるために、ゲーム/シミュレーション業界で長い間知られており、適用されてきた手法です。

そこでは、「フラスタム カリング」を使用して、シーンのどの部分が実際に表示されるかを判断し、関連する部分のみがレンダリングされるようにします。

同様に、他のクライアントが対応する更新を取得できるように、他のクライアントが実際に「関連性の範囲」内にある場合など、実際に関連する場合にのみ、特定の更新/情報を受信するようにマルチプレイヤー クライアントを制限するために同じ手法を使用できます。

それでも、関連性と「可視性」は区別してください。ドアで隔てられた 2 人のプレイヤーは、実際にはお互いを「見る」ことはできませんが、周囲によっては、お互いの声がよく聞こえる場合があります。したがって、さまざまな種類の「可視性」を区別してください。可聴状態の伝播は、必ずしもゲーム座標におけるプレーヤーの実際の位置の伝播を意味する必要はありません。逆もまた同様です。プレーヤーを「見る」からといって、必ずしもクライアントの声を聞く資格があるとは限りません (たとえば、ライフルのスコープを想像してみてください)。

つまり、サポートする更新パケットを疎結合にして、相互に依存せず、独立して伝播/サブスクライブできるようにします。

不正行為は、適切なカプセル化とデータ隠蔽メカニズムを適用するだけで大​​幅に制御できるため、マルチプレイヤー クライアントは通常、グローバルな状態を共有しませんが、共有状態はプレイヤーのアクティブなコンテキスト (位置、方向、向き、速度など) に直接依存します。

于 2009-06-07T19:28:02.287 に答える