Как писать читы для игр

Как писать читы для игр

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

РЕКОМЕНДУЕМ:
Взлом игр Unity на примере игры Poker World

Виды читов и применяемые тактики

Существуют разные виды читов для игр. Можно разделить их на несколько групп.

  • External — внешние читы, которые работают в отдельном процессе. Если же мы скроем наш external-чит, загрузив его в память другого процесса, он превратится в hidden external.
  • Internal — внутренние читы, которые встраиваются в процесс самой игры при помощи инжектора. После загрузки в память игры в отдельном потоке вызывается точка входа чита.
  • Pixelscan — вид читов, который использует картинку с экрана и паттерны расположения пикселей, чтобы получить необходимую информацию от игры.
  • Network proxy — читы, которые используют сетевые прокси, те, в свою очередь, перехватывают трафик клиента и сервера, получая или изменяя необходимую информацию.

Есть три основные тактики модификации поведения игры.

  1. Изменение памяти игры. API операционной системы используется для поиска и изменения участков памяти, содержащих нужную нам информацию (например, жизни, патроны).
  2. Симуляция действий игрока: приложение повторяет действия игрока, нажимая мышкой в заранее указанных местах.
  3. Перехват трафика игры. Между игрой и сервером встает чит. Он перехватывает данные, собирая или изменяя информацию, чтобы обмануть клиент или сервер.

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

Пишем игру на C

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

Принцип игры прост: нажимаете Enter и проигрываете. Не особо честные правила, да? Попробуем их изменить.

Приступим к реверс-инжинирингу

Исполняемый файл игры
Исполняемый файл игры

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

Начнем с поведения игры
Начнем с поведения игры

При каждом нажатии Enter жизни игрока уменьшаются на 15. Начальное количество жизней — 100.

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

Подключение CE к игре
Подключение CE к игре

Первым делом мы получаем список всех значений 85 в памяти.

Все значения, которые нашел CE
Все значения, которые нашел CE

Нажмем Enter, и показатель жизней будет равен 70. Отсеем все значения.

Значение найдено
Значение найдено

Вот и нужное значение! Изменим его и нажмем Enter для проверки результата.

Значение изменено
Значение изменено
Скрин игры, после того как мы нажали Enter
Скрин игры, после того как мы нажали Enter

Проблема в том, что после перезапуска игры значение будет уже по другому адресу. Каждый раз отсеивать его нет никакого смысла. Необходимо прибегнуть к сканированию AOB (Array Of Bytes — массив байтов).

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

После нескольких нажатий на Enter количество жизней изменилось на 55. Снова найдем нужное значение в памяти и откроем регион, в котором оно находится.

Регион памяти
Регион памяти

Выделенный байт и есть начало нашего int32-числа. 37 00 00 00 — число 55 в десятичной форме.

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

Начинаем сравнивать байты
Начинаем сравнивать байты

Проверим байты перед структурой.

Бинго! Как писать читы для игр
Бинго!

Как видите, выделенные байты не изменились, значит, можно попробовать использовать их как сигнатуру. Чем меньше сигнатура, тем быстрее пройдет сканирование. Сигнатура 01 00 00 00 явно будет слишком часто встречаться в памяти. Лучше взять 03 00 00 01 00 00 00. Для начала найдем ее в памяти.

Сигнатура не уникальна
Сигнатура не уникальна

Сигнатура найдена, но она повторяется. Необходима более уникальная последовательность. Попробуем ED 03 00 00 01 00 00 00.

В подтверждение уникальности получим такой результат:

Сигнатура уникальна
Сигнатура уникальна

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

Жизненный цикл external

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

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

  1. Найти ID процесса.
  2. Получить дескриптор к этому процессу с нужными правами.
  3. Найти адреса в памяти.
  4. Пропатчить что-то, если нужно.
  5. Отрисовать GUI, если он имеется.
  6. Считывать или изменять память по мере надобности.

Пишем внешний чит для своей игры

Для вызова функций WinAPI из C# используется технология P/Invoke. Для начала работы с этими функциями их нужно задекларировать в коде. Я буду брать готовые декларации с сайта pinvoke.net. Первой функцией будет OpenProcess.

Следующая функция — ReadProcessMemory.

Теперь функция для считывания памяти WriteProcessMemory.

Перед нами встает проблема: для поиска паттерна необходимо собрать все регионы памяти процесса. Для этого нам потребуются функция и структура. Функция VirtualQueryEx:

Структура MEMORY_BASIC_INFORMATION:

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

Затем откроем дескриптор к нашей игре.

Совместим все это в начальном коде.

Мы найдем ID процесса, затем получим его дескриптор и, если что, выведем сообщение об ошибке. Имплементация CriticalError(string) не так важна.

РЕКОМЕНДУЕМ:
Лучшие игры для программистов и айтишников

После этого мы уже можем перейти к поиску паттерна в памяти. Создадим общий класс, в котором будут все функции для работы с памятью. Назовем его MemoryManager. Затем сделаем класс MemoryRegion для описания региона памяти. В MEMORY_BASIC_INFORMATION много лишних данных, которые не следует передавать дальше, поэтому я вынес их в отдельный класс.

Это все, что нам нужно: стартовый адрес региона, его размер и его защита. Теперь получим все регионы памяти. Как это делается?

  1. Получаем информацию о регионе памяти на нулевом адресе.
  2. Проверяем статус и защиту региона. Если все в порядке — добавляем его в список.
  3. Получаем информацию о следующем регионе.
  4. Проверяем и добавляем его в список.
  5. Продолжаем по кругу.

После получения регионов просканируем их на наличие нужного нам паттерна. Паттерн состоит из частей двух типов — известного и неизвестного (меняющийся байт): например, 00 ?? ?? FB. Создадим интерфейс для описания этих частей.

Теперь опишем ту часть, которая имеет известный байт.

То же самое провернем со вторым типом.

Теперь сделаем парсинг паттерна из строки.

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

Как писать читы
Успех!

Теперь нам нужно научить наш MemoryManager читать память.

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

Быстрое сканирование памяти
Быстрое сканирование памяти

Результат оригинальной функции:

Очень медленное сканирование памяти
Очень медленное сканирование памяти

Теперь поделюсь обретенной на этом этапе мудростью: не бойтесь оптимизировать свой код. Библиотеки не всегда предоставляют самые быстрые решения. Оригинальная функция:

Исправленная функция (просто используй Array.Copy()).

Эта функция ищет паттерн внутри региона памяти. Следующая функция использует ее для сканирования памяти всего процесса.

Добавим две функции для считывания и записи 32-битного числа в память.

Теперь все готово для поиска паттерна и написания основного кода чита.

Находим паттерн в памяти, затем — адрес жизней игрока.

Считываем значение жизней:

Почему бы не дать игроку почти бесконечные жизни?

И снова считаем жизни игрока для демонстрации.

Проверяем

Запустим наш чит, потом запустим игру.

Чит работает
Все работает

Попробуем нажать Enter в «игре».

Жизни с помощью чита изменились
Жизни изменились

Чит работает!

Пишем свой первый инжектор

Есть много способов заставить процесс загрузить наш код. Можно использовать DLL Hijacking, можно SetWindowsHookEx, но мы начнем с самой простой и известной функции — LoadLibrary. LoadLibrary заставляет нужный нам процесс самостоятельно загрузить библиотеку.

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

Затем запросим у пользователя имя процесса и найдем его ID.

У этого кода будут проблемы с процессами с одинаковыми именами.

Теперь можно перейти к первому методу инжекта.

Имплементируем LoadLibrary инжект

Для начала разберем принцип работы данного типа инжектора.

  1. Сначала он считывает полный путь до библиотеки с диска.
  2. Собирает ее в строку. Затем мы получаем адрес LoadLibraryA(LPCSTR) при помощи GetProcAddress(HMODULE, LPCSTR).
  3. Выделяет память для строки внутри приложения, записывает ее туда.
  4. После создает поток по адресу LoadLibraryA, передавая путь в аргументе.
  5. Для работы укажем импорты OpenProcess, ReadProcessMemory, WriteProcessMemory, GetProcAddress, GetModuleHandle, CreateRemoteThread, VirtualAllocEx.

Сигнатуры можно запросто найти на pinvoke.net.

Первым делом откроем дескриптор с полным доступом к процессу.

Превратим нашу строку в байты.

После необходимо выделить память для этой строки.

В функцию передается дескриптор процесса handle: _MAX_PATH (максимальный размер пути в Windows), он равен 256. Указываем, что в память можно записать, считать ее и выполнить. Записываем строку внутрь процесса.

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

Все готово для запуска процесса инжекта. Осталось лишь создать поток в удаленном приложении:

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

Пишем основу для internal

Переходим на C++! Начнем с точки входа и простого сообщения через WinAPI. Точка входа DLL должна принимать три параметра: HINSTANCE, DWORD, LPVOID.

  • HINSTANCE — ссылается на библиотеку.
  • DWORD — это причина вызова точки входа (загрузка и выгрузка DLL).
  • LPVOID — зарезервированное значение.

Так выглядит пустая точка входа библиотеки:

Для начала проверим, почему вызывается точка входа.

Аргумент fdwReason будет равен DLL_PROCESS_ATTACH, если библиотека только что была подключена к процессу, или DLL_PROCESS_DETACH, если она в процессе выгрузки. Для теста выведем сообщение:

Теперь можем проверить инжектор и эту библиотеку. Запускаем инжектор, вводим имя библиотеки и процесса.

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

Теперь напишем простой класс с синглтоном для красоты кода.

Теперь сам код. Конструктор по умолчанию и синглтон.

Далее простой код точки входа.

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

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

Для каждого найденного региона этот код вызывает функцию find_pattern_in_range, которая ищет паттерн в этом регионе.

Сначала функция парсит паттерн.

Затем начинает и само сканирование.

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

Теперь несколько слов про ошибку, о которой я говорил ранее. Я постоянно переписывал функцию поиска паттерна, пока не решил взглянуть на функцию поиска регионов памяти. Проблема была в том, что я сравнивал защиту памяти совсем неправильно. Первоначальная версия:

Код принимал только страницы с читаемой/исполняемой памятью и читаемой/записываемой/исполняемой памятью. Остальные же он игнорировал. Код был изменен на такой:

Эта функция начала находить все нужные страницы памяти.

PAGE_READONLY может вызвать критическую ошибку во время записи данных, у нас всегда есть VirtualProtect.

Обнаружил же я эту ошибку, когда начал проверять страницы памяти в приложении при помощи Process Hacker и Cheat Engine. Мой паттерн оказался в одном из самых первых регионов памяти с защитой от исполнения, поэтому он никогда не находился.

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

После этого будет вызвана функция internal_cheat::run(), которая и должна выполнять все функции чита.

Мы просто получаем адрес жизней игрока от нашего паттерна и устанавливаем их на максимальное значение ( INT_MAX) каждые 100 мс.

Проверяем наш чит

Запускаем игру, инжектим библиотеку.

Созданный чит заинжекчен
Чит заинжекчен

Попробуем нажать пару раз кнопку Enter.

Чит работает
Чит работает

Наши жизни не изменяются и все прекрасно работает!

Подведем итоги

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

Понравилась статья? Поделиться с друзьями:
Комментарии: 3
  1. Илья

    Очень интересная статья, спасибо!

  2. Некта

    я может профтыкал, но где описание класса MemoryPattern?

  3. Crusader

    В какой 55 десятичной форме? 37 — это в шестнадцатеричной системе счисления.

Добавить комментарий