Об авторе

Илья Шпигорь — разработчик программного обеспечения и поклонник открытого ПО. Имеет большой опыт работы со встраиваемыми системами и информационной безопасностью.

Сейчас работает над системами безопасности Ethernet сетей для автомобилей. До этого занимался системами обнаружения вторжений, авиасимуляторами для профессиональных пилотов и системами управления кораблями. Также участвовал в разработке эмулятора Wine и дистрибутива ALT Linux.

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

Благодарности

Хочу поблагодарить всех, кто принимал участие в написании этой книги. Прежде всего спасибо Светлане Залогиной, которая первая увидела черновики и помогала мне с корректировкой стиля. Без неё эта книга никогда бы не была написана.

Спасибо Данилу Богданову и Эмилю Шайхилисламову, которые указали мне на технические ошибки и предложили несколько отличных идей.

Спасибо Руслану Пясецкому за то, что посвятил меня в тонкости криптографических алгоритмов.

Спасибо Алексею Пыльцыну за помощь с корректурой перевода книги на русский язык и переносом её на платформу Leanpub.

Также спасибо моей маме Елене Шпигорь, которая поддерживала меня на протяжении всей работы над книгой и помогала с корректурой.

Предисловие

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

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

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

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

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

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

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

Задачи ботов

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

Одно из самых ранних упоминаний термина игровой бот встречается применительно к играм в жанре шутер от первого лица (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), которые позволяют подменять системные библиотеки. В этом случае игровое приложение взаимодействует с библиотеками, контролируемыми ботом. Они собирают информацию о вызываемых функциях ОС. Анализ этой информации позволит определить состояние игровых объектов.
Внедрение действий бота с помощью системных библиотек ОС достаточно просто реализовать. С другой стороны, система защиты легко обнаруживает эту технику.

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

Выводы

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

Кликеры

Мы начнём изучение ботов с самого простого для реализации вида – кликеров. В начале этой главы мы рассмотрим широко используемые инструменты для разработки. Затем изучим техники встраивания данных в процесс игрового приложения на уровне ОС, а также перехвата устройства вывода. Чтобы закрепить полученные знания, мы напишем простого бота для игры Lineage 2. Этот небольшой проект поможет нам оценить достоинства и недостатки кликеров. В конце главы мы рассмотрим подходы для обнаружения этого вида ботов системами защиты.

Инструменты для разработки

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

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

Язык программирования

AutoIt — один из самых популярных языков программирования для различных задач автоматизации приложений. У него много возможностей, которые ускоряют разработку:

• Простой для изучения синтаксис.
• Подробная доступная онлайн документация и поддержка сообщества на форумах.
• Хорошая интеграция с функциями ОС (WinAPI) и сторонними библиотеками.
• Встроенный редактор исходного кода.

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

AutoHotKey – это ещё один подходящий язык для написания кликеров. У него есть практически все возможности AutoIt. Основное различие этих языков в синтаксисе. Некоторые примеры этой главы будет проще и быстрее реализовать на AutoHotKey. Но этот язык немного более сложен в изучении.

Библиотеки обработки изображений

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

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

Библиотека FastFind предоставляет продвинутые возможности поиска определённой комбинации пикселей в окне приложения. Например, поиск ближайшего к указанной точке пикселя заданного цвета. Это может быть полезно для обнаружения игровых объектов в случаях, когда библиотека ImageSearch не справляется (например, с 3D-графикой).

Инструменты анализа изображений

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

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

Редакторы исходного кода

В дистрибутив языка AutoIt входит адаптированная версия редактора SciTE. Он хорошо подходит для написания и отладки AutoIt-скриптов. Если же вы планируете использовать другой язык (например, Python или AutoHotKey), вам понадобится более универсальный редактор. Notepad++ будет подходящим решением для разработки небольших скриптов. Для C++ и C# лучше всего использовать Visual Studio Community.

Перехват API

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

Существует несколько инструментов для перехвата вызова функций ОС. Я использовал бесплатное приложение API Monitor v2. У него есть следующие возможности:

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

Список всех возможностей приложения доступен на сайте разработчиков.

Внедрение данных на уровне ОС

Windows API

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

В этой книге мы рассматриваем только ОС Windows. На ней вы сможете запустить все приведённые примеры. В дальнейшем для простоты под ОС всегда будем подразумевать Windows.

Иллюстрация 2-1 демонстрирует интерфейс ОС, через который предоставляется доступ к её ресурсам. Каждый запущенный процесс может обратиться к Windows с запросом на выполнение какого-то действия (например создание нового окна, отправки сетевого пакета, выделения дополнительной памяти и т.д.). Для каждого из таких запросов у ОС есть соответствующая функция (или подпрограмма). Функции, которые решают задачи из одной области (например работа с сетью), собраны в отдельные системные библиотеки.

Способ, которым процесс может вызвать системную функцию, строго определён, хорошо задокументирован и остаётся неизменным для данной версии ОС. Такое взаимодействие можно сравнить с юридическим договором: если процесс выполняет предварительные условия для вызова функции, ОС гарантирует указанный в документации результат. Такой договор называется интерфейс прикладного программирования Windows (Windows API или WinAPI).

Программное обеспечение очень гибко и легко меняется согласно возникающим требованиям. Так каждое обновление Windows вносит изменения в некоторые детали реализации ОС (например, в какую-то системную библиотеку). Эти детали реализации связаны между собой: типичный случай – одна библиотека вызывает функции другой. Таким образом, даже небольшое изменение может оказать значительное влияние на систему в целом. То же самое справедливо и для игрового приложения. Единственное, что позволяет программному обеспечению работать в этом море постоянных изменений – это надёжные интерфейсы. Именно WinAPI гарантирует согласованное состояние системы и обеспечивает совместимость между новыми версиями ОС и приложения.

На иллюстрации 2-1 приведены два типа приложений. Win32-приложение взаимодействует с подмножеством системных библиотек через WinAPI интерфейс. Win32 – это историческое название, которое возникло в первой 32-битной версии Windows (Windows NT). Библиотеки, доступные через WinAPI, также известные как WinAPI библиотеки, содержат функции, оперирующие сложными абстракциями: элемент управления, файл и т.д.

Второй тип приложений называется нативные (native, поэтому иногда переводится как родной). Они взаимодействуют с более низкоуровневыми библиотеками и ядром Windows через Native API. Преимущество этих библиотек в том, что они становятся доступны на раннем этапе загрузки системы, когда многие функции ОС ещё не работоспособны. Функции этих библиотек оперируют простыми абстракциями, такими как страница памяти, процесс, поток и т.д. Примеры нативных приложений: утилита для разбивки жёсткого диска, антивирус до старта ОС, программа восстановления Windows.

Библиотеки WinAPI вызывают функции низкоуровневых библиотек. Такой подход позволяет составлять сложные абстракции из более простых. Низкоуровневые библиотеки в свою очередь вызывают функции ядра.

Драйвера предоставляют упрощённое представление устройств для системных библиотек. Это представление включает в себя набор функций, которые выполняют характерные для данного устройства действия. WinAPI и низкоуровневые библиотеки обращаются к драйверам через функции ядра.

Слой аппаратной абстракции (Hardware Abstraction Layer или HAL) – это модуль ядра ОС, который предоставляет универсальный доступ к различному аппаратному обеспечению. HAL нужен, чтобы облегчить портирование и сопровождение Windows на новых аппаратных платформах. Функции HAL используются ядром ОС и драйверами устройств.

Симуляция нажатий клавиш

Теперь мы рассмотрим технику симуляции нажатий клавиш. Это наиболее простой метод контроля ботом игрового приложения.

Нажатия клавиш в активном окне

Рассмотрим, какие возможности предлагает AutoIt для решения нашей задачи. В списке доступных функций есть функция Send. Мы воспользуемся ею в тестовом скрипте, который будет нажимать клавишу “a” в окне приложения Notepad (Блокнот).

Алгоритм работы нашего скрипта выглядит следующим образом:

1. Найти окно Notepad среди всех открытых окон.
2. Переключится на него.
3. Симулировать нажатие клавиши “a”.

Для поиска окна приложения мы воспользуемся функцией WinGetHandle. Её первый параметр является обязательным и может быть как заголовком окна, так и его классом. Функция возвращает дескриптор (handle) окна. Дескриптор – это структура данных, которая представляет некоторый ресурс или объект ОС. Большинство функций WinAPI оперируют этими структурами при работе с объектами.

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

Для чтения класса окна Notepad необходимо выполнить следующие шаги:

1. Запустить приложение Au3Info. Вы можете найти его в каталоге установки AutoIt. Путь к приложению по умолчанию: C:\Program Files (X86)\AutoIt3\Au3Info.exe.
2. Перетащить иконку “Finder Tool” на окно Notepad и отпустить.

Вы увидите результат, приведённый на иллюстрации 2-2.

Класс окна Notepad отображается на панели “Basic Info Window”. Этот класс – “Notepad”.

Скрипт Send.au3, представленный в листинге 2-1, симулирует нажатие клавиши “a”.

1 $hWnd = WinGetHandle("[CLASS:Notepad]")
2 WinActivate($hWnd)
3 Send("a")

В первой строке мы получаем дескриптор окна Notepad с помощью функции WinGetHandle. Далее мы переключаем фокус ввода на это окно функцией WinActivate. Последнее действие – симуляция нажатия клавиши “a”.

Чтобы запустить этот скрипт, создайте в вашем редакторе исходного кода файл с именем Send.au3 и скопируйте в него приведённый выше код. Запустите скрипт двойным щелчком по иконке этого файла.

Функция Send

Функция Send представляет собой обёртку над WinAPI вызовом. Мы можем выяснить что это за вызов с помощью приложения API Monitor, которое перехватит все обращения к WinAPI скрипта Send.au3.

Для подключения API Monitor к работающему процессу выполните следующие шаги:

1. Запустите 32-битную версию API Monitor.
2. Переключитесь на панель “API Filter” щелчком мыши. Нажмите комбинацию клавиш Ctrl+F, чтобы открыть диалог поиска. Введите в поле “Find what:” текст “Keyboard and Mouse Input” и нажмите кнопку “Find Next”. Закройте диалог поиска и активируйте найденный флажок (check box) “Keyboard and Mouse Input”.
3. Нажмите Ctrl+M для открытия диалога “Monitor New Process”. Выберите приложение AutoIt3.exe в поле “Process” и нажмите кнопку “OK”. По умолчанию путь к этому приложению должен быть следующий: C:\Program Files (x86)\AutoIt3\AutoIt3.exe.
4. В открывшемся диалоге “Run Script” выберите скрипт Send.au3. Сразу после этого начнётся его выполнение.
5. Переключитесь на панель “Summary” окна API Monitor. По нажатию Ctrl+F откройте диалог поиска и с его помощью найдите текст ‘a’ (с одинарными кавычками).

Иллюстрация 2-3 демонстрирует ожидаемый результат. Согласно перехваченным вызовам, VkKeyScanW – это единственная WinAPI-функция, получившая символ “a” в качестве параметра. Если мы обратимся к официальной документации WinAPI, выяснится что эта функция не выполняет нажатия клавиши. Она вместе с функцией MapVirtualKeyW только подготавливает параметры для вызова SendInput, который и симулирует нажатие.

Мы узнали достаточно, чтобы симулировать нажатие клавиши “a” напрямую через WinAPI вызовы. Удалим третью строчку скрипта Send.au3 и заменим её новым блоком кода. При этом оставим первые два вызова WinGetHandle и WinActivate без изменений. Листинг 2-2 демонстрирует получившийся результат.

 1 $hWnd = WinGetHandle("[CLASS:Notepad]")
 2 WinActivate($hWnd)
 3 
 4 Const $KEYEVENTF_UNICODE = 4
 5 Const $INPUT_KEYBOARD = 1
 6 Const $iInputSize = 28
 7 
 8 Const $tagKEYBDINPUT = _
 9     'word wVk;' & _
10     'word wScan;' & _
11     'dword dwFlags;' & _
12     'dword time;' & _
13     'ulong_ptr dwExtraInfo'
14 
15 Const $tagINPUT = _
16     'dword type;' & _
17     $tagKEYBDINPUT & _
18     ';dword pad;'
19 
20 $tINPUTs = DllStructCreate($tagINPUT)
21 $pINPUTs = DllStructGetPtr($tINPUTs)
22 $iINPUTs = 1
23 $Key = AscW('a')
24 
25 DllStructSetData($tINPUTs, 1, $INPUT_KEYBOARD)
26 DllStructSetData($tINPUTs, 3, $Key)
27 DllStructSetData($tINPUTs, 4, $KEYEVENTF_UNICODE)
28 
29 DllCall('user32.dll', 'uint', 'SendInput', _
30         'uint', $iINPUTs, 'ptr', $pINPUTs, 'int', $iInputSize)

Здесь мы используем функцию AutoIt DllCall. С её помощью можно вызвать код динамической библиотеки (DLL), написанной на языке C или C++. В данном случае мы делаем WinAPI вызов SendInput. Его входные параметры должны иметь типы, согласно документации WinAPI. Некоторые из этих типов AutoIt не поддерживает на уровне синтаксиса. Поэтому нам нужны дополнительные шаги, чтобы подготовить эти параметры.

Таблица 2-1 демонстрирует входные параметры функции DllCall.

Согласно WinAPI документации, декларация функции SendInput выглядит следующим образом:

1 UINT SendInput(UINT cInputs, LPINPUT pInputs, int cbSize);

Строчку вызова функции DllCall на AutoIt можно представить эквивалентом на языке C++:

1 SendInput(iINPUTs, pINPUTs, iInputSize);

Рассмотрим входные параметры, переданные нами в SendInput:

1. iINPUTs – количество структур типа INPUT, которые передаются вторым параметром.
2. pINPUTs – указатель на массив структур типа INPUT из одного элемента. Этот массив подготавливается в несколько этапов. Сначала мы объявляем строки KEYBDINPUT и INPUT с описанием полей соответствующих структур. При этом KEYBDINPUT является вторым полем INPUT. Такое отношение называется вложенные структуры (nested structure). На следующем шаге создаются структуры в формате языка C++ через вызов DllStructCreate. Результат сохраняется в переменной tINPUTs. С помощью функции DllStructGetPtr мы получаем указатель на эту структуру и помещаем его в pINPUTs. Запись значений полей C++ структуры происходит через вызов DllStructSetData. Обратите внимание, что вторым параметром в DllStructSetData передаётся номер поля, начиная с единицы. В случае вложенных структур их поля нумеруются последовательно. То есть элемент 1 соответствует полю dword type структуры INPUT, а элемент 3 – полю word wScan структуры KEYBDINPUT.
3. iInputSize – размер одной структуры INPUT в байтах. В нашем случае это константное значение, рассчитанное по формуле:

1 dword + (word + word + dword + dword + ulong_ptr) + dword =
2 4 + (2 + 2 + 4 + 4 + 8) + 4 = 28

Слагаемые в скобках – это размеры полей вложенной структуры KEYBDINPUT.

Может быть непонятно, откуда взялись последние четыре байта в приведённой выше формуле. Возможно, вы обратили внимание, что объявленная в скрипте Send.au3 структура INPUT имеет последнее поле типа dword с именем padding (набивка). Оно не используется и служит для выравнивания данных. Рассмотрим это поле подробнее.

Определение структуры INPUT согласно документации WinAPI выглядит следующим образом:

1 typedef struct tagINPUT {
2   DWORD type;
3   union {
4     MOUSEINPUT    mi;
5     KEYBDINPUT    ki;
6     HARDWAREINPUT hi;
7   };
8 } INPUT, *PINPUT;

Вложенная структура KEYBDINPUT на самом деле помещена в блок union с другими структурами MOUSEINPUT и HARDWAREINPUT. Это означает, что под все три структуры будет выделена одна и та же область памяти. Но использоваться она будет только одной из них. Так как область одна, её размер должен соответствовать самой большой структуре, которой является MOUSEINPUT. Она больше KEYBDINPUT на одно поле типа dword, т.е. на четыре байта. Именно из-за него мы добавили padding в наше определение KEYBDINPUT для выравнивания.

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

Нажатия клавиш в неактивном окне

Функция AutoIt Send симулирует нажатия клавиш в активном окне. Другими словами, вы не можете свернуть это окно или переключится на другое, что в некоторых случаях неудобно. Функция ControlSend позволяет обойти такое ограничение. Мы можем переписать скрипт Send.au3 с использованием ControlSend, как демонстрирует листинг 2-3.

1 $hWnd = WinGetHandle("[CLASS:Notepad]")
2 ControlSend($hWnd, "", "Edit1", "a")

Третьим параметром в функцию ControlSend передаётся элемент интерфейса (control), который получает симулируемое нажатие клавиши. Указать на него можно несколькими способами. В нашем случае, мы передаём класс элемента “Edit1”. Его можно узнать с помощью утилиты Au3Info точно так же, как и класс окна.

Применив API Monitor, мы узнаем, что ControlSend внутри себя вызывает WinAPI-функцию SetKeyboardState. В качестве упражнения предлагаю вам переписать скрипт ControlSend.au3 так, чтобы он вызывал SetKeyboardState напрямую.

Скрипт ControlSend.au3 работает корректно во всех случаях, кроме симуляции нажатия клавиши в развёрнутом на весь экран окне приложения DirectX. Проблема заключается в том, что такое окно не имеет элементов интерфейса. Чтобы её решить, достаточно просто не указывать третий параметр controlID функции ControlSend. Листинг 2-4 демонстрирует исправленный скрипт.

1 $hWnd = WinGetHandle("Warcraft III")
2 ControlSend($hWnd, "", "", "a")

Этот скрипт ищет окно игры Warcraft 3 по его заголовку и симулирует в нём нажатие клавиши “a”. Узнать заголовок окна DirectX-приложения иногда бывает сложно, потому что не всегда можно выйти из полноэкранного режима. В этом случае утилиты вроде Au3Info вам не помогут. Вместо них с этой задачей справится API Monitor. Если в окне приложения вы наведёте курсор мыши на интересующий вас процесс на панели “Running Process”, вы увидите заголовок окна этого приложения, как показано на иллюстрации 2-4.

Если вы не можете найти нужный процесс на панели “Running Process”, попробуйте запустить API Monitor с правами администратора. Если это не помогло и у вас установлена 64-битная версия Windows, надо запустить обе версии API Monitor – 32- и 64-битную. В одной из них процесс должен появиться.

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

Чтобы получить класс окна, открытого в полноэкранном режиме, вы можете воспользоваться скриптом AutoIt, приведённом в листинге 2-5.

1 #include <WinAPI.au3>
2 Sleep(5 * 1000)
3 $handle = WinGetHandle('[Active]')
4 MsgBox(0, "", "Title   : " & WinGetTitle($handle) & @CRLF _
5        & "Class : " & _WinAPI_GetClassName($handle))

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

