Какие хорошие способы предотвратить обман в многопользовательских играх?

Ответ 1

Сервер - это король. Клиенты взломаны.

Что вы хотите сделать, это две вещи с вашим веб-сайтом.

Отправьте игровые действия на сервер и получите состояние игры с сервера.

Вы показываете состояние игры. и вы отправляете данные на сервер.

• автоматический прицел - этого трудно решить. Вы должны пойти на реализм. Если пользователь наносит 10 выстрелов в голову за 10 мс, то вы ударяете его. Напишите умный алгоритм обнаружения читов.
• peeking за пределами видимой области - решается путем отправки видимой области каждому клиенту
• ускорение взлома - решается путем правильной обработки ввода. Вы получаете событие, которое пользователь перемещает вперед, и вы контролируете, как быстро он идет.

Вы не можете решить эти проблемы, выбирая код. Код на клиенте ТОЛЬКО для обработки ввода и вывода вывода. Логика ALL должна выполняться на сервере.

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

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

Что касается остановки ботов от подключения к вашему веб-сайту, напрямую настроить отдельный канал проверки HTTP или HTTPS в вашей многопользовательской игре для дополнительной безопасности. Используйте несколько каналов Http/https/ws для проверки того, что клиент является "официальным", действуя как форма рукопожатия. Это сделает соединение с ws более жестким.

Пример:

Подумайте о простой многопользовательской игре. 2D-гоночная игра. Upto n пользователи идут по плоской карте 2D-платформы и расы, чтобы добраться от A до B.

Скажем, ради аргументов, что у вас есть система с безумной безопасностью, где существует сложная аутентификация по каналу HTTPS, чтобы пользователи не могли напрямую обращаться к вашему каналу websocket и вынуждены проходить через браузер. У вас может быть расширение chrome, связанное с аутентификацией, и вы вынуждаете пользователей использовать его. Это уменьшает область проблем.

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

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

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

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

Ответ 2

На стороне сервера есть 2 варианта:

1) Полная серверная игра

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

2) Полная клиентская игра

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

Недостатком второго метода является то, что некоторые хаки остаются необнаруженными: например, maphack. Читер может вводить код, поэтому он видит все, но все же только отправляет данные, которые он обычно должен видеть на сервере.

-

На стороне клиента есть один вариант: Компонент javascript, который сканирует код игры, чтобы увидеть, было ли что-либо изменено (например, код изменен для визуализации объектов, которые не видны, но отправляют на сервер разные данные проверки).

Очевидно, что хакер может легко отключить этот компонент. Чтобы исправить это, вы можете заставить клиента периодически перезагружать компонент с сервера (сервер может проверить, запрашивался ли пользователь файл script пользователем). Это создает новую проблему: хакер просто периодически запрашивает компонент через AJAX, но не позволяет ему работать. Чтобы этого избежать: сначала загрузите компонент, но немного изменив его версию.

Например: укажите компонент, расположенный на вашем сайте /cheatdetect.js? control = 5. Сервер будет генерировать слегка измененный cheatdetect.js, так что в следующей итерации необходимо загрузить cheatdetect.js? Control = 22 (например). Если механизм управления достаточно сложный, хакер не сможет предсказать, какой контрольный номер запросить следующий, а cheatdetect.js должен быть выполнен для продолжения игры.

Ответ 3

Обвините свой клиентский код как можно больше. Кроме того, используйте магию.

Ответ 4

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

Обновление: проблема состоит из нескольких частей, и у меня нет ответов с головы, но различные варианты могут быть оценены с учетом этих вопросов:

• Насколько вы готовы пойти, чтобы предотвратить обман? Если вы только заботитесь о случайном обмане, сколько барьеров достаточно, чтобы препятствовать случайному обману? Промежуточный Javascript-программист? Серьезный эксперт? Взвешивание этого против преимуществ мошенничества, есть ли что-то реальное значение на карту, как деньги и призы, или просто репутация?
• Как вы получаете высокую уверенность в том, что человек предоставляет входные данные для вашей игры? Например, имея достаточно хорошую библиотеку компьютерного зрения, я мог бы моделировать вашу игру на отдельных входах машинной подачи на компьютер, притворяясь мышью, но это имеет высокую относительную стоимость (не стоит моего времени).
• Как вы можете создать цепочку доверия к вашему протоколу, чтобы знание (2) могло быть передано серверу и что ваш сервер относительно уверен, что ваш клиентский код отправляет сообщения?

Конечно, многие из препятствий, которые вы бросаете, могут быть отшатнуты, но какова стоимость игрока и вас? См. "" Война за истощение".

Ответ 5

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

Ответ 6

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

Ответ 7

Я бы использовал комбинацию minification и AJAX. Если все функции и данные не загружены на страницу, было бы сложнее обмануть.

С другой стороны, моддинг оказался очень выгодным инструментом для таких компаний, как Id Software. Возможно, позволяя модификации системы сделать игру более приятной для сообщества в целом.

Ответ 8

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

Например,. для основного действия входа: в angular при выполнении вызова на сервер бэкэнд проверяет имя пользователя и pwd, и если он проверен, он вернется к клиенту и позволит пользователю войти в систему с помощью angular.

Когда я говорю логин, используя angular, он будет хранить вещи в куки, например, в объектах пользователя и других вещах. Но все же пользователь может удалить JS-код, который делает вызов для backend, и вернуть TRUE (где необходимо) и вставить объект пользователя (фиктивный) в файлы cookie и другие объекты (независимо от того, что необходимо) и логин. Это очень сложно сделать, но это выполнимо. Во многих сценариях это нежелательно, даже если для редактирования/взлома кода требуется несколько часов.

Это возможно в одностраничных приложениях, где файлы JS не загружаются для каждой страницы. Чтобы уменьшить вероятность взлома, мы можем использовать сокращенные коды. И я думаю, что если такие действия выполняются в бэкэнд (например, login в Django), это намного безопаснее.

Пожалуйста, поправьте меня, если я ошибаюсь.