Как писать читы на c
Перейти к содержимому

Как писать читы на c

Как писать читы на c

Completing the CAPTCHA proves you are a human and gives you temporary access to the web property.

What can I do to prevent this in the future?

If you are on a personal connection, like at home, you can run an anti-virus scan on your device to make sure it is not infected with malware.

If you are at an office or shared network, you can ask the network administrator to run a scan across the network looking for misconfigured or infected devices.

Another way to prevent getting this page in the future is to use Privacy Pass. You may need to download version 2.0 now from the Chrome Web Store.

Cloudflare Ray ID: 71a81fc14e52918e • Your IP : 82.102.23.104 • Performance & security by Cloudflare

CS Source кратко о создании чита All in One

Решил поделиться, с Вами, своим небольшим опытом создании чита для Counter-Strike Source v34. Данное приложение было написано исключительно ради спортивного интереса(служит, исключительно, для ознакомления), так как в годы своей юности (изрядно убил времени за этой игрой :() всегда интересовало как же устроены эти программы, хотя теоретически знал как они работают. И вот спустя пол десятка лет (в 2010 году), после игры с коллегами в канун одного из праздников я опять вспомнил о своем давнем *интересе*…

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

Видео записалось с низким фпс, извиняюсь — камтазия, а так никаких фризов модуль не вызывает.

И так, для начала нам понадобится:
Microsoft DirectX — менюшки, есп, имя, хелсы, кросхайр рисовать.
Microsoft Detours — как нетрудно догадаться для подмены вызовов, как собрать и работать с данной либой есть на хабре , я на этом останавливаться не буду.
Source SDK — SDK CSS оно облегчит нам процесс.

Приступим. Создаем новый проект из Source SDK. Удаляем весь хлам в нем — все *.cpp, они нам не нужны.
И так в точке входа создаем свой виток, в котором запускаем бесконечный цикл (для хоткеев) и подменяем вызовы DX:

DllMain.cpp

А вот и самая грязная функция, она то и подменяет вызовы CSS:

Как вы помните мы переопредилили вызов iEndScene, которым и воспользуемся для отрисовки menu, esp, wallHack и Anti flash/smoke/fog:

Для wallHack и Anti то/се нам требуется получит материалы:

И говорим рисуем/игнорируем их или нет:

Переопределенной функцией new_CreateMove воспользуемся для aimBot и, совсем забыл, bunnyHop:

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

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

И так перейдем к инъекции нашей сборки в процесс игры, 2 варианта c++ по хендлу окна или c# по процессу

Это читерство! Учимся взламывать игры и писать читы на простом примере

Это читерство! Учимся взламывать игры и писать читы на простом примере, изображение №1

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

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

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

  • 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 к игре

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

Нажмем 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-чита выглядит так:

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

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

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

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

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

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

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

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

Мы найдем 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 , передавая путь в аргументе.

Для работы необходимо указать импорты OpenProcess , ReadProcessMemory , WriteProcessMemory , GetProcAddress , GetModuleHandle , CreateRemoteThread , VirtualAllocEx .

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

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

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

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

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

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

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

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

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

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

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

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

Ваш адрес email не будет опубликован. Обязательные поля помечены *