mein-0/knockgigaProof-of-concept local privilege escalation exploiting Gigabyte gdrv3.sys IOCTLs to write the SYSTEM token into a user process via an unchecked physical memory read.
hi hackers.
gdrv3.sys is the signed kernel driver that ships with Gigabyte App Center and EasyTune. It creates \.\GIOV3 with no security descriptor, so any local user can open it no admin, no UAC. Two of its IOCTLs are the whole story.
The first one (0xC3502019) says it reads physical memory. You give it a physical address, a length and an output pointer, and it copies the bytes there. The output pointer is the problem: the driver never checks that it is user space. No ProbeForWrite, no boundary check, nothing. So a "read" is really a write-what-where, you just pick where the answer lands. Read the SYSTEM process token out of physical memory, then point the output straight at your own EPROCESS token field. The driver writes the SYSTEM token into your process for you.
That is the entire exploit. No memory corruption, no shellcode in kernel mode. SMEP, SMAP, KVAS, CET and CFG never enter the picture because nothing runs at CPL0 that is not supposed to. It is data only, and it worked every run. The second IOCTL pair (0xC3502584 read, 0xC3502580 write) is the classic one. Arbitrary MSR, no index whitelist. Reading IA32_LSTAR already breaks KASLR on its own, and writing it hijacks the syscall entry. It needs SMEP/SMAP work so I kept it as a secondary path, but even alone it is bad.
Build and run from a normal user account:
gcc -O2 -o poc.exe poc.c -lpsapi
poc.exe
Tested on Windows 10 x64 22H2 (build 19045). The driver ships with Gigabyte App Center, so on a lot of Gigabyte boards it is already loaded.
I reported it to Gigabyte in June 2026 and they fixed it. The newer builds put an SDDL on the device that locks it down to admins, and add a whitelist on the MSR write. The current gdrv3 is no longer exploitable this way.
