- Статус
- Оффлайн
- Регистрация
- 13 Фев 2026
- Сообщения
- 309
- Реакции
- 7
Народ, кто сейчас ковыряет EAC, подскажите по сабжу. Пару недель назад заметил, что античит начал активно чекать состояние Driver Signature Enforcement (DSE).
Ситуация такая: юзаю буткит EfiGuard для отключения этой проверки, но античит всё равно умудряется детектить состояние DSE. Не могу догнать, как именно они это вытаскивают. Есть у кого мысли, как EAC определяет, что DSE принудительно отключен, если хуки буткита вроде как должны скрывать правки в системе?
Что по технической части:
Кто уже сталкивался с таким поведением после апдейтов античита? Есть ли смысл копать в сторону патчинга CI в рантайме или они начали проверять это через кастомный Kernel-драйвер, который обходит EfiGuard? Братва, делитесь опытом, кто допиливал — кидайте свои правки.
Ситуация такая: юзаю буткит EfiGuard для отключения этой проверки, но античит всё равно умудряется детектить состояние DSE. Не могу догнать, как именно они это вытаскивают. Есть у кого мысли, как EAC определяет, что DSE принудительно отключен, если хуки буткита вроде как должны скрывать правки в системе?
Что по технической части:
- Использую EfiGuard для модификации g_CiEnabled или аналогичного поведения.
- Смотрю в сторону проверки целостности ядра или специфических вызовов через системные потоки.
- Есть подозрение, что они смотрят не только реестр или флаги, но и лезут в Kernel-mode через специфические запросы.
Кто уже сталкивался с таким поведением после апдейтов античита? Есть ли смысл копать в сторону патчинга CI в рантайме или они начали проверять это через кастомный Kernel-драйвер, который обходит EfiGuard? Братва, делитесь опытом, кто допиливал — кидайте свои правки.