Рассмотрим подробнее скрипт GetWindowTitle.au3. В первой строке стоит ключевое слово (keyword) include. С его помощью AutoIt включает содержание указанного скрипта WinAPI.au3 в текущий. В WinAPI.au3 реализована нужная нам функция _WinAPI_GetClassName. Она возвращает класс окна по его дескриптору. Далее с помощью функции Sleep скрипт ждёт пять секунд. После этого дескриптор активного в данный момент окна сохраняется в переменную handle. Функция MsgBox создаёт диалоговое окно, в котором выводится результат. Заголовок окна возвращает функция WinGetTitle.

Симуляция действий мыши

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

Действия мыши в активном окне

Мы воспользуемся графическим редактором Microsoft Paint для тестирования скриптов, симулирующих действия мыши. Самое простое действие – это однократный щелчок в указанной точке экрана. Листинг 2-6 демонстрирует соответствующий скрипт.

1 $hWnd = WinGetHandle("[CLASS:MSPaintApp]")
2 WinActivate($hWnd)
3 MouseClick("left", 250, 300)

Для тестирования этого скрипта выполните следующее:

1. Запустите приложение Paint.
2. Переключитесь на инструмент “Кисти” (Brushes).
3. Запустите скрипт MouseClick.au3.

Скрипт нарисует чёрную точку по координатам x = 250, y = 300. Их корректность вы можете проверить с помощью утилиты ColorPix.

Для симуляции щелчка мыши мы использовали функцию AutoIt MouseClick. Она принимает пять входных параметров, первые три из которых являются обязательными:

1. Кнопка мыши для щелчка. Основные варианты: левая (left), правая (right), средняя (middle).
2. Координата X позиции курсора.
3. Координата Y позиции курсора.
4. Число последовательных щелчков.
5. Скорость мыши для перемещения курсора в указанные координаты.

Внутри себя MouseClick вызывает WinAPI-функцию mouse_event.

Координаты позиции курсора можно задавать в одном из трёх режимов, представленных в таблице 2-2.

Рассмотрим иллюстрацию 2-5. Каждый номер соответствует режиму координат из таблицы 2-1. Например, точка с номером “0” демонстрирует режим относительно активного окна. Её координаты X0 и Y0.

Функция AutoIt Opt, вызванная с первым параметром MouseCoordMode, позволяет выбрать режим координат для текущего скрипта. Листинг 2-7 демонстрирует выбор координат относительно клиентской части окна в скрипте MouseClick.au3.

1 Opt("MouseCoordMode", 2)
2 $hWnd = WinGetHandle("[CLASS:MSPaintApp]")
3 WinActivate($hWnd)
4 MouseClick("left", 250, 300)

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

Одно из распространённых действий мышью в компьютерных играх – перетаскивание (drag-and-drop). Для его симуляции AutoIt предоставляет функцию MouseClickDrag. Листинг 2-8 демонстрирует её использование.

1 $hWnd = WinGetHandle("[CLASS:MSPaintApp]")
2 WinActivate($hWnd)
3 MouseClickDrag("left", 250, 300, 400, 500)

После запуска скрипт MouseClickDrag.au3 рисует линию в окне Paint. Координаты её начала: x = 250, y = 300. Она заканчивается в точке x = 400, y = 500. Функция AutoIt MouseClickDrag делает внутри себя уже знакомый нам WinAPI вызов mouse_event. Обе AutoIt функции MouseClick и MouseClickDrag симулируют действия мыши только в активном окне.

Действия мыши в неактивном окне

AutoIt предоставляет функцию ControlClick, которая симулирует щелчок мыши в неактивном окне. Пример её использования приведён в листинге 2-9.

1 $hWnd = WinGetHandle("[CLASS:MSPaintApp]")
2 ControlClick($hWnd, "", "Afx:00000000FFC20000:81", "left", 1, 250, 300)

Скрипт ControlClick.au3 симулирует щелчок мыши в неактивном или свёрнутом окне Paint. По принципу работы функция ControlClick похожа на ControlSend. Вы должны указать элемент интерфейса по которому будет выполнен щелчок. В нашем случае – это рабочая область окна Paint, в которой пользователь применяет инструменты рисования (например кисти). Согласно информации от утилиты Au3Info, элемент рабочей области имеет класс “Afx:00000000FFC20000:81”.

Ради эксперимента мы можем передать одни и те же координаты курсора в функции MouseClick и ControlClick. В результате щелчки мыши произойдут в разных точках экрана. Причина в том, что входные параметры функции ControlClick – это координаты относительно левого верхнего угла указанного элемента интерфейса. В случае скрипта ControlClick.au3, щелчок произойдёт в точке x = 250, y = 300 относительно левого верхнего угла рабочей области. Тогда как режим координат для функции MouseClick определяется параметром MouseCoordMode.

ControlClick дважды вызывает WinAPI-функцию PostMessageW внутри себя. Иллюстрация 2-6 демонстрирует её вызовы, перехваченные с помощью API Monitor.

При вызове функции PostMessageW первый раз, в неё передаётся параметр WM_LBUTTONDOWN. В результате симулируется нажатие кнопки мыши и её удержание. Во втором вызове передаётся параметр WM_LBUTTONUP, что соответствует отпусканию кнопки мыши.

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

Выводы

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

Перехват устройств вывода

В этом разделе мы познакомимся с методами перехвата данных с устройств вывода. Сначала мы изучим, какие возможности Windows предоставляет приложениям для работы с этими устройствами. Затем рассмотрим способы перехвата выводимых на них изображений.

Интерфейс графических устройств Windows

Интерфейс графических устройств (Graphics Device Interface или GDI) – один из основных компонентов Windows, который отвечает за представление графических объектов и передачу их на устройства вывода. Обычно все элементы интерфейса окна приложения создаются с помощью графических объектов, таких как контекст устройства (device context или DC), битовое изображение (bitmap), кисти, цвета, шрифты.

Ключевая концепция GDI – это контекст устройства. Он представляет собой абстракцию, благодаря которой разработчики могут единообразно работать с графическими объектами независимо от устройства вывода (монитором, принтером, плоттером или графопостроителем и т.д). Сначала все операции по подготовке изображения выполняются над контекстом устройства в памяти. Затем готовый результат отправляется на устройство вывода.

На иллюстрации 2-7 приведены два контекста устройств, которые содержат изображения окон двух приложений A и B. Также на ней представлен DC, соответствующий итоговому изображению всего рабочего стола. ОС может собрать это изображение из всех видимых окон и визуальных элементов рабочего стола (например панели задач). Когда контекст устройства подготовлен в памяти, ОС выводит его содержимое на экран.

Предположим, вам нужно напечатать документ, открытый в текстовом редакторе (окно B). В этом случае ОС просто отправляет DC окна этого приложения на принтер. Контексты устройств, связанные с другими открытыми в данный момент окнами игнорируются.

Контекст устройства представляет собой структуру в памяти. Разработчики могу работать с ней только через WinAPI-функции. Каждый DC содержит аппаратно-зависимое битовое изображение (Device Depended Bitmap или DDB). Битовое изображение – это представление поверхности для рисования в памяти. Все операции над графическими объектами в контексте устройства отражаются на соответствующем битовом изображении. Следовательно, оно хранит результат всех этих операций.

Битовое изображение состоит из двух основных частей:

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

У каждого пикселя есть два параметра: координаты и цвет. Их соответствие задаётся двумерным массивом. Номера элементов массива (индексы) равны координатам пикселя по осям X и Y. Числовое значение элемента массива соответствует коду цвета в палитре, которая связана с данным битовым изображением. Для анализа изображения все элементы двумерного массива должны обрабатываться последовательно.

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

Функции AutoIt для анализа изображений

AutoIt предоставляет функции для анализа текущего изображения на экране. Все они оперируют объектами GDI. Сейчас мы подробно рассмотрим эти функции.

Анализ отдельного пикселя

Самая простая операция при анализе изображения – это чтение цвета одного пикселя. Для этого необходимо знать его координаты. AutoIt поддерживает несколько режимов координат, которые представлены в таблице 2-3. Они идентичны режимам координат позиционирования курсора мыши из таблицы 2-2.

Выбрать нужный режим координат можно с помощью функции Opt, вызванной с первым параметром PixelCoordMode. Например, следующий вызов переключает скрипт во второй режим:

1 Opt("PixelCoordMode", 2)

Функция AutoIt PixelGetColor читает цвет пикселя. Входными параметрами она принимает координаты X и Y пикселя. Функция возвращает код цвета в десятичной системе счисления. Листинг 2-10 демонстрирует её использование.

1 $color = PixelGetColor(200, 200)
2 MsgBox(0, "", "Цвет пикселя: " & Hex($color, 6))

Скрипт PixelGetColor.au3 читает цвет пикселя с координатами x = 200, y = 200. После этого функция MsgBox выводит диалоговое окно с результатом. После запуска скрипта, вы увидите сообщение вроде: “Цвет пикселя 0355BB”.

Цвет кодируется числом 0355BB в шестнадцатеричной системе счисления. Такое представление широко распространено и называется цветовой моделью RGB. В ней любой цвет представляется координатами в трёхмерном цветовом пространстве. Трём его осям соответствуют цвета: X – красный (Red), Y – зелёный (Green) и Z – синий (Blue). Таким образом, цвет 0355BB из нашего примера соответствует точке с координатами: X = 03, Y = 55, Z = BB. Большинство графических редакторов и утилит используют этот способ кодирования.

Если вы переместите окно Notepad так, чтобы перекрыть им точку с координатой x = 200, y = 200 рабочего стола, результат возвращаемый скриптом PixelGetColor.au3 изменится. Это означает, что он анализирует не конкретное окно, а изображение всего рабочего стола.

Иллюстрация 2-8 демонстрирует перехваченные WinAPI вызовы скрипта PixelGetColor.au3.

Функция PixelGetColor делает внутри себя три WinAPI вызова в следующей последовательности: GetDC, GetPixel, ReleaseDC. GetDC получает входным параметром значение “NULL”. Таким образом мы выбираем контекст устройства всего экрана для дальнейших операций. Если мы передадим в функцию GetDC дескриптор окна, мы получим DC его клиентской области. Благодаря этому наш скрипт сможет анализировать неактивные или перекрытые окна.

Дескриптор окна можно передать третьим параметром в AutoIt функцию PixelGetColor. Листинг 2-11 демонстрирует это решение.

1 $hWnd = WinGetHandle("[CLASS:MSPaintApp]")
2 $color = PixelGetColor(200, 200, $hWnd)
3 MsgBox(0, "", "Цвет пикселя: " & Hex($color, 6))

Скрипт PixelGetColorWindow.au3 должен вернуть цвет пикселя в окне Paint, даже если оно неактивно. Мы ожидаем прочитать белый цвет с кодом “FFFFFF”, потому что область для рисования по умолчанию пуста.

Скрипт работает корректно, если окно Paint активно. Теперь попробуем перекрыть его окном другого приложения (например интерпретатором командной строки CMD). Скрипт прочитает чёрный цвет вместо белого.

Сравним WinAPI вызовы скриптов PixelGetColorWindow.au3 и PixelGetColor.au3, перехваченные с помощью приложения API Monitor. В обоих случаях функция GetDC получает “NULL” входным параметром. Такое поведение похоже на ошибку в реализации функции PixelGetColor версии 3.3.14.1 AutoIt. Возможно, она будет исправлена в следующий версиях. Попробуем эту ошибку обойти.

Проблема функции PixelGetColor в некорректном параметре при вызове GetDC. Мы знаем, к каким WinAPI-функциям обращается PixelGetColor. Поэтому можем вызвать их напрямую из нашего скрипта, но с корректными параметрами. Результат приведён в листинге 2-12.

1 #include <WinAPIGdi.au3>
2 
3 $hWnd = WinGetHandle("[CLASS:MSPaintApp]")
4 $hDC = _WinAPI_GetDC($hWnd)
5 $color = _WinAPI_GetPixel($hDC, 200, 200)
6 MsgBox(0, "", "Цвет пикселя: " & Hex($color, 6))

Скрипт GetPixel.au3 начинается с ключевого слова include. С его помощью мы включаем файл WinAPIGdi.au3, который содержит обёртки _WinAPI_GetDC и _WinAPI_GetPixel для соответствующих WinAPI-функций. Этот скрипт читает цвет пикселя окна Paint, независимо от того перекрыто оно или нет.

У рассмотренного нами решения есть одна проблема. Если вы свернёте окно Paint и запустите скрипт, он вернёт белый цвет. Этот результат выглядит корректным. Теперь попробуем изменить цвет рабочей области Paint, залив её для примера красным. Свернём окно снова, и запустим скрипт. Он опять прочитает белый цвет, хотя мы ожидаем красный. Рассмотрим, почему это происходит.

У каждого окна есть клиентская область. В этой области находятся все элементы интерфейса кроме заголовка окна, его границ и главного меню. Наша проблема с чтением цвета пикселя возникла из-за того, что размер клиентской области свёрнутого окна равен нулю. Следовательно, контекст устройства, связанный с окном, имеет пустое битовое изображение. При попытке чтения несуществующего пикселя, функция WinAPI GetPixel возвращает белый цвет.

Мы можем прочитать размер клиентской области окна с помощью скрипта, представленного в листинге 2-13.

1 #include <WinAPI.au3>
2 
3 $hWnd = WinGetHandle("[CLASS:MSPaintApp]")
4 $tRECT = _WinAPI_GetClientRect($hWnd)
5 MsgBox(0, "Прямоугольник", _
6        "Левый край: " & DllStructGetData($tRECT, "Left") & @CRLF & _
7        "Правый край: " & DllStructGetData($tRECT, "Right") & @CRLF & _
8        "Верхний край: " & DllStructGetData($tRECT, "Top") & @CRLF & _
9        "Нижний край: " & DllStructGetData($tRECT, "Bottom"))

Скрипт GetClientRect.au3 выводит X- и Y-координаты верхней левой и правой нижней точки клиентской области окна Paint. Если оно свёрнуто, все координаты равны нулю. В противном случае мы получим ненулевые числа.

Ограничение при работе со свёрнутым окном крайне неудобно, если вы планируете запускать бота и переключаться на другие приложения. У этой проблемы есть решение. Windows позволяет восстановить свёрнутое окно в прозрачном режиме. После этого можно скопировать битовое изображение его клиентской области в DC, связанный с оперативной памятью, и свернуть окно снова. Для копирования можно воспользоваться WinAPI-функцией PrintWindow. После можно анализировать копию с помощью известной нам AutoIt-обёртки _WinAPI_GetPixel.

Следующая статья подробно рассматривает работу со свёрнутыми окнами.

Анализ изменений картинки

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

Предположим, что мы ищем конкретный игровой объект на экране. Мы знаем его цвет, но не координаты. Эта задача является обратной той, которую решает функция AutoIt PixelGetColor. Для поиска координат игрового объекта по его цвету можно воспользоваться функцией PixelSearch. Листинг 2-14 демонстрирует пример.

1 $coord = PixelSearch(0, 207, 1000, 600, 0x000000)
2 If @error = 0 then
3     MsgBox(0, "", "Координата чёрной точки: x = " & $coord[0] & _
4            " y = " & $coord[1])
5 else
6     MsgBox(0, "", "Чёрная точка не найдена")
7 endif

Скрипт PixelSearch.au3 ищет пиксель чёрного цвета с кодом 000000 в прямоугольной области экрана с координатами верхнего левого угла x = 0, y = 207 и правого нижнего – x = 1000, y = 600. Если в процессе поиска происходит ошибка, мы обрабатываем её с помощью макроса @error. В этом случае выводится сообщение: “Чёрная точка не найдена”.

Макрос @error можно рассматривать как глобальную переменную. Если в процессе работы AutoIt функции происходит ошибка, её код будет записан в @error. При обработке ошибки важно проверять макрос сразу после вызова функции, поскольку последующие вызовы могут переписать его значение.

Воспользуемся приложением Paint, чтобы протестировать скрипт PixelSearch.au3. Сначала поставим чёрную точку с помощью карандаша или кисти в области для рисования. Затем запустим скрипт. Он выведет координаты точки в диалоговом окне. Если этого не произошло, убедитесь, что Paint не перекрывают другие окна.

Проверим, какие вызовы WinAPI делает функция PixelSearch. Для этого запустим скрипт PixelSearch.au3 из приложения API Monitor. Подождём, пока он отработает. После этого будем искать текст “0, 207” (координаты точки) в окне “Summary”. Вы должны найти вызов WinAPI StretchBlt, как показано на иллюстрации 2-9.

Функция StretchBlt копирует битовое изображение из DC экрана в контекст устройства памяти, который также известен как совместимый контекст устройства (compatible device context). Чтобы проверить это предположение, сравним входные параметры вызовов GetDC, CreateCompatibleBitmap, CreateCompatibleDC, SelectObject и StretchBlt в окне API Monitor.

Функция GetDC возвращает дескриптор DC экрана, который в нашем случае равен 0x5a011146. Что означает это шестнадцатеричное число? Воспользуемся документацией WinAPI, чтобы уточнить определение типа HDC, соответствующее дескриптору DC:

1 typedef void *PVOID;
2 typedef PVOID HANDLE;
3 typedef HANDLE HDC;

HDC представляет собой указатель на область памяти. Следовательно, 0x5a011146 – это адрес памяти, где хранится дескриптор.

Вызов CreateCompatibleBitmap идёт после GetDC. Он создаёт битовое изображение для работы над ним в памяти. Первым входным параметром CreateCompatibleBitmap принимает дескриптор DC экрана. Далее с помощью CreateCompatibleDC создаётся совместимый контекст устройства. Вызовом SelectObject в него загружается битовое изображение. После этого вызов StretchBlt может выполнить копирование изображения из контекста экрана (дескриптор 0x5a011146) в совместимый DC в памяти.

На следующем шаге AutoIt-функции PixelSearch происходит WinAPI-вызов GetDIBits. Он конвертирует аппаратно-зависимое битовое изображение (DDB) в аппаратно-независимое (DIB). Зачем это нужно? DIB формат более удобен, поскольку позволяет работать с изображениями как с обычным массивом.

Заключительный шаг функции PixelSearch – проход по всем пикселям DIB и сравнение цвета каждого из них с заданным. Для этой операции вызовы WinAPI не нужны.

Пример C++ реализации захвата изображений с экрана доступен в WinAPI документации. Эта реализация демонстрирует копирование битового изображения в совместимый DC и преобразование DDB в DIB.

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

Листинг 2-15 демонстрирует поиск пикселя в заданном окне.

