Как записать результат js игры и избежать накруток.

#1 1 ноября 2016 в 18:59
Кто хочет и может, может поделиться соображениями на тему, как это лучше сделать.

Есть js скрипт игры, я решил вести статистику игр, счёт игрока, и рейтинг команд.
С запись результата игры в базу данных там все просто, по окончании игры js отправляет get запрос на php обработчик, тот пишет результат игры в бд из этого вытекает все остальное — рейтинг, статистика.

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

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

Но полностью от манипуляций с результатами игр и статистикой это защитить не сможет.

Есть у кого идеи, что еще можно сделать при описанных исходных данных?
Не скажу, что тема насущная прямо, это просто проект пока, скорее просто экзерсисы.
#2 1 ноября 2016 в 19:17
а в процессе игры отправлять промежуточные запросы?.. Есть возможность?
#3 1 ноября 2016 в 19:19
Вот неплохо разжёвано.
#4 1 ноября 2016 в 19:23

а в процессе игры отправлять промежуточные запросы?.. Есть возможность?

Zau4man
Нет весь игровой процесс сразу выполняется на стороне клиента, в окончании игры есть алерт на который я и повесил передачу данных на сервер.
Вариант с обработкой каждого хода конечно тоже можно рассматривать, но мне кажется если речь не идет о взаимодействии между двумя игроками то нет смысла и накладно.
#5 1 ноября 2016 в 19:32

Вот неплохо разжёвано

Lora
спасибо интересно.
особенно про дурачить читера понравилось, пусть наслаждается величием в своё маленьком мирке smile

Но мне кажется в этом случае, можно найти какое то радикальное решение отсекающее все варианты. Всё гениальное — просто. Но я найти его не могу) пока

Пока только один вариант, если игра доступна только в андроид приложении и не доступна через браузер. Правильно ли я понимаю, что в этом случае, игра защищена?
#6 1 ноября 2016 в 19:55
Например в идентификатор игры включать еще какой то параметр, который не будет передаваться в запросе в явном виде, но будет востребован как обязательный принимающим обработчиком. В запросе на отправку результатов игры он передаваться не будет, соответственно тот кто будет исследовать исходный код не будет видеть что этот параметр участвует в запросе.
Как пример урл реферера, или другой ключ имеющийся на странице игры, или какой то ключ хранящийся в базе сms_users имеющий отношений к данному пользователю.
#7 1 ноября 2016 в 20:54

Пока только один вариант, если игра доступна только в андроид приложении и не доступна через браузер. Правильно ли я понимаю, что в этом случае, игра защищена?

Нил™
Не понятно.Если игра не браузерная, то о чём речь вообще? Где юзер будет видеть исходный код?
#8 1 ноября 2016 в 21:05
Lora
Игра браузерная. Я имел ввиду если её завернуть в android приложение основанное на WebView и запретить открываться вне приложения.

Где юзер будет видеть исходный код?

Lora
Ну я предполагаю что в этом случае нельзя видеть исходный код, но возможно я не знаю каких то вариантов, поэтому уточняю.
#9 1 ноября 2016 в 22:09
Javascript легко обойти, вплоть до замены скрипта при загрузке на свой с правками в исходниках. Кому надо будет — тот легко сделает.

А вот заюзать uglifier — даже не смотря на открытый код, никто, даже гик, в этом г копаться не будет.
#10 1 ноября 2016 в 22:16
Я в этом нуб, но если отталкиваться от того, что WebView по сути встраиваемый браузер, то наверное открыв консоль в мобильнике можно будет и код увидеть.
#12 1 ноября 2016 в 22:37
Всё зависит от того, наверное, какой уровень защиты для ТС требуется. И какой спрос на игру ожидается. Если средний и ниже, то возможна эмуляция игры на сервере не худший вариант.
#13 2 ноября 2016 в 13:21
Какой-либо серьезной защиты в случае с JavaScript не существует в принципе. Но можно отсечь самый распространенный вид читеров, который называется "я открыл консоль браузера, посмотрел в Network куда уходит запрос и сделал такой же".

Для этого:
— обфусцировать JS-код;
— обфусцировать имена backend-скриптов (т.е. запрос слать не на /save-score.php?score=123, а на /ph12.php?qq=123). Тут можно изголяться и, например, слать вообще не число, а делить результат на разряды и слать символ с нужным ASCII-кодом для каждого разряда. Будет выглядеть как /ph.12.php?qq=A#Hf5
— передавать не результат в открытом виде, а его некий хэш, например просто XOR-ить счет (для поиска этой логики нужно будет разбираться с обфусцированным кодом, что в общем никому не нужно).

Пример:
  1. var xoredScore = score ^ key;
  1. $score = $xoredScore ^ $key
Такой метод в свое время использовался в Яндекс.Играх (пока их не прикрыли). Однажды мы с приятелем изучали как там все работает и понять не могли что за цифры он шлет после игры. Помогла только декомпиляция SWF-файла игры и несколько часов раскуривания кода. Таким никто не будет заниматься, я думаю. А если кто-то займется и сделает эксплоит, то логику можно поменять за 10 минут и ждать новой итерации.

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

Если же все-таки хочется 100% защиты, то здесь только один вариант:
— уносить логику на сервер, используя JS только как "тупой терминал", показывающий данные с сервера
Вы не можете отвечать в этой теме.
Войдите или зарегистрируйтесь, чтобы писать на форуме.
Используя этот сайт, вы соглашаетесь с тем, что мы используем файлы cookie.