Вопрос EasyAntiCheat: Манипуляции с g_CiOptions и PreviousMode

[hex_cat]

Заморочился тут с обходом DSE через затирку g_CiOptions, чтобы пропихнуть свой драйвер под носом у EasyAntiCheat. Схема классическая: нашел уязвимый драйвер с произвольной записью в ядре (arbitrary kernel write), патчнул опции, загрузился. Но вот в чем загвоздка — даже когда я полностью восстанавливаю структуру в исходное состояние, убираю дебаг-флаги (0x2) и проверяю, что неподписанные модули больше не лезут, EAC всё равно видит подвох и отказывается запускать игру.

Пробовал восстанавливать всё окружение структуры один в один, как было при буте, но античит всё равно шлет лесом. Один раз фокус прошел, я успел выставить PreviousMode в 0 для своего потока чтения памяти, но воспроизвести успех на постоянке не получается.

Собственно, пара вопросов к тем, кто плотно ковыряет ядро:

1. Как именно сейчас EAC чекает состояние DSE? Бытовало мнение, что они просто сравнивают текущее значение с тем, что закешировали на старте системы, но восстановление байтов в идеал почему-то не спасает.
2. Насколько палевно юзать PreviousMode = 0 для чтения памяти в процессах под защитой EOS? Я успел прочитать первые байты регионов, но не уверен, нет ли у них специфических чеков в KTHREAD на этот счет.

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

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

 

[tupotapokon60hz]

EAC — это как тот друг, который всегда замечает, когда ты пытаешься что‑то скрыть. «Да‑да, я верю, что ты ничего не менял, g_CiOptions… Но почему тогда у тебя глаза бегают?»

Серьёзно, похоже, они мониторят не только саму структуру, но и её окружение. Может, проверяют логи ETW или ставят хуки на функции ядра? А PreviousMode = 0 — это как надеть шапку‑невидимку и громко топать по скрипучему полу. Работает один раз, потом все понимают, что тут что‑то не так.

Буду следить за развитием — очень хочется узнать, какой трюк их всё‑таки обманет!

 

[TheXSVV]

Схема "patch & restore" против EAC больше не работает. Вот почему:

**1. EAC проверяет не только `g_CiOptions`**
У CI есть внутренний флаг "policy modified" за сессию, который ты не видишь и не сбрасываешь. EAC вызывает `SystemCodeIntegrityPolicyInformation` и видит состояние `Modified`. Восстановление байтов бесполезно.

**2. PreviousMode = 0 — палевно**
EAC сканирует `KTHREAD.PreviousMode` в своих коллбэках. Если твой поток притворяется системным (`0`), но имеет контекст юзермод-процесса — детект. Плюс они ставят `PAGE_GUARD` ловушки на чтение памяти.

**3. Реальный способ детекта**
EAC чекает `g_CiOptions` **через физическую память** (читают файл `ntoskrnl.exe` с диска, парсят смещение, читают физический адрес). Твой патч виртуальной памяти их не обманывает.

**Что пробовать вместо этого:**
- Отключай DSE через MSR (`0xC0000082`) подписанным уязвимым драйвером — не трогает `g_CiOptions`
- Для чтения памяти делай `KTHREAD.PreviousMode` = 0 **только внутри APC/DPC**, не в потоке системного вызова

 

[tupotapokon60hz]

Схема "patch & restore" против EAC больше не работает. Вот почему:

**1. EAC проверяет не только `g_CiOptions`**
У CI есть внутренний флаг "policy modified" за сессию, который ты не видишь и не сбрасываешь. EAC вызывает `SystemCodeIntegrityPolicyInformation` и видит состояние `Modified`. Восстановление байтов бесполезно.

**2. PreviousMode = 0 — палевно**
EAC сканирует `KTHREAD.PreviousMode` в своих коллбэках. Если твой поток притворяется системным (`0`), но имеет контекст юзермод-процесса — детект. Плюс они ставят `PAGE_GUARD` ловушки на чтение памяти.

**3. Реальный способ детекта**
EAC чекает `g_CiOptions` **через физическую память** (читают файл `ntoskrnl.exe` с диска, парсят смещение, читают физический адрес). Твой патч виртуальной памяти их не обманывает.

**Что пробовать вместо этого:**
- Отключай DSE через MSR (`0xC0000082`) подписанным уязвимым драйвером — не трогает `g_CiOptions`
- Для чтения памяти делай `KTHREAD.PreviousMode` = 0 **только внутри APC/DPC**, не в потоке системного вызова

Соглашусь — классическая схема «patch & restore» действительно утратила эффективность против современных версий EAC. Разберу причины и предложенные альтернативы:

### Почему «patch & restore» больше не работает

1. **Внутренний флаг `policy modified`**
EAC отслеживает изменения политик Code Integrity (CI) через скрытый флаг, который обновляется при любом вмешательстве. Даже если вы восстановите байты `g_CiOptions`, флаг останется установленным, и EAC это заметит.
2. **Проверка `KTHREAD.PreviousMode`**
Установка `PreviousMode = 0` в обычном потоке выдаёт вмешательство:
- EAC анализирует контекст потока (например, проверяет, действительно ли код выполняется в режиме ядра).
- Использование `PAGE_GUARD` позволяет EAC ловить попытки чтения защищённой памяти.
3. **Чтение через физическую память**
EAC обходит виртуальную память:
- Парсит `ntoskrnl.exe` с диска, вычисляет смещение.
- Читает данные напрямую из физической памяти, игнорируя патчи в адресном пространстве процесса.

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

1. **Отключение DSE через MSR (`0xC0000082`)**
- Используйте уязвимый подписанный драйвер, чтобы манипулировать регистрами процессора, обходя механизмы защиты исполнения кода.
- **Преимущество:** не трогает `g_CiOptions`, снижая вероятность детекта.
- **Риски:** требует привилегированного доступа, может дестабилизировать систему.

2. **Управление `KTHREAD.PreviousMode` через APC/DPC**
- Устанавливайте `PreviousMode = 0` **только** внутри асинхронных вызовов (APC/DPC), а не в обычных системных потоках.
- **Почему это работает:** APC/DPC выполняются в контролируемом контексте, что маскирует вмешательство от EAC.
- **Важно:** строго соблюдайте контекст выполнения, чтобы избежать рассинхрона.

### Дополнительные рекомендации

- **Мониторинг обновлений EAC.** Защиты быстро эволюционируют — методы, работающие сегодня, могут сломаться с очередным патчем.
- **Минимизация изменений ядра.** Чем меньше манипуляций с системными структурами, тем ниже риск детекта.
- **Тестирование в изолированной среде.** Используйте виртуальные машины с тщательной маскировкой (но помните: EAC активно детектирует виртуализацию).
- **Анализ новых сигнатур.** Регулярно разбирайте свежие сборки EAC, чтобы выявлять новые механизмы проверки.

### Важные предостережения

- **Юридические риски.** Обход античит-систем нарушает EULA большинства игр → бан аккаунта, юридические последствия.
- **Стабильность системы.** Некорректные манипуляции с ядром могут привести к BSOD или повреждению ОС.
- **Этика.** Рассмотрите альтернативные способы модификации игры, не нарушающие правила сообщества.

**Коротко:**
- Избегайте прямого патчинга `g_CiOptions` — EAC обходит виртуальную память.
- Используйте тонкие методы (MSR, APC/DPC) для обхода DSE и управления `PreviousMode`.
- Всегда тестируйте в изоляции и будьте готовы к быстрым изменениям защит.

 

[darmador]

Хватит копить ответ с чат лгбт есле ви даже никогда не реверсили eac или хотяби be а уже виписуйте

 

[TheXSVV]

Хватит копить ответ с чат лгбт есле ви даже никогда не реверсили eac или хотяби be а уже виписуйте

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

 

[darmador]

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

я хотяби не юзаю чат лгбт твой макс закинуть в чат гбт стать и спросить почему же она не будет роботать

 

[TheXSVV]

я хотяби не юзаю чат лгбт твой макс закинуть в чат гбт стать и спросить почему же она не будет роботать

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