LasleyChao
Команда форума
LasleyChao
- 4 Апр 2019
- 1,775
- 13,684
Учимся взламывать игры и писать читы на простом примере
Компьютерные игры открывают перед нами новые миры. И мир читов — один из них. Сегодня мы вместе пройдем путь от теории к практике и напишем собственный чит. Если ты хочешь научиться взламывать исполняемые файлы, то это может стать неплохим упражнением.
Виды читов и применяемые тактики
Существуют разные виды читов. Можно разделить их на несколько групп.
Пишем игру на C
Про читы лучше всего рассказывать на практике. Мы напишем свою небольшую игру, на которой сможем потренироваться. Я буду писать игру на C#, но постараюсь максимально приблизить структуру данных к игре на C++. По моему опыту читерить в играх на C# очень просто.
Принцип игры прост: нажимаешь Enter и проигрываешь. Не особо честные правила, да? Попробуем их изменить.
Приступим к реверс-инжинирингу
Исполняемый файл игры
У нас есть файл игры. Но вместо исходного кода мы будем изучать память и поведение приложения.
Начнем с поведения игры
При каждом нажатии Enter жизни игрока уменьшаются на 15. Начальное количество жизней — 100.
Изучать память мы будем при помощи Cheat Engine. Это приложение для поиска переменных внутри памяти приложения, а еще хороший дебаггер. Перезапустим игру и подключим к ней Cheat Engine.
Подключение CE к игре
Первым делом мы получаем список всех значений 85 в памяти.
Все значения, которые нашел CE
Нажмем Enter, и показатель жизней будет равен 70. Отсеем все значения.
Значение найдено
Вот и нужное значение! Изменим его и нажмем 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-чита выглядит так:
Пишем внешний чит для своей игры
Для вызова функций WinAPI из C# используется технология P/Invoke. Для начала работы с этими функциями их нужно задекларировать в коде. Я буду брать готовые декларации с сайта pinvoke.net. Первой функцией будет OpenProcess.
[Flags]
public enum ProcessAccessFlags : uint
{
All = 0x001F0FFF,
Terminate = 0x00000001,
CreateThread = 0x00000002,
VirtualMemoryOperation = 0x00000008,
VirtualMemoryRead = 0x00000010,
VirtualMemoryWrite = 0x00000020,
DuplicateHandle = 0x00000040,
CreateProcess = 0x000000080,
SetQuota = 0x00000100,
SetInformation = 0x00000200,
QueryInformation = 0x00000400,
QueryLimitedInformation = 0x00001000,
Synchronize = 0x00100000
}
[DllImport("kernel32.dll", SetLastError = true)]
public static extern IntPtr OpenProcess(
ProcessAccessFlags processAccess,
bool bInheritHandle,
int processId);
Следующая функция — ReadProcessMemory.
[DllImport("kernel32.dll", SetLastError = true)]
public static extern bool ReadProcessMemory(
IntPtr hProcess,
IntPtr lpBaseAddress,
[Out] byte[] lpBuffer,
int dwSize,
out IntPtr lpNumberOfBytesRead);
Теперь функция для считывания памяти WriteProcessMemory.
[DllImport("kernel32.dll", SetLastError = true)]
public static extern bool WriteProcessMemory(
IntPtr hProcess,
IntPtr lpBaseAddress,
byte[] lpBuffer,
int nSize,
out IntPtr lpNumberOfBytesWritten);
Перед нами встает проблема: для поиска паттерна необходимо собрать все регионы памяти процесса. Для этого нам потребуются функция и структура. Функция VirtualQueryEx:
[DllImport("kernel32.dll")]
static extern int VirtualQueryEx(IntPtr hProcess, IntPtr lpAddress, out MEMORY_BASIC_INFORMATION lpBuffer, uint dwLength);
Структура MEMORY_BASIC_INFORMATION:
[StructLayout(LayoutKind.Sequential)]
public struct MEMORY_BASIC_INFORMATION
{
public IntPtr BaseAddress;
public IntPtr AllocationBase;
public uint AllocationProtect;
public IntPtr RegionSize;
public uint State;
public uint Protect;
public uint Type;
}
Теперь можно приступить к написанию кода для самого чита. Первым делом найдем игру.
private static int WaitForGame()
{
while (true)
{
var prcs = Process.GetProcessesByName("SimpleConsoleGame");
if (prcs.Length != 0)
{
return prcs.First().Id;
}
Thread.Sleep(150);
}
}
Затем откроем дескриптор к нашей игре.
private static IntPtr GetGameHandle(int id)
{
return WinAPI.OpenProcess(WinAPI.ProcessAccessFlags.All, false, id);
}
Совместим все это в начальном коде.
Console.Title = "External Cheat Example";
Console.ForegroundColor = ConsoleColor.White;
Console.WriteLine("Waiting for game process..");
var processId = WaitForGame();
Console.WriteLine($"Game process found. ID: {processId}");
var handle = GetGameHandle(processId);
if (handle == IntPtr.Zero)
{
CriticalError("Error. Process handle acquirement failed.\n" +
"Insufficient rights?");
}
Console.WriteLine($"Handle was acquired: 0x{handle.ToInt32():X}");
Console.ReadKey(true);
Мы найдем ID процесса, затем получим его дескриптор и, если что, выведем сообщение об ошибке. Имплементация CriticalError(string) не так важна.
После этого мы уже можем перейти к поиску паттерна в памяти. Создадим общий класс, в котором будут все функции для работы с памятью. Назовем его MemoryManager. Затем сделаем класс MemoryRegion для описания региона памяти. В MEMORY_BASIC_INFORMATION много лишних данных, которые не следует передавать дальше, поэтому я вынес их в отдельный класс.
public class MemoryRegion
{
public IntPtr BaseAddress { get; set; }
public IntPtr RegionSize { get; set; }
public uint Protect { get; set; }
}
Это все, что нам нужно: стартовый адрес региона, его размер и его защита. Теперь получим все регионы памяти. Как это делается?
long curr = 0;
var regions = new List<MemoryRegion>();
while (true) {
try {
var memDump = WinAPI.VirtualQueryEx(_processHandle, (IntPtr) curr, out var memInfo, 28);
if (memDump == 0) break;
if ((memInfo.State & 0x1000) != 0 && (memInfo.Protect & 0x100) == 0)
{
regions.Add(new MemoryRegion
{
BaseAddress = memInfo.BaseAddress,
RegionSize = memInfo.RegionSize,
Protect = memInfo.Protect
});
}
curr = (long) memInfo.BaseAddress + (long) memInfo.RegionSize;
} catch {
break;
}
}
return regions;
}
После получения регионов просканируем их на наличие нужного нам паттерна. Паттерн состоит из частей двух типов — известного и неизвестного (меняющийся байт): например, 00 ?? ?? FB. Создадим интерфейс для описания этих частей.
interface IMemoryPatternPart
{
bool Matches(byte b);
}
Теперь опишем ту часть, которая имеет известный байт.
public class MatchMemoryPatternPart : IMemoryPatternPart
{
public byte ValidByte { get; }
public MatchMemoryPatternPart(byte valid)
{
ValidByte = valid;
}
public bool Matches(byte b) => ValidByte == b;
}
То же самое провернем со вторым типом.
public class AnyMemoryPatternPart : IMemoryPatternPart
{
public bool Matches(byte b) => true;
}
Теперь сделаем парсинг паттерна из строки.
private void Parse(string pattern)
{
var parts = pattern.Split(' ');
_patternParts.Clear();
foreach (var part in parts)
{
if (part.Length != 2)
{
throw new Exception("Invalid pattern.");
}
if (part.Equals("??"))
{
_patternParts.Add(new AnyMemoryPatternPart());
continue;
}
if (!byte.TryParse(part, NumberStyles.HexNumber, null, out var result))
{
throw new Exception("Invalid pattern.");
}
_patternParts.Add(new MatchMemoryPatternPart(result));
}
}
Как уже делалось выше, проверяем, какой это тип части паттерна, парсим его, если необходимо, и добавляем в список. Надо проверить работу этого метода.
var p = new MemoryPattern("01 ?? 02 ?? 03 ?? FF");
Успех!
Теперь нам нужно научить наш MemoryManager читать память.
public byte[] ReadMemory(IntPtr addr, int size)
{
var buff = new byte[size];
return WinAPI.ReadProcessMemory(_processHandle, addr, buff, size, out _) ? buff : null;
}
Сначала я написал красивую функцию с использованием Linq для сканирования памяти. Но ее выполнение заняло много времени. Затем я переписал метод без использования этой технологии, и все заработало в разы быстрее. Результат оптимизированной функции:
Быстрое сканирование памяти
Результат оригинальной функции:
Очень медленное сканирование памяти
Теперь поделюсь обретенной на этом этапе мудростью: не бойся оптимизировать свой код. Библиотеки не всегда предоставляют самые быстрые решения. Оригинальная функция:
public IntPtr ScanForPatternInRegion(MemoryRegion region, MemoryPattern pattern)
{
var endAddr = (int) region.RegionSize - pattern.Size;
var wholeMemory = ReadMemory(region.BaseAddress, (int) region.RegionSize);
for (var addr = 0; addr < endAddr; addr++)
{
var b = wholeMemory.Skip(addr).Take(pattern.Size).ToArray();
if (!pattern.PatternParts.First().Matches(b.First()))
{
continue;
}
if (!pattern.PatternParts.Last().Matches(b.Last()))
{
continue;
}
var found = true;
for (var i = 1; i < pattern.Size - 1; i++)
{
if (!pattern.PatternParts.Matches(b))
{
found = false;
break;
}
}
if (!found)
{
continue;
}
return region.BaseAddress + addr;
}
return IntPtr.Zero;
}
Исправленная функция (просто используй Array.Copy()).
public IntPtr ScanForPatternInRegion(MemoryRegion region, MemoryPattern pattern)
{
var endAddr = (int) region.RegionSize - pattern.Size;
var wholeMemory = ReadMemory(region.BaseAddress, (int) region.RegionSize);
for (var addr = 0; addr < endAddr; addr++)
{
var buff = new byte[pattern.Size];
Array.Copy(wholeMemory, addr, buff, 0, buff.Length);
var found = true;
for (var i = 0; i < pattern.Size; i++)
{
if (!pattern.PatternParts.Matches(buff))
{
found = false;
break;
}
}
if (!found)
{
continue;
}
return region.BaseAddress + addr;
}
return IntPtr.Zero;
}
Эта функция ищет паттерн внутри региона памяти. Следующая функция использует ее для сканирования памяти всего процесса.
public IntPtr PatternScan(MemoryPattern pattern)
{
var regions = QueryMemoryRegions();
foreach (var memoryRegion in regions)
{
var addr = ScanForPatternInRegion(memoryRegion, pattern);
if (addr == IntPtr.Zero)
{
continue;
}
return addr;
}
return IntPtr.Zero;
}
Добавим две функции для считывания и записи 32-битного числа в память.
public int ReadInt32(IntPtr addr)
{
return BitConverter.ToInt32(ReadMemory(addr, 4), 0);
}
public void WriteInt32(IntPtr addr, int value)
{
var b = BitConverter.GetBytes(value);
WinAPI.WriteProcessMemory(_processHandle, addr, b, b.Length, out _);
}
Теперь все готово для поиска паттерна и написания основного кода чита.
var playerBase = memory.PatternScan(new MemoryPattern("ED 03 00 00 01 00 00 00"));
Находим паттерн в памяти, затем — адрес жизней игрока.
var playerHealth = playerBase + 24;
Считываем значение жизней:
Console.WriteLine($"Current health: {memory.ReadInt32(playerHealth)}");
Почему бы не дать игроку почти бесконечные жизни?
memory.WriteInt32(playerHealth, int.MaxValue);
И снова считаем жизни игрока для демонстрации.
Console.WriteLine($"New health: {memory.ReadInt32(playerHealth)}");
Проверяем
Запустим наш чит, потом запустим игру.
Все работает
Попробуем нажать Enter в «игре».
Жизни изменились
Чит работает!
Пишем свой первый инжектор
Есть много способов заставить процесс загрузить наш код. Можно использовать DLL Hijacking, можно SetWindowsHookEx, но мы начнем с самой простой и известной функции — LoadLibrary. LoadLibrary заставляет нужный нам процесс самостоятельно загрузить библиотеку.
Нам понадобится дескриптор с необходимыми правами. Начнем подготовку к инжекту. Сначала получим у пользователя имя библиотеки.
Console.Write("> Enter DLL name: ");
var dllName = Console.ReadLine();
if (string.IsNullOrEmpty(dllName) || !File.Exists(dllName))
{
Console.WriteLine("DLL name is invalid!");
Console.ReadLine();
return;
}
var fullPath = Path.GetFullPath(dllName);
Затем запросим у пользователя имя процесса и найдем его ID.
var fullPath = Path.GetFullPath(dllName);
var fullPathBytes = Encoding.ASCII.GetBytes(fullPath);
Console.Write("> Enter process name: ");
var processName = Console.ReadLine();
if (string.IsNullOrEmpty(dllName))
{
Console.WriteLine("Process name is invalid!");
Console.ReadLine();
return;
}
var prcs = Process.GetProcessesByName(processName);
if (prcs.Length == 0)
{
Console.WriteLine("Process wasn't found.");
Console.ReadLine();
return;
}
var prcId = prcs.First().Id;
У этого кода будут проблемы с процессами с одинаковыми именами.
Теперь можно перейти к первому методу инжекта.
Имплементируем LoadLibrary инжект
Для начала разберем принцип работы данного типа инжектора.
WWW
Сигнатуры можно запросто найти на pinvoke.net.
Первым делом откроем дескриптор с полным доступом к процессу.
var handle = WinAPI.OpenProcess(WinAPI.ProcessAccessFlags.All,
false,
processID);
if (handle == IntPtr.Zero)
{
Console.WriteLine("Can't open process.");
return;
}
Превратим нашу строку в байты.
var libraryPathBytes = Encoding.ASCII.GetBytes(libraryPath);
После необходимо выделить память для этой строки.
var memory = WinAPI.VirtualAllocEx(handle,
IntPtr.Zero,
256,
WinAPI.AllocationType.Commit | WinAPI.AllocationType.Reserve,
WinAPI.MemoryProtection.ExecuteReadWrite);
В функцию передается дескриптор процесса handle: _MAX_PATH (максимальный размер пути в Windows), он равен 256. Указываем, что в память можно записать, считать ее и выполнить. Записываем строку внутрь процесса.
WinAPI.WriteProcessMemory(handle, memory, libraryPathBytes, libraryPathBytes.Length, out var bytesWritten);
Так как мы будем использовать функцию LoadLibraryA для загрузки библиотеки, нам нужно получить ее адрес.
var funcAddr = WinAPI.GetProcAddress(WinAPI.GetModuleHandle("kernel32"), "LoadLibraryA");
Все готово для запуска процесса инжекта. Осталось лишь создать поток в удаленном приложении:
var thread = WinAPI.CreateRemoteThread(handle, IntPtr.Zero, IntPtr.Zero, funcAddr, memory, 0, IntPtr.Zero);
Инжектор готов, но проверять его будем только после написания простой библиотеки.
Пишем основу для internal
Переходим на C++! Начнем с точки входа и простого сообщения через WinAPI. Точка входа DLL должна принимать три параметра: HINSTANCE, DWORD, LPVOID.
#include <Windows.h>
BOOL WINAPI DllMain(
_In_ HINSTANCE hinstDLL,
_In_ DWORD fdwReason,
_In_ LPVOID lpvReserved
)
{
return 0;
}
Для начала проверим, почему вызывается точка входа.
if(fdwReason == DLL_PROCESS_ATTACH) { }
Аргумент fdwReason будет равен DLL_PROCESS_ATTACH, если библиотека только что была подключена к процессу, или DLL_PROCESS_DETACH, если она в процессе выгрузки. Для теста выведем сообщение:
if(fdwReason == DLL_PROCESS_ATTACH)
{
MessageBox(nullptr, "Hello world!", "", 0);
}
Теперь можем проверить инжектор и эту библиотеку. Запускаем инжектор, вводим имя библиотеки и процесса.
Библиотека загружена
Теперь напишем простой класс с синглтоном для красоты кода.
#pragma once
class internal_cheat
{
public:
static internal_cheat* get_instance();
void initialize();
void run();
private:
static internal_cheat* _instance;
bool was_initialized_ = false;
internal_cheat();
};
Теперь сам код. Конструктор по умолчанию и синглтон.
internal_cheat::internal_cheat() = default;
internal_cheat* internal_cheat::get_instance()
{
if(_instance == nullptr)
{
_instance = new internal_cheat();
}
return _instance;
}
Далее простой код точки входа.
#include <Windows.h>
#include "InternalCheat.h"
BOOL WINAPI DllMain(
_In_ HINSTANCE hinstDLL,
_In_ DWORD fdwReason,
_In_ LPVOID lpvReserved
)
{
if(fdwReason == DLL_PROCESS_ATTACH)
{
auto cheat = internal_cheat::get_instance();
cheat->initialize();
cheat->run();
}
return 0;
}
Должен сказать, что на следующую часть ушло больше всего времени. Одна маленькая ошибка привела к огромной трате времени. Но я сделал выводы и объясню тебе, где можно допустить такую ошибку и как ее обнаружить.
Нам нужно найти паттерн внутри памяти игры. Для этого сначала мы переберем все регионы памяти приложения, затем просканируем каждый из них. Ниже представлена имплементация получения списка регионов памяти, но только для собственного процесса. Я объяснил принцип ее работы ранее.
DWORD internal_cheat::find_pattern(std::string pattern)
{
auto mbi = MEMORY_BASIC_INFORMATION();
DWORD curr_addr = 0;
while(true)
{
if(VirtualQuery(reinterpret_cast<const void*>(curr_addr), &mbi, sizeof mbi) == 0)
{
break;
}
if((mbi.State == MEM_COMMIT || mbi.State == MEM_RESERVE) &&
(mbi.Protect == PAGE_READONLY ||
mbi.Protect == PAGE_READWRITE ||
mbi.Protect == PAGE_EXECUTE_READ ||
mbi.Protect == PAGE_EXECUTE_READWRITE))
{
auto result = find_pattern_in_range(pattern, reinterpret_cast<DWORD>(mbi.BaseAddress), reinterpret_cast<DWORD>(mbi.BaseAddress) + mbi.RegionSize);
if(result != NULL)
{
return result;
}
}
curr_addr += mbi.RegionSize;
}
return NULL;
}
Для каждого найденного региона этот код вызывает функцию find_pattern_in_range, которая ищет паттерн в этом регионе.
DWORD internal_cheat::find_pattern_in_range(std::string pattern, const DWORD range_start, const DWORD range_end)
{
auto strstream = istringstream(pattern);
vector<int> values;
string s;
Сначала функция парсит паттерн.
while (getline(strstream, s, ' '))
{
if (s.find("??") != std::string::npos)
{
values.push_back(-1);
continue;
}
auto parsed = stoi(s, 0, 16);
values.push_back(parsed);
}
Затем начинает и само сканирование.
for(auto p_cur = range_start; p_cur < range_end; p_cur++ )
{
auto localAddr = p_cur;
auto found = true;
for (auto value : values)
{
if(value == -1)
{
localAddr += 1;
continue;
}
auto neededValue = static_cast<char>(value);
auto pCurrentValue = reinterpret_cast<char*>(localAddr);
auto currentValue = *pCurrentValue;
if(neededValue != currentValue)
{
found = false;
break;
}
localAddr += 1;
}
if(found)
{
return p_cur;
}
}
return NULL;
}
Я использовал вектор из int, чтобы хранить данные о паттерне, -1 означает, что там может находиться любой байт. Сделал я это, чтобы упростить поиск паттерна, ускорить его и не переводить один и тот же код из внешнего чита.
Теперь несколько слов про ошибку, о которой я говорил ранее. Я постоянно переписывал функцию поиска паттерна, пока не решил взглянуть на функцию поиска регионов памяти. Проблема была в том, что я сравнивал защиту памяти совсем неправильно. Первоначальная версия:
if((mbi.State == MEM_COMMIT || mbi.State == MEM_RESERVE) &&
(mbi.Protect == PAGE_EXECUTE_READ ||
mbi.Protect == PAGE_EXECUTE_READWRITE)) { }
Код принимал только страницы с читаемой/исполняемой памятью и читаемой/записываемой/исполняемой памятью. Остальные же он игнорировал. Код был изменен на такой:
if((mbi.State == MEM_COMMIT || mbi.State == MEM_RESERVE) &&
(mbi.Protect == PAGE_READONLY ||
mbi.Protect == PAGE_READWRITE ||
mbi.Protect == PAGE_EXECUTE_READ ||
mbi.Protect == PAGE_EXECUTE_READWRITE)) { }
Эта функция начала находить все нужные страницы памяти.
INFO
PAGE_READONLY может вызвать критическую ошибку во время записи данных, у нас всегда есть VirtualProtect.
Обнаружил же я эту ошибку, когда начал проверять страницы памяти в приложении при помощи Process Hacker и Cheat Engine. Мой паттерн оказался в одном из самых первых регионов памяти с защитой от исполнения, поэтому он никогда не находился.
Теперь же, найдя паттерн, мы можем сохранить его в поле нашего класса.
void internal_cheat::initialize()
{
if(was_initialized_)
{
return;
}
printf("\n\n[CHEAT] Cheat was loaded! Initializing..\n");
was_initialized_ = true;
player_base_ = reinterpret_cast<void*>(find_pattern("ED 03 00 00 01 00 00 00"));
printf("[CHEAT] Found playerbase at 0x%p\n", player_base_);
}
После этого будет вызвана функция internal_cheat::run(), которая и должна выполнять все функции чита.
void internal_cheat::run()
{
printf("[CHEAT] Cheat is now running.\n");
const auto player_health = reinterpret_cast<int*>(reinterpret_cast<DWORD>(player_base_) + 7);
while(true)
{
*player_health = INT_MAX;
Sleep(100);
}
}
Мы просто получаем адрес жизней игрока от нашего паттерна и устанавливаем их на максимальное значение (INT_MAX) каждые 100 мс.
Проверяем наш чит
Запускаем игру, инжектим библиотеку.
Чит заинжекчен
Попробуем нажать пару раз кнопку Enter.
Чит работает
Наши жизни не изменяются и все прекрасно работает!
Подведем итоги
Любой элемент игры, который обрабатывается на нашем компьютере, может быть модифицирован или вовсе удален. К сожалению или к счастью, игровые компании не всегда заботятся об античите, открывая дорогу нам, читерам.
Компьютерные игры открывают перед нами новые миры. И мир читов — один из них. Сегодня мы вместе пройдем путь от теории к практике и напишем собственный чит. Если ты хочешь научиться взламывать исполняемые файлы, то это может стать неплохим упражнением.
Виды читов и применяемые тактики
Существуют разные виды читов. Можно разделить их на несколько групп.
- External — внешние читы, которые работают в отдельном процессе. Если же мы скроем наш external-чит, загрузив его в память другого процесса, он превратится в hidden external.
- Internal — внутренние читы, которые встраиваются в процесс самой игры при помощи инжектора. После загрузки в память игры в отдельном потоке вызывается точка входа чита.
- Pixelscan — вид читов, который использует картинку с экрана и паттерны расположения пикселей, чтобы получить необходимую информацию от игры.
- Network proxy — читы, которые используют сетевые прокси, те, в свою очередь, перехватывают трафик клиента и сервера, получая или изменяя необходимую информацию.
- Изменение памяти игры. API операционной системы используется для поиска и изменения участков памяти, содержащих нужную нам информацию (например, жизни, патроны).
- Симуляция действий игрока: приложение повторяет действия игрока, нажимая мышкой в заранее указанных местах.
- Перехват трафика игры. Между игрой и сервером встает чит. Он перехватывает данные, собирая или изменяя информацию, чтобы обмануть клиент или сервер.
Пишем игру на C
Про читы лучше всего рассказывать на практике. Мы напишем свою небольшую игру, на которой сможем потренироваться. Я буду писать игру на C#, но постараюсь максимально приблизить структуру данных к игре на C++. По моему опыту читерить в играх на C# очень просто.
Принцип игры прост: нажимаешь Enter и проигрываешь. Не особо честные правила, да? Попробуем их изменить.
Приступим к реверс-инжинирингу
Исполняемый файл игры
У нас есть файл игры. Но вместо исходного кода мы будем изучать память и поведение приложения.
Начнем с поведения игры
При каждом нажатии Enter жизни игрока уменьшаются на 15. Начальное количество жизней — 100.
Изучать память мы будем при помощи Cheat Engine. Это приложение для поиска переменных внутри памяти приложения, а еще хороший дебаггер. Перезапустим игру и подключим к ней Cheat Engine.
Подключение CE к игре
Первым делом мы получаем список всех значений 85 в памяти.
Все значения, которые нашел CE
Нажмем Enter, и показатель жизней будет равен 70. Отсеем все значения.
Значение найдено
Вот и нужное значение! Изменим его и нажмем 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-чита выглядит так:
- Найти ID процесса.
- Получить дескриптор к этому процессу с нужными правами.
- Найти адреса в памяти.
- Пропатчить что-то, если нужно.
- Отрисовать GUI, если он имеется.
- Считывать или изменять память по мере надобности.
Пишем внешний чит для своей игры
Для вызова функций WinAPI из C# используется технология P/Invoke. Для начала работы с этими функциями их нужно задекларировать в коде. Я буду брать готовые декларации с сайта pinvoke.net. Первой функцией будет OpenProcess.
[Flags]
public enum ProcessAccessFlags : uint
{
All = 0x001F0FFF,
Terminate = 0x00000001,
CreateThread = 0x00000002,
VirtualMemoryOperation = 0x00000008,
VirtualMemoryRead = 0x00000010,
VirtualMemoryWrite = 0x00000020,
DuplicateHandle = 0x00000040,
CreateProcess = 0x000000080,
SetQuota = 0x00000100,
SetInformation = 0x00000200,
QueryInformation = 0x00000400,
QueryLimitedInformation = 0x00001000,
Synchronize = 0x00100000
}
[DllImport("kernel32.dll", SetLastError = true)]
public static extern IntPtr OpenProcess(
ProcessAccessFlags processAccess,
bool bInheritHandle,
int processId);
Следующая функция — ReadProcessMemory.
[DllImport("kernel32.dll", SetLastError = true)]
public static extern bool ReadProcessMemory(
IntPtr hProcess,
IntPtr lpBaseAddress,
[Out] byte[] lpBuffer,
int dwSize,
out IntPtr lpNumberOfBytesRead);
Теперь функция для считывания памяти WriteProcessMemory.
[DllImport("kernel32.dll", SetLastError = true)]
public static extern bool WriteProcessMemory(
IntPtr hProcess,
IntPtr lpBaseAddress,
byte[] lpBuffer,
int nSize,
out IntPtr lpNumberOfBytesWritten);
Перед нами встает проблема: для поиска паттерна необходимо собрать все регионы памяти процесса. Для этого нам потребуются функция и структура. Функция VirtualQueryEx:
[DllImport("kernel32.dll")]
static extern int VirtualQueryEx(IntPtr hProcess, IntPtr lpAddress, out MEMORY_BASIC_INFORMATION lpBuffer, uint dwLength);
Структура MEMORY_BASIC_INFORMATION:
[StructLayout(LayoutKind.Sequential)]
public struct MEMORY_BASIC_INFORMATION
{
public IntPtr BaseAddress;
public IntPtr AllocationBase;
public uint AllocationProtect;
public IntPtr RegionSize;
public uint State;
public uint Protect;
public uint Type;
}
Теперь можно приступить к написанию кода для самого чита. Первым делом найдем игру.
private static int WaitForGame()
{
while (true)
{
var prcs = Process.GetProcessesByName("SimpleConsoleGame");
if (prcs.Length != 0)
{
return prcs.First().Id;
}
Thread.Sleep(150);
}
}
Затем откроем дескриптор к нашей игре.
private static IntPtr GetGameHandle(int id)
{
return WinAPI.OpenProcess(WinAPI.ProcessAccessFlags.All, false, id);
}
Совместим все это в начальном коде.
Console.Title = "External Cheat Example";
Console.ForegroundColor = ConsoleColor.White;
Console.WriteLine("Waiting for game process..");
var processId = WaitForGame();
Console.WriteLine($"Game process found. ID: {processId}");
var handle = GetGameHandle(processId);
if (handle == IntPtr.Zero)
{
CriticalError("Error. Process handle acquirement failed.\n" +
"Insufficient rights?");
}
Console.WriteLine($"Handle was acquired: 0x{handle.ToInt32():X}");
Console.ReadKey(true);
Мы найдем ID процесса, затем получим его дескриптор и, если что, выведем сообщение об ошибке. Имплементация CriticalError(string) не так важна.
После этого мы уже можем перейти к поиску паттерна в памяти. Создадим общий класс, в котором будут все функции для работы с памятью. Назовем его MemoryManager. Затем сделаем класс MemoryRegion для описания региона памяти. В MEMORY_BASIC_INFORMATION много лишних данных, которые не следует передавать дальше, поэтому я вынес их в отдельный класс.
public class MemoryRegion
{
public IntPtr BaseAddress { get; set; }
public IntPtr RegionSize { get; set; }
public uint Protect { get; set; }
}
Это все, что нам нужно: стартовый адрес региона, его размер и его защита. Теперь получим все регионы памяти. Как это делается?
- Получаем информацию о регионе памяти на нулевом адресе.
- Проверяем статус и защиту региона. Если все в порядке — добавляем его в список.
- Получаем информацию о следующем регионе.
- Проверяем и добавляем его в список.
- Продолжаем по кругу.
long curr = 0;
var regions = new List<MemoryRegion>();
while (true) {
try {
var memDump = WinAPI.VirtualQueryEx(_processHandle, (IntPtr) curr, out var memInfo, 28);
if (memDump == 0) break;
if ((memInfo.State & 0x1000) != 0 && (memInfo.Protect & 0x100) == 0)
{
regions.Add(new MemoryRegion
{
BaseAddress = memInfo.BaseAddress,
RegionSize = memInfo.RegionSize,
Protect = memInfo.Protect
});
}
curr = (long) memInfo.BaseAddress + (long) memInfo.RegionSize;
} catch {
break;
}
}
return regions;
}
После получения регионов просканируем их на наличие нужного нам паттерна. Паттерн состоит из частей двух типов — известного и неизвестного (меняющийся байт): например, 00 ?? ?? FB. Создадим интерфейс для описания этих частей.
interface IMemoryPatternPart
{
bool Matches(byte b);
}
Теперь опишем ту часть, которая имеет известный байт.
public class MatchMemoryPatternPart : IMemoryPatternPart
{
public byte ValidByte { get; }
public MatchMemoryPatternPart(byte valid)
{
ValidByte = valid;
}
public bool Matches(byte b) => ValidByte == b;
}
То же самое провернем со вторым типом.
public class AnyMemoryPatternPart : IMemoryPatternPart
{
public bool Matches(byte b) => true;
}
Теперь сделаем парсинг паттерна из строки.
private void Parse(string pattern)
{
var parts = pattern.Split(' ');
_patternParts.Clear();
foreach (var part in parts)
{
if (part.Length != 2)
{
throw new Exception("Invalid pattern.");
}
if (part.Equals("??"))
{
_patternParts.Add(new AnyMemoryPatternPart());
continue;
}
if (!byte.TryParse(part, NumberStyles.HexNumber, null, out var result))
{
throw new Exception("Invalid pattern.");
}
_patternParts.Add(new MatchMemoryPatternPart(result));
}
}
Как уже делалось выше, проверяем, какой это тип части паттерна, парсим его, если необходимо, и добавляем в список. Надо проверить работу этого метода.
var p = new MemoryPattern("01 ?? 02 ?? 03 ?? FF");
Успех!
Теперь нам нужно научить наш MemoryManager читать память.
public byte[] ReadMemory(IntPtr addr, int size)
{
var buff = new byte[size];
return WinAPI.ReadProcessMemory(_processHandle, addr, buff, size, out _) ? buff : null;
}
Сначала я написал красивую функцию с использованием Linq для сканирования памяти. Но ее выполнение заняло много времени. Затем я переписал метод без использования этой технологии, и все заработало в разы быстрее. Результат оптимизированной функции:
Быстрое сканирование памяти
Результат оригинальной функции:
Очень медленное сканирование памяти
Теперь поделюсь обретенной на этом этапе мудростью: не бойся оптимизировать свой код. Библиотеки не всегда предоставляют самые быстрые решения. Оригинальная функция:
public IntPtr ScanForPatternInRegion(MemoryRegion region, MemoryPattern pattern)
{
var endAddr = (int) region.RegionSize - pattern.Size;
var wholeMemory = ReadMemory(region.BaseAddress, (int) region.RegionSize);
for (var addr = 0; addr < endAddr; addr++)
{
var b = wholeMemory.Skip(addr).Take(pattern.Size).ToArray();
if (!pattern.PatternParts.First().Matches(b.First()))
{
continue;
}
if (!pattern.PatternParts.Last().Matches(b.Last()))
{
continue;
}
var found = true;
for (var i = 1; i < pattern.Size - 1; i++)
{
if (!pattern.PatternParts.Matches(b))
{
found = false;
break;
}
}
if (!found)
{
continue;
}
return region.BaseAddress + addr;
}
return IntPtr.Zero;
}
Исправленная функция (просто используй Array.Copy()).
public IntPtr ScanForPatternInRegion(MemoryRegion region, MemoryPattern pattern)
{
var endAddr = (int) region.RegionSize - pattern.Size;
var wholeMemory = ReadMemory(region.BaseAddress, (int) region.RegionSize);
for (var addr = 0; addr < endAddr; addr++)
{
var buff = new byte[pattern.Size];
Array.Copy(wholeMemory, addr, buff, 0, buff.Length);
var found = true;
for (var i = 0; i < pattern.Size; i++)
{
if (!pattern.PatternParts.Matches(buff))
{
found = false;
break;
}
}
if (!found)
{
continue;
}
return region.BaseAddress + addr;
}
return IntPtr.Zero;
}
Эта функция ищет паттерн внутри региона памяти. Следующая функция использует ее для сканирования памяти всего процесса.
public IntPtr PatternScan(MemoryPattern pattern)
{
var regions = QueryMemoryRegions();
foreach (var memoryRegion in regions)
{
var addr = ScanForPatternInRegion(memoryRegion, pattern);
if (addr == IntPtr.Zero)
{
continue;
}
return addr;
}
return IntPtr.Zero;
}
Добавим две функции для считывания и записи 32-битного числа в память.
public int ReadInt32(IntPtr addr)
{
return BitConverter.ToInt32(ReadMemory(addr, 4), 0);
}
public void WriteInt32(IntPtr addr, int value)
{
var b = BitConverter.GetBytes(value);
WinAPI.WriteProcessMemory(_processHandle, addr, b, b.Length, out _);
}
Теперь все готово для поиска паттерна и написания основного кода чита.
var playerBase = memory.PatternScan(new MemoryPattern("ED 03 00 00 01 00 00 00"));
Находим паттерн в памяти, затем — адрес жизней игрока.
var playerHealth = playerBase + 24;
Считываем значение жизней:
Console.WriteLine($"Current health: {memory.ReadInt32(playerHealth)}");
Почему бы не дать игроку почти бесконечные жизни?
memory.WriteInt32(playerHealth, int.MaxValue);
И снова считаем жизни игрока для демонстрации.
Console.WriteLine($"New health: {memory.ReadInt32(playerHealth)}");
Проверяем
Запустим наш чит, потом запустим игру.
Все работает
Попробуем нажать Enter в «игре».
Жизни изменились
Чит работает!
Пишем свой первый инжектор
Есть много способов заставить процесс загрузить наш код. Можно использовать DLL Hijacking, можно SetWindowsHookEx, но мы начнем с самой простой и известной функции — LoadLibrary. LoadLibrary заставляет нужный нам процесс самостоятельно загрузить библиотеку.
Нам понадобится дескриптор с необходимыми правами. Начнем подготовку к инжекту. Сначала получим у пользователя имя библиотеки.
Console.Write("> Enter DLL name: ");
var dllName = Console.ReadLine();
if (string.IsNullOrEmpty(dllName) || !File.Exists(dllName))
{
Console.WriteLine("DLL name is invalid!");
Console.ReadLine();
return;
}
var fullPath = Path.GetFullPath(dllName);
Затем запросим у пользователя имя процесса и найдем его ID.
var fullPath = Path.GetFullPath(dllName);
var fullPathBytes = Encoding.ASCII.GetBytes(fullPath);
Console.Write("> Enter process name: ");
var processName = Console.ReadLine();
if (string.IsNullOrEmpty(dllName))
{
Console.WriteLine("Process name is invalid!");
Console.ReadLine();
return;
}
var prcs = Process.GetProcessesByName(processName);
if (prcs.Length == 0)
{
Console.WriteLine("Process wasn't found.");
Console.ReadLine();
return;
}
var prcId = prcs.First().Id;
У этого кода будут проблемы с процессами с одинаковыми именами.
Теперь можно перейти к первому методу инжекта.
Имплементируем LoadLibrary инжект
Для начала разберем принцип работы данного типа инжектора.
- Сначала он считывает полный путь до библиотеки с диска.
- Собирает ее в строку. Затем мы получаем адрес LoadLibraryA(LPCSTR) при помощи GetProcAddress(HMODULE, LPCSTR).
- Выделяет память для строки внутри приложения, записывает ее туда.
- После создает поток по адресу LoadLibraryA, передавая путь в аргументе.
- Для работы укажем импорты OpenProcess, ReadProcessMemory, WriteProcessMemory, GetProcAddress, GetModuleHandle, CreateRemoteThread, VirtualAllocEx.
WWW
Сигнатуры можно запросто найти на pinvoke.net.
Первым делом откроем дескриптор с полным доступом к процессу.
var handle = WinAPI.OpenProcess(WinAPI.ProcessAccessFlags.All,
false,
processID);
if (handle == IntPtr.Zero)
{
Console.WriteLine("Can't open process.");
return;
}
Превратим нашу строку в байты.
var libraryPathBytes = Encoding.ASCII.GetBytes(libraryPath);
После необходимо выделить память для этой строки.
var memory = WinAPI.VirtualAllocEx(handle,
IntPtr.Zero,
256,
WinAPI.AllocationType.Commit | WinAPI.AllocationType.Reserve,
WinAPI.MemoryProtection.ExecuteReadWrite);
В функцию передается дескриптор процесса handle: _MAX_PATH (максимальный размер пути в Windows), он равен 256. Указываем, что в память можно записать, считать ее и выполнить. Записываем строку внутрь процесса.
WinAPI.WriteProcessMemory(handle, memory, libraryPathBytes, libraryPathBytes.Length, out var bytesWritten);
Так как мы будем использовать функцию LoadLibraryA для загрузки библиотеки, нам нужно получить ее адрес.
var funcAddr = WinAPI.GetProcAddress(WinAPI.GetModuleHandle("kernel32"), "LoadLibraryA");
Все готово для запуска процесса инжекта. Осталось лишь создать поток в удаленном приложении:
var thread = WinAPI.CreateRemoteThread(handle, IntPtr.Zero, IntPtr.Zero, funcAddr, memory, 0, IntPtr.Zero);
Инжектор готов, но проверять его будем только после написания простой библиотеки.
Пишем основу для internal
Переходим на C++! Начнем с точки входа и простого сообщения через WinAPI. Точка входа DLL должна принимать три параметра: HINSTANCE, DWORD, LPVOID.
- HINSTANCE — ссылается на библиотеку.
- DWORD — это причина вызова точки входа (загрузка и выгрузка DLL).
- LPVOID — зарезервированное значение.
#include <Windows.h>
BOOL WINAPI DllMain(
_In_ HINSTANCE hinstDLL,
_In_ DWORD fdwReason,
_In_ LPVOID lpvReserved
)
{
return 0;
}
Для начала проверим, почему вызывается точка входа.
if(fdwReason == DLL_PROCESS_ATTACH) { }
Аргумент fdwReason будет равен DLL_PROCESS_ATTACH, если библиотека только что была подключена к процессу, или DLL_PROCESS_DETACH, если она в процессе выгрузки. Для теста выведем сообщение:
if(fdwReason == DLL_PROCESS_ATTACH)
{
MessageBox(nullptr, "Hello world!", "", 0);
}
Теперь можем проверить инжектор и эту библиотеку. Запускаем инжектор, вводим имя библиотеки и процесса.
Библиотека загружена
Теперь напишем простой класс с синглтоном для красоты кода.
#pragma once
class internal_cheat
{
public:
static internal_cheat* get_instance();
void initialize();
void run();
private:
static internal_cheat* _instance;
bool was_initialized_ = false;
internal_cheat();
};
Теперь сам код. Конструктор по умолчанию и синглтон.
internal_cheat::internal_cheat() = default;
internal_cheat* internal_cheat::get_instance()
{
if(_instance == nullptr)
{
_instance = new internal_cheat();
}
return _instance;
}
Далее простой код точки входа.
#include <Windows.h>
#include "InternalCheat.h"
BOOL WINAPI DllMain(
_In_ HINSTANCE hinstDLL,
_In_ DWORD fdwReason,
_In_ LPVOID lpvReserved
)
{
if(fdwReason == DLL_PROCESS_ATTACH)
{
auto cheat = internal_cheat::get_instance();
cheat->initialize();
cheat->run();
}
return 0;
}
Должен сказать, что на следующую часть ушло больше всего времени. Одна маленькая ошибка привела к огромной трате времени. Но я сделал выводы и объясню тебе, где можно допустить такую ошибку и как ее обнаружить.
Нам нужно найти паттерн внутри памяти игры. Для этого сначала мы переберем все регионы памяти приложения, затем просканируем каждый из них. Ниже представлена имплементация получения списка регионов памяти, но только для собственного процесса. Я объяснил принцип ее работы ранее.
DWORD internal_cheat::find_pattern(std::string pattern)
{
auto mbi = MEMORY_BASIC_INFORMATION();
DWORD curr_addr = 0;
while(true)
{
if(VirtualQuery(reinterpret_cast<const void*>(curr_addr), &mbi, sizeof mbi) == 0)
{
break;
}
if((mbi.State == MEM_COMMIT || mbi.State == MEM_RESERVE) &&
(mbi.Protect == PAGE_READONLY ||
mbi.Protect == PAGE_READWRITE ||
mbi.Protect == PAGE_EXECUTE_READ ||
mbi.Protect == PAGE_EXECUTE_READWRITE))
{
auto result = find_pattern_in_range(pattern, reinterpret_cast<DWORD>(mbi.BaseAddress), reinterpret_cast<DWORD>(mbi.BaseAddress) + mbi.RegionSize);
if(result != NULL)
{
return result;
}
}
curr_addr += mbi.RegionSize;
}
return NULL;
}
Для каждого найденного региона этот код вызывает функцию find_pattern_in_range, которая ищет паттерн в этом регионе.
DWORD internal_cheat::find_pattern_in_range(std::string pattern, const DWORD range_start, const DWORD range_end)
{
auto strstream = istringstream(pattern);
vector<int> values;
string s;
Сначала функция парсит паттерн.
while (getline(strstream, s, ' '))
{
if (s.find("??") != std::string::npos)
{
values.push_back(-1);
continue;
}
auto parsed = stoi(s, 0, 16);
values.push_back(parsed);
}
Затем начинает и само сканирование.
for(auto p_cur = range_start; p_cur < range_end; p_cur++ )
{
auto localAddr = p_cur;
auto found = true;
for (auto value : values)
{
if(value == -1)
{
localAddr += 1;
continue;
}
auto neededValue = static_cast<char>(value);
auto pCurrentValue = reinterpret_cast<char*>(localAddr);
auto currentValue = *pCurrentValue;
if(neededValue != currentValue)
{
found = false;
break;
}
localAddr += 1;
}
if(found)
{
return p_cur;
}
}
return NULL;
}
Я использовал вектор из int, чтобы хранить данные о паттерне, -1 означает, что там может находиться любой байт. Сделал я это, чтобы упростить поиск паттерна, ускорить его и не переводить один и тот же код из внешнего чита.
Теперь несколько слов про ошибку, о которой я говорил ранее. Я постоянно переписывал функцию поиска паттерна, пока не решил взглянуть на функцию поиска регионов памяти. Проблема была в том, что я сравнивал защиту памяти совсем неправильно. Первоначальная версия:
if((mbi.State == MEM_COMMIT || mbi.State == MEM_RESERVE) &&
(mbi.Protect == PAGE_EXECUTE_READ ||
mbi.Protect == PAGE_EXECUTE_READWRITE)) { }
Код принимал только страницы с читаемой/исполняемой памятью и читаемой/записываемой/исполняемой памятью. Остальные же он игнорировал. Код был изменен на такой:
if((mbi.State == MEM_COMMIT || mbi.State == MEM_RESERVE) &&
(mbi.Protect == PAGE_READONLY ||
mbi.Protect == PAGE_READWRITE ||
mbi.Protect == PAGE_EXECUTE_READ ||
mbi.Protect == PAGE_EXECUTE_READWRITE)) { }
Эта функция начала находить все нужные страницы памяти.
INFO
PAGE_READONLY может вызвать критическую ошибку во время записи данных, у нас всегда есть VirtualProtect.
Обнаружил же я эту ошибку, когда начал проверять страницы памяти в приложении при помощи Process Hacker и Cheat Engine. Мой паттерн оказался в одном из самых первых регионов памяти с защитой от исполнения, поэтому он никогда не находился.
Теперь же, найдя паттерн, мы можем сохранить его в поле нашего класса.
void internal_cheat::initialize()
{
if(was_initialized_)
{
return;
}
printf("\n\n[CHEAT] Cheat was loaded! Initializing..\n");
was_initialized_ = true;
player_base_ = reinterpret_cast<void*>(find_pattern("ED 03 00 00 01 00 00 00"));
printf("[CHEAT] Found playerbase at 0x%p\n", player_base_);
}
После этого будет вызвана функция internal_cheat::run(), которая и должна выполнять все функции чита.
void internal_cheat::run()
{
printf("[CHEAT] Cheat is now running.\n");
const auto player_health = reinterpret_cast<int*>(reinterpret_cast<DWORD>(player_base_) + 7);
while(true)
{
*player_health = INT_MAX;
Sleep(100);
}
}
Мы просто получаем адрес жизней игрока от нашего паттерна и устанавливаем их на максимальное значение (INT_MAX) каждые 100 мс.
Проверяем наш чит
Запускаем игру, инжектим библиотеку.
Чит заинжекчен
Попробуем нажать пару раз кнопку Enter.
Чит работает
Наши жизни не изменяются и все прекрасно работает!
Подведем итоги
Любой элемент игры, который обрабатывается на нашем компьютере, может быть модифицирован или вовсе удален. К сожалению или к счастью, игровые компании не всегда заботятся об античите, открывая дорогу нам, читерам.
