- 720
- 432
Тема для тех, кому интересен принцип работы античита, стоявшего на проекте весь 2023 и частично 2024 год.
- Как он работал в целом?
- Лаунчером в процесс игры встраивалась (инжектилась более корректный термин) DLL-библиотека, содержащая в себе различные системы проверки игры и ПК. Описанное в дальнейшем будет именоваться как "клиентский плагин или часть". На стороне SAMP-сервера находился специальный плагин, в дальнейшем именуемый - "серверный плагин или часть". Кроме того, была еще и аналитическая часть системы, которая принимала решения по автоматическим блокировкам, в дальнейшем именуется как "аналитическая часть". То есть, античит в целом представлял из себя комплексную систему.
- Какую роль исполнял "клиентский плагин"?
- Клиентский плагин на протяжении всей Вашей игры поддерживал сессионное соединение с аналитической частью, если клиентская часть не получала регулярного ответа от аналитической части, то после ряда попыток обменяться данными, клиент просто закрывал игру.
Клиентский плагин при старте игры отправлял запрос аналитической части на создании сессии, вместе с этим запросом отправлялся ряд данных Вашего ПК (Хэш CPU, HWID логистических дисков, MAC-адреса всех интернет-адаптеров, UUID всех учетных записей в системе, имена всех учетных записей, серийный номер материнской платы).
- Как "клиентский плагин" отслеживал встраивание читов в игру?
- Было несколько методов проверки, прежде всего это тупой перебор загруженных DLL-библиотек в процесс игры (gta_sa.exe), поиск определенных byte-паттернов в памяти процесса, сравнение целостности динамической памяти процесса игры, а так-же периодическое получение списка открытых окон для поиска известных читов по имени.
- Как "клиентский плагин" отличал легитимные DLL-библиотеки (по типу оверлея Discord) от запретных?
- "клиентский плагин" периодически отправлял на "аналитическую часть" информацию о загруженных DLL-библиотеках с приложением их имени, MD5-хэш суммы и информации о их подписи сертификатом кода. Наличие официальной подписи у DLL-библиотеки или MD5-хэш в базе разрешенных библиотек, позволял отличить запрещенные библиотеки от разрешенных.
- Что такое поиск byte-паттернов?
- Любая программа, библиотека или ещё что либо, представляют из себя набор байтов в шестнадцатеричном формате, если вскрыть любой из доступных читов, можно достаточно просто найти набор байтов произвольной длины который будет отличать этот чит от любого другого. При встраивании чита в процесс игры, он расширяет себе место в динамической памяти процесса игры и становится его составной частью. Отсюда можно просто сканировать всю динамическую память на поиск определенного набора байтов и при нахождении отправлять информацию о конкретном чите.
- Что такое целостность динамической памяти игры?
- Как было написано ранее, процесс игры и ее библиотеки представляют из себя единую часть в памяти. "Клиентский плагин" сохранял слепок всей памяти игры после запуска и в последствии периодически сравнивал текущий с истинным слепком. В "аналитической части" это именовалось аномальным участком памяти и использовалось для последующих решений о блокировке или закрытии игры.
- Как античит находил SAMPFUNCS-скрипты внутри игры, если они не являются полноценными DLL-библиотеками?
- С помощью неописанного в официальной документации метода SF_GetNextLoadedPlugin, мы получали список всех загруженных скриптов в игру и так-же отправляли отчет об этом на "аналитическую часть". Кроме того с помощью метода SF_DisableConsole скрывалась консоль, открываемая на клавишу ~ (источник).
- Как античит находил CLEO-скрипты?
- Самым глупым способом, простым перебором файлов с расширением .cs в папке клео.
- Как работала "аналитическая часть"?
- Эта часть представляла из себя базу данных со всеми отчетами игроков, активными и архивными сессиями, зарегистрированными пользователями и микро-сервис для принятия решений о блокировке, закрытии игры. Так как "клиентская часть" периодически отправляла отчеты о различных частях игры, системе не составляло труда сравнить различные данные и отправить команду о закрытии игры на "клиентскую часть".
- Как работала система сессий?
- После запуска игры "клиентская часть" отправляла запрос на создание сессии "аналитической части", далее перед появлением окна авторизации на сервере, "серверный плагин" через запрос "аналитической части" проверял наличие сессии и допускал к авторизации, если вкратце, то ник игрока перед заходом в игру изменялся на определенную MD5-хэш сумму состоящую из ника игрока, текущего timestamp и константной соли.
После успешной сверки этой хэш-суммы, игроку присваивался настоящий ник. У сессии были временные ограничения, чтобы не допустить обхода системы через копирование ника из окна со списком игроков на TAB.
- Как "аналитическая часть" блокировала игроков?
- Из отправленных данных о системе, частично или полностью по ним находился пользователь в таблице users и проверялась колонка banned. Как объяснял ранее potop`у, изменить один только MAC-адрес или HWID дисков было недостаточно, нужно было менять все данные комплексно для обхода блокировки.
- Как "аналитическая часть" общалась с "клиентской частью"?
- По принципам REST API, у сессии была активная страница на домене rockac.stalker-rp.net, к которой "клиентская часть" периодически отправляла запросы и по определенным кодам вызывала закрытие игры (источник).
Extra-вопросы:
- Почему extremecheats обходил проверки "клиентской части"?
- У любой DLL-библиотеки как и любой другой программы в Windows имеется определенный набор данных в самом начале кода называемый PE-заголовками. Метод инжектирования этого чита (Reflective Injection) удалял эти самые PE-заголовки и в дальнейшем не числился в списке DLL-библиотек, по просту представляя из себя участок dummy-кода. Такой код очень сложно найти в памяти процесса и осуществить это можно только через поиск определенных магических символов во всей памяти процесса, так как PE-заголовки все до единого содержат два константных символа MZ, с дальнейшим сравнением всех известных PE-заголовков с аномальными, либо через сканирование методом поиска byte-паттернов. Подробнее о поиске можно почитать в этой статье.
- RockAC написан на основе SAMPCAC?
- Нет, идея и реализация была задумана в декабре 2022 года (ранее были наработки в StalkerAnticheat.dll) и написана полностью своими силами.
- Если "клиентская часть" так активно общалась с "аналитической частью" значит пакеты можно было просто перехватить и изучить данные в них?
- Не совсем, так как вся отправляемая информация из "клиентской части" и в неё шифровалась при помощи публичного AES-ключа, меняющегося с каждой новой сборкой античита.
- Где найти исходный код системы?
- https://github.com/0z0sk0/rock-anticheat-client/
- Как он работал в целом?
- Лаунчером в процесс игры встраивалась (инжектилась более корректный термин) DLL-библиотека, содержащая в себе различные системы проверки игры и ПК. Описанное в дальнейшем будет именоваться как "клиентский плагин или часть". На стороне SAMP-сервера находился специальный плагин, в дальнейшем именуемый - "серверный плагин или часть". Кроме того, была еще и аналитическая часть системы, которая принимала решения по автоматическим блокировкам, в дальнейшем именуется как "аналитическая часть". То есть, античит в целом представлял из себя комплексную систему.
- Какую роль исполнял "клиентский плагин"?
- Клиентский плагин на протяжении всей Вашей игры поддерживал сессионное соединение с аналитической частью, если клиентская часть не получала регулярного ответа от аналитической части, то после ряда попыток обменяться данными, клиент просто закрывал игру.
Клиентский плагин при старте игры отправлял запрос аналитической части на создании сессии, вместе с этим запросом отправлялся ряд данных Вашего ПК (Хэш CPU, HWID логистических дисков, MAC-адреса всех интернет-адаптеров, UUID всех учетных записей в системе, имена всех учетных записей, серийный номер материнской платы).
- Как "клиентский плагин" отслеживал встраивание читов в игру?
- Было несколько методов проверки, прежде всего это тупой перебор загруженных DLL-библиотек в процесс игры (gta_sa.exe), поиск определенных byte-паттернов в памяти процесса, сравнение целостности динамической памяти процесса игры, а так-же периодическое получение списка открытых окон для поиска известных читов по имени.
- Как "клиентский плагин" отличал легитимные DLL-библиотеки (по типу оверлея Discord) от запретных?
- "клиентский плагин" периодически отправлял на "аналитическую часть" информацию о загруженных DLL-библиотеках с приложением их имени, MD5-хэш суммы и информации о их подписи сертификатом кода. Наличие официальной подписи у DLL-библиотеки или MD5-хэш в базе разрешенных библиотек, позволял отличить запрещенные библиотеки от разрешенных.
- Что такое поиск byte-паттернов?
- Любая программа, библиотека или ещё что либо, представляют из себя набор байтов в шестнадцатеричном формате, если вскрыть любой из доступных читов, можно достаточно просто найти набор байтов произвольной длины который будет отличать этот чит от любого другого. При встраивании чита в процесс игры, он расширяет себе место в динамической памяти процесса игры и становится его составной частью. Отсюда можно просто сканировать всю динамическую память на поиск определенного набора байтов и при нахождении отправлять информацию о конкретном чите.
- Что такое целостность динамической памяти игры?
- Как было написано ранее, процесс игры и ее библиотеки представляют из себя единую часть в памяти. "Клиентский плагин" сохранял слепок всей памяти игры после запуска и в последствии периодически сравнивал текущий с истинным слепком. В "аналитической части" это именовалось аномальным участком памяти и использовалось для последующих решений о блокировке или закрытии игры.
- Как античит находил SAMPFUNCS-скрипты внутри игры, если они не являются полноценными DLL-библиотеками?
- С помощью неописанного в официальной документации метода SF_GetNextLoadedPlugin, мы получали список всех загруженных скриптов в игру и так-же отправляли отчет об этом на "аналитическую часть". Кроме того с помощью метода SF_DisableConsole скрывалась консоль, открываемая на клавишу ~ (источник).
- Как античит находил CLEO-скрипты?
- Самым глупым способом, простым перебором файлов с расширением .cs в папке клео.
- Как работала "аналитическая часть"?
- Эта часть представляла из себя базу данных со всеми отчетами игроков, активными и архивными сессиями, зарегистрированными пользователями и микро-сервис для принятия решений о блокировке, закрытии игры. Так как "клиентская часть" периодически отправляла отчеты о различных частях игры, системе не составляло труда сравнить различные данные и отправить команду о закрытии игры на "клиентскую часть".
- Как работала система сессий?
- После запуска игры "клиентская часть" отправляла запрос на создание сессии "аналитической части", далее перед появлением окна авторизации на сервере, "серверный плагин" через запрос "аналитической части" проверял наличие сессии и допускал к авторизации, если вкратце, то ник игрока перед заходом в игру изменялся на определенную MD5-хэш сумму состоящую из ника игрока, текущего timestamp и константной соли.
После успешной сверки этой хэш-суммы, игроку присваивался настоящий ник. У сессии были временные ограничения, чтобы не допустить обхода системы через копирование ника из окна со списком игроков на TAB.
- Как "аналитическая часть" блокировала игроков?
- Из отправленных данных о системе, частично или полностью по ним находился пользователь в таблице users и проверялась колонка banned. Как объяснял ранее potop`у, изменить один только MAC-адрес или HWID дисков было недостаточно, нужно было менять все данные комплексно для обхода блокировки.
- Как "аналитическая часть" общалась с "клиентской частью"?
- По принципам REST API, у сессии была активная страница на домене rockac.stalker-rp.net, к которой "клиентская часть" периодически отправляла запросы и по определенным кодам вызывала закрытие игры (источник).
Extra-вопросы:
- Почему extremecheats обходил проверки "клиентской части"?
- У любой DLL-библиотеки как и любой другой программы в Windows имеется определенный набор данных в самом начале кода называемый PE-заголовками. Метод инжектирования этого чита (Reflective Injection) удалял эти самые PE-заголовки и в дальнейшем не числился в списке DLL-библиотек, по просту представляя из себя участок dummy-кода. Такой код очень сложно найти в памяти процесса и осуществить это можно только через поиск определенных магических символов во всей памяти процесса, так как PE-заголовки все до единого содержат два константных символа MZ, с дальнейшим сравнением всех известных PE-заголовков с аномальными, либо через сканирование методом поиска byte-паттернов. Подробнее о поиске можно почитать в этой статье.
- RockAC написан на основе SAMPCAC?
- Нет, идея и реализация была задумана в декабре 2022 года (ранее были наработки в StalkerAnticheat.dll) и написана полностью своими силами.
- Если "клиентская часть" так активно общалась с "аналитической частью" значит пакеты можно было просто перехватить и изучить данные в них?
- Не совсем, так как вся отправляемая информация из "клиентской части" и в неё шифровалась при помощи публичного AES-ключа, меняющегося с каждой новой сборкой античита.
- Где найти исходный код системы?
- https://github.com/0z0sk0/rock-anticheat-client/
Последнее редактирование:
