Windows 7 x64 Kernel Exploitation – Setup (1/3)

Several months ago, I took a short sojourn into the world of Windows Kernel exploitation, based on the work of hacksysteam and their excellent HackSys Extreme Vulnerable Driver (github here). I learned some things, and built a short community presentation on this, which was quietly presented a few times. I post this here in the hopes that someone finds this useful.

All of this work was done against a Windows 7 x64 target: when I get time, I will update this to a Windows 10 target (this may be a while). Fair warning, I am by no means an expert by any stretch of the imagination.

If you’d rather see a condensed presentation instead of my caffeine-fuelled shitposting, please download a PDF:

Without further ado:


As mentioned above, our target was set up as follows:

  • Host:
    • Windows 8.1 x64, Windows 10 x64
    • Visual Studio 2015 Community
    • Windows 10 DDK
    • VirtualBox
    • WinDbg
  • Guest:
    • Windows 7 x64
      • Windows 7 SDK (for cl.exe – but any language will work. you just need to call things)
      • FASM (because fuck you, visual studio. fuck you and your compiler intrinsics).
    • Hacksys Extreme Vulnerable Driver, self-built
    • OSR Loader (

We needed to use the “bcdedit.exe” utility to configure the target Windows 7 box to allow the loading of unsigned drivers, as follows:

bcdedit /set TESTSIGNING ON
bcdedit /copy {current} /d "lol" (this will return something, which we refer to as $GUID)
bcdedit /set $GUID debugtype serial
bcdedit /set $GUID debugport 4
bcdedit /set $GUID baudrate 115200
bcdedit /debug $GUID on

From here, we configure WinDbg in our guest to allow kernel debugging:

From here, start WinDbg on the host first, then start your guest VM, and when the boot menu pops up, select the appropriate debug option. You should see something like this:

From here, hit break in WinDbg, and enter the following, to enable kernel debugging via printf (well, DbgPrint):


From here, enter into your target VM, and use OSRLoader to load the vulnerable driver (HEVD_7x64.sys), and start the HEVD service. You should see something like the following:

In the next two parts of this series, we will explore actually exploiting two of the vulnerabilities within the HEVD driver (specifically, the arbitrary overwrite, and the stack overflow).

About Norman

Sometimes, I write code. Occasionally, it even works.
This entry was posted in Bards, Computers, Jesting. Bookmark the permalink.

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s

This site uses Akismet to reduce spam. Learn how your comment data is processed.