Античит-джаваскрипт для браузерной / HTML5 игры

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

Так какие стратегии вы предлагаете помимо минимизации и запутывания?

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

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

А как насчет переменных и функций? Работать с небольшими эскопами всегда, когда это возможно, безопаснее, но стоит ли это усилий?

Есть ли какой-нибудь способ для javascript для самостоятельной проверки его текста, как в контрольной сумме?

Есть браузерные решения? Я не стал бы ограничивать это для Chrome только в ранних сборках.

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

Хорошая новость заключается в том, что, как правило, в однопользовательских играх очень мало читерства. Единственное серьезное исключение - игры, в которых есть большие сообщества «рекордов YouTube», такие как Line Rider, где игроки соревнуются друг с другом за YouTube.

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

Хотелось бы, чтобы был лучший ответ на это, но нет.

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

• Сократите и запутайте свой JS, что абсолютно затруднит чтение кода. Вы можете де-минимизировать и сортировать-де-обфускацию, но вы никогда не сможете вернуть правильные имена переменных и функций или комментарии.
• Выпекать в ценностях с другим языком. В этом случае вы можете использовать PHP или другие серверные языки для обработки статических переменных установки. Если расстояние прыжка всегда должно быть 2 пробела, обычно вы определяете расстояние прыжка для объекта игрока. Не обрабатывайте это с помощью PHP, чтобы исходный код JS заканчивался с 2s, намазанными по всему коду в миллионе мест. Это имеет счастливый дополнительный побочный эффект от возможности ускорить ваш JS тоже.
• С некоторой практикой вы получите опыт в миксе, и вы даже можете создать свой JS для каждого игрока. Что является еще одним способом предотвращения обмана. Если код каждого игрока отличается, то сложнее написать чит, который может быть частью инструментария.
• Наконец, вы можете проверить контрольную сумму источника на основе личности игрока. Скажите их IP-адрес и / или имя пользователя. Вы знаете, какой будет версия JS для конкретного игрока, вы можете запечь контрольную сумму и потребовать, чтобы она была такой же на другом конце. Легко отключить, как и любой JS на стороне клиента, но еще раз усложняет создание инструментария.

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

Я уже ответил на такой вопрос здесь , и мне жаль говорить, но:

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

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

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

Это хорошо для вас, для вашего кода, для ваших пользователей и для сообщества.

Что ж, для начала лучше всего использовать функцию Object.freeze (которая включит защиту от исправления объектов).

Это «предотвращает добавление новых свойств», «предотвращает удаление существующих свойств», «предотвращает изменение существующих свойств или их перечислимости, конфигурируемости или возможности записи»; любые изменения во внутреннем состоянии должны быть сделаны через средства доступа. Следующий пример работает на chrome (должен работать на firefox, хотя я не знаю об IE ...):

var b = {}
// Fill your object with whatever you want
b.a = "ewq"
// Freeze all changes
Object.freeze(b)
// Try to put new value. This wont throw any error, put wont work either, 
// as we shall see ...
b.b = "qwe"

// Values 
console.log(b.a); // outputs "eqw"
console.log(b.b); // outputs  undefined

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

• купить чеки - если я что-то покупаю, у меня должно быть достаточно золота
• Чеки на продажу - если я что-то продаю, мне нужно иметь этот предмет в своих товарных чеках - так же, как продать оружие
• оборудовать чеки - если я экипирую оружие, у меня есть / есть ли оно?
• проверка повреждений - если я атакую ​​что-то (врага), я не могу нанести удар больше, чем максимальный урон, который могло нанести мое оружие (здесь не следует ожидать, что клиент скажет, какое оружие он использовал, потому что оно должно было сохраняться раньше)
• проверка крафта - если я что-то создал, у меня есть все необходимые ингредиенты / компоненты?

... и так далее

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

• Я на месте1 @ T1, я на месте2 T2, каково минимальное время, необходимое для перемещения из места1 в место2, и оно соответствует моему T2 - T1. Вы можете иметь отображение этого от малого до большого в зависимости от размера карты. У вас должен быть список, по крайней мере, основных областей, таких как, NPC - босс, NPC - область появления врага (не обязательно точное местоположение)

Надеюсь, это поможет, это звучит сложно, но вам нужно научиться делать реальные рабочие игры

Это в принципе невозможно. Было бы так легко обойти все, что вы положили, чтобы избежать мошенничества.

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

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

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

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

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

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

Это та степень, в которой я повторю другие ответы.

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

С этим сказал:

• Смягчение грубых клиентов: обслуживание по HTTPS, использование совместного использования ресурсов между источниками (CORS), разрешение только одного источника, использование целостности подресурсов. Я предлагаю реализовать работника сервиса для принудительного применения его ко всем запросам, что также будет означать, что игра не будет работать, просто переместив ее в HTTP (потому что без HTTPS нет работника сервиса, работник сервера выполняет клиентскую часть CORS и сервер ожидают CORS), и если они работают по HTTPS, он не будет работать, потому что сервер отклонит другое происхождение.
• Смягчение сценариев: используйте аутентификацию и для выполнения каких-либо действий требуется токен. В каждом цикле обновления сервер должен выдавать клиенту новый токен, и токен потребляется, делая все, что он делает ... для выполнения каких-либо действий требуется действительный токен, токен всегда меняется, и, следовательно, его невозможно угадать, и если клиент отправляет один и тот же токен дважды или отправляет неверный токен, сервер знает, что что-то не так. Для дополнительной защиты: создайте код аутентификации сообщения (MAC) токена с секретным ключом и добавьте его в файл cookie. Изменение cookie-файла убьет сеанс (и им нужно угадать ключ), а изменение токена приведет к сбою проверки MAC.
• Смягчение изменений кода: помимо целостности подресурсов (которые современные браузеры также проверяют во время выполнения), держите ваши переменные в ограниченном объеме (используя let, самозапускающиеся анонимные функции и модули javascript). Кроме того, не полагайтесь на DOM (DOM предназначен только для ввода-вывода, а не для хранения, если вам нужно прикрепить атрибуты, обернуть объекты DOM и добавить их в оболочки). Таким образом, все, что у вас на консоли, не сможет достичь логики игры (если вы не воспользуетесь какой-либо уязвимостью браузера). Вы можете также рассмотреть возможность использования методов для обнаружения инструментов разработчика (они специфичны для каждого браузера, могут работать не во всех случаях или перестать работать в будущем ... таким образом, это гонка вооружений).
• Что-то случилось? Сессия прервалась? Ударить игрока из текущего матча, запросить логин еще раз. Рассмотрим капчу ... которая также дает пользователю преимущество: "мы знаем, что происходит что-то редкое" (это был не случайный сбой сервера), и да, это форма смягчения. Да, и не забудьте записать это. Вы должны быть в состоянии проверить, почему они произошли, чтобы предотвратить ложные предположения и ответить на билеты поддержки.

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