1 $hWnd = WinGetHandle("[CLASS:MSPaintApp]")
2 $coord = PixelSearch(0, 207, 1000, 600, 0x000000, 0, 1, $hWnd)
3 If @error = 0 then
4     MsgBox(0, "", "Координата чёрной точки: x = " & $coord[0] & _
5            " y = " & $coord[1])
6 else
7     MsgBox(0, "", "Чёрная точка не найдена")
8 endif

Согласно документации AutoIt, скрипт PixelSearchWindow.au3 должен искать пиксель в перекрытом окне Paint, но этого не происходит. Похоже, что мы снова столкнулись с ошибкой, которая проявлялась ранее в функции PixelGetColor. API Monitor подтвердит, что в WinAPI вызов GetDC снова передаётся “NULL” вместо дескриптора окна. По этой причине PixelSearch всегда обрабатывает DC экрана, независимо от своего пятого параметра. Вы можете обойти эту ошибку, если будете работать с WinAPI напрямую. Пример аналогичного решения приведён в листинге 2-12. В этом случае вам необходимо полностью повторить алгоритм функции PixelSearch.

PixelChecksum – это ещё одна функция AutoIt для анализа движущихся изображений. Рассмотренные нами ранее функции PixelGetColor и PixelSearch позволяют получить информацию о единственном пикселе. PixelChecksum работает иначе. Она обнаруживает изменение изображения в заданной области экрана. Это может быть полезно, когда бот должен реагировать на игровые события.

Функция PixelChecksum рассчитывает контрольную сумму (checksum) для пикселей в указанной области. Эта сумма представляет собой число, полученное в результате применения определённого алгоритма к набору данных. Простейшим примером такого алгоритма может быть суммирование кодов цветов пикселей. Если цвет хотя бы одного пикселя поменяется, результирующая контрольная сумма также изменится.

Листинг 2-16 демонстрирует применение функции PixelChecksum.

1 $checkSum = PixelChecksum(0, 0, 50, 50)
2 
3 while $checkSum = PixelChecksum(0, 0, 50, 50)
4     Sleep(100)
5 wend
6 
7 MsgBox(0, "", "Изображение в области экрана изменилось")

Скрипт PixelChecksum.au3 выводит диалоговое окно, если меняется изображение в области экрана между точками с координатами x = 0, y = 0 и x = 50, y = 50. В скрипте многократно вызывается функция PixelChecksum. Первый раз она вычисляет начальное значение контрольной суммы. После этого функция вызывается каждые 100 миллисекунд в цикле while. Временная задержка выполняется с помощью вызова Sleep. Цикл продолжается до тех пор, пока контрольная сумма не изменится. Как только это происходит, цикл прерывается и выводится диалоговое окно.

Рассмотрим внутренние вызовы функции PixelChecksum. API Monitor покажет нам ту же самую последовательность WinAPI вызовов, что и для функции PixelSearch. Это означает, что AutoIt следует одному и тому же алгоритму для получения DIB из изображения на экране. Однако, последний шаг этих двух функций отличается. PixelChecksum вычисляет контрольную сумму по указанному алгоритму. Вы можете выбрать один из двух доступных алгоритмов: ADLER или CRC32. Рассмотрим их различия.

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

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

Библиотеки для анализа изображений

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

Библиотека FastFind

Библиотека FastFind предоставляет мощные функции для анализа изображений, которые хорошо подходят для поиска игровых объектов на экране. Эти функции доступны как из AutoIt скриптов, так и из C++ приложений.

Для вызова функции библиотеки из AutoIt скрипта выполните следующие шаги:

1. Создайте отдельную папку для вашего скрипта. Для примера назовём её FFDemo.
2. Скопируйте файл FastFind.au3 из архива FastFind библиотеки в папку FFDemo.
3. Скопируйте также один из файлов FastFind.dll или FastFind64.dll. Если вы работаете на 64-битной версии Windows, вам нужен файл FastFind64.dll, иначе – FastFind.dll.
4. Включите файл FastFind.au3 в ваш скрипт с помощью include:

1 #include "FastFind.au3"

Теперь вы можете вызывать функции FastFind в своём скрипте.

Для работы с функциями библиотеки из C++ приложения сделайте следующее:

1. Скачайте и установите компилятор C++. Это может быть IDE Visual Studio Community с сайта Microsoft, в которую уже встроен компилятор. Альтернативным решением является набор инструментов MinGW.
2. Если вы используете MinGW, создайте файл с исходным кодом (например test.cpp). В случае Visual Studio, создайте проект “Win32 Console Application”.
3. Скопируйте код из листинга 2-17 в свой CPP-файл.
4. Скопируйте из архива библиотеки файл FastFind.dll в папку вашего проекта. FastFind64.dll следует копировать только в том случае, если вы собираетесь компилировать 64-битные исполняемые файлы.
5. Если вы используете MinGW, создайте файл с именем Makefile и следующим содержанием:

1 all:
2     g++ test.cpp -o test.exe

6. В случае использования MinGW, скомпилируйте приложение с помощью команды make, запущенной в командной строке CMD. Для Visual Studio достаточно нажать горячую клавишу F7.

 1 #include <iostream>
 2 
 3 #define WIN32_LEAN_AND_MEAN
 4 #include <windows.h>
 5 
 6 using namespace std;
 7 
 8 typedef LPCTSTR(CALLBACK* LPFNDLLFUNC1)(void);
 9 
10 HINSTANCE hDLL;               // Дескриптор DLL-библиотеки
11 LPFNDLLFUNC1 lpfnDllFunc1;    // Указатель на функцию
12 LPCTSTR uReturnVal;
13 
14 int main()
15 {
16     hDLL = LoadLibraryA("FastFind");
17     if (hDLL != NULL)
18     {
19         lpfnDllFunc1 = (LPFNDLLFUNC1)GetProcAddress(hDLL, "FFVersion");
20         if (!lpfnDllFunc1)
21         {
22             // Обработка ошибки
23             FreeLibrary(hDLL);
24             cout << "error" << endl;
25             return 1;
26         }
27         else
28         {
29             // Вызов функции из библиотеки
30             uReturnVal = lpfnDllFunc1();
31             cout << "version = " << uReturnVal << endl;
32         }
33     }
34     return 0;
35 }

После компиляции вы получите исполняемый EXE-файл. Запустив его, вы увидите вывод версии библиотеки FastFind в консоль:

1 version = 2.2

В нашем примере мы использовали явную компоновку библиотеки (explicit library linking) для доступа к её функциям. Также возможно альтернативное решение – неявная компоновка библиотеки (implicit library linking). Вы можете применять любой подход для работы с FastFind. Но во втором случае вам придётся использовать тот же компилятор C++ (желательно и той же версии), что и разработчики FastFind.

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

На иллюстрации 2-10 приведён снимок экрана (или скриншот) популярной MMORPG-игры Lineage 2. На нём вы видите модели двух персонажей. В правой части расположен персонаж игрока с именем “Zagstruk”. Слева от него находится монстр “Wretched Archer”. Чтобы определить его координаты, применим функцию FFBestSpot.

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

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

Листинг 2-18 демонстрирует поиск текста зелёного цвета с помощью функции FFBestSpot.

 1 #include "FastFind.au3"
 2 
 3 Sleep(5 * 1000)
 4 
 5 const $sizeSearch = 80
 6 const $minNbPixel = 50
 7 const $optNbPixel = 200
 8 const $posX = 700
 9 const $posY = 380
10 
11 $coords = FFBestSpot($sizeSearch, $minNbPixel, $optNbPixel, _
12                      $posX, $posY, 0xA9E89C, 10)
13 
14 if not @error then
15     MsgBox(0, "Coords", $coords[0] & ", " & $coords[1])
16 else
17     MsgBox(0, "Coords", "Текст не найден")
18 endif

Если вы запустите скрипт FFBestSpot.au3 и переключитесь на окно с иллюстрацией 2-10, появится диалоговое окно с координатами текста. После старта, скрипт ждёт пять секунд, в течение которых вы должны переключиться на скриншот игры. Функция FFBestSpot отработает после этой задержки. Таблица 2-4 описывает её входные параметры.

Функция FFBestSpot возвращает массив из трёх элементов, если ей удаётся найти указанную область. В противном случае возвращается ноль и выставляется макрос @error с кодом ошибки. Первые два элемента массива с результатом – это X и Y координаты найденной области. Третий элемент равен числу пикселей указанного цвета в ней. Более подробную информацию о функции вы можете найти в файле документации FastFind.chm из архива библиотеки.

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

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

Скрипт FFLocalizeChanges.au3, приведённый в листинге 2-19, определяет координаты текста, который вы введёте в окне Notepad.

 1 #include "FastFind.au3"
 2 
 3 Sleep(5 * 1000)
 4 FFSnapShot (0, 0, 0, 0, 0)
 5 
 6 MsgBox(0, "Info", "Измените изображение")
 7 
 8 Sleep(5 * 1000)
 9 FFSnapShot (0, 0, 0, 0, 1)
10 
11 $coords = FFLocalizeChanges(0, 1, 10)
12 
13 if not @error then
14     MsgBox(0, "Coords", "x1 = " & $coords[0] & ", y1 = " & $coords[1] & _
15            " x2 = " & $coords[2] & ", y2 = " & $coords[3])
16 else
17     MsgBox(0, "Coords", "Изменения не обнаружены")
18 endif

Для тестирования скрипта FFLocalizeChanges.au3 выполните следующие шаги:

1. Запустите приложение Notepad и разверните его окно на весь экран.
2. Запустите скрипт.
3. Переключитесь на окно Notepad.
4. Ожидайте диалоговое окно с сообщением “Измените изображение”.
5. Введите несколько символов в Notepad в течение пяти секунд.
6. Ожидайте диалоговое окно с координатами введённого текста.

Функции библиотеки FastFind оперируют абстракцией SnapShot (снимок). SnapShot – это копия текущего изображения на экране в память. По сути такой снимок очень похож на DIB. Когда мы использовали функцию FFBestSpot, она создавала SnapShot неявно. Затем на нём отрабатывал алгоритм поиска нужной области.

Функция FFLocalizeChanges принимает входными параметрами два SnapShot: до и после изменения. Она не знает, в какой момент времени произошло изменение. Поэтому SnapShot должен создавать пользователь библиотеки с помощью функции FFSnapShot. Получившиеся снимки будут сохранены в массиве, индексы которого начинаются с нуля. По умолчанию после каждого вызова FFSnapShot индекс инкриминируется. Но его можно указать и явно в пятом параметре функции. Первые четыре параметра FFSnapShot – это координаты X и Y верхнего левого и правого нижнего углов сохраняемой области. Если все координаты равны нулю, скопировано будет изображение всего экрана.

Рассмотрим алгоритм скрипта FFLocalizeChanges.au3. После пятисекундной задержки вызывается функция FFSnapShot, которая создаёт SnapShot экрана с первоначальным изображением окна Notepad. Затем выводится сообщение “Измените изображение”, после которого пользователь вводит текст. Спустя пять секунд, скрипт делает ещё один SnapShot. Оба SnapShot передаются в функцию FFLocalizeChanges, которая вычисляет координаты изменившейся области.

Входные параметры FFLocalizeChanges приведены в таблице 2-5.

Функция FFLocalizeChanges возвращает массив из пяти элементов. Первые четыре из них – это координаты X и Y верхнего левого и правого нижнего углов изменённой области. Пятый элемент хранит число отличающихся пикселей. FFLocalizeChanges представляет собой хорошую альтернативу AutoIt функции PixelChecksum, потому что реже ошибается и предоставляет больше информации об обнаруженном изменении.

Функции библиотеки FastFind работают с перекрытыми окнами, но не со свёрнутыми. Большинству из них можно передать дескриптор окна через необязательный входной параметр. Также все функции работают корректно с полноэкранными окнами DirectX-приложений.

Библиотека ImageSearch

Библиотека ImageSearch решает одну единственную задачу. Она ищет заданный фрагмент изображения в указанной области экрана.

Для вызова функций библиотеки из AutoIt скрипта выполните следующие шаги:

1. Создайте папку для проекта (например с именем ImageSearchDemo).
2. Скопируйте в неё файлы ImageSearch.au3 и ImageSearchDLL.dll из архива библиотеки.
3. Включите файл ImageSearch.au3 в ваш скрипт:

1 #include "ImageSearch.au3"

После этого все функции библиотеки станут доступны.

Если вы разрабатываете приложение на C++ и планируете работать с ImageSearch, необходимо выполнить явную компоновку библиотеки. Пример этого метода приведён в предыдущем разделе, посвящённом FastFind.

Для демонстрации возможностей ImageSearch напишем скрипт для поиска иконки приложения Notepad на экране. Для начала подготовим фрагмент изображения, который будем искать. В нашем случае это иконка, приведённая на иллюстрации 2-11.

Вы можете создать эту иконку с помощью приложения Paint. Для этого запустите приложение Notepad, сделайте скриншот окна, вставьте его в Paint и вырежьте иконку. Сохраните результат в файл с именем notepad-logo.bmp в папку с проектом ImageSearchDemo.

Листинг 2-20 демонстрирует скрипт Search.au3 для поиска иконки на экране.

 1 #include <ImageSearch.au3>
 2 
 3 Sleep(5 * 1000)
 4 
 5 global $x = 0, $y = 0
 6 $search = _ImageSearch('notepad-logo.bmp', 0, $x, $y, 20)
 7 
 8 if $search = 1 then
 9     MsgBox(0, "Coords", $x & ", " & $y)
10 else
11     MsgBox(0, "Coords", "Фрагмент изображения не найден")
12 endif

Чтобы протестировать скрипт, выполните следующие шаги:

1. Запустите приложение Notepad.
2. Запустите скрипт Search.au3.
3. Сделайте активным окно Notepad.
4. Ожидайте сообщения с координатами иконки.

Если у вас возникли проблемы с последними версиями библиотеки, вы можете воспользоваться более старой, но стабильной сборкой.

Параметры функции _ImageSearch приведены в таблице 2-6.

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

Функция _ImageSearch ищет фрагмент изображения на всём экране. Библиотека также предоставляет функцию _ImageSearchArea для поиска только в указанной области экрана. Пример её вызова выглядит следующим образом:

1 $search = _ImageSearchArea('notepad-logo.bmp', 0, 100, 150, 400, 450, $x, $y, 20)

Четыре дополнительных параметра функции (со второго по шестой) – это координаты области экрана для поиска. В нашем примере она ограничена точками x = 100, y = 150 и x = 400, y = 450. _ImageSearchArea возвращает такой же результат, как и функция _ImageSearch: код ошибки и координаты найденного фрагмента через седьмой и восьмой входной параметр.

Функции библиотеки ImageSearch работают только с текущим изображением на экране. Это значит, что вы не можете перекрыть или свернуть окно анализируемого приложения. Полноэкранные окна DirectX-приложений обрабатываются корректно.

Библиотека ImageSearch – это надёжный инструмент для поиска статичных фрагментов в окне игрового приложения. Она хорошо подходит для обнаружения элементов интерфейса и 2D-объектов.

Выводы

Мы рассмотрели функции AutoIt для анализа пикселей изображения на экране и для обнаружения изменений этого изображения.

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

Пример кликера для Lineage 2

Напишем простого бота-кликера для MMORPG Lineage 2, чтобы закрепить полученные знания о техниках внедрения данных на уровне ОС и перехвате устройств вывода.

Обзор игры Lineage 2

Игровой процесс Lineage 2 типичен для жанра RPG. Сначала надо выбрать расу и класс для своего персонажа. Для получения новых умений и покупки предметов игрок должен выполнять задания (или квесты) и охотиться на монстров. Этот процесс получения ресурсов называется фарминг (farming). При этом у игроков всегда есть возможность общаться и взаимодействовать между собой, как и в любой MMORPG. Они могут помогать или мешать друг другу. Если несколько игроков хотят получить один и тот же ресурс, они должны сражаться за него. Этот элемент соперничества представляет наиболее привлекательную часть игрового процесса. Поэтому пользователи стремятся как можно быстрее и лучше развить своего персонажа, чтобы сражаться между собой.

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

На иллюстрации 2-12 приведён скриншот игры. Рассмотрим на нём элементы игрового интерфейса, помеченные номерам:

1. Окно состояния с параметрами персонажа игрока. К наиболее важным из них относятся очки здоровья (health points или HP) и мана (mana points или MP).
2. Окно цели с информацией о выделенном в данный момент монстре. В нём есть полоска с HP цели.
3. Панель горячих клавиш с иконками возможных действий и доступных умений.
4. Окно чата для ввода команд и отправки сообщений другим игрокам.

Тщательное изучение интерфейса поможет вам разработать наиболее простой и эффективный алгоритм взаимодействия бота с игрой. Более подробно интерфейс Lineage 2 описан на вики-странице.

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

Реализация бота

Чтобы лучше понять механику игры, попробуйте зарегистрироваться на сервере РПГ-Клуб, создать персонажа и убить нескольких монстров. Вы заметите, что почти всё время нажимаете одни и те же кнопки на панели горячих клавиш.

Теперь составим список действий, которые надо автоматизировать. Предлагаю следующий вариант:

1. Выбрать монстра для атаки. Это можно сделать двумя способами: левым щелчком мыши по нему или ввести в окно чата команду “/target”. Например:

1 /target ИмяМонстра

Полный список игровых команд приведён на официальном сайте. Их можно комбинировать в одно действие с помощью макросов.

2. Атаковать монстра. Для этого можно нажать кнопку “атака” на панели горячих клавиш или горячую клавишу F1.
3. Ожидать пока персонаж убьёт монстра.
4. Подобрать выпавшие из монстра предметы и золото. Опять же можно щёлкнуть мышью по действию на панели горячих клавиш или нажать F8.

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

Слепой бот

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

Перед тем как начать писать код, рассмотрим конфигурацию панели горячих клавиш. Вам нужно настроить её так же как на иллюстрации 2-13.

Таблица 2-7 описывает конфигурацию панели.

Теперь стало очевидно, как надо связать горячие клавиши с шагами алгоритма бота. Скрипт BlindBot.au3, приведённый в листинге 2-21, демонстрирует это.

 1 #RequireAdmin
 2 
 3 Sleep(2000)
 4 
 5 while true
 6     Send("{F9}")
 7     Sleep(200)
 8     Send("{F1}")
 9     Sleep(5000)
10     Send("{F8}")
11     Sleep(1000)
12 wend

В первой строчке скрипта стоит ключевое слово #RequireAdmin. Благодаря ему при старте скрипт потребует предоставить ему права администратора. Получив эти права, он сможет взаимодействовать с другими приложениями независимо от того, какой пользователь их запустил. Некоторые клиенты Lineage 2 при старте также требуют прав администратора. Поэтому к ним не смогут получить доступ скрипты AutoIt, запущенные от имени пользователя с меньшими правами. Я рекомендую всегда использовать #RequireAdmin в ваших кликерах.

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

