Начинающий
- Статус
- Оффлайн
- Регистрация
- 13 Фев 2026
- Сообщения
- 429
- Реакции
- 10
Народ, кто плотно сидит на реверсе ядра под последние билды десятки и одиннадцатой винды, зацените прикол. Пишу кастомный гипервизор под инжект скрытого драйвера, и наткнулся на стену при резолве базы ntoskrnl.exe.
Классическая схема, которой все пользовались годами: читаем LSTAR (который из-за KPTI услужливо указывает на KiSystemCall64Shadow), выравниваем страницу и валим назад по памяти, пока не уткнемся в MZ заголовок. Но на свежих билдах Windows 11 24H2 этот метод начал выдавать какую-то дичь.
Суть проблемы:
Похоже, аллокация пула KVASCODE (где теперь живет теневой системный вызов) разбрасывается по адресному пространству настолько далеко от реального имиджа ядра (область 0xFFFFF805...), что при сканировании назад мы просто проваливаемся в бесконечную пустоту.
Что было замечено на тестах:
Самое забавное, что через юзермодный NtQuerySystemInformation адрес прилетает мгновенно и он корректный. Но когда ты сидишь внутри VMM exit handler-а, тебе нужно выживать без экспортов и грязных костылей.
Собственно, вопрос к знатокам:
Майки окончательно сломали гарантию того, что ntoskrnl лежит ниже KVASCODE в адресном пространстве? И есть ли сейчас более вменяемый якорь, кроме LSTAR/IDTR, который выживает при активном KPTI и позволяет зацепиться за базу ядра, не брутфорся гигабайты пустоты?
Кто уже сталкивался с таким поведением на 24H2, отпишитесь по своим методам поиска.
Классическая схема, которой все пользовались годами: читаем LSTAR (который из-за KPTI услужливо указывает на KiSystemCall64Shadow), выравниваем страницу и валим назад по памяти, пока не уткнемся в MZ заголовок. Но на свежих билдах Windows 11 24H2 этот метод начал выдавать какую-то дичь.
Суть проблемы:
Похоже, аллокация пула KVASCODE (где теперь живет теневой системный вызов) разбрасывается по адресному пространству настолько далеко от реального имиджа ядра (область 0xFFFFF805...), что при сканировании назад мы просто проваливаемся в бесконечную пустоту.
Что было замечено на тестах:
- Обычный шаг в 0x1000 — это смерть, цикл уходит в бесконечность из-за миллионов итераций.
- Даже если прыгать по 2MB (PDE large-page) на 8192 итерации вперед (что кроет около 16 ГБ), база не находится. Между теневым кодом и реальным ядром зияет дыра в 8+ гигабайт неразмеченных страниц.
- На некоторых бутах сканер ловит page-fault прямо посреди этого вакуума в VA.
Самое забавное, что через юзермодный NtQuerySystemInformation адрес прилетает мгновенно и он корректный. Но когда ты сидишь внутри VMM exit handler-а, тебе нужно выживать без экспортов и грязных костылей.
Собственно, вопрос к знатокам:
Майки окончательно сломали гарантию того, что ntoskrnl лежит ниже KVASCODE в адресном пространстве? И есть ли сейчас более вменяемый якорь, кроме LSTAR/IDTR, который выживает при активном KPTI и позволяет зацепиться за базу ядра, не брутфорся гигабайты пустоты?
Кто уже сталкивался с таким поведением на 24H2, отпишитесь по своим методам поиска.