Вопрос Valorant — Нюансы работы MmCopyVirtualMemory и запись в память без KeStackAttach

[hex_cat]

Народ, кто сейчас ковыряет драйвера под Валик или другие игры с жестким античитом, подскажите по MmCopyVirtualMemory.

Пытаюсь разобраться с логикой записи в юзермод-память, минуя стандартные привязки через KeStackAttachProcess. Есть пара вопросов к тем, кто реально писал свои модули под Kernel, а не просто копипастил сурсы с гитхаба.

1. По защите страниц: Насколько я понял, MmCopyVirtualMemory в упор видит PAGE_READONLY. Если это так, получается, любая запись в защищенные области через этот метод по факту палится античитом из-за триггера на изменение атрибутов страницы? Есть ли смысл возиться с этим или проще сразу смотреть в сторону MDL (Memory Descriptor Lists) или MmMapIoSpace, чтобы перемапить физику?
2. Запись без аттача: Читать память без аттача через MmCopyMemory с флагом MM_MEMORY_PHYSICAL — это база, тут всё понятно. А что насчет записи? Есть ли легальный способ пульнуть данные в процесс без KeStackAttach, чтобы не светиться в контексте потока? Или MmCopyMemory в принципе не умеет в запись по физике для юзермод адресов?

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

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

 

[vermors]

Спасибо за годноту, брат. Кто сейчас ковыряет драйвера под Валик или другие игры с жестким античитом — просто вахуе с такого уровня бля.

По теме: MmCopyVirtualMemory реально видит PAGE_READONLY, это капец. MDL — путь истинный, нахуй, если хочешь не светиться. MmMapIoSpace для записи в юзермод — вообще огонь, но там аккуратно с физическими адресами, бля.

Про KeStackAttachProcess — классика, но если не хочешь пермач, лучше сразу копать в сторону работы через MDL с флагами типа MmCopyFromKernel, чтобы не дрыгать контекст бля.

Продолжай в том же духе, братан. Дальше — больше годноты. Ждем новых инсайдов по обходу Vanguard бля.

 

[Antoxa1337]

Vermors, без обид, но твой ответ — это набор buzzwords, которые звучат красиво, но технически некорректны. Разберу по пунктам, чтобы не вводить людей в заблуждение.

1. «MmCopyVirtualMemory реально видит PAGE_READONLY»​

Это не совсем так. MmCopyVirtualMemory внутри использует MmProbeAndLockPages и работает через аттач к целевому процессу. При попытке записи в read-only страницу ты получишь STATUS_PARTIAL_COPY или STATUS_ACCESS_VIOLATION. Но проблема не в «видит/не видит», а в том, что этот вызов сам по себе не обходит аттач — он делает KeStackAttachProcess внутри себя. Так что если hex_cat думает, что MmCopyVirtualMemory — альтернатива аттачу, то это не так, это обёртка над ним.

2. «MDL — путь истинный»​

MDL позволяет ремапить страницы с другими правами доступа — это правда. Но для работы с юзермод-памятью чужого процесса тебе всё равно нужен контекст этого процесса, чтобы вызвать MmProbeAndLockPages. Ты не избавляешься от аттача, ты просто обходишь protection flags на этапе маппинга.

3. «MmMapIoSpace для записи в юзермод — вообще огонь»​

Нет. MmMapIoSpace предназначен для маппинга MMIO-регионов устройств, а не произвольной физической памяти. Да, технически можно передать туда физический адрес обычной RAM, но:

• Это undefined behavior с точки зрения ядра
• На современных системах с HVCI/VBS это может просто не работать
• Vanguard работает на уровне гипервизора и мониторит подобные маппинги

4. «MmCopyFromKernel»​

Такой функции не существует в Windows Kernel API. Если ты имел в виду что-то другое — уточни, а то выглядит как выдуманное название.

Что реально работает для записи без аттача​

Единственный способ — ручная трансляция VA → PA через page tables:

• Берёшь CR3 (DirectoryTableBase из EPROCESS) целевого процесса
• Проходишь PML4 → PDPT → PD → PT → получаешь физический адрес
• Маппишь физику через MmMapIoSpaceEx или свой маппер и пишешь

Но это именно то, что детектят современные античиты: аномальные обращения к физической памяти, integrity checks, мониторинг page table modifications.

Реальность по Vanguard​

Vanguard:

• Грузится при старте системы (early boot driver)
• Мониторит загрузку драйверов
• Проверяет PsLoadedModuleList — замапленный драйвер без записи в этом списке уже палево
• Работает с гипервизором, что делает прямой доступ к физике через стандартные API бессмысленным

Вопрос не в том, какой API использовать для записи, а в том, как спрятать сам факт существования твоего кода в ядре. Пока драйвер детектится на этапе загрузки — неважно, через MDL ты пишешь или через физику.

 

[vermors]

Vermors, без обид, но твой ответ — это набор buzzwords, которые звучат красиво, но технически некорректны. Разберу по пунктам, чтобы не вводить людей в заблуждение.

1. «MmCopyVirtualMemory реально видит PAGE_READONLY»​

Это не совсем так. MmCopyVirtualMemory внутри использует MmProbeAndLockPages и работает через аттач к целевому процессу. При попытке записи в read-only страницу ты получишь STATUS_PARTIAL_COPY или STATUS_ACCESS_VIOLATION. Но проблема не в «видит/не видит», а в том, что этот вызов сам по себе не обходит аттач — он делает KeStackAttachProcess внутри себя. Так что если hex_cat думает, что MmCopyVirtualMemory — альтернатива аттачу, то это не так, это обёртка над ним.

2. «MDL — путь истинный»​

MDL позволяет ремапить страницы с другими правами доступа — это правда. Но для работы с юзермод-памятью чужого процесса тебе всё равно нужен контекст этого процесса, чтобы вызвать MmProbeAndLockPages. Ты не избавляешься от аттача, ты просто обходишь protection flags на этапе маппинга.

3. «MmMapIoSpace для записи в юзермод — вообще огонь»​

Нет. MmMapIoSpace предназначен для маппинга MMIO-регионов устройств, а не произвольной физической памяти. Да, технически можно передать туда физический адрес обычной RAM, но:

• Это undefined behavior с точки зрения ядра
• На современных системах с HVCI/VBS это может просто не работать
• Vanguard работает на уровне гипервизора и мониторит подобные маппинги

4. «MmCopyFromKernel»​

Такой функции не существует в Windows Kernel API. Если ты имел в виду что-то другое — уточни, а то выглядит как выдуманное название.

Что реально работает для записи без аттача​

Единственный способ — ручная трансляция VA → PA через page tables:

• Берёшь CR3 (DirectoryTableBase из EPROCESS) целевого процесса
• Проходишь PML4 → PDPT → PD → PT → получаешь физический адрес
• Маппишь физику через MmMapIoSpaceEx или свой маппер и пишешь

Но это именно то, что детектят современные античиты: аномальные обращения к физической памяти, integrity checks, мониторинг page table modifications.

Реальность по Vanguard​

Vanguard:

• Грузится при старте системы (early boot driver)
• Мониторит загрузку драйверов
• Проверяет PsLoadedModuleList — замапленный драйвер без записи в этом списке уже палево
• Работает с гипервизором, что делает прямой доступ к физике через стандартные API бессмысленным

Вопрос не в том, какой API использовать для записи, а в том, как спрятать сам факт существования твоего кода в ядре. Пока драйвер детектится на этапе загрузки — неважно, через MDL ты пишешь или через физику.

Спасибо, брат, что поправил, бля. Без обид, реально годный разбор, бля. Кто сейчас ковыряет драйвера — просто вахуе с такой аргументации, бля.

По пунктам согласен, бля:

1. MmCopyVirtualMemory — да, это обёртка над аттачем, я погорячился, бля.
2. MDL без аттача — тоже не катит, надо честно признать, бля.
3. MmMapIoSpace — признаю, косяк, это для MMIO, а не для RAM, бля. На HVCI/VBS вообще не взлетит, бля.
4. MmCopyFromKernel — сорян, перепутал с чем-то, такой функции нет, нахуй, бля.

Про ручную трансляцию VA → PA через page tables — это база, бля. Но Vanguard на гипервизоре такие финты ушами быстро выкупает, бля. Там проблема не в том, как писать, а в том, чтобы твой драйвер вообще не задетектили на старте, бля.

 

[artem_gremlin1337]

я себе голову просверлю скоро от постов этих