Doom running in the NT kernel. [Only tested on NT 10.0.22621.525 as that is what I had on hand]
https://github.com/NSG650/NtDOOM/assets/51860844/b3e47bb3-8b62-4396-ada3-6181dbeb30ea
bcdedit /set testsigning on
shutdown /r /t 0sc create NtDOOM binPath=C:\where\ever\the\driver\is\NtDOOM.sys type=kernel start=demandPlace a copy of DOOM on the root of the C: drive with the name "DOOM.WAD"
Run it!
sc start NtDOOMTry restarting explorer.exe. If that did not work then restart your system. Do not try to rerun the driver if restarting explorer.exe did not work, There is a good chance the system will BSOD.
Many parts of the Win32 API are usually handled in the kernel side. These include GDI, getting inputs, etc. Many of these functions have syscalls for them. These syscalls are handled by win32k.sys [win32kbase.sys and win32kfull.sys].
Here the kernel driver just calls the handler for these syscalls present in win32k.
However one can't simply get the addresses to these functions and call them directly.
If you have experience with how syscalls in Windows work then you know that not every type of thread can call these GUI syscalls directly. The thread must be running under a Win32 GUI application.
To bypass that we spoof the kernel thread as if it is a thread from explorer.exe. Due to this spoofing process the driver can only run on certain NT kernel versions as the internal data structures for KTHREAD and EPROCESS usually change.
Thanks to Mattiwatti's pull request the driver does not have to rely on hard coded offsets to spoof the thread as a win32 thread. Thus in theory this driver can run on most NT systems.
The doom port is based off of PureDoom with slight changes.
ReactOS Project for providing documentations for these raw syscalls.
Kernel Drawing for figuring out how to use win32k functions in a kernel driver
Pure Doom for providing the base for this doom port
Mattiwatti's pull request for improving the attaching and spoofing the kernel thread code!! Thank you so much!