После вызова Sleep идёт бесконечный цикл while, в котором выполняются все действия бота:

1. Send("{F9}") – выбрать монстра с помощью макроса, настроенного на клавишу F9.
2. Sleep(200) – подождать 200 миллисекунд. Это время требуется клиенту Lineage 2, чтобы выделить монстра и отрисовать окно цели.

3. Send("{F1}") – атаковать выбранного монстра.
4. Sleep(5000) – ожидать пять секунд, пока персонаж не подбежит к монстру и не убьёт его.
5. Send("{F8}") – подобрать один выпавший предмет.

5. Sleep(1000) – ждать одну секунду, пока персонаж подбирает предмет.

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

Попробуйте запустить скрипт и проверить его работу. Часто бот будет совершать не те действия, которые нужны в данный момент. Причина в том, что одно из условий его работы нарушено. С другой стороны, все его ошибки не критичны, поскольку он продолжает свою работу. Это возможно благодаря особенности команды /target и механизму атаки цели. Если выполнить макрос /target дважды, бот будет атаковать уже выбранного монстра. Таким образом он всегда будет добивать цель. Даже если монстр выжил после первой итерации цикла while, атака на него продолжится в следующих итерациях. Кроме того, команда “поднять предмет” не прерывает атаку, если поблизости от персонажа нет предметов. Поэтому он будет продолжать бить цель и после пятисекундной задержки, отведённой на убийство монстра.

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

Можно сделать скрипт более удобным для чтения и модификации, если вынести каждый шаг алгоритма в отдельную функцию с говорящим названием. Результат такого улучшения приведён в скрипте BlindBotFunc.au3 из листинга 2-22.

 1 #RequireAdmin
 2 
 3 func SelectTarget()
 4     Send("{F9}")
 5     Sleep(200)
 6 endfunc
 7 
 8 func Attack()
 9     Send("{F1}")
10     Sleep(5000)
11 endfunc
12 
13 func Pickup()
14     Send("{F8}")
15     Sleep(1000)
16 endfunc
17 
18 Sleep(2000)
19 
20 while true
21     SelectTarget()
22     Attack()
23     Pickup()
24 wend

Теперь скрипт выглядит намного понятнее. Он начинает свою работу с вызова Sleep(2000). Выше этой строчки находятся только объявления пользовательских функций, которые определены разработчиком для своих целей. Их код будет выполнен только в местах вызова, то есть в цикле while. Обратите внимание, что несмотря на изменившуюся структуру кода, алгоритмы скриптов BlindBotFunc.au3 и BlindBot.au3 остались идентичны.

Бот с условиями

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

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

Реализация функции вывода сообщений в файл представлена в листинге 2-23.

1 global const $LogFile = "debug.log"
2 
3 func LogWrite($data)
4     FileWrite($LogFile, $data & chr(10))
5 endfunc
6 
7 LogWrite("Hello world!")

После выполнения этого скрипта в одной папке с ним будет создан файл debug.log, содержащий строку “Hello world!”. Функция LogWrite является обёрткой над AutoIt вызовом FileWrite. Она будет удобна, если вам понадобиться отключить вывод в лог-файл. Для этого достаточно будет закомментировать в ней вызов FileWrite. Вы можете изменить путь до лог-файла и его имя с помощью константы LogFile.

Первое условие, которое бот должен проверить, – это результат выбора цели. Попробуйте несколько раз выделить монстров с помощью мыши. Заметили ли вы элемент интерфейса, который отличается при наличии и отсутствии цели? Я имею в виду окно цели. Оно появляется каждый раз при выборе цели и пропадает при её убийстве или отмене по клавише Esc. Наш бот может найти это окно на экране с помощью функции FFBestSpot библиотеки FastFind.

Чтобы отличить окно цели от остальных, нам нужно выбрать уникальный для него цвет. Другими словами, надо найти такой цвет, который встречается только в окне цели. Для этого подошёл бы красный цвет полосы HP монстра. Код из листинга 2-24 проверяет, есть ли окно цели на экране.

 1 func IsTargetExist()
 2     const $SizeSearch = 80
 3     const $MinNbPixel = 3
 4     const $OptNbPixel = 10
 5     const $PosX = 688
 6     const $PosY = 67
 7 
 8     $coords = FFBestSpot($SizeSearch, $MinNbPixel, $OptNbPixel, _
 9                          $PosX, $PosY, 0x871D18, 10)
10 
11     const $MaxX = 800
12     const $MinX = 575
13     const $MaxY = 100
14 
15     if not @error then
16         if $MinX < $coords[0] and $coords[0] < $MaxX _
17            and $coords[1] < $MaxY then
18 
19             LogWrite("IsTargetExist() - Success, coords = " & _
20                      $coords[0] & ", " & $coords[1] & " pixels = " & _
21                      $coords[2])
22             return True
23         else
24             LogWrite("IsTargetExist() - Fail #1")
25             return False
26         endif
27     else
28         LogWrite("IsTargetExist() - Fail #2")
29         return False
30     endif
31 endfunc

Рассмотрим функцию IsTargetExist подробнее. Константы PosX и PosY – это примерные координаты полосы HP цели. Мы передаём их и красный цвет полосы (равный 871D18) в функцию FFBestSpot в качестве входных параметров. Она ищет указанную область по всему экрану.

Внимательный читатель заметит, что вместо окна цели может быть найдено окно состояния персонажа. Ведь в нём тоже встречается красный цвет на полоске HP персонажа. В таком случае бот всегда будет делать вывод, что цель есть. Чтобы избежать этой ошибки, мы проверяем координаты области, найденной функцией FFBestSpot. Сравниваем их (coords[0] и coords[1]) с максимальными (MaxX и MaxY) и минимальными (MinX) допустимыми значениями. Эти значения задают область экрана, в которой ожидается появление окна цели. Они зависят от разрешения экрана и конфигурации интерфейса игры. Поэтому вам придётся подбирать их самостоятельно.

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

IsTargetExist позволяет нам решить сразу две задачи:

1. Проверка успешности выбора цели в функции SelectTarget.
2. Проверка состояния атакуемого ботом монстра (жив или нет).

Скрипт AnalysisBot.au3, представленный в листинге 2-25, использует функцию IsTargetExist для проверки наличия цели.

 1 #include "FastFind.au3"
 2 
 3 #RequireAdmin
 4 
 5 Sleep(2000)
 6 
 7 global const $LogFile = "debug.log"
 8 
 9 func LogWrite($data)
10     FileWrite($LogFile, $data & chr(10))
11 endfunc
12 
13 func IsTargetExist()
14     ; Смотрите реализацию в листинге 2-24
15 endfunc
16 
17 func SelectTarget()
18     LogWrite("SelectTarget()")
19     while not IsTargetExist()
20         Send("{F9}")
21         Sleep(200)
22     wend
23 endfunc
24 
25 func Attack()
26     LogWrite("Attack()")
27     while IsTargetExist()
28         Send("{F1}")
29         Sleep(1000)
30     wend
31 endfunc
32 
33 func Pickup()
34     Send("{F8}")
35     Sleep(1000)
36 endfunc
37 
38 while True
39     SelectTarget()
40     Attack()
41     Pickup()
42 wend

Обратите внимание на новую реализацию функций SelectTarget и Attack. В SelectTarget бот пытается выделить цель в цикле до тех пор, пока функция IsTargetExist не вернёт значение True. Только после этого он переходит в функцию Attack. В ней бот продолжает атаковать монстра (выбирая действие “атака” по клавише F1) до тех пор, пока тот жив.

Мы печатаем в лог-файл названия функций SelectTarget и Attack, когда они получают управление. Этот вывод позволяет определить, которая из них вызывает IsTargetExist.

Дальнейшие улучшения

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

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

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

Чтобы решить эту проблему, воспользуемся командой “выбор ближайшей цели”. На нашей панели горячих клавиш она доступна по нажатию F10. Ближайшая цель находится на минимальной (по сравнению с другими) дистанции от бота. Это значительно уменьшит время бота в пути, а значит и вероятность встречи с агрессивными монстрами.

Листинг 2-26 демонстрирует дополненную версию функции SelectTarget.

 1 func SelectTarget()
 2     LogWrite("SelectTarget()")
 3 
 4     while not IsTargetExist()
 5         Send("{F10}")
 6         Sleep(200)
 7 
 8         if IsTargetExist() then
 9             exitloop
10         endif
11 
12         Send("{F9}")
13         Sleep(200)
14     wend
15 endfunc

Теперь бот в первую очередь пытается найти ближайшую цель по клавише F10. Только тогда, когда ему это не удалось, он использует команду /target. Таким образом бот всегда стремится выбрать ближайшего к нему монстра. Если тот окажется агрессивным, то побежит навстречу и будет ближе всего.

Вторую серьёзную проблему для бота представляют собой преграды на карте. При движении к цели он может зацепиться за камень или дерево и застрять. Самое простое решение заключается в тайм-ауте на атаку. Если отведённое время на убийство монстра прошло, а цель осталась жива, можно предположить, что бот застрял. Тогда для обхода препятствия ему помогут случайные перемещения. Новые версии функций Move и Attack из листинга 2-27 демонстрируют это решение.

 1 func Move()
 2     SRandom(@MSEC)
 3     MouseClick("left", Random(300, 800), Random(170, 550), 1)
 4 endfunc
 5 
 6 func Attack()
 7     LogWrite("Attack()")
 8 
 9     const $TimeoutMax = 10
10     $timeout = 0
11     while IsTargetExist() and $timeout < $TimeoutMax
12         Send("{F1}")
13         Sleep(2000)
14 
15         Send("{F2}")
16         Sleep(2000)
17 
18         $timeout += 1
19     wend
20 
21     if $timeout == $TimeoutMax then
22         Move()
23     endif
24 endfunc

Мы добавили счётчик timeout в функцию Attack. На каждой итерации цикла while он инкрементируется и сравнивается с пороговым значением константы TimeoutMax. Когда счётчик достигает TimeoutMax, бот делает вывод, что застрял. В этом случае вызывается функция Move, которая симулирует щелчок левой кнопки мыши по точке со случайной координатой. Чтобы получить случайное число, используются функции AutoIt SRandom и Random. Первая из них инициализирует генератор псевдослучайных чисел. Вторая возвращает следующее число из очереди сгенерированных. В качестве параметров функция Random принимает границы интервала для случайного числа.

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

Теперь наш кликер способен самостоятельно работать достаточно долгое время. Он умеет обходить препятствия и первым атаковать агрессивных монстров. Но есть одно улучшение, способное значительно увеличить выживаемость бота. Речь идёт об использовании зелья восстановления здоровья, которое привязано к горячей клавише F5. Чтобы правильно его применять, необходимо анализировать полосу HP персонажа в окне состояния. Вы можете реализовать этот механизм самостоятельно в качестве упражнения. Алгоритм чтения уровня HP будет похож на функцию IsTargetExist.

Выводы

Мы реализовали кликера для игры Lineage 2. Он использует самые распространённые техники симуляции действий и анализа окна игрового приложения. Попробуем оценить их эффективность и обобщить результат на всех ботов этого типа.

Преимущества кликеров:

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

Недостатки кликеров:

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

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

Методы защиты от кликеров

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

В первой главе мы рассмотрели архитектуру типичной онлайн-игры. Как вы помните, её приложение состоит из двух частей: клиентской и серверной. Зачастую, система защиты придерживается такой же архитектуры и разделена на две части. Клиентская часть контролирует точки перехвата и внедрения данных на стороне пользователя (драйвера, ОС, приложение). Серверная часть следит за взаимодействием игрового приложения и сервером. Большинство техник по обнаружению кликеров работают на клиентской стороне.

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

1. Уведомить администратора игрового сервера о подозрительных действиях игрока. Для этого достаточно сделать запись в лог-файл на стороне сервера.
2. Разорвать соединение между подозрительным пользователем и сервером.
3. Заблокировать игрока по IP-адресу. Это предотвратит его дальнейшие попытки подключения к серверу.

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

Тестовое приложение

Для тестирования алгоритмов обнаружения ботов, мы воспользуемся приложением Notepad. Предположим, что это игровой клиент, который мы должны защитить. Напишем простейший AutoIt-скрипт, который выполняет роль кликера и вводит текст в Notepad. Тогда наша цель заключается в его обнаружении.

Листинг 2-28 демонстрирует скрипт SimpleBot.au3, который печатает буквы “a”, “b”, “c” в окне Notepad.

 1 $hWnd = WinGetHandle("[CLASS:Notepad]")
 2 WinActivate($hWnd)
 3 
 4 Sleep(200)
 5 
 6 while true
 7     Send("a")
 8     Sleep(1000)
 9     Send("b")
10     Sleep(2000)
11     Send("c")
12     Sleep(1500)
13 wend

Для тестирования запустите Notepad, а затем скрипт SimpleBot.au3. Он переключится на нужное окно и будет вводить буквы в бесконечном цикле.

Скрипт SimpleBot.au3 служит отправной точкой нашего исследования. Его цель в том, чтобы отличить симулируемые ботом нажатия клавиш от действий пользователя в окне Notepad. Прототипы алгоритмов защиты мы будем писать на AutoIt. Благодаря этому получится простой и компактный код для изучения. В реальных системах защиты предпочтительнее использовать компилируемые языки вроде C или C++.

Анализ действий игрока

Вычисление временных задержек

Скрипт SimpleBot.au3 симулирует одни и те же действия в цикле. Их систематичность – это первое, что бросается в глаза при анализе работы бота. Ещё раз обратимся к его коду. Между каждым действием и предыдущим стоят строго определённые задержки. Человек не может действовать в таких точных временных интервалах. Более того, такие чёткие остановки не имеет никакого смысла в компьютерной игре, потому что зачастую пользователь должен реагировать на различные случайные ситуации. Если кто-то ведёт себя подобным образом, очень вероятно что это программа.

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

Наш скрипт защиты должен выполнять две задачи: перехватывать действия пользователя и измерять временные задержки между ними. Код в листинге 2-29 реализует перехват нажатия клавиш.

 1 global const $gKeyHandler = "_KeyHandler"
 2 
 3 func _KeyHandler()
 4     $keyPressed = @HotKeyPressed
 5 
 6     LogWrite("_KeyHandler() - asc = " & asc($keyPressed) & " key = " & $keyPressed)
 7     AnalyzeKey($keyPressed)
 8 
 9     HotKeySet($keyPressed)
10     Send($keyPressed)
11     HotKeySet($keyPressed, $gKeyHandler)
12 endfunc
13 
14 func InitKeyHooks($handler)
15     for $i = 0 to 255
16         HotKeySet(Chr($i), $handler)
17     next
18 endfunc
19 
20 InitKeyHooks($gKeyHandler)
21 
22 while true
23     Sleep(10)
24 wend

Мы применили функцию AutoIt HotKeySet, чтобы назначить обработчик (handler или hook) для нажатий клавиш. Она принимает на вход два параметра: код перехватываемой клавиши и ссылку на функцию-обработчик. Чтобы пройти по всем кодам от 0 до 255, в пользовательской функции InitKeyHooks используется цикл for. Обработчик _KeyHandler назначается для всех клавиш. Алгоритм его работы выглядит следующим образом:

1. Вызвать функцию AnalyzeKey и передать ей код нажатой клавиши. Этот код хранится в макросе @HotKeyPressed.
2. Выключить перехват следующего нажатия обрабатываемой клавиши. Для этого снова вызывается функция HotKeySet. Данный шаг нужен, чтобы последующее нажатие обработало приложение Notepad, а не наш скрипт.
3. Вызвать функцию Send для симуляции нажатия обрабатываемой клавиши в Notepad. Этот шаг нужен, поскольку нажатие пользователя получил скрипт, а не Notepad.
4. Включить перехват скриптом последующих нажатий с помощью HotKeySet.

Листинг 2-30 демонстрирует код функции AnalyzeKey.

 1 global $gTimeSpanA = -1
 2 global $gPrevTimestampA = -1
 3 
 4 func AnalyzeKey($key)
 5     local $timestamp = (@SEC * 1000 + @MSEC)
 6     LogWrite("AnalyzeKey() - key = " & $key & " msec = " & $timestamp)
 7     if $key <> 'a' then
 8         return
 9     endif
10 
11     if $gPrevTimestampA = -1 then
12         $gPrevTimestampA = $timestamp
13         return
14     endif
15 
16     local $newTimeSpan = $timestamp - $gPrevTimestampA
17     $gPrevTimestampA = $timestamp
18 
19     if $gTimeSpanA = -1 then
20         $gTimeSpanA = $newTimeSpan
21         return
22     endif
23 
24     if Abs($gTimeSpanA - $newTimeSpan) < 100 then
25         MsgBox(0, "Alert", "Обнаружен бот-кликер!")
26     endif
27 endfunc

В функции AnalyzeKey мы измеряем задержки между нажатиями клавиши “a”. Две глобальные переменные хранят текущее состояние алгоритма:

1. gPrevTimestampA – это момент времени (timestamp) первого нажатия.
2. gTimeSpanA – это задержка между первым и вторым нажатиями.

При старте скрипта обоим переменным присваивается значение -1, которое соответствует неинициализированному состоянию. Нашему алгоритму требуется перехватить как минимум три нажатия клавиш, чтобы обнаружить бота. Первое нажатие инициализирует переменную gPrevTimestampA:

1     if $gPrevTimestampA = -1 then
2         $gPrevTimestampA = $timestamp
3         return
4     endif

Момент времени второго нажатия мы используем для расчёта переменной gTimeSpanA. Она равна разности между временем первого и второго нажатий:

1     local $newTimeSpan = $timestamp - $gPrevTimestampA
2     $gPrevTimestampA = $timestamp
3 
4     if $gTimeSpanA = -1 then
5         $gTimeSpanA = $newTimeSpan
6         return
7     endif

После третьего нажатия мы можем вычислить задержку второй раз (переменная newTimeSpan) и сравнить её с предыдущей (значение gTimeSpanA):

1     if Abs($gTimeSpanA - $newTimeSpan) < 100 then
2         MsgBox(0, "Alert", "Clicker bot detected!")
3     endif

Если разница между первой и второй задержкой меньше 100 миллисекунд, алгоритм защиты выводит сообщение об обнаружении бота.

Полный код защиты представлен в скрипте TimeSpanProtection.au3 из листинга 2-31. В нём мы опустили реализацию функций _KeyHandler и AnalyzeKey, поскольку рассмотрели их ранее.

 1 global const $gKeyHandler = "_KeyHandler"
 2 global const $kLogFile = "debug.log"
 3 
 4 global $gTimeSpanA = -1
 5 global $gPrevTimestampA = -1
 6 
 7 func LogWrite($data)
 8     FileWrite($kLogFile, $data & chr(10))
 9 endfunc
