Предположим, вы создали онлайн-игру на HTML5/JavaScript. Весь код будет загружен в браузер пользователя, и они запустят игру.
Как вы не позволяете кому-либо копировать игру на свой компьютер и вводить функции и модули для обмана? Например, они могут написать функцию, которая автоматически нацеливается, например, на ближайшего вражеского спрайта.
Есть ли какой-нибудь фундаментальный способ защитить людей от подобных вещей, разработав свой игровой код определенным образом?
Что мешает кому-то копировать игры на свой компьютер и инъекции функций и модулей в обмануть?
Ничего.
Есть ли какой-либо фундаментальный способ защищать людей от такого рода путем разработки кода игры в определенным образом?
Неа.
Вот почему большинство игр для JavaScript сильно зависят от состояния сервера, чтобы предотвратить читы.
Короче говоря, нет. Однако вы можете обфускать Javascript, чтобы сделать его намного сложнее.
Для таких вещей, как оценки, пользователь мог бы в теории POST получить любую оценку для вашего обработчика script. В этом случае вы можете использовать сеанс и регулярно отправлять сообщения обратно на сервер через AJAX.
Некоторые мысли
Серверная сторона:
Храните внутреннюю часть с правами пользователя и проверяйте входные сообщения клиентов на сервере.
Autoaim: создайте поддельные спрайты, которые невидимы для обычных игроков, если их слишком часто ударяют, у вас есть бот. (не всегда будет работать, так как боты могут быть обновлены для проверки невидимости)
проверить время реакции клиента на изменения на сервере, проверить слишком много слишком быстрых реакций. (должен принять большое количество быстрых ответов, прежде чем реагировать, поскольку человек может быстро реагировать, и время должно учитывать задержку сети, чтобы поймать что-либо). Дайте игроку какую-то капчу, обычный игрок никогда ее не увидит.
Клиентская сторона:
используйте обфускацию, чтобы затруднить взаимодействие с вашим кодом.
проверить функции, определенные в хаках, о которых вы знаете. Должно быть изменено/обновлено часто, поскольку создатели таких хаков могут обойти эти проблемы.
Дизайн игры: делая вашу игру менее повторяющейся, это затрудняет запись инструментов/ботов для нее.
обновлять клиент, чтобы время от времени изменять часть его структуры. Хотя это не остановит ботов, для их работы потребуется работа. Либо сделайте его прозрачным для пользователя, либо замаскируйте его новой функцией.
Важно: убедитесь, что ваш серверный интерфейс проверяет вход пользователя, обфускацию и проверку на стороне клиента, не поможет кому-то писать собственный клиент.
Мне нравится этот вопрос, и, хотя есть, вероятно, лучшие ответы, вот несколько от верхушки головы, которые могут (или не могут) работать:
В целом, его трудные и все вышеперечисленные предложения можно обойти. Я полагаю, что ключевым моментом является то, чтобы им было сложно обмануть, но, учитывая, что есть читеры для даже безопасных онлайн-игр в режиме онлайн, будет трудно помешать JS-играм быть восприимчивыми к этому.
Есть ли какой-либо фундаментальный способ защитить людей от такого рода вещей, разработав свой игровой код определенным образом?
Единственный здравомыслящий метод - хранить критические фрагменты кода на серверах, которыми вы управляете, и никогда не отдавать их на компьютеры пользователей вообще. Трудная часть делает этот квадрат, удерживая игру достаточно быстро, чтобы играть.
Вы пытаетесь сделать невозможное. Лучший совет, который я могу вам дать, заключается в том, что если вы планируете сохранять любые данные, такие как монеты/деньги/золото, уровни, то вы не убедитесь, что никогда не доверяете клиенту и не делаете столько логического сервера, насколько это возможно.
Я думаю, что для этого нужно было написать клиенту таким образом, чтобы вы динамически изменяли код клиента и проверяли использование созданного на нем кода на сервере.
например. есть пространство имен, подобное этому
window.mynamespace = {
foo : function(){
// some stuff here
},
bar : function(){
// some more stuff here
}
}
который содержит весь ваш клиентский код и для всех методов сервера требуется токен, который является результатом предыдущей динамической оценки базы кода. сделать это сложнее, переопределив методы и изменив имена методов. Вот несколько примеров проблем (это имеет смысл только в том случае, если проблемы создаются динамически и не предсказуемы). Все сначала содержат задачу, а затем вызов, который будет использоваться для создания токена авторизации для следующего запроса. (Это объекты ответа от вызовов ajax). В основном задача будет оценена, и результатом вызова eval'd станет следующий токен.
{
task: "mynamespace.baz=mynamespace.foo;mynamespace.foo=undefined;",
challenge: "mynamespace[11].toString().substr(10,22)"
// get part of a well-known functions source code
}
{
task: "mynamespace.bar=function(){ /* new code here */ }",
challenge: "var xy=0;mynamespace.each(function(item){xy+=item.toString().lastIndexOf(';')}); xy"
// accumulate the last index of a semicolon in all elements
// of the namespace
}
Чтобы побить это и все еще получить действительные токены авторизации, клиенту придется написать весь уровень эмуляции javascript. Хотя это можно сделать, я попытался бы очень существенно изменить код сервера основными способами, чтобы сделать эту технику практически невозможной (поэтому слой эмуляции не будет знать, что эмулировать).
они могли бы написать функцию, которая автоматически например, у ближайшего вражеского спрайта.
Вы можете сделать это даже для игр, поскольку большинство процессов происходит на сервере! Вам просто нужно достаточно быстро проанализировать экран.
Вы даже можете повторно реализовать части AI игры, чтобы попытаться предсказать, как будут двигаться боты. Нелегкая задача, если у вас нет доступа к исходному коду игры, но если вы запишете много времени на игровое время, вы можете применить методы машинного обучения.
Есть ли какой-либо фундаментальный способ защищать людей от такого рода путем разработки кода игры в определенным образом?
Не забывайте, что вы можете изменить саму игру, а не только, как она реализована. Например, используйте произвольно генерируемые уровни, а не статические, используйте человеческих игроков, а не ботов, делайте ваши искусство/спрайты более сложными, больше используйте аудио, ограничивайте скорость перемещения курсора, добавьте время перезарядки оружие, добавить скрытые опасности и т.д.
В теории вы играете в игру против хакеров. Вы не можете выиграть эту игру, но вы сделаете ее сложной.
Мое предложение состояло в том, чтобы использовать столько же логики на стороне сервера, сколько вы можете использовать и использовать Javascript Obfuscation.
Обфускация Javascript будет очень трудно понять код, но даже лучше это позволит вам выпустить несколько тысяч версий вашего кода при сохранении той же базы кода.
Я использовал JScrambler, чтобы сделать это один раз. Вместо того, чтобы взломать код из 1 игры, хакеры должны будут взломать несколько тысяч версий кода!:)
Вы можете поместить все, что когда-либо вызывает код внутри закрытия:
(function() {
var cantSeeMe = function() {
// do some game stuff!
};
})();
За пределами закрытия будет сложно очень получить код для "инъекционных хаков" (например, переопределение функции на консоли). Это не заставит кого-то переписывать ваш код, но передача данных через упаковщик или даже компилятор закрытия может сделать ваш код довольно трудным для чтения/изменения... (посмотрите jQuery min
В целом, ЛЮБАЯ игра, работающая на стороне клиента, является взломанной.
travian (http://www.travian.us/) является хорошим примером игры большего масштаба, которая работает в DHTML, и у нее много проблем с на стороне клиента. Просто установка жирной обезьяны в firefox открывает довольно большую дверь для всех видов эксплуататорского поведения. Тем не менее, они, похоже, поддерживают игру в некоторой степени функциональной, так как большинство эксплойтов, похоже, вращается вокруг автоматизации общих внутриигровых задач, а не прямых нарушений внутренней логики игры. Имейте в виду, что этот пример далек от запуска только с JS и в значительной степени зависит от элементов управления на стороне сервера.
Отказ от ответственности. Это ужасный метод и, вероятно, слишком много усилий, чем это стоит.
Предположим, что перед отправкой вам был обработан код javascript.
Прежде всего, каждый метод имеет идентификационную переменную, которая привязана к результату каждой функции (т.е. каждая функция возвращает {ident:"special code",result:"actual useful function result"}). У вас также есть функция testIdent(), которая будет принимать имя функции для вызова, а также "тестовые данные" для ее получения (если это необходимо). Целью testIdent() было бы отправить идентификатор, возвращенный с указанной функции, на сервер для проверки (идея состоит в том, что сервер может запросить тест, когда вы сочтете это подходящим). Идентификатор для каждой функции должен быть рандомизирован и записан специально для указанного пользователя перед отправкой.
Во-вторых, прежде чем код будет отправлен клиенту, порядок функций будет рандомизирован, а имена функций будут запутаны в некотором случайном застои. Таким образом, хакеру не удается найти какой-либо переменной ident в функции x(), поскольку он будет называться случайным образом. Кроме того, это было бы еще одним плюсом, если каждое имя переменной также запутывается случайным образом, просто добавив еще один шаг к усложнению и головным болям... ну... всех (я сказал вам, что это ужасный метод).
Теперь, если принять правильные меры, чтобы убедиться, что код всегда будет функционировать правильно, хакеры - люди с высокой степенью очистки, и хакеры все еще могут отслеживать этот код, если они достаточно определены. По крайней мере, одним из способов будет поиск структур key code, таких как оператор switch с определенным количеством элементов, или цикл for с числом операторов x и т.д. Хотя каждый из они могут быть противопоставлены, скажем, путем добавления произвольных операторов case в коммутаторах или нескольких бит if(true) случайным образом по всему коду, противодействие хакерам всегда будет постоянным (и, возможно, проигравшим) сражением.
Надеюсь, это может дать вам некоторые идеи. Я не знаю, как кто-то будет реализовывать это точно, но это, по крайней мере, идея.
Удачи!