Создание игры доказательства взлома в [закрытом] JavaScript

Вот почему большинство игр на JavaScript сильно полагаются на состояние сервера , чтобы предотвратить читерство.

Некоторые мысли

Сторона сервера:

• Сохранение стороны сервера внутреннего состояния игр и проверка ввода, отправляемого клиентами на сервере.

• Autoaim : Создавайте фальшивые спрайты, которые невидимы для обычных игроков, если они получают слишком частые удары, у вас есть бот. (не всегда будет работать, так как боты могут быть обновлены для проверки на невидимость)

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

Клиентская сторона:

• используйте обфускацию, чтобы усложнить взаимодействие с вашим кодом.

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

• Дизайн игры: делая вашу игру менее повторяющейся, становится сложнее писать для нее инструменты / ботов.

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

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

Мне нравится вопрос, и хотя, вероятно, есть лучшие ответы, вот несколько вариантов, которые могут (или не могут) сработать:

• Обфускация. Да, это не гарантировано, и кто-то может в конечном итоге добраться до него, но иногда это боль в заднице, с которой приходится иметь дело.
• Генерировать JS с новым временным токеном каждый раз. Возможно, вы сможете шаблонизировать .js, выполняющий код, и вставить сгенерированный сервером токен, отличающийся для каждого экземпляра. Токен может быть временным и может быть одним из способов проверки подлинности кода
• Возможно, есть способ определить правильное местоположение запускаемого скрипта - но это, вероятно, можно подделать

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

Короче говоря, нет. Однако вы можете запутать Javascript , чтобы сделать это намного сложнее.

Для таких вещей, как оценки, пользователь теоретически может отправить любую оценку в ваш скрипт-обработчик POST. В этом случае вы можете использовать сеанс и регулярно отправлять обратно на сервер через AJAX.

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

Например. иметь такое пространство имен

window.mynamespace = {

    foo : function(){
        // some stuff here
    },

    bar : function(){
        // some more stuff here
    } 
}

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

{
    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. Хотя это можно сделать, я бы очень часто пытался внести фундаментальные изменения в код сервера, чтобы сделать этот метод практически невозможным (чтобы уровень эмуляции не знал, что имитировать).

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

они могли написать функцию, которая автоматически например, на ближайшем вражеском спрайте.

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

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

Есть ли какой-нибудь фундаментальный способ защищать людей от подобных действий вещь, разработав свой игровой код в определенным образом?

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

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

(function() {
  var cantSeeMe = function() {
    // do some game stuff!
  };

})();

Вне замыкания будет очень сложно получить код для "внедрения" hacks »(например, переопределение функции на консоли). Это не помешает кому-то переписать ваш код, но передача вещей через упаковщик или даже компилятор закрытия может затруднить чтение / изменение вашего кода ... (взгляните на jQuery min

В общем, ЛЮБАЯ игра, на которой запущена клиентская сторона, может быть взломана.

travian ( http://www.travian.us/ ) - хороший пример крупномасштабной игры, которая работает на DHTML и имеет массу проблем со злоупотреблениями на стороне клиента. Простая установка grease monkey в firefox открывает довольно большие двери для всех видов эксплуататорского поведения. Тем не менее, они, похоже, поддерживают игру в некоторой степени функциональной, поскольку большинство эксплойтов, похоже, вращаются вокруг автоматизации общих внутриигровых задач, а не прямых нарушений внутренней логики игры. Имейте в виду, что этот пример далек от того, чтобы запускать только JS и в значительной степени полагается на элементы управления на стороне сервера.

Заявление об ограничении ответственности : Это ужасный метод и, вероятно, слишком много усилий, чем оно того стоит.

Предположим, у вас есть метод обработки кода javascript перед его отправкой.

Прежде всего, каждый метод имеет переменную identity , которая привязана к результату каждой функции (то есть каждая функция будет возвращать {identify: "специальный код", результат: "действительно полезно результат функции "} ). У вас также есть функция testIdent () , которая будет принимать имя функции для вызова, а также «тестовые данные» для ее передачи (если таковые требуются). Целью testIdent () будет отправка идентификатора , возвращенного указанной функцией, на сервер для проверки (идея состоит в том, что сервер может запросить тест, когда вы сочтете это подходящим) . идентификатор для каждой функции должен быть рандомизирован и записан специально для указанного пользователя перед отправкой.

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

Теперь, если принять правильные меры, чтобы гарантировать, что код всегда будет работать правильно, хакеры - очень умные люди, и у хакеров все еще есть способы отследить этот код, если они достаточно решительны. По крайней мере, одним из способов будет поиск структур ключевого кода, таких как оператор switch с определенным количеством элементов или цикл for с количеством операторов x и т. Д. каждому из них можно противодействовать, например, добавив фиктивные операторы case в переключатели или пару битов if (true) случайным образом по всему коду, противодействие хакерам всегда будет постоянным ( и, возможно, проигрышный) бой.

Надеюсь, это может дать вам некоторые идеи. Я не знаю, как это точно реализовать, но это, по крайней мере, идея.

Удачи!

Есть ли какой-либо фундаментальный способ защитить людей от подобных действий, определенным образом спроектировав игровой код?

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