View Single Post
Old 12-30-2021, 20:06
DavidXanatos DavidXanatos is offline
Join Date: Jun 2018
Posts: 168
Rept. Given: 2
Rept. Rcvd 40 Times in 27 Posts
Thanks Given: 53
Thanks Rcvd at 311 Times in 106 Posts
DavidXanatos Reputation: 40
Invoking Win32k syscalls from kernel space

I have noticed that while calling ntoskrnl.exe/ntdll.dll syscalls directly from the kernel works just fine, doing the same for win32k.sys/win32u.dll syscalls however fails when HVCI is enabled with the bug check 139, with the additional hint: Arg1: 0 - A stack-based buffer has been overrun.
Which is strange, as why would it work with HVCI enabled for the kernel itself but not for the win32 stuff? That would be problem 1.

Another issue is that before calling the first win32k sys call KiConvertToGuiThread must be triggered, unfortunately neither this nor PsConvertToGuiThread is exported, by the kernel. And this would be problem 2.

What I want to achieve as the final goal is to provide a syscall interface in my driver that an application could call, the driver would than do something in the kernel space, invoke the actual syscall, then do something else, before finally returning control to the user mode application.

Problem 2 could be successfully ignored as other un redirected win32k syscalls would have been executed at this point already.

But problem 1 is in urgent need of fixing and I’m out of ideas why this would not work with HVCI enabled for the new set of syscalls. The redirection is implemented in the same exact way as the old working one and without HVCI it works just fine.

Anyone here knowing whats going on and how to fix it?

imho the best would be a way to actually invoke the original syscall from the kernel such that it does everything including KiConvertToGuiThread , but I'm not sure if that is even possible.

Reply With Quote
The Following 2 Users Say Thank You to DavidXanatos For This Useful Post:
niculaita (12-30-2021), user1 (12-31-2021)