10 
11 func _KeyHandler()
12     ; См листинг 2-29
13 endfunc
14 
15 func InitKeyHooks($handler)
16     for $i = 0 to 256
17         HotKeySet(Chr($i), $handler)
18     next
19 endfunc
20 
21 func AnalyzeKey($key)
22     ; См листинг 2-30
23 endfunc
24 
25 InitKeyHooks($gKeyHandler)
26 
27 while true
28     Sleep(10)
29 wend

Анализ последовательности действий

Мы можем незначительно изменить скрипт SimpleBot.au3, чтобы обойти защиту TimeSpanProtection.au3. Для этого заменим фиксированные задержки между действиями на случайные. Листинг 2-32 демонстрирует исправленную версию бота.

 1 SRandom(@MSEC)
 2 
 3 $hWnd = WinGetHandle("[CLASS:Notepad]")
 4 WinActivate($hWnd)
 5 
 6 Sleep(200)
 7 
 8 while true
 9     Send("a")
10     Sleep(Random(800, 1200))
11     Send("b")
12     Sleep(Random(1700, 2300))
13     Send("c")
14     Sleep(Random(1300, 1700))
15 wend

Каждый раз, в вызов Sleep мы передаём случайное число, полученное из функции Random. Попробуйте протестировать нового бота вместе с защитой TimeSpanProtection.au3. Теперь она не обнаружит кликера. Можем ли мы её улучшить?

У скрипта RandomDelayBot.au3 по-прежнему есть закономерность, которая сразу видна человеку, следящему за его работой. Речь идёт о последовательности нажимаемых кнопок. Очевидно, что игрок не способен безошибочно повторять свои действия десятки и сотни раз. Даже если он и захочет это сделать, в какой-то момент он ошибётся и нажмёт не ту клавишу.

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

 1 global const $gActionTemplate[3] = ['a', 'b', 'c']
 2 global $gActionIndex = 0
 3 global $gCounter = 0
 4 
 5 func Reset()
 6     $gActionIndex = 0
 7     $gCounter = 0
 8 endfunc
 9 
10 func AnalyzeKey($key)
11     LogWrite("AnalyzeKey() - key = " & $key);
12 
13     $indexMax = UBound($gActionTemplate) - 1
14     if $gActionIndex <= $indexMax and $key <> $gActionTemplate[$gActionIndex] then
15         Reset()
16         return
17     endif
18 
19     if $gActionIndex < $indexMax and $key = $gActionTemplate[$gActionIndex] then
20         $gActionIndex += 1
21         return
22     endif
23 
24     if $gActionIndex = $indexMax and $key = $gActionTemplate[$gActionIndex] then
25         $gCounter += 1
26         $gActionIndex = 0
27 
28         if $gCounter = 3 then
29             MsgBox(0, "Alert", "Обнаружен бот-кликер!")
30             Reset()
31         endif
32     endif
33 endfunc

Новый вариант функции AnalyzeKey использует глобальную константу и две переменные:

1. gActionTemplate – это массив с последовательностью действий, которую выполняет предполагаемый бот.
2. gActionIndex – индекс массива gActionTemplate, который соответствует последнему перехваченному нажатию.
3. gCounter – число обнаруженных повторений последовательности действий.

В функции AnalyzeKey есть три основных условия для обработки нажатия клавиши. Первое из них выполняется, если нажатие не соответствует ни одному элементу массива gActionTemplate:

1     $indexMax = UBound($gActionTemplate) - 1
2     if $gActionIndex <= $indexMax and $key <> $gActionTemplate[$gActionIndex] then
3         Reset()
4         return
5     endif

В этом случае мы вызываем функцию Reset, которая сбрасывает в ноль значения переменных gActionIndex и gCounter. После этого мы выходим из AnalyzeKey.

Второе условие обработки нажатия выполняется, когда перехваченное действие встречается в массиве gActionTemplate, кроме того этот элемент не последний и его индекс равен gActionIndex:

1     if $gActionIndex < $indexMax and $key = $gActionTemplate[$gActionIndex] then
2         $gActionIndex += 1
3         return
4     endif

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

Третье условие выполняется, когда перехваченное нажатие соответствует последнему элементу массива gActionTemplate:

1 if $gActionIndex = $indexMax and $key = $gActionTemplate[$gActionIndex]
2 then
3         $gCounter += 1
4         $gActionIndex = 0
5         if $gCounter = 3 then
6             MsgBox(0, "Alert", "Clicker bot detected!")
7             Reset()
8         endif
9     endif

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

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

Вы можете запустить скрипты ActionSequenceProtection.au3 и RandomDelayBot.au3 для тестирования защиты. Теперь бот будет обнаружен.

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

1         if $gCounter = 3 then
2             MsgBox(0, "Alert", "Clicker bot detected!")
3             Reset()
4         endif

К сожалению, у скрипта защиты ActionSequenceProtection.au3 есть и другой серьёзный недостаток. Он способен обнаружить только бота, который запрограммирован на последовательность нажатий “a”, “b”, “c”. Если кликер вместо этого будет выполнять “a”, “c”, “b”, то алгоритм не сможет его обнаружить.

Изменим нашего бота согласно листингу 2-34. Это позволит ему обойти защиту ActionSequenceProtection.au3.

 1 SRandom(@MSEC)
 2 
 3 $hWnd = WinGetHandle("[CLASS:Notepad]")
 4 WinActivate($hWnd)
 5 
 6 Sleep(200)
 7 
 8 while true
 9     Send("a")
10     Sleep(1000)
11 
12     if Random(0, 9, 1) < 5 then
13         Send("b")
14         Sleep(2000)
15     endif
16 
17     Send("c")
18     Sleep(1500)
19 wend

Теперь симулируемая ботом последовательность действий случайна. Он пропускает нажатие клавиши “b” после “a” с вероятностью порядка 50%. Это приводит к тому, что условия функции AnalyzeKey на обнаружение бота перестают выполняться. Каждый раз, когда бот пропускает “b”, алгоритм защиты сбрасывает счётчик gCounter в ноль. Таким образом, он никогда не достигает порогового значения.

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

1. “a”, “c”.
2. “a”, “b”, “c”.

Сканирование процессов

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

Скрипт ProcessScanProtection.au3, приведённый в листинге 2-35, демонстрирует этот подход.

 1 global const $kLogFile = "debug.log"
 2 
 3 func LogWrite($data)
 4     FileWrite($kLogFile, $data & chr(10))
 5 endfunc
 6 
 7 func ScanProcess($name)
 8     local $processList = ProcessList($name)
 9 
10     if $processList[0][0] > 0 then
11         LogWrite("Name: " & $processList[1][0] & " PID: " & $processList[1][1])
12         MsgBox(0, "Alert", "Обнаружен бот-кликер!")
13     endif
14 endfunc
15 
16 while true
17     ScanProcess("AutoHotKey.exe")
18     Sleep(5000)
19 wend

Мы можем получить список запущенных в данный момент процессов с помощью AutoIt функции ProcessList. У неё есть единственный необязательный параметр: имя процесса, который нужно найти. Если его передать, функция вернёт список из одного элемента в случае успешного поиска. Предположим, что защита ищет процесс интерпретатора AutoHotKey.exe, который выполняет скрипт бота. ProcessList возвращает двумерный массив, представленный в таблице 2-8.

Если элемент массива processList[0][0] не равен нулю, процесс AutoHotKey.exe в данный момент запущен и работает.

Почему мы ищем процесс AutoHotKey.exe, а не AutoIt.exe? Дело в том, что мы не сможем протестировать скрипт ProcessScanProtection.au3 на нашем тестовом боте SimpleBot.au3. Оба скрипта написаны на языке AutoIt. Это значит, что как только мы щёлкнем два раза мышью по иконке ProcessScanProtection.au3, ОС запустит процесс интерпретатора AutoIt.exe, который и выполнит наш скрипт. Из-за этого алгоритм защиты будет всегда находить процесс AutoIt.exe, независимо от того запущен бот или нет.

Перепишем нашего тестового бота на языке AutoHotKey. Результат приведён в листинге 2-36.

 1 WinActivate, Untitled - Notepad
 2 Sleep, 200
 3 
 4 while true
 5 {
 6     Send, a
 7     Sleep, 1000
 8     Send, b
 9     Sleep, 2000
10     Send, c
11     Sleep, 1500
12 }

Вы можете сравнить скрипты SimpleBot.ahk и SimpleBot.au3. Они выглядят похоже. Единственное отличие заключается в синтаксисе вызова функций. В AutoHotKey параметры указываются не в скобках, а через запятую и пробел после имени функции.

Теперь мы можем протестировать скрипт защиты ProcessScanProtection.au3. Для этого выполните следующие шаги:

1. Запустите приложение Notepad.
2. Запустите скрипт ProcessScanProtection.au3.
3. Запустите тестового бота SimpleBot.ahk. Не забудьте перед этим установить на свой компьютер интерпретатор AutoHotKey.
4. Ожидайте, пока алгоритм защиты не обнаружит бота. Когда это случится, откроется диалоговое окно с сообщением.

Есть несколько методов для обхода такого типа защиты. Самый простой из них заключается в применении компилятора скриптов. Компилятор собирает скрипт и интерпретатор AutoHotKey.exe в единый исполняемый EXE-файл. Имя этого файла будет соответствовать имени процесса в списке, возвращаемом функцией ProcessList. Таким образом, алгоритм защиты ProcessScanProtection.au3 не сработает.

Для компилирования скрипта SimpleBot.ahk выполните следующие шаги:

1. Запустите приложение компилятора AutoHotKey. Его окно выглядит как на иллюстрации 2-14. Путь к нему по умолчанию:

1 C:\Program Files (x86)\AutoHotkey\Compiler\Ahk2Exe.exe

2. Выберите скрипт SimpleBot.ahk в качестве исходного файла. Диалоговое окно для выбора файла открывается по кнопке “Browse” напротив текста “Source (script file)”.
3. Не указывайте имя выходного файла в поле “Destination (.exe file)”. В этом случае в той же папке, где находится скрипт, будет создан EXE-файл с таким же именем.
4. Нажмите кнопку “> Convert <”. После окончания процесса компиляции вы увидите сообщение.

Попробуйте запустить полученный EXE-файл с именем SimpleBot.exe. Он ведёт себя точно так же, как и скрипт SimpleBot.ahk. Единственное отличие в том, что алгоритм защиты ProcessScanProtection.au3 не может его обнаружить. Это происходит из-за того, что процесс бота теперь называется SimpleBot.exe, а не AutoHotKey.exe.

Вычисление хэш-суммы запускаемого файла

Можем ли мы усовершенствовать скрипт ProcessScanProtection.au3 так, чтобы он обнаруживал скомпилированную версию бота SimpleBot.exe? Как мы выяснили, имя исполняемого файла легко поменять в отличие от его содержания. EXE-файл представляет собой машинный код, который выполняется процессором, и заголовки с метаинформацией. Неверное изменение любой из этих частей приведёт к ошибке приложения при старте.

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

1. Рассчитывать хэш-суммы исполняемых файлов всех запущенных процессов и сравнивать их с предопределёнными значениями.
2. Проверять последовательность байт в определённом месте каждого из этих исполняемых файлов.
3. Искать заданную последовательность байт по всему файлу.

Попробуем реализовать первый подход. Скрипт Md5ScanProtection.au3 из листинга 2-37 считает хэш-сумму по алгоритму MD5 для исполняемого файла каждого из запущенных процессов. Если она совпала с искомой, алгоритм делает вывод о наличии работающего бота.

 1 #include <Crypt.au3>
 2 
 3 global const $kLogFile = "debug.log"
 4 global const $kCheckMd5[2] = ["0x3E4539E7A04472610D68B32D31BF714B", _
 5                               "0xD960F13A44D3BD8F262DF625F5705A63"]
 6 
 7 func LogWrite($data)
 8     FileWrite($kLogFile, $data & chr(10))
 9 endfunc
10 
11 func _ProcessGetLocation($pid)
12     local $proc = DllCall('kernel32.dll', 'hwnd', 'OpenProcess', 'int', _
13                           BitOR(0x0400, 0x0010), 'int', 0, 'int', $pid)
14 
15     if $proc[0] = 0 then
16         return ""
17     endif
18 
19     local $struct = DllStructCreate('int[1024]')
20     DllCall('psapi.dll', 'int', 'EnumProcessModules', 'hwnd', $proc[0], _
21             'ptr', DllStructGetPtr($struct), 'int', _
22             DllStructGetSize($struct), 'int_ptr', 0)
23 
24     local $return = DllCall('psapi.dll', 'int', 'GetModuleFileNameEx', _
25         'hwnd', $proc[0], 'int', DllStructGetData($struct, 1), _
26         'str', '', 'int', 2048)
27 
28     if StringLen($return[3]) = 0 then
29         return ""
30     endif
31 
32     return $return[3]
33 endfunc
34 
35 func ScanProcess()
36     local $processList = ProcessList()
37 
38     for $i = 1 to $processList[0][0]
39         local $path = _ProcessGetLocation($processList[$i][1])
40         local $md5 = _Crypt_HashFile($path, $CALG_MD5)
41         LogWrite("Name: " & $processList[$i][0] & " PID: " & _
42                  $processList[$i][1] & " Path: " & $path & " md5: " & $md5)
43 
44         for $j = 0 to Ubound($kCheckMd5) - 1
45             if $md5 == $kCheckMd5[$j] then
46                 MsgBox(0, "Alert", "Обнаружен бот-кликер!")
47             endif
48         next
49     next
50 endfunc
51 
52 while true
53     ScanProcess()
54     Sleep(5000)
55 wend

Рассмотрим скрипт Md5ScanProtection.au3 подробнее. Весь алгоритм обнаружения бота реализован в функции ScanProcess, которая вызывается в цикле while каждые пять секунд. В ней читается список запущенных процессов с помощью AutoIt-вызова ProcessList. Его результат сохраняется в переменную processList. После этого цикл for проходит по полученному списку. Для каждого его элемента функция _ProcessGetLocation читает путь к исполняемому файлу, машинный код которого был загружен в память процесса. Полученный путь передаётся в AutoIt-функцию _Crypt_HashFile, которая считает хэш-сумму по содержимому всего файла. На заключительном шаге алгоритма происходит сравнение рассчитанной хэш-суммы с искомыми значениями из глобального массива kCheckMd5. В нашем примере этот массив содержит MD5-суммы файлов SimpleBot.exe и AutoHotKey.exe.

Рассмотрим функцию _ProcessGetLocation. В ней происходит три WinAPI-вызова через AutoIt обёртку DllCall:

1. OpenProcess
2. EnumProcessModules
3. GetModuleFileNameEx

Первый вызов OpenProcess возвращает дескриптор процесса по его идентификатору. С помощью дескриптора можно запросить дополнительную информацию о процессе через WinAPI.

Следующая функция EnumProcessModules читает список модулей процесса в массив struct. Обычно процесс состоит из нескольких модулей. Каждый из них содержит машинный код исполняемого файла или динамической библиотеки DLL. Этот код загружается в память процесса при старте. Первый модуль в списке всегда соответствует исполняемому файлу. Его мы и передаём в функцию GetModuleFileNameEx. Она извлекает из метаинформации модуля путь к соответствующему ему файлу.

Попробуйте запустить скрипт Md5ScanProtection.au3 и оба варианта бота: SimpleBot.ahk и SimpleBot.exe. Новый алгоритм должен их обнаружить.

Может случиться так, что скрипт SimpleBot.ahk не будет обнаружен. Это означает, что ваша версия интерпретатора AutoHotKey отличается от моей. Чтобы это исправить, добавьте в массив kCheckMd5 его хэш-сумму. Вы можете узнать её из лог-файла debug.log с отладочной информацией. В него пишутся все прочитанные защитой Md5ScanProtection.au3 процессы и их MD5-суммы.

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

1. Сделать незначительное изменение в коде скрипта SimpleBot.ahk (например, уменьшить задержку на пару миллисекунд) и скомпилировать его по новой.
2. Изменить заголовок с метаинформацией исполняемого файла AutoHotKey.exe. Для этого можно воспользоваться редактором HT Editor.

Изменение машинного кода, записанного в исполняемый файл, чревато повреждением приложения. В этом случае оно завершится с ошибкой при старте. Но метаинформация, хранимая в заголовке COFF (Common Object File Format), не так чувствительна к изменениям. У заголовка есть несколько стандартных полей. Одно из них – время создания файла. Очевидно, изменение этого поля никак не повлияет на функциональность приложения. В то же время исправленное время создания файла приведёт к другому результату расчёта MD5-суммы. В результате алгоритм защиты Md5ScanProtection.au3 не сможет обнаружить бота.

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

1. Запустите приложение HT Editor с правами администратора. Для удобства скопируйте сначала исполняемый файл редактора в папку к AutoHotKey.exe.
2. В окне редактора нажмите клавишу F3, чтобы вызвать диалог открытия файла (“open file”).
3. Нажмите клавишу Tab, чтобы перейти к списку файлов (“files”). Найдите в нём AutoHotKey.exe и нажмите Enter.
4. Нажмите F6, чтобы открыть диалог выбора режима редактирования (“select mode”). В нём включите режим “- pe/header”. После этого вы увидите список заголовков файла AutoHotKey.exe.
5. Выберите пункт “COFF header” и нажмите Enter. Перейдите на поле “time-data stamp” заголовка.
6. Нажмите F4 для редактирования поля и измените его. Иллюстрация 2-15 демонстрирует эту операцию.
7. Нажмите F4 и выберите вариант “Yes” в диалоге подтверждения сохранения изменений.

В результате мы получим файл AutoHotKey.exe, содержание которого отличается от исходного. Попробуйте запустить его и указать нашего бота SimpleBot.ahk в диалоге открытия скрипта. Алгоритм защиты Md5ScanProtection.au3 не сможет его обнаружить.

Можно исправить алгоритм защиты так, чтобы он игнорировал все заголовки исполняемого файла при подсчёте хэш-суммы. Тогда разработчику бота придётся менять его машинный код. Альтернативное решение для усиления защиты – считать MD5 не для всего содержания файла, а только для небольшого набора байтов из строго определённого места. В этом случае для обхода алгоритма надо будет точно знать это место.

Проверка состояния клавиатуры

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

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

Теперь мы должны реализовать функцию-обработчик события. Она получает входным параметром структуру типа KBDLLHOOKSTRUCT, которая содержит полную информацию о перехваченном событии. У этой структуры есть поле flags. Если в нём присутствует флаг (то есть бит в определённой позиции) LLKHF_INJECTED, перехваченное нажатие клавиши было симулировано WinAPI-функцией SendInput или keybd_event. Если флага LLKHF_INJECTED нет, источником события является клавиатура. Подменить поле flags структуры KBDLLHOOKSTRUCT достаточно сложно, поскольку оно выставляется на уровне ядра ОС.

