Что такое battleye в unturned

Обновлено: 04.07.2024

Ребят скажите пожалуйста что такое battleye anti-cheat хотел скачать игру вообщем скачал потом мне вылезло окошко об установление battleye anti cheat я отменил установление етого но оно установилось и после етого оно помоему както повлеяло на игру unturned потомучто не получается заходить на сервере через кнопку conect и ищет не те сервера как раньше подскажите пожалуйста что такое battleye anti cheat и как его удалить

и да battleye anti cheat вот ето появилось когда я скачивал игру со стима Paladins®

Что такое battleye в unturned

11 ноя. 2016 в 15:28

So within the first. Mmm.. 15 hours or so we already have people complaining about BattlEye. For those that don't know, battleEye is a anti-cheat client, meant for banning, well, cheaters! Recently with hundreds of complaints of cheaters, and cheating getting more popular in the unturned community, even rivaling 2.0's cheating, this addition couldn't be better. The problem is, people are having an increase of problems with launching, and playing the game.

I'm having a decrease in frame rate! It's BattlEye! Wahh!

First off, get rid of all modifications to the game. Less to worry about. You could even go in the files and completely delete them.

Second, verify the integrity of your game's cache. You can do this by right clicking unturned in your library, clicking, properties, files, and clicking that tasty button right there.

Third, lower your settings. You don't need things like foliage or clouds, and having a 90 degree FoV isn't that bad unless you get nauseous with that.

Fourth, and last, don't having 100 programs running at a single time. Run unturned, steam, maybe chrome, maybe discord, and no more. This is less for your computer to run, and more focus and the toast at hand.

can't launch the game! It's BattlEye! Wahh!

Following the steps for the first question may already fix that, but if it dosent, redownload unturned, and if you have to, restart your computer. It may help.

I got banned for no reason! Stupid BattlEye! Wahh!

If you got banned, tough luck. You may have had mischievous files in your game, or your running suspicious programs, in which you will have to make a new steam account.

If you really weren't cheating, that sucks. But nothing will really change, so get a new account, and be more careful this time.

remove BattlEye! Bad feature! Wahh!

No. This is beneficial to unturned, and is supposed to filter out cheaters. It's for the best.

Реверс-инжиниринг популярного античита BattlEye


