Начинающий
Начинающий
- Статус
- Оффлайн
- Регистрация
- 13 Фев 2026
- Сообщения
- 130
- Реакции
- 4
Народ, кто сейчас ковыряет HyperGuard, есть повод для обсуждения. Завис тут на пару недель в IDA, анализируя securekernel и hvix64, и докладываю по фактам: стандартный подход с EPT-сплитом через type-1 гипервизор против них уже не катит, 0x18B прилетает стабильно.
Суть проблемы в том, как именно SkpgVerifyExtents чекает память. Трассировка цепочки вызовов показала следующее:
Так как наши shadow-страницы (--X) при попытке чтения со стороны гипервизора возвращают GpaNoReadAccess (результат 5), Skpg просто дропает систему в 0x18B. Даже если подсунуть валидный байт, проверка доступа (access rights check) на 0x140064996 ожидает R-X или RWX. Наш --X отдает 4, что для них вердикт — детект и последующий селф-дестракт VTL1.
Самое неприятное, что VTL1 сейчас планируется не только через гиперколы, а в четырех точках:
Короче, этот BugCheck — это в одну сторону, восстановления нет. Сейчас думаю, есть ли смысл пытаться хукать HvSetEptPointer непосредственно в hvix64 как единственное горлышко для всех обновлений EPTP, либо пытаться манипулировать VTL-планировщиком в нулевом кольце, чтобы принудительно обходить проверки.
Кто-то уже пробовал работать из вложенной позиции (nested)? Есть варианты обхода без того, чтобы вызывать EPT violation при каждом чихе? Кидайте свои мысли, кто в теме, а то я уже перебрал все варианты с подменой таблиц.
Суть проблемы в том, как именно SkpgVerifyExtents чекает память. Трассировка цепочки вызовов показала следующее:
- SkpgHyperguardRuntime: Триггерит проверку через рандомный таймер.
- SkpgTranslateVaWorker: Дергает гиперколл 0x52 (HvTranslateVirtualAddress).
- Флаги доступа: Выставляются в 0x71, что требует прав на чтение.
Так как наши shadow-страницы (--X) при попытке чтения со стороны гипервизора возвращают GpaNoReadAccess (результат 5), Skpg просто дропает систему в 0x18B. Даже если подсунуть валидный байт, проверка доступа (access rights check) на 0x140064996 ожидает R-X или RWX. Наш --X отдает 4, что для них вердикт — детект и последующий селф-дестракт VTL1.
Самое неприятное, что VTL1 сейчас планируется не только через гиперколы, а в четырех точках:
- Hypercall 0x11 (explicit vtl call)
- Синтетические таймеры (sub_FFFFF8000020F180)
- Secure Interrupts
- VMExit Piggybacking: Диспетчер в 0x2168BA проверяет очередь событий VTL1 буквально после каждого экзита.
Короче, этот BugCheck — это в одну сторону, восстановления нет. Сейчас думаю, есть ли смысл пытаться хукать HvSetEptPointer непосредственно в hvix64 как единственное горлышко для всех обновлений EPTP, либо пытаться манипулировать VTL-планировщиком в нулевом кольце, чтобы принудительно обходить проверки.
Кто-то уже пробовал работать из вложенной позиции (nested)? Есть варианты обхода без того, чтобы вызывать EPT violation при каждом чихе? Кидайте свои мысли, кто в теме, а то я уже перебрал все варианты с подменой таблиц.
