Inspiration

Following this tutorial, and more broadly, this entire series, this is my attempt at learning how to exploit a vulnerable windows driver. A driver is kind of like a mediator between user programs and the kernel. User programs make IRPs, or I/O request packets (also called ioctls on Linux) to drivers, which have special handler functions that are expecting these requests. Upon receiving a request, the driver does whatever it is it's meant to do- a network driver will process packets, a a mouse driver might deal with mouse interrupts.

The significant part is- drivers have access to kernel mode routines, which on Windows, is available to use in the <wdm.h> header by Microsoft. This grants drivers a lot of power in what they can do, allowing us to interact directly with kernel objects. This means it is very easy to bluescreen your computer if you make any mistake!

This exploit attempts to "bypass" VAC by denying handles to CSGO, using something called ObRegisterCallbacks. This is a kernel mode routine that "calls back" a function, each time there is a handle operation on the system. And in Windows, a handle is kind of like a ticket to access something. Without handles, processes cannot access other processes. And this doesn't just go for processes. You can have a handle to a thread, a file, a mutex, an event- in fact, any object. Objects are an interesting topic in Windows, and I recommend reading Chapter 8 of Windows Internals, or downloading WinObjEx64 to play around with them.

What this means is, we can monitor which processes are requesting handles to which other processes, and if the name of the process it is requesting a handle to is our target process, we will downgrade the handle permissions. If you want to change which program it denies handles to, change line 12 in Source.c:

char* target_process = "csgo.exe";

To run this exploit:

0. Download Process Hacker 2

1. The driver itself is available at the ASROCK website. AsRock is just a motherboard manufacturing company, kind of like MSI. To install it, go to this link. If you're worried that it's a virus, don't be, because I uploaded it. It's just a extracted version of the correct AsRock driver (some of them install later versions, which may or may not have patched the vulnerability) which you can find on the AsRock Support Site. All this driver does is work with the RGB lights on AsRock motherboards (another example of what drivers can do!) If you want to read more about why the driver is vulnerable, check out the original author's post. To summarize, it's because they massively over-engineered the driver by making it a template of the Read/Write Everything driver.

2. After obtaining the folder, go to Bin, then run AsrPolychromeRGB. This will install the driver (AsrDrv104.sys) onto your system. Don't worry if you don't have an AsRock motherboard, tons of drivers are completely useless and won't do anything if loaded. For example, the Null Driver, or the doskey driver. Or a CD-ROM driver, which comes by default in Windows, but obviously isn't being used if you don't have a CD-ROM.

3. After installation finishes (don't worry if you get any error messages, we don't have the right motherboard so it will be confused), you should see "AsrDrv104.sys" in Process Hacker 2 under the services tab. Right click on it and click "Start". It should change to status "Running". The IOCTL handler is now ready to process requests from usermode programs!

4. Open up the project in Visual Studio, run the project in Release. I'm not sure if Visual studio saves Configuration settings, but the projects titled "AsrDrvExploit" and "MyManualMapper" require C++17. Also, you need the WDK (Windows Driver Kit), which will provide the wdm.h header. There are a few more subtlties that may need to be figured out, setting up the driver kit can be a bit of a pain. I know it was for me.

5. Download DebugView, so we can see the output of the driver (since runs in kernel mode, the debug statements print to the kernel output). Setup your capture options like this.

6. Finally, run the driver and watch all the handle requests on the system get printed out in DebugView. You can change which processes have access to your target process by altering the isAllowedProgram function in Source.c. The output looks like this:

7. If you try to open your target process (here I used notepad.ex, you will see a spike in output, because the program is trying to deny all the handles that are being requested to your target process.

8. This program also periodically scans all the handles that exist to your target process, and strips them if they are not in the whitelist of functions and the permissions are too high. This is why the console output will keep moving down. To stop this, just disable autoscroll:

8. To unload, just open a command prompt and type doskey. There's nothing special about running this in particular, in fact, the doskey driver is just another example of a driver that doesn't do anything (since it runs for DOS only). I just made it so that if the handle that is being requested is made to doskey, the driver will unload. Unload output looks like this:

9. And there you go, we have a simple handle monitor that parellels something that a anti-cheat would do. Although, this is kind of like 2 projects in 1, because you can write whatever you would really like in Source.c, and run whatever routines you would like in kernel mode. This is the true power of this exploit!