BattlEye — это преимущетвенно немецкий сторонний античит, в основном разрабатываемый 32-летним Бастианом Хейко Сутером. Он предоставляет (или пытается предоставить) издателям игр простую в применении систему античита, использующую механизмы общей защиты, а также обнаружение читов для конкретных игр для оптимизации безопасности. Как сказано на веб-сайте продукта, он всегда остаётся на вершине современных технологий и использует инновационные методики защиты и обнаружения; очевидно, это следствие национальности разработчика: QUALITY MADE IN GERMANY . BattlEye состоит из множества элементов, совместно работающих над поиском читеров в играх, оплативших использование продукта. Четырьмя основными элементами являются:

  • BEService
    • Системная служба Windows, обменивающаяся данными с сервером BattlEye BEServer, который обеспечивает возможности клиент-серверной связи с BEDaisy и BEClient.
    • Драйвер ядра Windows, регистрирующий превентивные механизмы обработки событий и мини-фильтры, чтобы препятствовать читерам в незаконном изменении игры
    • Динамически подключаемая библиотека Windows, отвечающая за большинство векторов обнаружения, в том числе за описанные в данной статье. После инициализации она привязывается к процессу игры.
    • Проприетарный бэкенд-сервер, отвечающий за сбор информации и принятие конкретных мер против читеров.

    Обход по стеку BattlEye

    Взлом игр — постоянная игра в кошки-мышки, поэтому слухи о новых приёмах распространяются как пожар. В этой части мы рассмотрим новые эвристические техники, которые недавно добавил в свой арсенал крупный поставщик античитов BattlEye. Чаще всего эти техники называют обходом по стеку (stack walking). Обычно они реализуются обработкой функции и проходом по стеку, чтобы выяснить, кто же конкретно вызвал эту функцию. Зачем это нужно делать? Как и любая другая программа, хаки видеоигр имеют набор хорошо известных функций, которые они используют для получения информации от клавиатуры, вывода в консоль или вычисления определённых математических выражений. Кроме того, хаки видеоигр любят скрывать своё существование, будь то в памяти или на диске, чтобы античитерское ПО их не нашло. Но что забывают читерские программы, так это то, что регулярно вызывают функции из других библиотек, и это можно использовать для эвристического обнаружения неизвестных читов. Реализовав движок обхода по стеку для таких функций, как std::print , мы сможем найти эти читы, даже если они маскируются.

    BattlEye реализовал «обход по стеку», несмотря на то, что публично об этом не заявлялось и на момент выпуска статьи оставалось только слухами. Обратите внимание на кавычки — то, что вы здесь увидите, на самом деле не настоящий обход по стеку, а просто сочетание проверки обратного адреса и дампа вызывающей программы. Настоящая реализация обхода по стеку проходила бы по стеку и генерировала настоящий стек вызовов.

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

    Один из таких шелл-кодов BattlEye отвечает за выполнение этого анализа стека; мы будем называет его shellcode8kb, потому что он немного меньше по сравнению с shellcodemain, который я задокументировал здесь. Этот небольшой шелл-код при помощи функции AddVectoredExceptionHandler подготавливает векторизированный обработчик исключений, а затем устанавливает ловушки прерываний на следующих функциях:

    GetAsyncKeyState
    GetCursorPos
    IsBadReadPtr
    NtUserGetAsyncKeyState
    GetForegroundWindow
    CallWindowProcW
    NtUserPeekMessage
    NtSetEvent
    sqrtf
    __stdio_common_vsprintf_s
    CDXGIFactory::TakeLock
    TppTimerpExecuteCallback

    Для этого он просто итеративно обходит список стандартно используемых функций, присваивая первую инструкцию соответствующей функции значение int3, которое используется как точка останова. После установки точки останова все вызовы соответствующей функции проходят через обработчик исключений, имеющий полный доступ к регистрам и стеку. Имея этот доступ, обработчик исключений создаёт дамп адреса вызывающей программы из вершины стека, и в случае выполнения одного из эвристических условий 32 байта вызывающей функции дампятся и отправляются на сервера BattlEye с идентификатором отчёта 0x31:


    Как мы видим, обработчик исключений выполняет дамп всех вызывающих функций в случае бесцеремонного изменения страницы памяти или когда функция не принадлежит к известному модулю процесса (тип страницы памяти MEM_IMAGE не задан manualmapper-ами). Также он выполняет дамп вызывающих функций, когда не удаётся вызвать NtQueryVirtualMemory, чтобы читы не привязывались к этому системному вызову и не скрывали свой модуль от дампера стека. Последнее условие на самом деле довольно интересное, оно помечает все вызывающие функции, использующие гаджет jmp qword ptr [rbx] — способ, применяемый для «спуфинга обратного адреса». Он выпущен моим коллегой-участником тайного клуба с ником namazso. Похоже, разработчики BattlEye увидели, что люди пользуются этим способом спуфинга в их играх и решили нацелиться непосредственно на него. Здесь стоит упомянуть, что описанный namazsos способ работает хорошо, достаточно просто использовать другой гаджет, или полностью отличающийся, или просто другой регистр — это не важно.

    Совет разработчикам BattlEye: используемый вами для поиска CDXGIFactory::TakeLock в памяти неверен, потому что вы (случайно или намеренно) включили CC padding, который сильно отличается при каждой компиляции. Для максимальной совместимости нужно убрать padding (первый байт в сигнатуре) и так вы скорее всего поймаете больше читеров :)

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

    Перебирание памяти

    Самый распространённый механизм обнаружения в античитах — это перебирание (memory enumeration) и сканирование памяти для поиска известных образов читов. Он легко реализуем и, как показало прошлое, при правильном подходе достаточно эффективен, если вы не забыли основы ассемблера и занесли в чёрный список пролог общей функции.

    Battleye перебирает всё адресное пространство процесса игры (текущего процесса в данном контексте) и выполняет различные проверки на предмет исполняемости страницы и нахождения за пределами соответствующего пространства памяти шелл-кода.

    Вот как это реализовано в Battleye:

    Шелл-код


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

    BattlEye предположительно выполняет потоковую передачу шелл-кода со своего сервера в службу Windows под названием BEService. Эта служба обменивается данными с модулем BEClient, расположенным внутри процесса игры. Обмен данными выполняется через конвейер \.namedpipeBattleye и до 2018 года был незашифрованным. Теперь все передаваемые данные шифруются xor-шифровальщиком с очень маленькими ключами, из-за чего чрезвычайно просто выполнять известные атаки на основе открытых текстов (plaintext attacks). Когда шелл-код передаётся клиенту, он располагается и выполняется за пределами всех известных модулей, из-за чего его легко определить. Для создания дампа шелл-кода можно или обрабатывать стандартные функции Windows API типа CreateFile, ReadFile и т.п., и выполнять дамп соответствующей области памяти всех вызывающих модулей (запрашивая информацию о памяти по возвращаемому адресу), находящихся за пределами всех известных модулей, или периодически сканировать пространство виртуальной памяти игры в поисках исполняемой памяти за пределами всех известных модулей, и дампить её на диск. При этом нужно отслеживать, дамп каких областей уже был выполнен, чтобы в результате не получилось множество одинаковых дампов.

    Объяснение

    Представленные в статье фрагменты псевдокода сильно модифицированы ради красоты. Вы не сможете сдампить шелл-код BattlEye и сразу же узнать эти части; шелл-код не содержит вызовов функций, а многие алгоритмы в статье развёрнуты. Но на самом деле это не важно, потому что когда вы закончите читать об этом ужасном античите, вам представится возможность обойти его (:

    Аномалии памяти

    BattlEye помечает все аномалии в адресном пространстве памяти, в основном памяти исполняемых модулей, не соответствующей загруженному образу:

    Сканирование в поисках паттернов

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

    При чтении этого псевдокода вы можете догадаться, что эти проверки можно обойти переписыванием области кода каждого загруженного модуля, так как они не будут выполнять сканирования в поисках паттернов в известных образах. Чтобы не попасть на проверки целостности, нужно загружать все упакованные и помещённые в белый список области и переписывать области кода, помеченные как RWX, потому что мы не можем выполнять проверки целостности без эмуляции упаковщика. В текущей версии шелл-кода BattlEye эти паттерны памяти жёстко прописаны:


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

    Чего мы не увидим, так это того, что BattlEye также динамически выполняет потоковую передачу паттернов из BEServer и отправляет их в BEClient, но в статье мы рассматривать это не будем.

    Они итеративно сканируются следующим алгоритмом:

    Проверки образов

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

    Sleep delta

    Кроме того, BattlEye может запрашивать у текущего потока одну секунду бездействия и измеряет разность количества циклов до и после бездействия (sleep):

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

    Проверка конкретных модулей (Microsoft)

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

    Перебирание окон

    Шелл-код BattlEye перебирает каждое из текущих видимых во время работы игры окон, обходя окна сверху вниз (по z-значению). Дескрипторы окон, находящиеся внутри процесса игры, исключаются из этого перебора, и это определяется вызовом GetWindowThreadProcessId . Следовательно, можно привязать соответствующую функцию к ложному владельцу окна, чтобы BattlEye не проверял ваше окно.

    Перебирание процессов

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

    Проверка конкретных модулей (неизвестных)

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


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

    Дополнение: @how02 сообщил нам, что модуль action_x64.dll имеет метку времени 0x5B12C900 и содержит область кода, в которую можно выполнять запись; как и говорилось ранее, это можно использовать для эксплойта.

    Аномалия при перебирании

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

    Защита памяти

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

    Проверка пути

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


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


    Если клиент не может открыть дескриптор с соответствующими правами QueryLimitedInformation , то он установит бит флага 0x04 , если причина ошибки при сбое вызова OpenProcess не равна ERROR_ACCESS_DENIED , что даёт нам последний контейнер перечисления для соответствующего значения флага:


    Если родительским процессом является steam, то пользователю мгновенно устанавливается флаг и об этом сообщается серверу с id уведомления 0x40

    Заголовки окон

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

    Уровень аппаратных абстракций

    BattlEye проверяет наличие динамически подключаемой библиотеки уровня аппаратных абстракций Windows (hal.dll), и сообщает серверу, загружена ли она внутри процесса игры.

    Различные уведомления

    BattlEye собирает различную информацию и отправляет её серверу с id уведомления 3C . Эта информация состоит из следующих элементов:

    • Любое окно с флагом WS_EX_TOPMOST или его аналогами:
      • Текст окна (Unicode)
      • Имя класса окна (Unicode)
      • Window style
      • Window extended style
      • Прямоугольник окна
      • Путь к образу процесса-владельца
      • Размер образа процесса-владельца
      • Имя образа
      • Путь к образу
      • Размер образа
      • Доступ к дескриптору
      • ….ContentPaksTslGame-WindowsNoEditor_assets_world.pak
      • ….ContentPaksTslGame-WindowsNoEditor_ui.pak
      • ….ContentPaksTslGame-WindowsNoEditor_sound.pak
      • ….BLGameCookedContentScriptBLGame.u
      • Выполняются все инструкции перехода (E9), и адрес назначения записывается в лог

      Имя образа

      Если процесс соответствует любому из множества представленных ниже критериев, то вам мгновенно устанавливается флаг и об этом сообщается серверу с id уведомления 0x38

      Проверка сети

      Перебор таблицы TCP по-прежнему работает, но после того, как я выпустил предыдущий анализ, критикующий разработчиков за пометку флагами IP-адресов Cloudflare, они всё-таки убрали эту проверку. Античит всё равно сообщает о порте, который использует для соединения xera.ph, но разработчики добавили новую проверку, чтобы определять, есть ли у процесса с соединением активная защита (предположительно, это выполняется при помощи обработчика).


      Благодарю IChooseYou и abstract

      Оверлей игр Steam

      BattlEye отслеживает процесс оверлея игр Steam, отвечающий за внутриигровой оверлей, известный большинству пользователей Steam. Полное имя хоста оверлея игр Steam — gameoverlayui.exe ; известно, что его часто используют для эксплойтов рендеринга, потому что довольно легко взломать и выполнять незаконную отрисовку в окне игры. Проверка имеет следующее условие:


      Дальнейшие проверки, специфичные для оверлея игр Steam, практически аналогичны процедурам, выполняемым для самого процесса игры, поэтому в псевдокоде пропущены.

      NoEye

      В BattlEye реализована довольно ленивая проверка обнаружения публично доступного руткита для обхода этого античита под названием NoEye: система при помощи GetFileAttributesExA проверяет размер файла BE_DLL.dll , если эта библиотека найдена на диске.

      Сканирование памяти оверлея игр Steam

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


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

      Защита процесса оверлея игр Steam

      Если процесс оверлея игр Steam защищён какой-нибудь защитой процессов Windows наподобие Light (WinTcb), то сервер получит об этом уведомление.


      Кроме того, если соответствующий вызов OpenProcess к процессу оверлея возвращает ERROR_ACCESS_DENIED, то о пользователе высылается уведомление с id 3B .

      Перебирание модулей

      Модули процесса оверлея игр Steam тоже перебираются, в частности, ищутся vgui2_s.dll и gameoverlayui.dll . Для этих модулей выполняется несколько проверок, начиная с gameoverlayui.dll .

      Если выполняется это условие: [gameoverlayui.dll+6C779] == 08BE55DC3CCCCB8. C3CCCCCC , то шелл-код сканирует vtable по адресу, хранящемуся в байтах . . Если любой из этих элементов vtable находится за пределами исходного модуля gameoverlayui.dll или указывает на инструкцию int 3 , то о пользователе сообщается на сервер с id уведомления 3B .


      Для модуля vgui2_s.dll тоже выполняется специфическая процедура проверки:


      Данная процедура проверяет наличие изменений по смещению 48378 , которое является расположением области кода:


      Затем процедура проверяет наличие очень специфического и кажущегося мусорным изменения:


      Нам не удалось найти копию vgui2_s.dll, не соответствующую первой из двух вышеприведённых проверок, поэтому не можем узнать, какую vtable она проверяет.

      Наличие драйверов

      Проверяется наличие устройств Beep и Null; в случае их наличия создаётся уведомление. В обычном состоянии эти два устройства не доступны в системе, и это может говорить о том, что кто-то вручную включил устройство. Такая техника называется driver device hijacking. Это делается для того, чтобы обеспечить обмен данными IOCTL с зловредным драйвером без необходимости отдельного объекта драйвера для этого драйвера.

      Распознавание гипервизора в BattlEye

      Игра в кошки-мышки в области взлома игр продолжает оставаться источником новаций в эксплойтах и борьбе с читами. Использование технологии виртуализации во взломе игр начало активно развиваться после появления таких простых в применении гипервизоров, как DdiMon Сатоси Танда и hvpp Петра Бенеша. Эти два проекта используются большинством платных читов андерграундной хакерской сцены благодаря низкому порогу вхождения и подробной документации. Эти релизы с большой вероятностью ускорили гонку вооружений в области гипервизоров, которая сейчас начинает проявляться в сообществе хакеров игр. Вот что об этой ситуации говорит администратор одного из крупнейших сообществ взлома игр под ником wlan:

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

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

      Недавно в BattlEye было реализовано распознавание распространённых гипервизоров наподобие упомянутых выше платформ (DdiMon, hvpp) при помощи обнаружения на основе времени. Это распознавание пытается обнаружить нестандартные значения времени инструкции CPUID. CPUID — это относительно малозатратная на реальном оборудовании инструкция, обычно требующая всего двух сотен циклов, а в виртуальном окружении её выполнение может занимать в десять раз больше времени из-за лишних операций, вызываемых движком интроспекции. Движок интроспекции непохож на реальное оборудование, которое просто выполняет операцию ожидаемым образом, поскольку он на основании произвольного критерия отслеживает и условно изменяет данные, возвращаемые гостю.

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

      Распознавание

      Ниже представлена процедура распознавания из модуля BattlEye «BEClient2»; я выполнил её реверс-инжиниринг и воссоздал код на псевдо-C, а потом опубликовал его в twitter. Спустя день после моего твита разработчики BattlEye неожиданно изменили обфускацию BEClient2, видимо надеясь, что это помешает мне анализировать модуль. Предыдущая обфускация не менялась больше года, но изменилась на следующий день после моего твита о ней — впечатляющая скорость.


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

      Обход распознавания

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

      Усовершенствование

      Эту функцию можно улучшить множеством способов. Во-первых, можно намеренно отключить прерывания и принудительно задать приоритет потока, изменив CR8 на самый высокий уровень IRQL. Также было бы идеально изолировать эту проверку в одном ядре ЦП. Ещё одно улучшение: следует использовать разные таймеры, однако многие из них не так точны, как TSC, но существует один такой таймер под названием таймер APERF, или Actual Performance Clock. Я рекомендую этот таймер, потому что с ним сложнее жульничать и он только накапливает счётчик, когда логический процессор находится в состоянии питания C0. Это великолепная альтернатива использованию TSC. Также можно использовать таймер ACPI, HPET, PIT, таймер GPU, таймер NTP или таймер PPERF, который похож на APERF, но считает такты, которые воспринимаются как выполнение инструкций. Недостаток этого заключается в том, что необходимо включение HWP, который может быть отключен промежуточным оператором, а потому оказывается бесполезным.

      Ниже представлена улучшенная версия процедуры распознавания, которая должна выполняться в ядре:


      Примечание: IET означает Instruction Execution Time (время выполнения инструкции).

      Тем не менее, процедура всё равно может быть очень ненадёжной в обнаружении распространённых гипервизоров, поскольку время выполнения CPUID может очень сильно варьироваться. Лучше было бы сравнивать IET двух инструкций. Одна из них должна иметь большую задержку выполнения, чем CPUID. Например, это может быть FYL2XP1 — арифметическая инструкция, выполнение которой занимает чуть больше времени, чем среднее IET инструкции CPUID. Кроме того, она не вызывает никаких ловушек в гипервизоре и её время можно надёжно замерить. При помощи этих двух функций функция профилирования могла бы создавать массив для хранения IET инструкций CPUID и FYL2XP1. При помощи таймера APERF можно было бы получать начальный такт арифметической инструкции, выполнять инструкцию и вычислять для неё дельту тактов. Результаты можно было бы сохранять в массив IET в течение N циклов профилирования, получая среднее значение, и повторять процесс для CPUID. Если время выполнения инструкции CPUID больше, чем у арифметической инструкции, то это надёжный признак того, что система виртуальна, потому что арифметическая инструкция ни при каких условиях не могла бы тратить больше времени, чем выполнение CPUID для получения информации о производителе или версии. Такая процедура распознавания также сможет обнаруживать тех, кто использует смещение/масштабирование TSC.

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

      Потоки оверлея игр Steam

      Потоки в процессе оверлея игр Steam тоже перебираются:

      Чёрный список временных меток

      В последнем анализе BattlEye, в списке теневого бана было всего две метки дат времени компиляции, и похоже, что разработчики решили добавить гораздо больше:

      0x5B12C900 (action_x64.dll)
      0x5A180C35 (TerSafe.dll, Epic Games)
      0xFC9B9325 (?)
      0x456CED13 (d3dx9_32.dll)
      0x46495AD9 (d3dx9_34.dll)
      0x47CDEE2B (d3dx9_32.dll)
      0x469FF22E (d3dx9_35.dll)
      0x48EC3AD7 (D3DCompiler_40.dll)
      0x5A8E6020 (?)
      0x55C85371 (d3dx9_32.dll)
      0x456CED13 (?)
      0x46495AD9 (D3DCompiler_40.dll)
      0x47CDEE2B (D3DX9_37.dll)
      0x469FF22E (?)
      0x48EC3AD7 (?)
      0xFC9B9325 (?)
      0x5A8E6020 (?)
      0x55C85371 (?)

      Мне не удалось идентифицировать оставшиеся временные метки, а два 0xF******* — это хеши, созданные детерминированными сборками Visual Studio. Благодарю @mottikraus и T0B1 за идентификацию некоторых временных меток.

      LSASS

      Адресное пространство памяти процесса Windows lsass.exe, также известного как процесс Local Security Authority, тоже перебирается и о всех аномалиях сообщается серверу, как и в случае двух предыдущих проверок:


      LSASS ранее использовался в эксплойтах для выполнения операций с памятью, так как любой процесс, которому нужно Интернет-подключение, должен предоставить доступ к нему LSASS. В настоящее время BattlEye справляется с этой проблемой, вручную очищая дескриптор процесса от операций чтения/записи, а затем подключая ReadProcessMemory / WriteProcessMemory , перенаправляя вызовы на свой драйвер BEDaisy. Далее BEDaisy решает, является ли операция с памятью законной. Если он считает, что операция законна, то он продолжает её, а в противном случае намеренно включает машине синий экран.

      Проверки модулей

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


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

      Изменения в популярном античите BattlEye и способы их обхода


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

      Названия образов

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

      frAQBc8W.dll
      C:\\Windows\\mscorlib.ni.dll
      DxtoryMM_x64.dll
      Project1.dll
      OWClient.dll

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

      7-Zip широко использовался и продолжает использоваться участниками чит-сцены как заполнитель памяти для пустот кода (code-caves). BattlEye пытается бороться с этим, выполняя очень плохую проверку целостности, которую со времени моей предыдущей статьи изменили:


      Похоже, разработчики BattlEye догадались, что моя предыдущая статья привела к тому, что многие пользователи обходят эту проверку, просто копируя нужные байты в место, проверяемое BattlEye. Как же они исправили ситуацию? Сместили проверку на восемь байтов и продолжили использовать тот же плохой способ проверки целостности. Исполняемый раздел read-only, и всё, что вам нужно сделать — загрузить 7-Zip с диска и сравнить перемещённые разделы друг с другом; если есть какие-то расхождения, то что-то не так. Серьёзно, ребята, выполнять проверки целостности не так сложно.

      Читайте также: