Классификация ботов

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

Задачи ботов

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

Одно из самых ранних упоминаний термина игровой бот встречается применительно к играм в жанре шутер от первого лица (first-person Shooter или FPS). Проблема появилась с момента возникновения режима игрок-против-игрока (player versus player или PvP), в котором пользователи могли соревноваться друг с другом. Некоторым из них хотелось подготовиться к состязанию самостоятельно, либо у них не было возможности подключаться к сети регулярно. Для этой цели требовались оппоненты, управляемые компьютерной программой, а не человеком.

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

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

С развитием компьютерных игр возникли новые задачи для ИИ. Распространение интернета привело к росту популярности массовых многопользовательских ролевых онлайн-игр (massively multiplayer online role-playing game или MMORPG). Этот новый жанр имеет много общего с классическими ролевыми играми (role-playing game или RPG), но в отличие от них игровой процесс стал более растянутым по времени из-за большого числа участников. Кроме того, в MMORPG разработчики стремятся поддержать интерес пользователей как можно дольше. Эти особенности привели к более длительному развитию игрового персонажа. Теперь требуются недели, а иногда и месяцы, для выполнения квестов и добычи ресурсов. Благодаря этому повышается уровень персонажа, который важен для сражения с другими игроками. Именно этот соревновательный режим и является главной привлекательной чертой MMORPG.

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

Автоматизация игрового процесса – не единственная задача, возникшая после появления новых жанров онлайн-игр. Некоторые увлечённые соперничеством пользователи начали искать пути обхода правил, чтобы получить нечестное преимущество. Например, приобрести необходимые ресурсы или дополнительную информацию о состоянии игры, изменить характеристики персонажей и т.д. Приложения для расширения функциональности игры с целью обхода её правил называются читы (cheats), хаки (hacks) и иногда боты. Это вызывает определённую путаницу. Жульничество в компьютерных играх – это не то же самое, что автоматизация. В этой книге мы проведём чёткую грань между читами и ботами. Боты – это средства для имитации поведения игрока, и именно их мы будем рассматривать.

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

Игровое приложение

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

Сначала мы рассмотрим онлайн-игру. Иллюстрация 1-1 демонстрирует её логические элементы.

Запуская игру на компьютере, вы создаёте новый вычислительный процесс (process). Он имеет собственную область памяти (memory region), которая выделяется операционной системой (ОС). Память – только один из ресурсов предоставляемых ОС. Другими ресурсами являются устройства ввода-вывода: монитор, клавиатура, мышь, сетевая плата и т.д. Процессорное время тоже относится к одному из ресурсов. Оно определяет, как часто конкретный процесс получает управление в многозадачной ОС.

Возможно, вы спросите: “Зачем нужна ОС для запуска игры? Разве не проще работать приложениям вообще без неё?” ОС – это прежде всего удобная платформа для разработки. Без неё каждой компании, создающей программы, пришлось бы изобретать собственные средства для работы с устройствами ввода-вывода. Это потребовало бы много времени и усилий. Намного проще использовать драйвера устройств и системные библиотеки, предоставляемые ОС. Кроме того ни о какой многозадачности не могло бы идти и речи: всё процессорное время использовалось бы только одним приложением, как это было в MS-DOS.

Вернёмся к иллюстрации 1-1. Прямоугольники соответствуют элементам приложения, а стрелки – направлению передачи данных.

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

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

1. Устройство ввода -> Операционная система
Клавиатура посылает сигнал о нажатии клавиши контроллеру прерываний. Это устройство передаёт сигналы в процессор в порядке очереди и с учётом приоритетов. На программном уровне они обрабатываются драйвером ОС.

2. Операционная система -> Клиент игрового приложения
ОС получает от драйвера событие, соответствующее нажатию клавиши. Затем ОС передаёт его дальше: процессу игрового приложения. Обычно, событие нажатия клавиши получает процесс, окно которого является активным в данный момент. Предположим, что активно игровое приложение.

3. Клиент игрового приложения
После получения события нажатия клавиши, процесс обновляет состояние игровых объектов в своей памяти. В нашем случае изменение касается местоположения персонажа.

4. Клиент игрового приложения -> Операционная система
Процесс должен сообщить игровому серверу о новом местоположении персонажа. Для этого надо отправить на сервер сетевой пакет с новой информацией. Процесс обращается к ОС через системную библиотеку. Эта библиотека получает доступ к драйверу сетевой платы, который и отправляет пакет.

