Гайд [Разбор] Реверс EasyAntiCheat_EOS.sys — Полный цикл инициализации драйвера

[hex_cat]

Разбор полетов по поводу того, что на самом деле творит EasyAntiCheat_EOS.sys в ядре при старте. Прогнал драйвер через эмулятор, разложил все по фазам и вытащил техническое мясо. Краткая суть: почти вся логика сидит под их собственной VM, а как только проходят первичные анти-дебаг гейты, драйвер начинает веером рассылать мониторинг по модулям, сертификатам и памяти.

Технические данные билда:

Binary: EasyAntiCheat_EOS.sys (37MB)
DriverEntry: RVA 0x173188
VM section: .sec7 at RVA 0x267000 (33.3MB)
Worker thread entry: RVA 0x19054

Спойлер: Фаза 1: Инициализация и логи ошибок

Сразу после DriverEntry EAC пишет пачку диагностических ключей в реестр:

\Registry\Machine\Software\Wow6432Node\EasyAntiCheat_EOS

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

Спойлер: Фаза 2: Вход в VM (Virtual Machine)

После этого исполнение улетает в секцию .sec7. Это кастомная ВМка EAC:

1. 1025 уникальных адресов хендлеров.
2. Почти 70% хендлеров — обычный диспетчерский роутинг.
3. Константно держит структуру контекста на 54 QWORD (GPR, XMM, флаги и состояние ВМ).

Именно здесь прячутся все проверки на отладку, виртуалки и логика принятия решений о запуске.

Спойлер: Фаза 3: Главные Anti-Debug ловушки

Тут EAC проверяет, не сидите ли вы под отладчиком:

3a. INT 1 Single-Step (Основной гейт)
Драйвер намеренно триггерит INT 1 и ожидает, что SEH (структурная обработка исключений) передаст управление в локальный хендлер. Если отладчик сожрет прерывание сам — инициализация стопается с ошибкой

STATUS_DRIVER_UNABLE_TO_LOAD (0xC000026C)

. Никаких потоков и устройств создано не будет.

3b. RDTSC Тайминги
Пролетает серия проверок RDTSC с рандомным числом циклов. Замеряют дельту между вызовами. Если задержка слишком большая (привет, VM и тяжелая инструментация) — вы в списке подозреваемых.

3c. INT 3 Breakpoint
То же самое, что с INT 1, но через брейкпоинт. Юзается как при старте, так и рандомно в цикле мониторинга.

Спойлер: Фаза 4-7: Мониторинг и HWID

ЕАС начинает агрессивно сканировать окружение:

1. SystemModuleInformation: Вызывает NtQuerySystemInformation по несколько раз подряд, чтобы получить стабильный список всех загруженных модулей.
2. HWID-фингерпринт: Делает более 500 вызовов HalGetBusDataByOffset, читая PCI-конфиг (VendorID/DeviceID), плюс забирает RAW данные SMBIOS через WMI (серийники материнки, биоса и т.д.).
3. Черный список драйверов: Прогоняет около 4674 сравнений строк. Ищут все: от VBoxGuest.sys и vm3dmp.sys до dbk64.sys (Cheat Engine) и PROCMON23.sys.
4. Проверка BCD: Смотрят значение BcdOSLoaderBoolean_AllowPrereleaseSignatures, чтобы понять, включен ли у вас тестовый режим подписи драйверов.

Спойлер: Фаза 8-16: Потоки воркеров и мониторинг памяти

Создается 5 воркер-тредов с энтрипоинтом

drv+0x19054

. Даже если основная DriverEntry вернет управление системе, эти ребята остаются жить и делать грязную работу.

Чего они мониторят:

1. Агрессивный обход всех хранилищ сертификатов (ROOT, AuthRoot, CA). Около 1000 запросов значений в реестре.
2. Проверка integrity дискового драйвера и FLTMGR.SYS (ищут инлайн-хуки).
3. Сканирование процессов и потоков через PsLookupProcessByProcessId и PID-вокинг.
4. Чтение памяти через MmCopyVirtualMemory — ищут заинжекченные куски кода, трамплины и мануал-мап.

Самое интересное здесь — проверка 0xC5 через NtQuerySystemInformation для детекта гипервизора. Если возвращается NULL, значит гипервизор не светится.

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

Как считаете, обход через эмуляцию исключений SEH все еще актуален при таких проверках?

 

[jopaaaadddaaa]

кто ты? ты нейросеть которой дали возможность сидеть на компе? человек не может такое количество инфы получать и сливать на форумы ,это же бред какой то

 

[xinO]

кто ты? ты нейросеть которой дали возможность сидеть на компе? человек не может такое количество инфы получать и сливать на форумы ,это же бред какой то

Я больше боюсь когда оно выкладывает сурсы

 

[tupotapokon60hz]

На основании вашего анализа EasyAntiCheat_EOS.sys можно сделать следующие выводы и дать рекомендации:

### О проверке 0xC5 через `NtQuerySystemInformation`

Проверка с кодом `0xC5` нацелена на обнаружение гипервизоров (например, VMware, Hyper-V). Если функция возвращает `NULL`, это сигнализирует, что гипервизор либо отсутствует, либо скрыт. Это усложняет использование виртуальных машин для обхода — античит активно мониторит окружение.

### Актуальность SEH-эмуляции

Эмуляция исключений SEH _может_ оставаться частично актуальной, но с оговорками:

- **Сложность VM-слоя.** Логика античита спрятана внутри кастомной VM, что затрудняет предсказание точек установки SEH-обработчиков.
- **Мониторинг воркеров.** Потоки-воркеры продолжают работу после инициализации, динамически проверяя память и модули. SEH-подход может не покрыть асинхронные проверки.
- **Анти-дебаг гейты.** Даже если перехватить исключения, VM может дополнительно проверять целостность кода (например, контрольные суммы секций).

### Альтернативные подходы к обходу

1. **Анализ VM-секции `.sec7`**
Исследуйте байт-код VM, чтобы выявить:
- точки входа в критические функции (мониторинг, проверка HWID);
- алгоритмы шифрования/дешифрования данных.
2. **Динамический анализ**
Используйте отладчики (например, WinDbg) для отслеживания:
- вызовов `NtQuerySystemInformation`;
- взаимодействия с модулями ядра;
- поведения воркер-потоков.
3. **Модификация возвращаемых данных**
Попробуйте перехватывать вызовы `NtQuerySystemInformation` (например, через драйверы или пользовательские хуки), чтобы подменять ответы и «скрыть» гипервизор.
4. **Обход через пользовательский режим**
Сосредоточьтесь на перехвате API, связанных с мониторингом памяти, вместо прямого вмешательства в ядро (снижает риск BSOD).
5. **Поиск уязвимостей VM**
Возможно, VM допускает ошибки при обработке определённых входных данных — это может стать точкой входа для обхода.

### Риски и предостережения

- **Юридические и этические риски.** Обход античит-систем часто нарушает EULA игр и может привести к бану.
- **Нестабильность системы.** Некорректное патчивание ядра (особенно VM) почти гарантированно вызовет BSOD.
- **Быстрое обновление защит.** Разработчики античита оперативно закрывают уязвимости, поэтому методы обхода быстро устаревают.

 

[zxcursed vmp]

Разбор полетов по поводу того, что на самом деле творит EasyAntiCheat_EOS.sys в ядре при старте. Прогнал драйвер через эмулятор, разложил все по фазам и вытащил техническое мясо. Краткая суть: почти вся логика сидит под их собственной VM, а как только проходят первичные анти-дебаг гейты, драйвер начинает веером рассылать мониторинг по модулям, сертификатам и памяти.

Технические данные билда:

Binary: EasyAntiCheat_EOS.sys (37MB)
DriverEntry: RVA 0x173188
VM section: .sec7 at RVA 0x267000 (33.3MB)
Worker thread entry: RVA 0x19054

Спойлер: Фаза 1: Инициализация и логи ошибок

Сразу после DriverEntry EAC пишет пачку диагностических ключей в реестр:

\Registry\Machine\Software\Wow6432Node\EasyAntiCheat_EOS

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

Спойлер: Фаза 2: Вход в VM (Virtual Machine)

После этого исполнение улетает в секцию .sec7. Это кастомная ВМка EAC:

1. 1025 уникальных адресов хендлеров.
2. Почти 70% хендлеров — обычный диспетчерский роутинг.
3. Константно держит структуру контекста на 54 QWORD (GPR, XMM, флаги и состояние ВМ).

Именно здесь прячутся все проверки на отладку, виртуалки и логика принятия решений о запуске.

Спойлер: Фаза 3: Главные Anti-Debug ловушки

Тут EAC проверяет, не сидите ли вы под отладчиком:

3a. INT 1 Single-Step (Основной гейт)
Драйвер намеренно триггерит INT 1 и ожидает, что SEH (структурная обработка исключений) передаст управление в локальный хендлер. Если отладчик сожрет прерывание сам — инициализация стопается с ошибкой

STATUS_DRIVER_UNABLE_TO_LOAD (0xC000026C)

. Никаких потоков и устройств создано не будет.

3b. RDTSC Тайминги
Пролетает серия проверок RDTSC с рандомным числом циклов. Замеряют дельту между вызовами. Если задержка слишком большая (привет, VM и тяжелая инструментация) — вы в списке подозреваемых.

3c. INT 3 Breakpoint
То же самое, что с INT 1, но через брейкпоинт. Юзается как при старте, так и рандомно в цикле мониторинга.

Спойлер: Фаза 4-7: Мониторинг и HWID

ЕАС начинает агрессивно сканировать окружение:

1. SystemModuleInformation: Вызывает NtQuerySystemInformation по несколько раз подряд, чтобы получить стабильный список всех загруженных модулей.
2. HWID-фингерпринт: Делает более 500 вызовов HalGetBusDataByOffset, читая PCI-конфиг (VendorID/DeviceID), плюс забирает RAW данные SMBIOS через WMI (серийники материнки, биоса и т.д.).
3. Черный список драйверов: Прогоняет около 4674 сравнений строк. Ищут все: от VBoxGuest.sys и vm3dmp.sys до dbk64.sys (Cheat Engine) и PROCMON23.sys.
4. Проверка BCD: Смотрят значение BcdOSLoaderBoolean_AllowPrereleaseSignatures, чтобы понять, включен ли у вас тестовый режим подписи драйверов.

Спойлер: Фаза 8-16: Потоки воркеров и мониторинг памяти

Создается 5 воркер-тредов с энтрипоинтом

drv+0x19054

. Даже если основная DriverEntry вернет управление системе, эти ребята остаются жить и делать грязную работу.

Чего они мониторят:

1. Агрессивный обход всех хранилищ сертификатов (ROOT, AuthRoot, CA). Около 1000 запросов значений в реестре.
2. Проверка integrity дискового драйвера и FLTMGR.SYS (ищут инлайн-хуки).
3. Сканирование процессов и потоков через PsLookupProcessByProcessId и PID-вокинг.
4. Чтение памяти через MmCopyVirtualMemory — ищут заинжекченные куски кода, трамплины и мануал-мап.

Самое интересное здесь — проверка 0xC5 через NtQuerySystemInformation для детекта гипервизора. Если возвращается NULL, значит гипервизор не светится.

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

Как считаете, обход через эмуляцию исключений SEH все еще актуален при таких проверках?

Скидывай на ориг тред в юц пж

 

[jopaaaadddaaa]

Я больше боюсь когда оно выкладывает сурсы

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

 

[Taero]

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

Это копипаст с uc, не более