Оценка игры основана на обратном отсчете на стороне клиента. Как пуленепробиваемый это?

Question

Я работаю над игрой, в которой счет основан на обратном отсчете JavaScript: чем быстрее вы закончите уровень до того, как обратный отсчет достигнет нуля, тем больше будет ваш счет.

Как я могу убедиться в этомне изменилось ли как-нибудь, когда я наконец получу его со стороны клиента на стороне сервера?

Моя первоначальная идея - создать две контрольные точки: одну в начале уровня и другую в конце.Контрольная точка - это, по сути, сеанс, отправляемый через AJAX на серверный PHP-скрипт, который затем помечается меткой времени.Таким образом, после того, как игра закончена на стороне клиента, результат сравнивается с показателем на стороне сервера.Является ли этот тип защиты хорошим?

Заранее спасибо!

РЕДАКТИРОВАТЬ: Я также открыт для любых других способов достижения желаемой функциональности.

Answer 1

Просто вы сохраняете значение в поле даты и времени в своей базе данных. Затем вы заполняете свой javascript этим значением. Таким образом, любое изменение на стороне клиента не повлияет на сохраненное время.

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

Как только ваш обратный отсчет как-то связан со стороной клиента, выхода нет:)

Answer 2

Как уже отмечали другие, вы не можете быть уверены, что времена не были подделаны, однако есть способы смягчить последствия:

Если у вас есть (серверная) система, которая подозревает , что оценки были подделаны, вы можете занести этот IP-адрес или файл cookie в черный список и не показывать эти оценки другим пользователям. Do покажет оценки хакеру. Это имеет несколько последствий: во-первых, если они думают, что победили вас, они могут пойти дальше и оставить ваш код в покое. Во-вторых, если ваше обнаружение мошенничества ошибочно считает, что игрок ниндзя взломал, игрок все равно будет видеть свой счет в таблицах как обычно (даже если другие игроки этого не делают). Следовательно, ложные срабатывания не имеют большого значения, и вы можете использовать нечеткие алгоритмы, например, Как уровень улучшения этого игрока сравнивается со средним? Получил ли он кучу плохих результатов, а потом неожиданно невероятных? Видел ли мой сервер необычную картину хитов от этого пользователя? И т.д.

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

Answer 3

Есть 2 возможных сценария, с которыми вы можете столкнуться.Позвольте мне начать с простого:

a) Если веб-приложение разработано так, что игра запускается сразу после загрузки страницы, ваша жизнь будет простой.Скрипт, который отсылает игру, должен пометить базу данных временем, в которое игра была отослана.Это было бы время начала.Время окончания будет записано, когда клиент отправит сообщение «уровень завершен».Поскольку в обоих случаях время записывается на стороне сервера, клиенту не нужно хранить время.Однако здесь есть одна загвоздка.См. Раздел The Catch ниже.

b) Если клиент загружает приложение, но игра начинается намного позже, когда пользователь нажимает «play» и т. Д., Ваша жизнь будет немноготруднее.В этом случае вам потребуется сообщение «уровень начат», а также сообщение «уровень завершен», поступающий от клиента.Опять же, было бы лучше держать время на сервере, а не на клиенте.Однако перед началом игры вам необходимо убедиться, что клиент получает ACK на сообщение «уровень начат», чтобы пользователь не играл в игру, которая не была записана сервером.(Возможно, сообщение «уровень начался» никогда не достигло сервера).

Поймать : вам нужно понять, что защита не возможна для обмана пользователяна его счетах!JS полностью открыт, и независимо от того, как вы реализуете свои начальные / конечные вызовы на сервер, любой пользователь может написать сценарий для отправки аналогичных вызовов на сервер в любой интервал времени, который он желает использовать.Даже если вы используете сеанс / cookie, они могут быть легко воспроизведены.(Использование сниффера, например).Таким образом, вы должны осознать и принять конструктивные ограничения, налагаемые архитектурой и кодом HTML / JS в этих пределах.Следовательно, лучшая идея состоит в том, чтобы написать код для пользователей , а не в том, чтобы хакеры не отправляли мошеннические вызовы.Сделайте вашу игру интересной для людей, которые будут играть в вашу игру и не беспокоиться о том, что хакеры обманывают свои результаты - они все равно не будут вашей целевой аудиторией.

Answer 4

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

Серверная сторона должна быть единственным органом для хранения времени.В начале уровня сохраните текущее время в $ _SESSION.В конце уровня вычтите его из текущего времени, и это истекшее время для уровня.

$_SESSION['start_time'] = time();

$elapsed_time = time() - $_SESSION['start_time'];

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

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

Answer 5

хорошо, размышления об этой проблеме дают мне две идеи:

1. Атакуйте свой собственный сервер. под этим я подразумеваю, отправлять запрос каждую 1 секунду, это сохранит счет. Таким образом, «хакер» не может отправить время начала / окончания и обмануть.

2. отправлять запросы в определенные промежутки времени. Хорошо, допустим, мы начали играть, вы можете отправить запрос через определенные промежутки времени (3,4 сек?) если запрос не находится в этом временном интервале, то пользователь обманывает? или хотя бы помечен как возможный читер.

3. использовать простую строку. XD время начала / окончания отправлено на сервер, зашифровано. Вы можете попробовать jCryption для шифрования.

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

Answer 6

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

Этот токен должен быть действителен только для одного запроса. В сочетании с упомянутыми решениями (проверка времени на сервере и т. Д.) Вы сможете создать надежную систему оценки.

Answer 7

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

Answer 8

Невозможно сделать его на 100% пуленепробиваемым, вы можете сделать его более трудным для взлома, только если он основан на клиентской стороне

Answer 9

Вы можете сгенерировать GUID при отображении страницы. Вы можете объединить этот GUID, отметки даты и времени начала, идентификатор сеанса и вычислить их хеш для проверки данных при возврате пользователем.