Защита от читеров в клиент-серверной игре

Question

[Артём]

Разрабатываю простую игру с клиентами для браузера и мобильных телефонов и серверной части. Пользователи будут проходить квесты и получать за это какие-то бонусы, которые затем через обычный HTTP GET/POST будут передаваться на сервер.

Интересуют способы о том, как защититься от читерства. в Q&A был один похожий вопрос и пару статей на хабре, но всё же не совсем то.

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

Answer 1

[rPman]

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

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

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

p.s. p2p связь возможна? перенесите часть обработки (проверки валидности/реальности событий управления персонажами) на соседнего клиента (ближайшего с точки зрения сети) — это поможет частично разгрузить сервера.

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

Comments

[Артём]

Спасибо за ответ! А можете уточнить про серверную часть — какие возможности существуют?

[joger]

Универсальный механизм — это проверка любого чиха юзера на сервере. всё остальное это полумеры:)

[joger]

например: герой движется из точки А в Б и получает за это 100500 бонусов. неправильно: клиент отправляет серверу запрос «прибыл в Б, запишите бонус». лучше: из А клиент отправляет запрос «я в А, хочу в Б. можно?», на что получает ответ «Да, можно. Получите бонус». Т.е. клиенту нельзя доверять больше, чем джойстику. IMHO:)

[ivsedm]

Последний ответ самый правильный имхо :)

[Volfram]

Я бы даже сказал так:
Клиент: «Хочу в Б»
Сервер: «Текс, помнится, вы были в А, ага, ну что ж, отправляйтесь».
… спустя некоторое время
Клиент: «А бонус?»
Сервер: «А ты не суетись!»
… спустя ещё некоторое время
Клиент: «Ну бонус!»
Сервер: «Вот, получите, распишитесь»

Параноидальная шизофрения — ваш лучший друг.

Answer 2

[korvindest]

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

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

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

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

4. Создать функцию, которая по каким то вам одному ведомым империческим параметрам характерезует суммарную скорость роста игрока за период и следить внимательно за лидерами.

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

6. Все действия игрока следует сопровождать идентификатором сессии(Я понимаю, что тут я КЭП, но все же), который стоит периодически подменять, не требуя повторной авторизации, если использование более старого идентификатора было не так давно.

7. Написать набор функций проверяющих наличия в базе нереальных значений. Например: в доме где максимум жильцов составляет 10 человек живет уже 236. Или суммарные затраты на содержание электростанции составляют -135 валюты. Это так же позволит обнаруживать особо наглых читеров.

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

Ну а вопрос шифрования оставлю на людей, более компетентных в этом вопросе.

Comments

[Артём]

Спасибо большое за развёрнутый ответ!

Answer 3

[AlpenColt]

Не забудьте про ботоводов. На dtf.ru была не плохая статья на эту тему. Вообще, рекомендую полазить по данному ресурсу, т.к. можно много интересной информации накопать.

Ещё хотел бы добавить, что чистое шифрование не поможет, об этом упомянул вскользь korvindest, но я уточню. Даже не расшифровывая сам запрос, мы может понять что при отправке пакета X на сервер происходят определённые действия. И этим легко воспользоваться при любой автоматизации действия, в то числе и при читерстве. Поэтому в данные нужно подмешивать некоторые уникальные IDшники, которые будут постоянно обновляются.

Comments

[Артём]

Отличный сайт. Спасибо за линк! Ушёл читать

Answer 4

[Виталий Сергеев]

Пожалуйста, уточните условие «Пользователи будут проходить квесты и получать за это какие-то бонусы, которые затем через обычный HTTP GET/POST будут передаваться на сервер». Кто будет передаваться? Бонусы?

Если квесты проходятся локально на клиенте, а через HTTP посылается готовый результат — то как ни защищайся, читы не предотвратишь (слишком много векторов атаки, возможна не только подделка трафика, но и вмешательство в работу самой игры). Если же прохождение квестов отслеживается со стороны сервера, а через HTTP игроку даётся лишь конечный интерфейс — то и читерить не получится.

Comments

[Артём]

Пока есть возможность выбирать логику и соответственную защиту, поэтому и создал этот вопрос. Я не знал, например, как лучше сделать отправление бонусов за прошедший квест — проходить весь квест на клиенте, высчитывать бонус, подписывать его ключём и затем отсылать, либо же это как-то по-другому делать. Теперь я понял, что делать надо по-другому :-)
Про GET/POST хотел обратить внимание, что все данные передаются по открытому HTTP без какого-либо шифрования.

[simon311]

Методов защиты со стороны клиента довольно много. Во-первых, самый простой вариант это отслеживать, чтобы все расчёты были правильными. К примеру, чтобы игроки не тратили на вещи отрицательное, или слишком маленькое количество денег, а именно столько, сколько оно стоит (т.е. по принципу доверяй, но проверяй). Если это квесты — то пусть отправляет полный отчёт, а затем можно искать в нём противоречия, к примеру если игрок не побывал в локации, где обязательно нужно побывать для прохождения этого квеста, то он, очевидно, считерил. Ну и так далее.
А можно отправлять клиенту числа, а в клиенте для каждого действия во время квеста будет назначено математическое действие. Т.е. в процессе прохождения квеста клиент считает некое выражение, используя переданные ему числа и математические действия, назначенные действиям в квесте, затем результат сравнивается с серверным.
Реализаций много можно придумать.

[dgrudinin]

Добавлю немного от себя.

Для того, чтобы действия подобного рода были защищены от читерства/подмены, достаточно сделать обмен данными с сервером наподобие игры в «пинг-понг».

Мораль в том, что на клиенте пользователь выполнил некоторое действие, при этом у клиента есть некий временный токен (не идентификатор сессии). Клиент передаёт запросом GET/POST/etc. серверу сообщение о действии с включённым в сообщение токеном.

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

Ответ клиенту выдаётся со свежесгенерированным токеном. И так далее.

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

Answer 5

[Вася]

Adblock Plus Android есть возможность фильтровать трафик