5. Операционная система -> Игровой сервер
Игровой сервер получает сетевой пакет. Затем он проверяет, соответствует ли новая информация о персонаже игровым правилам. Если проверка прошла успешно, сервер принимает эти данные и отправляет клиенту подтверждение. Если к серверу подключено несколько клиентов, он рассылает новую информацию о персонаже им всем.

6. Операционная система -> Клиент игрового приложения
Через контроллер прерываний сетевая плата посылает сигнал в процессор о получении сетевого пакета от игрового сервера. Сигнал обрабатывается драйвером. На уровне ОС создаётся соответствующее событие, которое передаётся процессу игрового приложения.

7. Клиент игрового приложения
Процесс извлекает из сетевого пакета код подтверждения игрового сервера. Если код сообщает об ошибке, местоположение персонажа остаётся неизменным. В противном случае процесс пометит в своей памяти, что новая информация о персонаже была успешно принята сервером.

8. Клиент игрового приложения -> Операционная система
Процесс игрового приложения обращается к системной библиотеке ОС (в случае Windows это обычно DirectX) для отображения на мониторе нового положения персонажа.

9. Операционная система -> Устройство вывода
Библиотека ОС выполняет необходимые расчёты и обращается к драйверу видеокарты для отрисовки картинки на экране.

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

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

Большинство современных онлайн-игр работают по рассмотренной нами схеме. Эта схема работы называется архитектурой клиент-сервер.

Иллюстрация 1-2 демонстрирует схему однопользовательской PC-игры. В отличие от онлайн-игры, здесь отсутствует сервер. Действия пользователя отражаются только на памяти процесса игрового приложения, в которой хранится состояние всех объектов.

PC и онлайн-игры взаимодействуют с ресурсами ОС через системные библиотеки по одинаковым алгоритмам.

В случае онлайн-игры, состояние игровых объектов хранится на сервере и клиенте. При этом информация на стороне сервера более приоритетна. Это значит, что если информация клиента отличается, она будет заменена на ту, что хранится на сервере. Таким образом сервер контролирует корректность состояния игровых объектов. В случае однопользовательской PC-игры такого контроля нет.

Виды ботов

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

Классификация сообщества игроков

Изучая информацию о ботах в Интернете, вы наверняка встретите термины внутриигровой (in-game) и внеигровой (out-game). Они широко используются и означают виды ботов, которые хорошо знакомы сообществу игроков. Основа для такой классификации – это способ взаимодействия с игровым приложением.

Внутриигровые боты получили своё название из-за того, что интегрируются в игровое приложение. Иллюстрация 1-3 демонстрирует такое взаимодействие. Специальные приёмы позволяют одному процессу ОС получить доступ к памяти другого процесса, либо загрузить в него произвольный исполняемый код. Таким образом бот манипулирует состоянием игровых объектов (например читает его, модифицирует и записывает обратно).

Внеигровые боты работают отдельно от игрового приложения, как на иллюстрации 1-4. Вместо чтения данных из памяти другого процесса, они используют возможности ОС для взаимодействия между процессами или сетевыми хостами. Хост – это компьютер подключённый к сети (например, клиент игрового приложения или сервер).

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

Второй тип внеигровых ботов работает одновременно с игрой. В этом случае бот собирает информацию о состоянии игровых объектов и симулирует действия пользователя через системные библиотеки ОС. Иллюстрация 1-5 демонстрирует схему такой работы.

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

Классификация разработчиков

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

Чтобы построить классификацию удобную для разработчиков, попробуем взять за основу именно детали реализации ботов. Например, к разным видам будут относиться боты, читающие состояние объектов из памяти игрового приложения, и те, которые обмениваются сообщениями с сервером.

Рассмотрим ещё раз схему приложения онлайн-игры. Отметим красными крестами точки, где бот может перехватить информацию о состоянии игровых объектов. Иллюстрация 1-6 демонстрирует результат.

Мы получили следующий список точек:

• Устройство вывода

С помощью системных библиотек ОС можно перехватывать данные, отправляемые на устройства вывода (например, монитор или звуковую карту). Предположим, что игровой объект отрисовывается на экране. Он имеет определённый цвет в зависимости от своего состояния. Бот может прочитать цвета пикселей отображённой на экране картинки и получить информацию об объекте.

• Операционная система

Бот может замещать или модифицировать системные библиотеки ОС или драйвера. Это позволит ему отслеживать взаимодействие игрового приложения с ОС. Альтернативное решение заключается в запуске игры в виртуальной машине или эмуляторе ОС (например, Wine). Как правило, эмуляторы имеют дополнительные средства журналирования событий. Эта информация позволит боту определить состояние игровых объектов.

