Как предотвратить обман в наших (многопользовательских) играх?

Ответ 1

Я не думаю, что вы должны что-то сделать, чтобы перестать обманывать одиночные игры. Ваши пользователи купили игру, они должны быть в состоянии обмануть, если захотят, до тех пор, пока они не играют против других.

Вот несколько вещей, которые я сделал. Они были в основном сделаны для анти-чит-систем в турнирных играх, где на карту поставлены деньги, и определенные уровни вторжения в пользовательскую систему считаются приемлемыми. Я был бы осторожен в том, чтобы делать некоторые из этих вещей в казуальных играх, поскольку, если ваша игра нестабильна, есть потенциальная возможность создавать проблемы с их системой.

1) По возможности, "Никогда не доверяйте клиенту" - ваш самый безопасный принцип. Выполняйте все действия на сервере и предоставляйте клиенту столько знаний, сколько необходимо для отображения того, что он должен видеть на экране в любой момент времени. то есть, если клиент не знает позицию игрока, который скрыт за стеной, взлом стены не принесет пользы пользователю. Для игр с высокими скоростями это может быть чрезвычайно сложно - особенно сейчас, когда тени в реальном времени и т.д. Являются нормой, когда пользователю может понадобиться видеть тень, даже если тело игрока видимо, но оно всегда должно быть в верхней части ваших опций. Также чрезвычайно сложно делать одноранговые игры, но есть способы ограничить знания между сверстниками. Только в том случае, если это становится неподъемным для производительности или вне вашего бюджета времени/денег, следует учитывать следующие пункты.

2) Откройте все остальные процессы и зацепите их функции WriteProcessMemory, чтобы они не могли записывать в память вашего игрового процесса. Сделано правильно, этот один шаг будет блокировать 90% всех читов и чит-движков.

3) Сделайте то же самое, подключив различные функции эмуляции мыши и клавиатуры. Это предотвратит много боеголовок и других типов ботов автоматизации.

4) Подключитесь к функциям VirtualProtectEx/VirtualAllocEx/etc в своей игре и проверьте, какие модули изменяют уровни защиты или выделяют новые куски памяти. Вы должны быть хитрыми с этим, чтобы предотвратить чрезмерную интенсивность процессора, когда ваша игра делает много распределений, но это можно сделать.

5) Подключитесь к функциям LoadLibrary и контролируйте любые DLL файлы, которые загружаются динамически, чтобы предотвратить инъекцию DLL.

6) Используйте некоторые легкие полиморфные кодировки в ваших игровых подключений.

7) Используйте некоторые методы отладки, чтобы предотвратить добавление отладчиков к вашим процессам. Анти-отладка Google, и вы сможете найти много вещей.

8) Используйте специальный запатентованный PE-упаковщик, чтобы предотвратить полезную разборку вашей игры.

9) Подключитесь к функциям и методам OpenGL или Direct3D, которые касаются прозрачности и альфа-смешивания.

10) Если вы используете шейдеры, проверяйте свои шейдеры и значения константы шейдера.

11) Используйте дополнительные методы отбраковки окклюзии на персонажах игроков, чтобы они вообще не отображались, когда линия зрения на них блокируется другой геометрией. Это может или не может помочь с вашей работой, но это предотвратит многие Wallhacks.

Ответ 2

Вы можете найти эту статью в чит-протоколах. Все они вариации по одной и той же идее: используя хеши в качестве обещания, а затем раскрывают смысл хешевого обещания, когда выполняются условия поведения других игроков. Это сложно, и это имеет влияние на производительность, но некоторые из идей могут быть полезны, особенно для сверстников в одноранговых играх.

Ответ 3

Когда игра основана на полностью архитектуре сервера-клиента, работа почти завершена, я думаю, но есть также настенные хаки или что-то еще.

Если вы не можете переместить большую часть логики для работы на стороне сервера, по крайней мере, попытайтесь использовать как можно меньше состояний, насколько это реально возможно во время каждой фазы игрового процесса, другими словами: учитывайте режим активной игры каждого игрока и только обмениваться информацией, которая действительно актуальна в то время.

Это не только уменьшит возможность обмана, но и уменьшит трафик, вызванный вашим протоколом, то есть повысит эффективность.

Это техника, которая сама по себе уже давно известна и применяется в индустрии игр и моделирования для повышения эффективности при рендеринге больших 3D-сцен.

Там, "открутка усечения" используется, чтобы определить, какие части сцены действительно видны, чтобы отображались только соответствующие части.

Аналогичным образом, тот же метод может использоваться для ограничения многопользовательских клиентов получать только определенные обновления/информацию, если они действительно актуальны, например. если другие клиенты фактически находятся в пределах "диапазона релевантности", чтобы другие клиенты могли получать соответствующие обновления.

Тем не менее, различайте релевантность и "видимость": два игрока, разделенные дверью, не могут "видеть" друг друга, но в зависимости от окружения могут очень хорошо слышать друг друга. Таким образом, различать разные типы "видимости": распространение звукового состояния необязательно подразумевать распространение фактической позиции игрока в координатах игры. То же самое относится наоборот: только потому, что вы видите "игрока", вы не всегда имеете право также слышать клиента (например, представить себе область на винтовке).

Другими словами, попробуйте свободно связывать пакеты обновлений, которые вы поддерживаете, чтобы они не имели взаимных зависимостей друг от друга, а также могут быть размножены/подписаны независимо.

Обман может в значительной степени контролироваться только путем применения надлежащих механизмов инкапсуляции и скрытия данных, так что многопользовательские клиенты обычно не имеют общего глобального состояния, но совместное состояние напрямую зависит от активного контекста игрока (позиция, заголовок, ориентация, скорость и т.д.).