KDU Kernel Driver Utility

KDU is a kernel driver utility designed to explore Windows kernel components without requiring a local debugger. It provides capabilities for protected process hijacking, bypassing Driver Signature Enforcement (DSE), and loading drivers via vulnerable third-party providers.

System Requirements:

• x64 Windows 7/8/8.1/10/11
• Administrative privileges

Warning: Using this tool may cause a Blue Screen of Death (BSOD). It is highly recommended to use KDU only within virtual machines.

To build KDU from the provided source code, you require the following environment:

• IDE: Microsoft Visual Studio 2019 or later.
• Driver Development: Microsoft Windows Driver Kit (WDK) 10 or above.

Deployment Note: When running the compiled binaries, kdu.exe and drv64.dll (the drivers database) must reside in the same directory and have read/write access enabled. All binaries MUST be unblocked from the system zone.

To enable support for the AsIO2 driver (provider #13) in KDU, you must generate the required 'unlocking' resource. This is done using the GenAsIo2Unlock utility.

If you are building KDU from source, this utility is configured to run automatically as a post-build event for both Debug and Release configurations. If you are manually managing the build, ensure you do not remove this post-build event, otherwise the newly compiled KDU will not be able to use the AsIO2 driver.

When running as an executable, Taigei can be configured to target specific devices by passing a numeric key as the first command-line argument. This is used to open a handle to a specific driver device and send that handle to the server via IpcSendHandleToServer.

Available target device keys:

• 0 (default): Targets \Device\KObjExp
• 1: Targets \Device\KRegExp

To map a driver file to the kernel, use the -map command. Depending on the shellcode version used, additional parameters may be required.

Command Syntax: kdu -map <filename> [options]

Options:

• -scv <version>: Select shellcode version (default is 1). Use version 3 for specific driver object/registry requirements.
• -drvn <name>: (Only for shellcode version 3) Sets the Driver object name.
• -drvr <name>: (Only for shellcode version 3) Sets the driver registry key name.

Example (Shellcode V3):

kdu -scv 3 -drvn MyName -map MyDriver.sys

In 32-bit (x86) environments, Taigei can be used to unlock the Cheat Engine driver (\\.\CEDRIVER73). This is achieved by using the DllMainUnlockDBK entry point.

When the DLL is attached to a process (DLL_PROCESS_ATTACH), it performs the following steps:

1. Loads its own raw executable content from disk.
2. Locates the .text section of the current process image.
3. Overwrites the process's .text section with its own raw .text section.
4. Opens a handle to \\.\CEDRIVER73.
5. Sends the driver handle to the server via IpcSendHandleToServer.

Note: This specific functionality is only compiled for 32-bit targets and uses the entry point DllMainUnlockDBK.

Microsoft (MSFT) uses several methods to blacklist drivers. These criteria are noted in the provider metadata:

• Cert: The driver is banned based on the certificate used to sign it, allowing multiple files to be banned simultaneously.
• Name: The driver is banned by its original filename entry stored in the VERSION_INFO file resources. This requires cross-checking file versions to avoid false positives on unaffected versions.
• Hash / Page hash: The driver is banned by its Authenticode hash or page hash, allowing MSFT to target an exact driver file.