Почти невозможно найти успешную многопользовательскую онлайн-игру (кроме тех, в которые играют только друзья разработчика), в которой нет читеров. Другими словами, если в вашей публичной игре нет читеров, она или недостаточно популярна, или распознавание мошенников работает не слишком хорошо. Во всех остальных случаях вам придётся иметь дело с читерством. Изучите список шагов которые НУЖНО и НЕЛЬЗЯ совершать (подробное обсуждение темы читерства приведено в моей трёхтомной книге, см. примечание в конце статьи) при борьбе с мошенничеством в играх.
1. Добавьте в условия использования своё право блокировать читеров
Нужно не просто добавить это право, но и указать, что такие решения принимаются «на собственное усмотрение». Однако здесь могут возникнуть трудности:
- Примечание: я не юрист, и эту статью не нужно считать юридическим советом. Лучше проконсультируйтесь со своим юристом.
- Это сложная юридическая проблема, решение которой зависит от страны или территории пребывания. НЕ принимайте решений по этому вопросу самостоятельно, узнайте у юриста (лучше, чтобы он был из вашей страны), будут ли ваши условия использования считаться действительным договором в суде. На GDC 2016 я разговаривал с человеком из одной крупной компании. Самой большой сложностью для них являлись юридические проблемы с баном обнаруженных читеров.
- Смысл здесь прост — иметь возможность банить игроков, если они жульничают. Однако нужно сформулировать условия использования таким образом, чтобы было ясно, что вам не нужно доказывать факт жульничества в суде, иначе преследование читеров становится слишком дорогой затеей. Самый важный юридический вопрос здесь в «бремени доказывания» — должны ли вы доказывать, что читеры мошенничают, или обвинённые читеры должны доказывать свою невиновность. Как вы понимаете, последнее гораздо выгоднее для вас и хуже для читеров. Я уже упомянул выше, что один из возможных способов решения этой проблемы — вставка оговорки «такие решения принимаются на наше собственное усмотрение». Однако нужно обязательно проверить действительность такой оговорки в соответствующей юрисдикции.
- Если это возможно, лучше всего иметь возможность блокировки игроков без возврата средств, чтобы жульничать было невыгодно. Но если это невозможно, то блокировка с возвратом денег НАМНОГО лучше, чем невозможность блокировать читеров вообще.
- НЕ слишком волнуйтесь о жалобах игроков на такие формулировки в условиях использования. Большинство игроков всё равно не читает условия, и при сравнении условий разных игр они всё равно мало отличимы друг от друга для широкой публики. Однако НЕ пытайтесь злоупотреблять этой формулировкой, иначе у вас очень быстро возникнут проблемы.
2. Если вы используете движок защиты стороннего изготовителя, НУЖНО добавить поверх него как можно больше своей защиты (или, что ещё лучше, объединить стороннюю и свою защиту)
Конечно, сторонние разработчики движков защиты часто знают, что делают, но в условиях взлома систем с принципом security-by-obscurity такие движки становятся мишенью для всего хакерского сообщества. Поэтому добавление защиты сверху значительно улучшает ваше положение.
3. НУЖНО бороться с читерами с самого начала
Как только появится сообщество читеров, делающих деньги на продаже читов к вашей игре, любое действие с вашей стороны будет вызывать ГОРАЗДО большее сопротивление. Другими словами, НЕЛЬЗЯ кормить читеров.
4. НУЖНО использовать полномочный сервер
Это действительно очень важно. Более того, НУЖНО переместить всю логику на сервер. В идеальной ситуации в клиенте вообще не должно приниматься решений. Поскольку это не всегда возможно на 100% (в основном потому, что игры имеют очень высокий темп) НУЖНО бороться против каждого решения, принимаемого в клиенте. Чем больше расчётов выполняется в клиенте, тем больше возможностей у атакующего. Если вы не будете агрессивно переносить всё на серверную сторону, это постепенно станет Очень Большой Проблемой (я сталкивался с этим, и по такой теме было один доклад на GDC 2016).
НЕЛЬЗЯ придерживаться deterministic-lockstep архитектур (в которых синхронизация происходит только отправкой данных ввода). Хотя игры с deterministic-lockstep архитектурой меньше страдают от решений, выполняемых на стороне клиента, они довольно уязвимы к атакам утечки информации (таких как Wallhack и Maphack. См. ниже пункт о том, как ограничить клиент только необходимой для него информацией).
5. НУЖНО шифровать трафик
Шифрование трафика позволяет оградиться от нескольких типов атак, в том числе на основе прокси (с которыми иначе почти невозможно справиться) и некоторых типов ботов.
Замечания в этой связи:
- Нет, использование UDP не является оправданием отсутствия шифрования трафика. Здесь на помощь приходит DTLS и некоторые другие протоколы.
- НУЖНО привязывать библиотеку OpenSSL статически. OpenSSL.DLL (или любая другая реализация шифрования через DLL) предоставляет атакующему гарантированный способ обхода шифрования.
- НЕЛЬЗЯ использовать анонимный протокол Диффи-Хелмана (Anonymous Diffie-Hellman, ADH). Да, об этом написано в каждой книге, но всё ещё находятся игры, в которых разработчики применяют его (как минимум одна игра даже упомянула ADH в окне About!).
- НУЖНО проверять сохранённый корневой сертификат на стороне клиента (да, некоторые разработчики этого по-прежнему не делают).
- НЕЛЬЗЯ использовать сертификат с машины пользователя. Вместо этого создайте свой центр сертификации и встройте корневой сертификат в клиент (иначе повышается вероятность MITM-атак).
- Обфусцируйте корневой сертификат в исполняемых файлах клиента, иначе подвергнетесь другому типу MITM-атак.
6. НУЖНО отслеживать публично доступные и платные читы
Находите их, анализируйте и выпускайте исправления как можно раньше. Если игра достаточно успешна, стоит выделить для этого отдельную команду.
Не забывайте при анализе читов следующие принципы:
Очевидно, что чем популярнее чит, тем выше о должен быть в списке исправлений.
- Что ещё более очевидно, НЕЛЬЗЯ запускать читы внутри собственной сети (иначе исполнится мечта очень многих читеров). Вместо этого создайте надёжно огороженную файрволлом «песочницу» (в идеале — в отдельном месте, не имеющем VPN между внутренней сетью и «песочницей»).
7. НЕЛЬЗЯ нанимать известных читеров
На самом деле у этого правила есть исключения. Во-первых, оно не касается white-hat-хакеров. Во-вторых, МОЖЕТ быть приемлемо нанять известных читеров, с соблюдением ВСЕХ следующих условий:
- У них НЕ будет специального доступа к «внутренностям» программы (в особенности к исходному коду)
- Они должны заниматься ТОЛЬКО «black-box-взломом» (которым они и так бы занялись). Единственная разница в том, что они будут сообщать о результатах взлома, а не использовать его.
- Всю связь с нанятыми читерами НУЖНО вести с отдельной учётной записи электронной почты (полностью изолированной от остальной части системы).
- Доступ ко всей информации с этой отдельной учётной записи ДОЛЖЕН быть только внутри «песочницы», настроенной для анализа читерских программ
8. НУЖНО думать о политике блокировок
Будете ли вы банить читеров навечно, или всего на несколько дней? А как насчёт рецидивистов (на GDC 2016 говорили, что 72% читеров снова пробуют жульничать)? Какая у вас есть защита от читеров, открывающих новую учётную запись (подсказка: в F2P-играх на ПК такая защита почти отсутствует)?
9. Проверенное правило: НЕЛЬЗЯ полагаться на игроков в жалобах на читерство
Кроме того, НЕЛЬЗЯ поощрять игроков жаловаться на читеров. Они в любом случае будут жаловаться на то, что посчитают читерством, но подталкивание к жалобам может легко превратить достаточно большое количество игроков в параноиков. Хотя в некоторых случаях блокировка голосованием МОЖЕТ быть необходимой, разрешение игрокам выкидывать противников редко бывает хорошей идеей.
С другой стороны, НУЖНО воспринимать жалобы о читерстве серьёзно и вручную просматривать информацию в таких отчётах. Для этого НУЖНА отдельная команда, если игра успешна. И вам НУЖНО собрать достаточную информацию (статистическую и любую другую) для выполнения такого анализа. НУЖНО хранить такую информацию в базе данных и добавлять отчёты по запросам античитерской команды.
10. НУЖНО передавать клиенту только необходимую информацию
Другими словами, реализуйте так называемую систему «управления интересами». Любые данные в клиенте могут быть взломаны, поэтому передача уязвимой информации, которая не должна быть публичной — это Очень Плохая Идея. Если не реализовать управление интересами, то вы почти гарантировано подвергнете игру читам, делающим стены прозрачными (Wallhacks) и убирающим туман войны (Maphacks), а также ESP-читам (позволяющим видеть здоровье и другие параметры противника).
11. НУЖНО использовать C++ в клиенте
C++ можно взломать, но я обычно разделяю «крекинг» и «полномасштабную обратную разработку». По моему опыту, хотя программу на C++ можно «крякнуть» (т.е. можно найти и отключить ограниченный набор проверок, и найти и изменить ограниченное количество мест в памяти), полномасштабная обратная разработка для C++ гораздо более сложна, чем для C#/Java (я даже не говорю о JavaScript без компиляции Emscripten).
Если уж мы упомянули об этом, то надо заметить, что для этой цели Emscripten почти также хорош, как и C++. Сейчас я не могу ничем подтвердить свои слова, но судя по тому, что я знаю, всё выглядит именно так.
12. НИ В КОЕМ СЛУЧАЕ не выпускайте игру с отладочной информацией внутри
Нужно ли это объяснять?
13. НУЖНО пройтись по коду и отфильтровать все сообщения об ошибках
То есть вам нужно избавиться от всех сообщений, которые не важны ни для кого, кроме вас (если вы хотите их сохранить, то можно всегда заменить их соответствующими хэшами).
Я помню случай, когда используемый алгоритм был восстановлен по невинному сообщению сторонней библиотеки, и это, в свою очередь, упростило создание почти хака. Повторюсь, в клиенте нужно обфусцировать всё, потому что любая выдаваемая информация может быть использована против вас (да, это очень похоже на правило Миранды).
14. НУЖНО беречь исходный код как свою жизнь
Если исходники утекут к хакерам, то 99% обфускации не будут иметь смысла.
В частности, если вы большая компания, то разделите исходный код на части, чтобы каждая часть была доступна только соответствующей команде. Кроме прочего, это поможет снизить ущерб от атак целевого фишинга на вашу команду, от которых практически невозможно защититься.
15. НУЖНО проверять целостность клиента (в том числе ресурсов и/или конфигурации)
Это нужно выполнять хотя бы при запуске клиента (в идеале — и в процессе его работы, но это уже другая история).
Также обеспечьте отправку отчётов на сервер в случае компрометации сервера — если это и не чит, то определённо тревожный сигнал.
16. НУЖНО установить в клиенте «ловушки» для читеров
Вот типичные примеры ловушек:
- Одно и то же значение хранится дважды в памяти клиента и время от времени проверяется на равенство. Для эффективности такой ловушки нужно обфусцировать память хотя бы в одном месте хранения (например, XOR какой-нибудь константой, хотя можно реализовать это ГОРАЗДО более сложно). Если значения не одинаковы, то это Очень Тревожный Сигнал, хотя я и против того, чтобы один случай такого несовпадения считался убедительным доказательством. Когда у игры миллион игроков, с некоторыми из них иногда происходят Очень Странные Вещи.
- Проверка целостности критичных частей кода клиента и проверка на наличие подозрительных внедрённых DLL.
- Измерение времени исполнения кода для поиска необычно долгих задержек, указывающих на отладку клиента. В этом случае интересным вариантом является инструкция RDTSC платформ x86/x64, потому что она часто позволяет измерять время даже при наличии отладчика ядра.
- Ещё один особый тип ловушек — «honey pot». Технически «honey pot» отличается от обычной ловушки в том, что для читера создаётся искусственная мишень.
17. НЕЛЬЗЯ сообщать читеру сразу же, что вы его поймали
Вместо того, чтобы сразу же блокировать читера, обычно всегда лучше отложить бан. Лично я не большой поклонник «волн блокировок» и предпочитаю случайные задержки для каждого игрока, но даже волны блокировок НАМНОГО лучше немедленных банов.
18. Не забывайте, что почти любая компенсация лага открывает возможность для читов, основанных на времени
Практически невозможно отличить действительную задержку от внесённой взломанным клиентом (искусственный лаг). С другой стороны, если вы достаточно аккуратны, то сможете ограничить воздействие таких читов на геймплей.
19. НЕЛЬЗЯ полагаться ни на какие способы идентификации компьютера
Вы МОЖЕТЕ реализовать их, но не забывайте, что идентификация компьютера обходится тривиально (и обеспечьте, чтобы отделы маркетинга/монетизации/бизнес-аналитики тоже знали об этом, иначе они будут полагаться на идентификацию для предотвращения злоупотреблений рекламой).
20. НУЖНО собирать статистику, которая может быть связана с читерством
Например, если игрок попадает в занимающий 5 процентов тела центр тяжести противника 95% времени, то можно что-то заподозрить.
Железное правило: статистика НЕ ДОЛЖНА использоваться как прямое доказательство, это только тревожный сигнал. Как выяснить, что делать с этим сигналом — отдельная история.
Последнее по порядку, но не по значимости: НЕЛЬЗЯ полагаться только на статистику, собранную клиентом. Другими словами, собирайте как можно больше статистики на стороне сервера.
21. НУЖНО обдумать CAPTCHA для распознавания гриндящих ботов
Один из типов защиты, достаточно хорошо работающий против нежелательных ботов (обычно занятых гриндом) — это CAPTCHA. Надо признать, что она довольно раздражает, но я видел примеры того, как разработчик объяснял необходимость CAPTCHA сообществу игроков, и те признавали её «необходимым злом», если она проверяет пользователей только изредка.
Учтите, чтобы она работала, это НЕ ДОЛЖНА быть CAPTCHA для всех, её НАДО активировать только при срабатывании одного из тревожных сигналов.
22. НУЖНО быть готовыми к сканированию компьютеров игроков на предмет известного читерского ПО
Это довольно противоречивый вопрос, но скорее надо реализовать эту функцию, чем нет. Для большинства игр сканирование компьютеров игроков — это ГОРАЗДО меньшее зло, чем беспрепятственное читерство (оно разрушает для игроков интересность процесса, а значит, убивает вашу игру).
В целом, реализация такого сканирования очень сложна (она довольно похожа на написание собственного антивируса), так что я дам здесь несколько советов:
- НУЖНО добавить в условия использования раздел о праве на такое сканирование.
- НЕЛЬЗЯ получать любую другую информацию, кроме необходимой для распознавания читов.
- Если вы проигрываете читерам в этой битве, НУЖНО рассмотреть варианты решений на основании драйверов устройств (подсказка: существуют такие коммерческие продукты)
- При использовании сканирования НУЖНО распознавать запуск в виртуальной машине (ВМ часто используются для сокрытия программного обеспечения, и их обычно НУЖНО считать тревожным сигналом)
- НУЖНО рассмотреть необходимость ДВУХ уровней распознавания. Первый уровень может быть простым распознаванием самых очевидных и популярных читов, и должен приводит к дружелюбному сообщению: «Ты используешь кое-что, запрещённое правилами. Не нужно этого делать, А НЕ ТО...». На втором уровне выполняется полномасштабное распознавание, приводящее к бану. Задумка здесь в том, чтобы остановить потенциального читера, пока не будет слишком поздно, по возможности не потеряв при этом игрока. Я видел примеры того, что такой подход хорошо работал в довольно большой многопользовательской игре (но тут, как говорится, нет никаких гарантий)
Заключение
Конечно же, приведённый выше список неполон. Если ваша игра успешна, вам придётся самому узнавать на этом пути что-то новое (иногда это даётся очень тяжко). Однако вот самый важный принцип, который СИЛЬНО помог нам в этом отношении:
«Чтобы спастись от медведя, не нужно бежать быстрее него. Достаточно бежать быстрее, чем человек рядом с тобой».
Джим Батчер
В нашем случае это можно перефразировать так:
«Не обязательно защищаться от читерства на 100%, чтобы спасти игру от читеров. Достаточно быть лучше своих конкурентов».
«No Bugs» Hare
Экономика читов (особенно продаваемых за деньги) говорит нам, что при наличии двух целей, одна из которых очень привлекательна, но хорошо защищена, а другая средне привлекательна, но защищена слабо, коммерческие читеры определённо выберут последнюю. В конце концов, это просто бизнес, ничего личного.
В этой статье вкратце рассмотрена тематика читерства на основании материалов из книги «Development and Deployment of Multiplayer Online Games» («Разработка и выпуск многопользовательских онлайн-игр»).
Автор: PatientZero
