KnockGiga

привет, хакеры.

gdrv3.sys — это подписанный драйвер ядра, который поставляется с Gigabyte App Center и EasyTune. Он создаёт \.\GIOV3 без дескриптора безопасности, поэтому любой локальный пользователь может его открыть — без прав администратора, без UAC. Вся суть в двух его IOCTL.

Первый (0xC3502019) заявлен как чтение физической памяти. Вы передаёте ему физический адрес, длину и указатель вывода, и он копирует туда байты. Проблема в указателе вывода: драйвер никогда не проверяет, что он указывает в пространство пользователя. Ни ProbeForWrite, ни проверки границ — ничего. Так что «чтение» на деле оказывается записью-куда-угодно, вы просто выбираете, куда попадёт результат. Считайте токен процесса SYSTEM из физической памяти, а затем направьте вывод прямо на поле токена в вашем собственном EPROCESS. Драйвер сам запишет токен SYSTEM в ваш процесс.

Это и есть весь эксплойт. Никакого повреждения памяти, никакого шелл-кода в режиме ядра. SMEP, SMAP, KVAS, CET и CFG вообще не в игре, потому что на CPL0 не выполняется ничего, что не должно выполняться. Только данные, и это срабатывало при каждом запуске. Вторая пара IOCTL (0xC3502584 — чтение, 0xC3502580 — запись) — классическая. Произвольный MSR, без белого списка индексов. Чтение IA32_LSTAR само по себе уже ломает KASLR, а запись в него перехватывает вход в syscall. Для неё нужна обход SMEP/SMAP, поэтому я оставил её как вторичный путь, но даже сама по себе она опасна.

Сборка и запуск из обычной учётной записи пользователя:

gcc -O2 -o poc.exe poc.c -lpsapi
poc.exe

Протестировано на Windows 10 x64 22H2 (сборка 19045). Драйвер поставляется с Gigabyte App Center, так что на многих платах Gigabyte он уже загружен.

Я сообщил об этом Gigabyte в июне 2026 года, и они это исправили. В более новых сборках на устройство ставится SDDL, ограничивающий доступ администраторами, и добавляется белый список для записи MSR. Текущий gdrv3 больше не эксплуатируется таким способом.