Подписывайтесь на наш Telegram и не пропускайте важные новости! Перейти

Гайд EasyAntiCheat.sys Kernel RE — Полный разбор детектов и логики

Sloppy
Начинающий
Начинающий
Статус
Оффлайн
Регистрация
13 Фев 2026
Сообщения
537
Реакции
14
Решил на досуге плотно покопаться в кишках EasyAntiCheat.sys от Rust. Дампил через IDA, прошелся по таблицам импортов и декомпилу — никакой инфы из вторых рук, только голый реверс бинарника. Если кто-то думает, что EAC всё еще сидит на уровне простых колбеков, у меня для вас плохие новости.

1. Обфускация импортов — DecryptImport

Первое, на чем спотыкается статик: EAC почти не использует IAT для работы с ядром. Вместо этого они вытягивают одну функцию из своего юзермод-модуля:
Код:
Expand Collapse Copy
DecryptImport — импортируется из EasyAntiCheat_EOS
Все чувствительные функции разрешаются в рантайме. Каждый вызов (callsite) уникален: используются разные константы для XOR и разные значения для ротации (ROR8). Насчитал более 47 таких вызовов. Обычный хук на DecryptImport не поможет — придется реверсить логику расшифровки для каждого конкретного вызова.

  1. SeRegisterImageVerificationCallback / SeUnregisterImageVerificationCallback
  2. RtlWalkFrameChain, RtlVirtualUnwind, RtlLookupFunctionEntry
  3. KeEnterCriticalRegion / KeLeaveCriticalRegion
  4. ExAcquirePushLockExclusiveEx / ExReleasePushLockExclusiveEx
  5. IoThreadToProcess
  6. Tbsi_Context_Create, Tbsi_GetDeviceInfo

2. Anti-Disassembly в DriverEntry

Точка входа (0x18012E054) сразу встречает мусором. Классический трюк jmp + 1 ломает линейный декомпил в IDA и Ghidra, прыгая в середину следующей инструкции. Нужно фиксить таргет вручную, иначе получите db-мусор вместо кода.

3. Мониторинг файловой системы

EAC работает как полноценный filesystem minifilter driver (использует FltRegisterFilter). Они видят абсолютно всё: чтение, запись, переименование файлов. Если ваш софт трогает игровые файлы или даже лежит в подозрительном месте — вы под колпаком. По импортам из FLTMGR это четко прослеживается (FltGetFileNameInformation, FltGetRequestorProcess).

4. Stack Walking — Гроза мапперов

Логика детекта мануал-мап драйверов строится на двух функциях:
  1. Capture (sub_1800A6928): Срабатывает на ивентах ядра. Чтобы не просаживать FPS, используется вероятностный метод — семплирование идет примерно в 1% случаев. Если ваш драйвер попал в этот 1%, EAC снимает 8 кадров стека.
  2. Validation (sub_1800D7870): Здесь начинается магия. Каждый адрес возврата проверяется на вхождение в легитимные модули. Если RIP указывает на неразмеченную память (unmapped memory) или за пределы доверенных драйверов — ловите флаг.

5. TPM 2.0 и Hardware Attestation

Для любителей софтовых спуферов новости паршивые. EAC инициализирует контекст TPM 2.0 (sub_18003C3BC), валидирует железо и отправляет команды напрямую чипу через Tbsip_Submit_Command. Endorsement Key и PCR-регистры — это аппаратный корень доверия. На уровне ОС это не фиксится, нужно либо перехватывать TBS API, либо надеяться, что на целевой машине нет TPM.

6. Прочие векторы детекта
  1. NMI Callbacks: Используют KeDeregisterNmiCallback. Немаскируемые прерывания позволяют чекать состояние ядер в обход классических хуков.
  2. ETW Tracing: Через NtTraceControl мониторят системные события и попытки вмешательства в трассировку.
  3. VBS Check: VslGetSecurePciEnabled проверяет, включена ли изоляция ядра (HVCI).
  4. Physical Memory Access: Прямой доступ через MmMapIoSpace для чтения SMBIOS таблиц и обхода виртуальной защиты памяти.

По итогу: EAC плотно сидит в пайплайне загрузки драйверов через SeRegisterImageVerificationCallback (чекают каждый драйвер в системе еще до его выполнения). Статик-анализ из-за DecryptImport — та еще боль, а аппаратные детекты TPM делают жизнь селлеров спуферов очень короткой.

Кто уже ковырял новые конфиги под другие игры, есть ли там существенные отличия по импортам в основном модуле?
 
спасибо конечно, но
— , либо надеяться, что на целевой машине нет TPM
типо сам по себе анализ (вроде) нормальный
я знаю что эту статью писала нейронка, но не могу доказать
 
Назад
Сверху Снизу