Скрипт KeyboardCheckProtection.au3 из листинга 2-38 демонстрирует проверку флага LLKHF_INJECTED.

 1 #include <WinAPI.au3>
 2 
 3 global const $kLogFile = "debug.log"
 4 global $gHook
 5 
 6 func LogWrite($data)
 7     FileWrite($kLogFile, $data & chr(10))
 8 endfunc
 9 
10 func _KeyHandler($nCode, $wParam, $lParam)
11     if $nCode < 0 then
12         return _WinAPI_CallNextHookEx($gHook, $nCode, $wParam, $lParam)
13     endIf
14 
15     local $keyHooks = DllStructCreate($tagKBDLLHOOKSTRUCT, $lParam)
16 
17     LogWrite("_KeyHandler() - keyccode = " & DllStructGetData($keyHooks, "vkCode"));
18 
19     local $flags = DllStructGetData($keyHooks, "flags")
20     if $flags = $LLKHF_INJECTED then
21         MsgBox(0, "Alert", "Обнаружен бот-кликер!")
22     endif
23 
24     return _WinAPI_CallNextHookEx($gHook, $nCode, $wParam, $lParam)
25 endfunc
26 
27 func InitKeyHooks($handler)
28     local $keyHandler = DllCallbackRegister($handler, "long", "int;wparam;lparam")
29     local $hMod = _WinAPI_GetModuleHandle(0)
30     $gHook = _WinAPI_SetWindowsHookEx($WH_KEYBOARD_LL, _
31         DllCallbackGetPtr($keyHandler), $hMod)
32 endfunc
33 
34 InitKeyHooks("_KeyHandler")
35 
36 while true
37     Sleep(10)
38 wend

Алгоритм назначения обработчика нажатий клавиш похож на тот, который мы применяли в скриптах TimeSpanProtection.au3 и ActionSequenceProtection.au3. Только в данном случае мы делаем вызов WinAPI через AutoIt-обёртку _WinAPI_SetWindowsHookEx в функции InitKeyHooks. Таким образом мы инициализируем обработчик _KeyHandler, который будет перехватывать все события клавиатуры.

Функция InitKeyHooks выполняет следующие шаги:

1. Регистрирует обработчик _KeyHandler через AutoIt-функцию DllCallbackRegister. Это позволит передать его в вызовы WinAPI.
2. Читает в переменную hMod дескриптор первого модуля (нумерация начинается с нуля) текущего процесса через обёртку _WinAPI_GetModuleHandle. Не забудьте, что наш скрипт выполняется в интерпретаторе AutoIt.
3. Добавляет _KeyHandler в цепочку обработчиков через WinAPI-вызов SetWindowsHookEx. В неё мы должны передать дескриптор модуля, в котором этот обработчик реализован. В нашем случае это переменная hMod.

Алгоритм проверки флага LLKHF_INJECTED в обработчике _KeyHandler выглядит следующим образом:

1. Проверить значение параметра nCode. Если оно меньше нуля, мы передаём событие дальше по цепочке обработчиков. В этом случае оно не содержит нужной нам структуры KBDLLHOOKSTRUCT.
2. Если параметр nCode не равен нулю, вызвать функцию DllStructCreate и передать в неё lParam. Таким образом мы получаем структуру KBDLLHOOKSTRUCT.
3. Прочитать поле flags из KBDLLHOOKSTRUCT с помощью функции DllStructGetData.
4. Проверить наличие флага LLKHF_INJECTED. Если он присутствует, нажатие клавиши было симулировано ботом.

Для тестирования защиты KeyboardCheckProtection.au3 запустите Notepad и бота SimpleBot.au3. Как только он выполнит первое нажатие клавиши, вы увидите сообщение об его обнаружении.

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

1. Использовать виртуальную машину (virtual machine или VM).
2. Использовать специальный драйвер клавиатуры вместо WinAPI-функций SendInput и keybd_event для симуляции нажатий. Пример такого драйвера – InpOut32.
3. Эмулировать клавиатуру или мышь на специальном устройстве. Мы рассмотрим этот подход в пятой главе.

Самый простой в реализации вариант – использование виртуальной машины. У неё есть виртуальные драйверы устройств. Они решают две задачи: эмулируют устройства для гостевой ОС (запущенной внутри VM) и предоставляют доступ к реальным устройствам. Все события симулируемые на хост-системе (на которой запускается VM) и идущие от реальных устройств проходят через виртуальные драйверы. Из-за этого гостевая ОС не может отличить их источник. Поэтому симулируемые ботом нажатия не будут иметь флага LLKHF_INJECTED.

Для запуска VM и нашего тестового бота выполните шаги:

1. Установите одну из следующих виртуальных машин:
   * Virtual Box
   * VMWare Player
   * Windows Virtual PC
2. Установите Windows в качестве гостевой ОС.
3. Запустите в ней Notepad и скрипт KeyboardCheckProtection.au3.
4. Запустите скрипт VirtualMachineBot.au3 на хост-системе.

Скрипт VirtualMachineBot.au3 из листинга 2-39 представляет адаптированную версию нашего бота.

 1 Sleep(2000)
 2 
 3 while true
 4     Send("a")
 5     Sleep(1000)
 6     Send("b")
 7     Sleep(2000)
 8     Send("c")
 9     Sleep(1500)
10 wend

Скрипт VirtualMachineBot.au3 отличается от SimpleBot.au3 процедурой переключения на окно Notepad. Теперь бот не может самостоятельно его найти, поскольку Notepad запущен на гостевой ОС. Мы добавили двухсекундную задержку после старта скрипта, чтобы у вас было время переключиться на окно VM и Notepad внутри неё. Алгоритм защиты KeyboardCheckProtection.au3 не сможет обнаружить скрипт VirtualMachineBot.au3.

Выводы

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

1. Перехват выполняемых защитой WinAPI-вызовов. Для этой цели подойдёт приложение API Monitor.
2. Применение методов реверс-инжиниринга для изучения исполняемых файлов и DLL-библиотек системы защиты.
3. Тестирование различных механизмов симуляции нажатий клавиш. Это поможет выяснить, на что именно реагирует защита.

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

Внутриигровые боты

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

Инструменты для разработки

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

Язык программирования

В этой главе мы будем использовать только язык C++. Для компиляции и работы с кодом рекомендую вам бесплатную IDE Microsoft Visual Studio вместо открытого набора инструментов MinGW. Проблема в том, что MinGW плохо интегрируется с некоторыми Windows библиотеками (например dbghelp.dll). Вы можете пробовать компилировать примеры этой главы с MinGW, но будьте готовы переключиться на Visual Studio IDE.

Чтобы запустить последнюю версию Visual Studio IDE, обновите браузер Microsoft Edge.

Для доступа к Windows Native API и линковки с системной библиотекой ntdll.dll вам понадобится Windows SDK.

Отладчики

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

Бесплатный отладчик OllyDbg мы будем активно использовать на протяжении всей главы. Простой и понятный интерфейс пользователя является его главным преимуществом. Также OllyDbg предоставляет широкие возможности для анализа Windows приложений без исходного кода. Главный его недостаток заключается в поддержке только 32-битный приложений. Рекомендую вам использовать последнюю версию OllyDbg 2.0.

Отладчик с открытым исходным кодом x64dbg поддерживает и 32-битные, и 64-битные приложения. Некоторые возможности OllyDbg в нём отсутствуют, поэтому часть вычислений вам придётся делать самостоятельно. Я рекомендую использовать x64dbg только для отладки 64-битных приложений и OllyDbg в остальных случаях.

WinDbg – многоцелевой бесплатный отладчик для работы с пользовательскими приложениями, драйверами устройств, системными библиотеками и ядром ОС. Он предоставляет некоторые возможности недоступные в OllyDbg и x64dbg, а также поддерживает 32 и 64-битные приложения. Единственный серьёзный недостаток WinDbg заключается в неудобном пользовательском интерфейсе. Эта проблема частично решается с помощью настройки рабочего окружения, которая делает его визуально похожим на OllyDbg. К сожалению, большинство возможностей WinDbg всё равно будут доступны только из командной строки.

Для настройки рабочего окружения WinDbg выполните следующие действия:

1. Скачайте архив с настройкой.
2. Распакуйте полученный архив windbg-workspace-master.zip в папку themes (темы) отладчика. Путь к ней по умолчанию:

C:\Program Files (x86)\Windows Kits\8.1\Debuggers\x64\themes.

3. Среди скопированных файлов найдите и запустите windbg.reg. Затем нажмите кнопку “Yes” в диалоге подтверждения.

После настройки окно WinDbg будет выглядеть как на иллюстрации 3-1.

Инструменты для анализа памяти

Помимо отладчика нам понадобится приложение для анализа памяти запущенного процесса.

Инструмент с открытым исходным кодом Cheat Engine предоставляет функции сканера памяти, отладчика и Hex-редактора (редактор бинарных файлов). Мы будем использовать Cheat Engine в основном как сканер для поиска адреса переменной в памяти процесса и модификации её значения. Более подробно этот инструмент описан в руководстве пользователя.

HeapMemView – бесплатный инструмент для анализа сегментов динамической памяти (heap, иногда переводится как “куча”), выделенных процессом. HeapMemView имеет две версии: для 32 и 64-битных приложений. В некоторых случаях он будет нам полезен.

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

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

Адресное пространство процесса

Исполняемый EXE-файл и запущенный процесс ОС – это не одно и то же. Файл – это некоторые данные, записанные на устройство хранения информации (например жёсткий диск). Исполняемый файл содержит инструкции (или машинный код), которые выполняет процессор без каких либо дополнительных преобразований.

Когда вы запускаете EXE-файл, для его исполнения ОС нужно выполнить несколько шагов. Во-первых, прочитать его содержимое с устройства хранения и записать в оперативную память (random-access memory или RAM). Благодаря этому процессор получает намного более быстрый доступ к инструкциям из файла, поскольку скорость его интерфейса с RAM на несколько порядков выше чем с любым диском.

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

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

Где процесс хранит свои данные? Мы уже знаем, что ОС всегда загружает исполняемые инструкции в оперативную память. В случае данных, сам процесс может свободно выбрать место их хранения: жёсткий диск, оперативная память или даже удалённый компьютер (например игровой сервер подключённый по сети). Большая часть данных, необходимых во время работы процесса копируются в оперативную память для ускорения доступа к ней. Поэтому, именно в RAM мы можем прочитать состояния игровых объектов. Они будут доступны на протяжении всего времени выполнения (runtime) процесса.

Иллюстрация 3-2 демонстрирует элементы типичного процесса. Как правило, он состоит из нескольких модулей. Обязательным из них является EXE, который содержит все инструкции и данные, загруженные из исполняемого файла. Другие модули (обозначенные DLL_1 и DLL_2) соответствуют библиотекам, функции которых вызываются из EXE.

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

Мы рассмотрели исполняемый файл и запущенный процесс. Теперь поговорим о библиотеках с функциями. Они делятся на два типа: динамически подключаемые (dynamic-link libraries или DLL) и статически подключаемые (static libraries). Главное различие между ними заключается во времени разрешения зависимостей. Когда исполняемый файл использует функцию библиотеки, говорят, что он от неё зависит.

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

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

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

Запущенное приложение может использовать несколько алгоритмов в ходе своей работы. Некоторые из них могут выполняться параллельно (так же как процессы в многозадачной ОС). Поток (thread) – это часть машинного кода процесса, которая может выполняться независимо от других частей. Потоки взаимодействуют друг с другом (обмениваются информацией) через разделяемые ресурсы, например файл или область RAM. За выбор потока для исполнения в данный момент отвечает уже знакомый нам планировщик ОС. Как правило, число одновременно работающих потоков определяется числом ядер процессора. Но есть технологии (например hyper-threading от Intel), позволяющие более эффективно использовать мощности процессора и исполнять сразу два потока на одном ядре.

Иллюстрация 3-2 демонстрирует, что модули процесса могут содержать несколько потоков, а могут не содержать ни одного. EXE-модуль всегда имеет главный поток (main thread), который первым получает управление при старте приложения.

Рассмотрим структуру памяти типичного процесса. Иллюстрация 3-3 демонстрирует адресное пространство процесса, состоящего из EXE-модуля и DLL-библиотеки. Адресное пространство – это множество всех доступных процессу адресов памяти. Оно разделено на блоки, называемые сегментами. У каждого из них есть базовый адрес, длина и набор прав доступа (на запись, чтение и исполнение). Разделение на сегменты упрощает задачу контроля доступа к памяти. С их помощью ОС может оперировать блоками памяти, а не отдельными адресами.

Процесс на иллюстрации 3-3 имеет три потока (включая главный). У каждого потока есть свой сегмент стека. Стек – это область памяти, организованная по принципу “последним пришёл — первым вышел” (“last in — first out” или LIFO). Она инициализируется ОС при старте приложения и используется для хранения переменных и вызова функций. В стеке сохраняется адрес инструкции, следующей за вызовом. После возврата из функции процесс продолжает своё выполнение с этой инструкции. Также через стек передаются входные параметры функций.

Кроме сегментов стека, у процесса есть несколько сегментов динамической памяти (heap), к которым имеет доступ каждый поток.

У всех модулей процесса есть обязательные сегменты: .text, .data и .bss. Кроме обязательных могут быть и дополнительные сегменты (например .rsrc). Они не представлены на схеме 3-3.

Таблица 3-1 кратко описывает каждый сегмент из иллюстрации 3-3. Во втором столбце приведены их обозначения в отладчике OllyDbg.

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

ОС назначает базовые адреса этих сегментов в момент старта приложения. Эти адреса могут отличаться от запуска к запуску. Кроме того, последовательность сегментов в памяти может также меняться. В то же время некоторые из сегментов, отмеченных синим цветом на иллюстрации 3-3 (например PEB, User Share Data и Kernel memory), имеют неизменный адрес при каждом старте приложения.

Отладчик OllyDbg позволяет прочитать структуру памяти (memory map) запущенного процесса. Иллюстрации 3-4 и 3-5 демонстрируют вывод OllyDbg для приложения, адресное пространство которого приведено на схеме 3-3.

Таблица 3-2 демонстрирует соответствие между схемой 3-3 и сегментами настоящего процесса из иллюстраций 3-4 и 3-5.

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

Поиск переменной в памяти

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

Термин “абсолютный адрес” неточен, если мы говорим о модели сегментации памяти x86. x86 – это архитектура процессора, впервые реализованная компанией Intel. Сегодня практически все настольные компьютеры имеют процессоры этой архитектуры. Правильный термин, который следует употреблять – “линейный адрес”. Он вычисляется по следующей формуле:

1 линейный адрес = базовый адрес сегмента + смещение в сегменте

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

Задачу поиска переменной в памяти процесса можно разделить на три этапа. В результате получится следующий алгоритм:

1. Найти сегмент, который содержит искомую переменную.
2. Определить базовый адрес сегмента.
3. Определить смещение переменной внутри сегмента.

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

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

Последний шаг алгоритма – найти смещение переменной в сегменте. Нет никаких гарантий, что оно не будет меняться при каждом старте приложения. Однако, смещение может оставаться тем же в некоторых случаях. Это зависит от типа сегмента, как демонстрирует таблица 3-3. Таким образом, в некоторых случаях мы можем выполнить третий шаг алгоритма вручную и закодировать результат в боте.

Поиск переменной в 32-битном приложении

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

Приложение ColorPix является 32-битным. Скриншот его окна приведён на иллюстрации 3-6. Попробуем найти в памяти переменную, которая соответствует координате X выделенного на экране пикселя. На иллюстрации 3-6 она подчёркнута красной линией.

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

1. Найти абсолютный адрес переменной с помощью сканера памяти Cheat Engine.
2. Сравнить найденный адрес с базовыми адресами всех сегментов. Таким образом мы узнаем сегмент, в котором хранится переменная.

Чтобы найти переменную с помощью Cheat Engine, выполните следующие действия:

1. Запустите 32-битную версию сканера с правами администратора.
2. Выберите пункт главного меню “File” -> “Open Process”. Вы увидите диалог со списком запущенных процессов (см. иллюстрацию 3-7).

3. Выберите процесс с именем “ColorPixel.exe” и нажмите кнопку “Open”. В результате имя этого процесса отобразится в верхней части окна Cheat Engine.
4. Введите значение координаты X, которое вы видите в данный момент в окне ColorPixel, в поле “Value” окна Cheat Engine.
5. Нажмите кнопку “First Scan”, чтобы найти абсолютный адрес указанного значения координаты X в памяти процесса ColorPixel.

Когда вы нажимаете кнопку “First Scan”, значение в поле “Value” окна Cheat Engine, должно соответствовать тому, что отображает ColorPixel. Координата X изменится, если вы переместите курсор мыши по экрану, поэтому нажать на кнопку будет затруднительно. Воспользуйтесь комбинацией клавиш Shift+Tab, чтобы переключиться на неё и Enter, чтобы нажать.

В левой части окна Cheat Engine вы увидите результаты поиска, как на иллюстрации 3-8.

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

1. Переместите курсор мыши, чтобы значение координаты X в окне ColorPixel изменилось.
2. Введите новую координату X в поле “Value” окна Cheat Engine.
3. Нажмите кнопку “Next Scan”.

После этого в окне результатов должны остаться только две переменные, как на иллюстрации 3-8. В моём случае их абсолютные адреса равны 0018FF38 и 0025246C. У вас они могут отличаться, но это не существенно для нашего примера.

Мы нашли абсолютные адреса двух переменных, хранящих значение координаты X. Теперь определим сегменты, в которых они находятся. Для этой цели воспользуемся отладчиком OllyDbg. Для поиска сегментов выполните следующие шаги:

1. Запустите отладчик OllyDbg с правами администратора. Путь к нему по умолчанию:
C:\Program Files (x86)\odbg201\ollydbg.exe.

2. Выберите пункт главного меню “File” -> “Attach”. Вы увидите диалог со списком запущенных 32-битных процессов (см. иллюстрацию 3-9).

3. Выберите процесс “ColorPix” в списке и нажмите кнопку “Attach”. Когда отладчик подключится к нему, вы увидите состояние “Paused” в правом нижнем углу окна OllyDbg.
4. Нажмите комбинацию клавиш Alt+M, чтобы открыть окно, отображающее структуру памяти процесса ColorPix. Это окно “Memory Map” приведено на иллюстрации 3-10.

Переменная с абсолютным адресом 0018FF38 хранится в сегменте стека главного процесса (“Stack of main thread”), который занимает адреса с 0017F000 по 00190000.

Вторая найденная нами переменная с адресом 0025246C находится в сегменте с базовым адресом 00250000, тип которого неизвестен. Найти его будет труднее чем сегмент стека. Поэтому мы продолжим работу с первой переменной.

Последний шаг поиска – расчёт смещения переменной в сегменте стека. Стек в архитектуре x86 растёт вниз. Это означает, что он начинается с больших адресов и расширяется в сторону меньших. Следовательно, базовый адрес стека равен его верхней границе (в нашем случае это 00190000). Нижняя границе стека может меняться по ходу его увеличения.

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

1 00190000 - 0018FF38 = C8

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

Теперь у нас есть вся необходимая информация, чтобы найти и прочитать координату X в любом запущенном процессе ColorPix. Алгоритм бота, который бы это делал, выглядит следующим образом:

1. Прочитать базовый адрес сегмента стека главного потока. Этот адрес хранится в TEB сегменте.
2. Вычесть смещение переменной (всегда равное C8) из базового адреса сегмента стека. В результате получим её абсолютный адрес.
3. Прочитать значение переменной из памяти процесса ColorPix по её абсолютному адресу.

Корректность первого шага алгоритма мы можем проверить вручную с помощью отладчика OllyDbg. Он позволяет прочитать информацию сегмента TEB в удобном виде. Для этого дважды щёлкните по сегменту, который называется “Data block of main thread”, в окне “Memory Map” отладчика. Вы увидите окно как на иллюстрации 3-11.

Базовый адрес сегмента стека 00190000 указан во второй строчке открывшегося окна. Учтите, что этот адрес может меняться при каждом запуске приложения.

Поиск переменной в 64-битном приложении

Применим наш алгоритм поиска переменной для 64-битного приложения.

Resource Monitor (монитор ресурсов) Windows 7 будет нашим приложением для анализа. Он распространяется вместе с ОС и доступен сразу после её установки. Разрядность Resource Monitor совпадает с разрядностью Windows. Чтобы запустить приложение, откройте меню Пуск (Start) Windows и введите следующую команду в строку поиска:

1 perfmon.exe /res

Иллюстрации 3-12 демонстрирует окно Resource Monitor.

Найдём переменную, хранящую размер свободной памяти системы. На иллюстрации её значение подчёркнуто красной линией.

Прежде всего найдём сегмент, содержащий искомую переменную. Для этого воспользуемся 64-битной версией сканера Cheat Engine. Интерфейс его 64 и 34-битных версий одинаков, поэтому вам нужно выполнить те же действия, что и при анализе приложения ColorPixel.

В моем случае сканер нашёл две переменные с адресами 00432FEC и 00433010. Определим сегменты, в которых они хранятся. Чтобы прочитать структуру памяти процесса с помощью отладчика WinDbg, выполните следующие действия:

1. Запустите 64-битную версию WinDbg с правами администратора. Путь к нему по умолчанию:
C:\Program Files (x86)\Windows ­Kits\8.1\Debuggers\x64\windbg.exe.

2. Выберите пункт главного меню “File” -> “Attach to a Process…”. Откроется окно диалога со списком запущенных 64-разрядных процессов, как на иллюстрации 3-13.

3. Выберите в списке процесс “perfmon.exe” и нажмите кнопку “OK”.
4. В командной строке отладчика, расположенной в нижней части окна “Command”, введите текст !address и нажмите Enter. Структура памяти процесса отобразится в окне “Command”, как на иллюстрации 3-14.

Обе переменные с абсолютными адресами 00432FEC и 00433010 находятся в сегменте динамической памяти с ID 2. Границы этого сегмента: с 003E0000 по 00447000. Смещение первой переменной в сегменте равно 52FEC:

1 00432FEC - 003E0000 = 52FEC

Задача решена.

Для бота алгоритм поиска переменной, хранящей размер свободной памяти ОС в приложении Resource Monitor, выглядит следующим образом:

1. Прочитать базовый адрес сегмента динамической памяти с ID 2. Чтобы получить доступ к этим сегментам, надо воспользоваться следующими WinAPI-функциями:
   * CreateToolhelp32Snapshot
   * Heap32ListFirst
   * Heap32ListNext
2. Добавить смещение переменной (в моем случае равное 52FEC) к базовому адресу сегмента. В результате получится её абсолютный адрес.
3. Прочитать значение переменной из памяти процесса.

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

Попробуйте перезапустить Resource Monitor и найти переменную ещё раз. Вы получите то же самое её смещение в сегменте, равное 52FEC.

Выводы

Мы рассмотрели адресное пространство Windows процесса. Затем составили алгоритм поиска переменной в памяти и применили его к 32 и 64-разрядному приложениям. В ходе этого мы познакомились с функциями отладчиков OllyDbg и WinDbg для анализа структуры памяти процесса.

Доступ к памяти процесса

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

Подключение к процессу

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

Практически все объекты и ресурсы Windows доступны через их дескрипторы. WinAPI-функция OpenProcess позволяет получить дескриптор работающего процесса. Возникает вопрос: как сообщить ОС, что нас интересует именно процесс игрового приложения? Для этой цели служит идентификатор процесса (process identifier или PID). PID – это уникальный номер, который ОС присваивает каждому процессу при старте. Его мы должны передать в OpenProcess входным параметром. Далее получив дескриптор процесса, мы можем обращаться к его памяти с помощью других WinAPI-функций.

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

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

Представим, что мы разрабатываем пользовательское приложение, например внутриигрового бота. Каким образом оно может взаимодействовать с каким-нибудь Windows объектом? Каждый объект представляет собой структуру, состоящую из заголовка (header) и тела (body). Тело содержит данные, специфичные для каждого типа объектов. Заголовок же включает метаинформацию, которая используется менеджером объектов (Object Manager). Именно он предоставляет доступ к ресурсам ОС через соответствующие им объекты.

Модель безопасности Windows ограничивает процессам доступ к системным объектам и различным действиям, требующих прав администратора. Можно сказать, что менеджер объектов реализует модель безопасности Windows. Согласно ей, процесс должен иметь специальные привилегии, чтобы получить доступ к памяти другого через вызов OpenProcess. Управлять привилегиями процесса можно с помощью специального объекта Windows под названием маркер доступа (access token).

Учитывая модель безопасности Windows, полный алгоритм подключения к процессу через WinAPI-функцию OpenProcess выглядит следующим образом:

1. Получить дескриптор текущего процесса.
2. По дескриптору получить маркер доступа текущего процесса.
3. Предоставить привилегию SE_DEBUG_NAME для маркера доступа. Эта привилегия даёт право отлаживать другие процессы.
4. Получить дескриптор целевого процесса через вызов OpenProcess.

Приложение, реализующее этот алгоритм, должно быть запущено с правами администратора. Без них невозможно выполнить третий шаг и предоставить текущему процессу привилегию SE_DEBUG_NAME через WinAPI-функцию AdjustTokenPrivileges.

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

Листинг 3-1 демонстрирует код приложения, которое подключается к процессу с заданным PID.

 1 #include <windows.h>
 2 #include <stdio.h>
 3 
 4 BOOL SetPrivilege(HANDLE hToken, LPCTSTR lpszPrivilege, BOOL bEnablePrivilege)
 5 {
 6     TOKEN_PRIVILEGES tp;
 7     LUID luid;
 8     if (!LookupPrivilegeValue(NULL, lpszPrivilege, &luid))
 9 
10     {
11         printf("LookupPrivilegeValue error: %u\n", GetLastError());
12         return FALSE;
13     }
14 
15     tp.PrivilegeCount = 1;
16     tp.Privileges[0].Luid = luid;
17 
18     if (bEnablePrivilege)
19         tp.Privileges[0].Attributes = SE_PRIVILEGE_ENABLED;
20     else
21         tp.Privileges[0].Attributes = 0;
22 
23     if (!AdjustTokenPrivileges(hToken, FALSE, &tp, sizeof(TOKEN_PRIVILEGES),
24                                (PTOKEN_PRIVILEGES)NULL, (PDWORD)NULL))
25     {
26         printf("AdjustTokenPrivileges error: %u\n", GetLastError());
27         return FALSE;
28     }
29 
30     if (GetLastError() == ERROR_NOT_ALL_ASSIGNED)
31     {
32         printf("The token does not have the specified privilege. \n");
33         return FALSE;
34     }
35     return TRUE;
36 }
37 
38 int main()
39 {
40     HANDLE hProc = GetCurrentProcess();
41     HANDLE hToken = NULL;
42 
43     if (!OpenProcessToken(hProc, TOKEN_ADJUST_PRIVILEGES, &hToken))
44         printf("Failed to open access token\n");
45 
46     if (!SetPrivilege(hToken, SE_DEBUG_NAME, TRUE))
47         printf("Failed to set debug privilege\n");
48 
49     DWORD pid = 1804;
50 
51     HANDLE hTargetProc = OpenProcess(PROCESS_ALL_ACCESS, FALSE, pid);
52     if (hTargetProc)
53         printf("Target process handle = %p\n", hTargetProc);
54     else
55         printf("Failed to open process: %u\n", GetLastError());
56 
57     CloseHandle(hTargetProc);
58     return 0;
59 }

Приложение из листинга 3-1 подключается к процессу с PID равным 1804. Вам нужно заменить его на PID работающего в данный момент процесса. Узнать идентификаторы всех запущенных процессов можно с помощью приложения Task Manager (диспетчер задач). Укажите PID целевого процесса в следующей строке файла OpenProcess.cpp:

1     DWORD pid = 1804;

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

Сначала мы с помощью WinAPI-функции GetCurrentProcess получаем дескриптор текущего процесса и сохраняем его в переменной hProc.

Далее вызывается WinAPI-функция OpenProcessToken, которая возвращает маркер доступа. В неё мы передаём дескриптор hProc и маску доступа TOKEN_ADJUST_PRIVILEGES. Благодаря этой маске мы получаем право менять возвращаемый функцией маркер доступа. Его мы сохраняем в переменной hToken.

Весь код, предоставляющий привилегию SE_DEBUG_NAME маркеру доступа hToken, мы реализовали в отдельной функции SetPrivilege. Она выполняет два действия:

1. Читает локальный уникальный идентификатор (locally unique identifier или LUID) константы, соответствующей привилегии SE_DEBUG_NAME с помощью WinApI функции LookupPrivilegeValue.
2. Предоставляет маркеру доступа, переданному входным параметром, привилегию SE_DEBUG_NAME (указанную по LUID) через WinAPI-функцию AdjustTokenPrivileges.

Функция SetPrivilege более детально разбирается в статье.

Последнее действие в функции main – подключение к целевому процессу, дескриптор которого сохраняется в переменной hTargetProc. Для этого мы используем WinAPI-функцию OpenProcess. В неё передаются права доступа PROCESS_ALL_ACCESS и PID процесса для подключения. После этого вся его память становится доступна по дескриптору hTargetProc.

Операции чтения и записи

Мы знаем как получить дескриптор целевого процесса. Теперь рассмотрим способы обращения к его памяти.

WinAPI-функция ReadProcessMemory читает данные из указанной области памяти целевого процесса и сохраняет их в память вызывающего процесса. Аналогичная ей функция WriteProcessMemory записывает указанные данные в память целевого процесса. Рассмотрим пример использования этих функций.

Тестовое приложение, приведённое в листинге 3-2, записывает шестнадцатеричное значение DEADBEEF по некоторому абсолютному адресу памяти целевого процесса. Затем по этому же адресу происходит чтение. Если запись была успешной, мы прочитаем то же самое значение DEADBEEF.

 1 #include <stdio.h>
 2 #include <windows.h>
 3 
 4 BOOL SetPrivilege(HANDLE hToken, LPCTSTR lpszPrivilege, BOOL bEnablePrivilege)
 5 {
 6     // Смотрите реализацию этой функции в листинге 3-1
 7 }
 8 
 9 DWORD ReadDword(HANDLE hProc, DWORD_PTR address)
10 {
11     DWORD result = 0;
12 
13     if (ReadProcessMemory(hProc, (void*)address, &result, sizeof(result), NULL) == 0)
14     {
15         printf("Failed to read memory: %u\n", GetLastError());
16     }
17     return result;
18 }
19 
20 void WriteDword(HANDLE hProc, DWORD_PTR address, DWORD value)
21 {
22     if (WriteProcessMemory(hProc, (void*)address, &value, sizeof(value), NULL) == 0)
23     {
24         printf("Failed to write memory: %u\n", GetLastError());
25     }
26 }
27 
28 int main()
29 {
30     HANDLE hProc = GetCurrentProcess();
31 
32     HANDLE hToken = NULL;
33     if (!OpenProcessToken(hProc, TOKEN_ADJUST_PRIVILEGES, &hToken))
34         printf("Failed to open access token\n");
35 
36     if (!SetPrivilege(hToken, SE_DEBUG_NAME, TRUE))
37         printf("Failed to set debug privilege\n");
38 
39     DWORD pid = 5356;
40     HANDLE hTargetProc = OpenProcess(PROCESS_ALL_ACCESS, FALSE, pid);
41     if (!hTargetProc)
42         printf("Failed to open process: %u\n", GetLastError());
43 
44     DWORD_PTR address = 0x001E0000;
45     WriteDword(hTargetProc, address, 0xDEADBEEF);
46     printf("Result of reading dword at 0x%llx address = 0x%x\n", address,
47            ReadDword(hTargetProc, address));
48 
49     CloseHandle(hTargetProc);
50     return 0;
51 }

Абсолютный адрес 001E0000 для записи значения DEADBEEF выбран произвольно. Эту область памяти занимает какой-то сегмент. Операция записи данных в него может привести к аварийному завершению целевого процесса. Поэтому в качестве него
не используйте важные системные службы Windows. Лучше всего для нашего теста подойдёт приложение Notepad.

Для запуска приложения ReadWriteProcessMemory.cpp выполните следующие действия:

1. Запустите Notepad.
2. С помощью Task Manager прочитайте PID процесса Notepad.
3. Присвойте этот PID соответствующей переменной в исходном коде приложения ReadWriteProcessMemory.cpp:

1 DWORD pid = 5356;

4. С помощью отладчика WinDbg прочитайте базовый адрес любого сегмента динамической памяти процесса Notepad. Для этого воспользуйтесь уже знакомой нам командой !address.
5. Отключите WinDbg от процесса Notepad с помощью команды .detach.
6. Присвойте базовый адрес сегмента динамической памяти переменной address в функции main:

1 DWORD_PTR address = 0x001E0000;

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

7. Скомпилируйте приложение ReadWriteProcessMemory.cpp. Разрядность (x86 или x64) полученного EXE-файл должна соответствовать разрядности Notepad. В противном случае наше приложение не сможет к нему подключиться.
8. Запустите тестовое приложение с правами администратора из командной строки Windows.

После успешного выполнения нашего примера, вы увидите в консоли строку:

1 Result of reading dword at 0x1e0000 address = 0xdeadbeef

В этом выводе указан абсолютный адрес для записи и прочитанное по нему же значение.

Обратите внимание на функции-обёртки WriteDword и ReadDword в листинге 3-2. Они скрывают несущественные детали и предоставляют простой интерфейс к WinAPI-функциям WriteProcessMemory и ReadProcessMemory. Их параметры представлены в таблице 3-4.

Доступ к сегментам TEB и PEB

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

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

Доступ к TEB текущего процесса

Главный поток 32-битного процесса

Рассмотрим методы доступа к TEB сегменту. Начнём с самого простого варианта этой задачи. Предположим, что у нас есть однопоточное приложение. Как ему получить доступ к TEB своего главного потока? Существует несколько способов.

Самый простой и прямолинейный метод – воспользоваться регистром FS процессора на x86 архитектуре или регистром GS на архитектуре x64. Вообще, процессор предоставляет ОС решать, как использовать эти регистры. Windows хранит в них указатель на TEB сегмент потока, который исполняется в данный момент. Листинг 3-3 демонстрирует чтение регистра FS.

 1 #include <winternl.h>
 2 
 3 PTEB GetTeb()
 4 {
 5     PTEB pTeb;
 6 
 7     __asm {
 8         mov EAX, FS:[0x18]
 9         mov pTeb, EAX
10     }
11     return pTeb;
12 }

В функции GetTeb используются ассемблерные вставки. Эта возможность C++ позволяет добавлять в программу код на языке ассемблера, каждая команда которого соответствует одной инструкции процессора. Другими словами мы спускаемся на самый нижний уровень и оперируем элементарными действиями процессора.

Рассмотрим код GetTeb подробнее. Функция начинается с выделения памяти на стеке для локальной переменной pTeb типа PTEB. Согласно WinAPI документации, тип PTEB – это указатель на структуру, содержащую все данные сегмента TEB. Далее идёт блок с двумя командами на языке ассемблера:

1. Запись в регистр EAX некоторого значения. Оно находится по абсолютному адресу памяти, который рассчитывается по формуле:

1 линейный адрес = базовый адрес из регистра FS + 0x18

2. Запись значение регистра EAX в переменную pTeb.

В результате этих команд базовый адрес регистра TEB оказывается записан в переменную pTeb. Её мы и возвращаем из функции.

Почему GetTeb не может просто вернуть значение регистра FS? Ведь он, по идее, должен указывать на TEB сегмент. Чтобы ответить на этот вопрос, рассмотрим как в Windows происходит доступ к сегментам процесса.

Большинство современных ОС использует защищённый режим процессора (protected processor mode). В этом режиме адресация сегментов происходит через глобальную таблицу дескрипторов (Global Descriptor Table или GDT). В регистрах FS и GS хранится селектор, который является индексом записи в таблице дескрипторов. В этой записи находится базовый адрес сегмента TEB. Запрос к GDT по селектору выполняется аппаратным блоком сегментации (segmentation unit) процессора. Результат этого запроса временно хранится в процессоре и недоступен для приложений или ОС. Таким образом, у Windows нет эффективного способа узнать базовый адрес сегмента TEB. Его можно прочитать из таблицы дескрипторов через WinAPI-функции GetThreadSelectorEntry и Wow64GetThreadSelectorEntry, но этот способ неэффективен из-за накладных расходов. Именно поэтому в TEB сегменте хранится его собственный базовый адрес.

Если вы интересуетесь подробностями, пример использования функции GetThreadSelectorEntry приведён в следующем обсуждении на форуме.

Структура TEB определена в заголовочном файле winternal.h, который распространяется с Windows SDK. Она отличается для разных версий Windows. Поэтому важно, чтобы ваши версии ОС и Windows SDK совпадали. Перед началом работы с TEB структурой всегда уточняйте её поля в заголовочном файле.

Определение структуры TEB из Windows SDK версии 8.1 выглядит следующим образом:

 1 typedef struct _TEB {
 2     PVOID Reserved1[12];
 3     PPEB ProcessEnvironmentBlock;
 4     PVOID Reserved2[399];
 5     BYTE Reserved3[1952];
 6     PVOID TlsSlots[64];
 7     BYTE Reserved4[8];
 8     PVOID Reserved5[26];
 9     PVOID ReservedForOle;  // Windows 2000 only
10     PVOID Reserved6[4];
11     PVOID TlsExpansionSlots;
12 } TEB, *PTEB;

В ней среди прочих есть поле ProcessEnvironmentBlock, которое указывает на структуру PEB. Через него мы можем получить доступ к PEB сегменту.

Главный поток 64-битного процесса

Мы не можем просто заменить регистр FS на GS и использовать функцию GetTeb из листинга 3-3 на 64-разрядной системе. Проблема в том, что компилятор Visual Studio C++ не поддерживает ассемблерные вставки при компиляции 64-разрядных приложений. Вместо них следует использовать встроенные функции компилятора (compiler intrinsics).

Листинг 3-4 демонстрирует функцию GetTeb, переписанную для поддержки обеих архитектур: x86 и x64.

 1 #include <windows.h>
 2 #include <winternl.h>
 3 
 4 PTEB GetTeb()
 5 {
 6 #if defined(_M_X64) // x64
 7     PTEB pTeb = reinterpret_cast<PTEB>(__readgsqword(0x30));
 8 #else // x86
 9     PTEB pTeb = reinterpret_cast<PTEB>(__readfsdword(0x18));
10 #endif
11     return pTeb;
12 }

В новом варианте GetTeb используется директива условной компиляции препроцессора. С её помощью перед компиляцией выбирается подходящая реализация функции. Если макрос _M_X64 определён, значит целевая архитектура приложения 64-разрядная. В этом случае вызывается встроенная функция компилятора __readgsqword, которая читает 64-битное значение со смещением 0x30 от базового адреса сегмента TEB (на него указывает регистр GS через селектор). Для 32-разрядной архитектуры вызывается встроенная функция __readfsdword, которая читает 32-битное значение со смещением 0x18 от базового адреса сегмента TEB (на него указывает регистр FS).

Новая реализация функции GetTeb может вызвать вопрос: почему поле структуры TEB с базовым адресом сегмента имеет разные смещения для x86 и x64 архитектур? Чтобы ответить на него, рассмотрим определение структуры NT_TIB, которая используется для представления части TEB, независимой от версии Windows:

 1 typedef struct _NT_TIB {
 2     struct _EXCEPTION_REGISTRATION_RECORD *ExceptionList;
 3     PVOID StackBase;
 4     PVOID StackLimit;
 5     PVOID SubSystemTib;
 6      union
 7      {
 8           PVOID FiberData;
 9           ULONG Version;
10      };
11     PVOID ArbitraryUserPointer;
12     struct _NT_TIB *Self;
13 } NT_TIB;

Поле с базовым адресом сегмента TEB называется Self. До него идут шесть полей, каждое из которых имеет тип PVOID. PVOID – это указатель на область памяти. Его размер зависит от разрядности процессора: 32 бита (или 4 байта) для архитектуры x86 и 64 бита (или 8 байт) для x64. Таким образом, в первом случае поле Self окажется смещено на 24 байта (6 * 4), а во втором на 48 байт (6 * 8). Переведём эти числа в шестнадцатеричную систему счисления и получим 0x18 и 0x30 соответственно.

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

 1 #include <windows.h>
 2 #include <winternl.h>
 3 
 4 PTEB GetTeb()
 5 {
 6 #if defined(_M_X64) // x64
 7     PTEB pTeb = reinterpret_cast<PTEB>(__readgsqword(reinterpret_cast<DWORD>(
 8                                        &static_cast<PNT_TIB>(nullptr)->Self)));
 9 #else // x86
10     PTEB pTeb = reinterpret_cast<PTEB>(__readfsdword(reinterpret_cast<DWORD>(
11                                        &static_cast<PNT_TIB>(nullptr)->Self)));
12 #endif
13     return pTeb;
14 }

Эта реализация функции GetTeb заимствована из статьи. В ней используются уже знакомые нам встроенные функции компилятора __readgsqword и __readfsdword. Мы применяем определение структуры NT_TIB, чтобы прочитать смещение её поля Self, содержащее базовый адрес сегмента TEB. Для этого мы последовательно приводим типы. Общий алгоритм расчёта смещения выглядит следующим образом:

1. Указатель на нулевой абсолютный адрес, который обозначается литералом nullptr, приводим к типу PNT_TIB с помощью оператора static_cast. Таким образом мы получаем указатель на структуру типа NT_TIB, расположенную по адресу 0.
2. С помощью оператора доступа к полю -> читаем поле Self структуры NT_TIB.
3. С помощью операции взятия адреса & читаем абсолютный адрес поля Self. В данном случае абсолютный адрес совпадёт с относительным, поскольку он считается от нуля.
4. Приведём полученный относительный адрес поля Self к типу DWORD или QWORD (в зависимости от целевой архитектуры) с помощью оператора reinterpret_cast. Это приведение необходимо, так как встроенные функции компилятора ожидают конкретный тип входного параметра.

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

WinAPI-функции доступа к TEB

Получить доступ к TEB сегменту можно и через WinAPI. Функция NtCurrentTeb реализует тот же алгоритм, что и GetTeb из листинга 3-5. С её помощью можно получить указатель на структуру типа TEB текущего потока. Листинг 3-6 демонстрирует использование NtCurrentTeb.

1 #include <windows.h>
2 #include <winternl.h>
3 
4 PTEB pTeb = NtCurrentTeb();

Теперь все манипуляции над регистрами FS и GS происходят на уровне системной библиотеки ОС. Мы можем рассчитывать на её корректную работу для всех архитектур, поддерживаемых Windows (x86, x64, ARM).

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

WinAPI-функция NtQueryInformationThread предоставляет доступ к TEB любого потока. Она работает только в контексте вызывающего процесса, т.е. с её помощью вы не сможете прочитать TEB игрового приложения из бота. Но в некоторых случаях NtQueryInformationThread может быть полезна. Листинг 3-7 демонстрирует реализацию GetTeb, которая использует NtQueryInformationThread.

 1 #include <windows.h>
 2 #include <winternl.h>
 3 
 4 #pragma comment(lib,"ntdll.lib")
 5 
 6 typedef struct _CLIENT_ID {
 7     DWORD UniqueProcess;
 8     DWORD UniqueThread;
 9 } CLIENT_ID, *PCLIENT_ID;
10 
11 typedef struct _THREAD_BASIC_INFORMATION {
12     typedef PVOID KPRIORITY;
13     NTSTATUS ExitStatus;
14     PVOID TebBaseAddress;
15     CLIENT_ID ClientId;
16     KAFFINITY AffinityMask;
17     KPRIORITY Priority;
18     KPRIORITY BasePriority;
19 } THREAD_BASIC_INFORMATION, *PTHREAD_BASIC_INFORMATION;
20 
21 typedef enum _THREADINFOCLASS2 {
22     ThreadBasicInformation,
23     ThreadTimes,
24     ThreadPriority,
25     ThreadBasePriority,
26     ThreadAffinityMask,
27     ThreadImpersonationToken,
28     ThreadDescriptorTableEntry,
29     ThreadEnableAlignmentFaultFixup,
30     ThreadEventPair_Reusable,
31     ThreadQuerySetWin32StartAddress,
32     ThreadZeroTlsCell,
33     ThreadPerformanceCount,
34     ThreadAmILastThread,
35     ThreadIdealProcessor,
36     ThreadPriorityBoost,
37     ThreadSetTlsArrayAddress,
38     _ThreadIsIoPending,
39     ThreadHideFromDebugger,
40     ThreadBreakOnTermination,
41     MaxThreadInfoClass
42 } THREADINFOCLASS2;
43 
44 PTEB GetTeb()
45 {
46     THREAD_BASIC_INFORMATION threadInfo;
47     if (NtQueryInformationThread(GetCurrentThread(),
48                                  (THREADINFOCLASS)ThreadBasicInformation,
49                                  &threadInfo, sizeof(threadInfo), NULL))
50     {
51         printf("NtQueryInformationThread return error\n");
52         return NULL;
53     }
54     return reinterpret_cast<PTEB>(threadInfo.TebBaseAddress);
55 }

Параметры функции NtQueryInformationThread приведены в таблице 3-5.

Чтобы прочитать структуру типа THREAD_BASIC_INFORMATION для заданного потока, мы должны передать в функцию NtQueryInformationThread константу ThreadBasicInformation из перечисления THREADINFOCLASS. К сожалению, эта константа недокументированна. Кроме того, она не определена в заголовочном файле winternl.h. В нём есть только константа ThreadIsIoPending.

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

В нашем новом перечислении THREADINFOCLASS2 не должно быть константы с именем ThreadIsIoPending, иначе она будет конфликтовать с определением из заголовочного файла winternl.h. Поэтому в листинге 3-7 мы переименовали её на _ThreadIsIoPending.

Функция NtQueryInformationThread возвращает структуру данных, тип который зависит от переданного вторым параметром константы. Если мы передаём недокументированную константу ThreadBasicInformation, то тип возвращаемой структуры будет также недокументирован. Поэтому мы должны самостоятельно определить её тип THREAD_BASIC_INFORMATION. Вы можете найти его в уже упомянутой неофициальной документации или скопировать из листинга 3-7.

Обратите внимание на определение структуры THREAD_BASIC_INFORMATION. Базовый адрес сегмента TEB хранится в её поле TebBaseAddress. Она отличается от структуры TEB, с которой мы сталкивались ранее.

Функция NtQueryInformationThread доступна через Native API интерфейс. Она реализована в динамической библиотеке ntdll.dll, которая всегда входит в состав дистрибутива Windows. Эта библиотека активно используется системами ОС. Но, чтобы вызвать её функции из пользовательского приложения, понадобится библиотека импорта ntdll.lib и заголовочный файл winternl.h. Windows SDK предоставляет эти файлы.

Воспользоваться библиотекой импорта можно с помощью директивы pragma:

1 #pragma comment(lib, "ntdll.lib")

Эта строчка добавляет файл ntdll.lib в список библиотек импорта, которым воспользуется компоновщик.

В архиве примеров к этой книге вы можете найти файл TebPebSelf.cpp, в котором приведены все рассмотренные нами способы доступа к TEB и PEB сегментам.

Доступ к TEB целевого процесса

Мы рассмотрели случай, когда приложение получает доступ к своим TEB сегментам. Такая задача редко возникает на практике, потому что все переменные доступны по своим именам и их не нужно искать в сегментах стека и динамической памяти. С другой стороны благодаря этой упрощённой задаче, мы разобрались в устройстве сегмента TEB.

Теперь перейдём к реальной практической задаче и рассмотрим методы доступа к сегментам TEB и PEB целевого процесса. В качестве цели воспользуемся любым стандартным Windows приложением.

Для тестирования дальнейших примеров необходимо выполнить следующие шаги:

1. Запустить стандартное Windows приложение (например Notepad). Помните, что его разрядность совпадает с разрядностью Windows.
2. Прочитайте PID процесса приложения с помощью Task Manager.
3. Присвойте прочитанный PID переменной pid функции main в коде соответствующего примера:

1 DWORD pid = 5356;

4. Скомпилируйте пример.
5. Запустите его из командной строки с правами администратора.

После выполнения приложение напечатает результат в командную строку.

Повторение базового адреса TEB

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

1. Прочитать базовый адрес TEB сегмента главного потока текущего процесса.
2. Прочитать сегмент по этому же базовому адресу в адресном пространстве целевого процесса.

Листинг 3-8 демонстрирует реализацию этого алгоритма.

 1 #include <windows.h>
 2 #include <winternl.h>
 3 
 4 BOOL SetPrivilege(HANDLE hToken, LPCTSTR lpszPrivilege, BOOL bEnablePrivilege)
 5 {
 6     // Смотрите реализацию этой функции в листинге 3-1
 7 }
 8 
 9 BOOL GetMainThreadTeb(DWORD dwPid, PTEB pTeb)
10 {
11     LPVOID tebAddress = NtCurrentTeb();
12     printf("TEB = %p\n", tebAddress);
13 
14     HANDLE hProcess = OpenProcess(PROCESS_VM_READ, FALSE, dwPid);
15     if (hProcess == NULL)
16         return false;
17 
18     if (ReadProcessMemory(hProcess, tebAddress, pTeb, sizeof(TEB), NULL) == FALSE)
19     {
20         CloseHandle(hProcess);
21         return false;
22     }
23 
24     CloseHandle(hProcess);
25     return true;
26 }
27 
28 int main()
29 {
30     HANDLE hProc = GetCurrentProcess();
31 
32     HANDLE hToken = NULL;
33     if (!OpenProcessToken(hProc, TOKEN_ADJUST_PRIVILEGES, &hToken))
34         printf("Failed to open access token\n");
35 
36     if (!SetPrivilege(hToken, SE_DEBUG_NAME, TRUE))
37         printf("Failed to set debug privilege\n");
38 
39     DWORD pid = 7368;
40 
41     TEB teb;
42     if (!GetMainThreadTeb(pid, &teb))
43         printf("Failed to get TEB\n");
44 
45     printf("PEB = %p StackBase = %p\n", teb.ProcessEnvironmentBlock,
46            teb.Reserved1[1]);
47 
48     return 0;
49 }

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

• TEB
• PEB
• Сегмент стека главного потока

Мы использовали уже знакомый нам метод предоставления привилегии SE_DEBUG_NAME для маркера доступа текущего процесса с помощью WinAPI-функций OpenProcessToken и SetPrivilege. После этого вызывается функция GetMainThreadTeb, которая принимает входным параметром PID целевого процесса и возвращает указатель на структуру TEB. Алгоритм GetMainThreadTeb следующий:

1. Прочитать базовый адрес TEB сегмента текущего потока с помощью вызова NtCurrentTeb.
2. Получить дескриптор целевого процесса с правами доступа PROCESS_VM_READ. Для этого используется WinAPI-функция OpenProcess.
3. Прочитать структуру TEB целевого процесса с помощью вызова ReadProcessMemory.

В общем случае, при старте нового процесса Windows назначает базовый адрес сегмента TEB произвольно. Для 32-разрядных приложений этот адрес часто оказывается одним и тем же. Но для 64-разрядных приложений, он меняется при каждом запуске. Поэтому рассмотренный нами метод доступа к TEB не рекомендуется применять в реальных ботах. Благодаря своей простоте он хорош только в качестве обучающего примера.

Приложение из листинга 3-8 успешно справляется с однопоточными целевыми процессами. Может ли оно работать с многопоточными? Да, но для этого надо немного изменить его код. Приложение должно создавать столько же вспомогательных потоков, сколько имеет целевой процесс. Для каждого потока надо прочитать базовый адрес соответствующего TEB сегмента. Затем через эти адреса можно пытаться получить доступ к сегментам TEB целевого процесса.

Узнать число потоков в целевом процессе можно с помощью отладчика WinDbg или OllyDbg. Достаточно открыть его карту памяти и посчитать число TEB сегментов в ней.

Для всех примеров этой главы важно помнить, что разрядность целевого процесса и вашего приложения должна быть одинаковой. Чтобы выбрать разрядность компилируемого приложения в Visual Studio, укажите желаемую целевую архитектуру в элементе интерфейса “Solution Platforms” (платформы для решения).

Перебор всех потоков целевого процесса

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

WinAPI-функции прохода по списку активных потоков следующие:

• CreateToolhelp32Snapshot делает снимок текущего состояния системы со всеми запущенными процессам, их потоками, модулями и сегментами динамической памяти. В функцию можно передать PID целевого процесса, тогда в снимок попадёт только он и его ресурсы.
• Thread32First начинает перебор потоков в указанном снимке состояния системы. Функция записывает результат своей работы в структуру типа THREADENTRY32, переданную входным параметром по указателю. Эта структура содержит информацию о первом потоке в снимке.
• Thread32Next продолжает перебор потоков в указанном снимке. Имеет те же входные и выходные параметры, что и функция Thread32First.

Приложение TebPebTraverse.cpp из листинга 3-9 демонстрирует алгоритм перебора потоков.

 1 #include <windows.h>
 2 #include <tlhelp32.h>
 3 #include <winternl.h>
 4 
 5 #pragma comment(lib,"ntdll.lib")
 6 
 7 typedef struct _CLIENT_ID {
 8     // Смотрите определение этой структуры в листинге 3-7
 9 } CLIENT_ID, *PCLIENT_ID;
10 
11 typedef struct _THREAD_BASIC_INFORMATION {
12     // Смотрите определение этой структуры в листинге 3-7
13 } THREAD_BASIC_INFORMATION, *PTHREAD_BASIC_INFORMATION;
14 
15 typedef enum _THREADINFOCLASS2
16 {
17     // Смотрите определение этой структуры в листинге 3-7
18 }   THREADINFOCLASS2;
19 
20 PTEB GetTeb(HANDLE hThread)
21 {
22     THREAD_BASIC_INFORMATION threadInfo;
23     NTSTATUS result = NtQueryInformationThread(hThread,
24                                     (THREADINFOCLASS)ThreadBasicInformation,
25                                     &threadInfo, sizeof(threadInfo), NULL);
26     if (result)
27     {
28         printf("NtQueryInformationThread return error: %d\n", result);
29         return NULL;
30     }
31     return reinterpret_cast<PTEB>(threadInfo.TebBaseAddress);
32 }
33 
34 void ListProcessThreads(DWORD dwOwnerPID)
35 {
36     HANDLE hThreadSnap = INVALID_HANDLE_VALUE;
37     THREADENTRY32 te32;
38 
39     hThreadSnap = CreateToolhelp32Snapshot(TH32CS_SNAPTHREAD, 0);
40 
41     if (hThreadSnap == INVALID_HANDLE_VALUE)
42         return;
43 
44     te32.dwSize = sizeof(THREADENTRY32);
45 
46     if (!Thread32First(hThreadSnap, &te32))
47     {
48         CloseHandle(hThreadSnap);
49         return;
50     }
51 
52     DWORD result = 0;
53     do
54     {
55         if (te32.th32OwnerProcessID == dwOwnerPID)
56         {
57             printf("\n     THREAD ID = 0x%08X", te32.th32ThreadID);
58 
59             HANDLE hThread = OpenThread(THREAD_ALL_ACCESS, FALSE,
60                                         te32.th32ThreadID);
61             PTEB pTeb = GetTeb(hThread);
62             printf("\n     TEB = %p\n", pTeb);
63 
64             CloseHandle(hThread);
65         }
66     } while (Thread32Next(hThreadSnap, &te32));
67 
68     printf("\n");
69     CloseHandle(hThreadSnap);
70 }
71 
72 int main()
73 {
74     DWORD pid = 4792;
75 
76     ListProcessThreads(pid);
77 
78     return 0;
79 }