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

Question

Если вы пишете игру, вам следует подумать о мошенниках и о том, как предотвратить их обман.

Я думаю, что не только многопользовательские игры mmo, но и однопользовательские или "домашние" p2p mp-игры тоже.

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

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

Большинство спидхаковских хуков gettickcount. Я разобрался со спидхакерами по следующему простому трюку. Я просто отслеживаю значение time()-GetTickCount(), и если разница меняется, это обман.

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

Чтобы разобраться с Cheat Engine, просто проверьте:

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

(друг сказал мне это, я еще не проверял.)

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

Answer 1

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

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

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

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

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

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

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

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

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

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

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

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

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

Answer 2

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

Answer 3

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

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

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

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

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

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

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

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

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