• Игровой сервер

Сервер и клиент игрового приложения отправляют друг другу сетевые пакеты, каждый из которых содержит информацию об объектах или её часть. Перехватив достаточно пакетов, бот может сделать вывод о состоянии игры.

• Клиент игрового приложения

Бот может получить доступ к памяти процесса игрового приложения и прочитать из неё информацию. Системные библиотеки ОС предоставляют функции для этого.

Главная задача любого бота – это совершать игровые действия. При этом важно, чтобы он скрывал своё присутствие. То есть игровой сервер должен принимать действия бота так, как будто их совершил пользователь. Иллюстрация 1-7 демонстрирует точки на схеме, в которых бот может внедрять свои данные в приложение.

Список точек получился следующий:

• Устройство ввода

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

• Операционная система

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

• Игровой сервер

Бот может уведомлять сервер о своих действиях напрямую, посылая ему сетевые пакеты. Процедура их отправки может быть скопирована у игрового приложения и перенесена в код бота.

• Клиент игрового приложения

Бот может встраивать свои действия и новые состояния объектов напрямую в память процесса игрового приложения. Таким образом сам игровой клиент будет обрабатывать эти действия и сообщать о них серверу.

В классификации разработчиков каждый бот может использовать одну из рассмотренных точек перехвата данных и внедрения своих действий. Таким образом мы получили 16 возможных комбинаций.

Сравнение ботов

Таблица 1-1 отображает соответствие между классификациями разработчиков и сообщества игроков. В столбцах указаны точки перехвата данных ботом, а в строках – точки внедрения действий. На пересечении полей и строк приведены названия из классификации игроков. Например, кликеры обычно перехватывают данные игры на уровне устройств вывода, а внедряют — на уровне ОС.

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

Перед тем как оценивать различные реализации ботов, определимся с критериями оценки. Рассмотрим три критерия:

1. Насколько трудозатратна реализация бота?
2. Насколько надёжен бот в смысле принятия верных решений?
3. Насколько сложно обнаружить бота системам защиты игры?

Кликеры наиболее просты для разработки и сопровождения. В то же время этот вид ботов наименее надёжен в использовании из-за большого количества совершаемых ошибок. Обнаружение кликеров – достаточно сложная задача для систем защиты игрового приложения.

Внеигровые боты наиболее трудоёмки для реализации. При этом их легко обнаружить. Их сильная сторона – максимальная надёжность в работе.

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

Почему результаты оценки ботов получились именно такими? Чтобы ответить на этот вопрос, рассмотрим каждый вариант реализации ботов с точки зрения оценки трудоёмкости разработки, надёжности и сложности обнаружения.

• Сетевые пакеты

Анализ сетевых пакетов является самым сложным методом перехвата данных. Разработчик бота должен реализовать протокол взаимодействия игрового клиента и сервера. Очевидно, документация на этот протокол есть только у создателей игры. Обычно единственная доступная информация о протоколе – это перехваченные пакеты. Как правило, они зашифрованы и расшифровать их однозначно довольно сложно. С другой стороны, наиболее полная информация об игровых объектах может быть получена только напрямую от сервера. В этом случае игровой клиент ещё не успел её модифицировать или отфильтровать.

• Память процесса игрового приложения

Анализ памяти процесса – второй по сложности метод перехвата данных. Разработчики игр распространяют свои приложения в виде двоичных файлов. Эти файлы генерирует компилятор после прохода по исходному коду игры, который представляет собой читаемый текст. Проблема в том, что процесс компиляции необратим без неоднозначностей. Кроме того, системы защиты ещё более затрудняют изучение алгоритмов и структур данных игрового приложения. С другой стороны, анализ памяти процесса даёт почти такую же полную информацию о состоянии игровых объектов, как и анализ сетевых пакетов.
Внедрять действия бота в память процесса достаточно опасно, так как это может привести к завершению приложения с ошибкой.

• Устройства вывода

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

• Устройства ввода

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

• Операционная система

Перехват данных на уровне ОС – это универсальный и надёжный метод. Существует несколько открытых проектов (например Direct3D 9 API Interceptor), которые позволяют подменять системные библиотеки. В этом случае игровое приложение взаимодействует с библиотеками, контролируемыми ботом. Они собирают информацию о вызываемых функциях ОС. Анализ этой информации позволит определить состояние игровых объектов.
Внедрение действий бота с помощью системных библиотек ОС достаточно просто реализовать. С другой стороны, система защиты легко обнаруживает эту технику.

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

Выводы

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