Kernel Exploitation Primer 0x0 - Windows Driver 101

In this series, I’ll be sharing my notes on Windows Kernel Exploitation, it's mitigations, and related internals, explaining how they work and potential bypasses. This will be the first of many upcoming posts. I also made sure to add all the references.

Let’s begin the series by getting to know more about the windows drivers and how to write our own driver and how a client (user-mode application) can interact with that.

Table of Contents

What is Driver?
Environment Setup
Debugger Machine
Debugee Machine
Driver Development
Loading and Unloading the Driver
Dispatch Routines
User-Mode Code
Device Control

What is Driver?

A driver's main job is to help an operating system (OS) communicate with hardware devices. Most drivers on your computer enable the OS to interact with components like the motherboard, hard drives, or graphics card. When you buy new hardware, you often need to install software from the manufacturer. This software usually includes a driver that lets the computer communicate with the hardware. Drivers run in kernel mode for this reason.

Not all drivers manage hardware. Some are purely software-based and serve other purposes. For example, antivirus programs may use a driver to protect the system from harmful actions.

Using drivers for offensive operations is very risky.

If a regular user-mode program crashes, the worst that happens is losing unsaved data. The operating system handles the crash, creates a report, and frees up resources like memory or CPU. This keeps the problem contained to that specific program.

But with drivers running in kernel mode, the consequences are much worse if something goes wrong. When a user-mode program exits, the kernel ensures all its resources are freed. However, if a driver has memory leaks, the kernel won’t clean them up. Those resources remain locked until you restart the system. Unsafe actions in drivers can also cause the infamous "blue screen of death" (BSOD).

Environment Setup

For the purpose of learning and exploitation, I will be using two virtual machines:

Debugger Machine: This machine will have tools like IDA, Visual Studio 2022, and WinDbg installed for remote debugging.
Debuggee Machine: This machine will be used to load and interact with the drivers for testing and exploration.

Debugger Machine

You can download Visual Studio 2022 Community Edition here. During the installation process, make sure to select the following option:

Workloads → Desktop development with C++

This setup provides the necessary tools and libraries for C++ development.

During the installation of Visual Studio 2022 Community Edition, navigate to Individual components and select the latest Windows SDK to ensure you have the necessary tools and headers for Windows development.

In addition to selecting the latest Windows SDK under Individual components, make sure to check the option for the latest "MSVC - x64/x86 Spectre-mitigation libraries".

After setting up Visual Studio, proceed as follows:

Download and install the latest Windows Driver Kit (WDK) from this link.
- During the installation, when prompted to install the Visual Studio extension, make sure to enable it. This step adds driver development templates to Visual Studio.
Install WinDbg:
- For the Preview version, you can download it from the Microsoft Store or relevant sources.
- Alternatively, if you prefer the classic version, it comes bundled with the WDK. You can find it under: C:\Program Files (x86)\Windows Kits\10\Debuggers\x64, I will be mostly using the classic version in this series for now.
Choose the version that suits your workflow.

Open Visual Studio and search for KMDF. We will use the “Kernel Mode Driver, Empty (KMDF)” template. If you don’t see the templates, there might be an issue with the Visual Studio extension. You could try following the steps again.

Debugee Machine

The debuggee machine is where we will run the drivers. On this machine, download and install the latest Windows SDK from the provided link. During the installation, it will ask you to select the features to be installed. Choose “Debugging Tools for Windows”. Since we are performing remote kernel debugging, KDNET is required.

As everybody knows, we can’t load unsigned drivers in latest Windows 10 implemented Driver Signature Enforcement (DSE). This feature ensures that only drivers signed by a trusted certificate authority (CA) or Microsoft itself can be loaded into the kernel. Since we gonna load unsigned drivers we need to enable test mode.

You can enable Test Mode in Windows, which disables DSE, allowing unsigned drivers to be loaded.

$> bcdedit /set testsigning on
The operation completed successfully.

Also enabled the kernel debug mode:

$> bcdedit /debug on
The operation completed successfully.

To print debug messages, we need to enable the option in the registery open regedit and navigate to HKLM\SYSTEM\CurrentControlSet\Control\Session Manager.

Create a new key as “Debug Print Filter”.
Create a new DWORD inside that key as “DEFAULT” with a value of 8.

To setup remote kernel debugging, obtain the IP address of the debugger machine (e.g., 192.168.200.131). Then, open an administrative command prompt on the debuggee machine and run the following command:

$> "C:\Program Files (x86)\Windows Kits\10\Debuggers\x64\kdnet.exe" 192.168.200.131 50000

Enabling network debugging on Intel(R) 82574L Gigabit Network Connection.

To debug this machine, run the following command on your debugger host machine.
windbg -k net:port=50000,key=1qzexc8jtyfsp.160le6mwlos63.e3j0fykwgxer.203824bm3qbt8

Then reboot this machine by running shutdown -r -t 0 from this command prompt.

Don’t restart the machine yet.
Copy the key value.

In debugger machine, launch WinDBG and File → Kernel Debug → NET and paste the key.

Once the following message is displayed in the Command box, restart the Debuggee machine:

Sometimes, the debuggee machine may encounter a BSOD, but that’s fine. Just check WinDBG on the debugger machine and send the g command. It will eventually work, and you will see the following message:

Driver Development

Let’s start by writing our first Windows driver. I created a new project with the “Kernel Mode Driver, Empty (KMDF)” template and named the solution “Driver-Development”. The first project is named as “km-driver”.

The “km-driver” project is our kernel mode driver and I created one more project under same solution as “um-client” which is normal C++ Console App, this is our client (user-mode) application which will interact with the driver.

Create Source.cpp under km-driver project, and let’s begin the coding, the first thing a driver require is “DriverEntry”, this is like main function for user-mode application.

NTSTATUS DriverEntry(
  _In_ PDRIVER_OBJECT  DriverObject,
  _In_ PUNICODE_STRING RegistryPath
);

This is the skeleton code of our driver,

#include <ntddk.h>

extern "C" NTSTATUS DriverEntry(_In_ PDRIVER_OBJECT DriverObject, _In_ PUNICODE_STRING RegistryPath)
{
	UNREFERENCED_PARAMETER(DriverObject);
	UNREFERENCED_PARAMETER(RegistryPath);

	return STATUS_SUCCESS;
}

UNREFERENCED_PARAMETER macro is to avoid any errors while compiling, this is to indicate that a function parameter is intentionally unused.
extern "C" is a linkage specification in C++ that tells the compiler to use C linkage, this is to avoid name mangling.

For debugging purpose, we can use KdPrint macro which outputs debug information to a kernel debugger, such as WinDbg, during the execution of a kernel-mode driver.

#include <ntddk.h>

extern "C" NTSTATUS DriverEntry(_In_ PDRIVER_OBJECT DriverObject, _In_ PUNICODE_STRING RegistryPath)
{
	UNREFERENCED_PARAMETER(DriverObject);
	UNREFERENCED_PARAMETER(RegistryPath);

	KdPrint(("Hello from DriverEntry!\n"));

	return STATUS_SUCCESS;
}

Loading and Unloading the Driver

Copy the compiled driver to the Debugee machine. Windows uses the Service Control Manager (SCM) to manage services, including drivers. By registering the driver with sc create, you're informing the SCM that this binary is a kernel-mode driver, and the operating system should load and manage it accordingly. To load the driver, we can create the service with type as kernel.

$> sc create MyFirstDriver type= kernel binPath= C:\Users\Victim\Desktop\km-driver.sys
[SC] CreateService SUCCESS

This can be also automated using this OSR Driver Loader, which can be downloaded here.

Everything seems good, we can start the driver now.

$> sc qc MyFirstDriver
[SC] QueryServiceConfig SUCCESS

SERVICE_NAME: MyFirstDriver
        TYPE               : 1  KERNEL_DRIVER
        START_TYPE         : 3   DEMAND_START
        ERROR_CONTROL      : 1   NORMAL
        BINARY_PATH_NAME   : \??\C:\Users\Victim\Desktop\km-driver.sys
        LOAD_ORDER_GROUP   :
        TAG                : 0
        DISPLAY_NAME       : MyFirstDriver
        DEPENDENCIES       :
        SERVICE_START_NAME :

The driver can be started using the sc.exe as well:

$> sc start MyFirstDriver

SERVICE_NAME: MyFirstDriver
        TYPE               : 1  KERNEL_DRIVER
        STATE              : 4  RUNNING
                                (STOPPABLE, NOT_PAUSABLE, IGNORES_SHUTDOWN)
        WIN32_EXIT_CODE    : 0  (0x0)
        SERVICE_EXIT_CODE  : 0  (0x0)
        CHECKPOINT         : 0x0
        WAIT_HINT          : 0x0
        PID                : 0
        FLAGS              :

Now if you check the debugger machine, we can see the KdPrint message, because when a driver is loaded into the machine, it will call DriverEntry first and inside that we added the print:

If you try to stop the driver, it will fail, because the cleanup function for driver unload is not yet implemented, so it’s better restart the Debugee machine to replace the driver with updated one.

$> sc stop MyFirstDriver
[SC] ControlService FAILED 1052:

The requested control is not valid for this service.

To unload the driver we need to use DriverUnload() this will performs any operations that are necessary before the system unloads the driver.

DRIVER_UNLOAD DriverUnload;

void DriverUnload(
  [in] _DRIVER_OBJECT *DriverObject
)
{...}

Before that we need to know an important structure for driver called DRIVER_OBJECT. The DRIVER_OBJECT structure contains number of members but DriverUnload member is what we are interested, because that will be the function it will call when the driver tries to unload.

typedef struct _DRIVER_OBJECT {
  CSHORT             Type;
  CSHORT             Size;
  PDEVICE_OBJECT     DeviceObject;
  ULONG              Flags;
  PVOID              DriverStart;
  ULONG              DriverSize;
  PVOID              DriverSection;
  PDRIVER_EXTENSION  DriverExtension;
  UNICODE_STRING     DriverName;
  PUNICODE_STRING    HardwareDatabase;
  PFAST_IO_DISPATCH  FastIoDispatch;
  PDRIVER_INITIALIZE DriverInit;
  PDRIVER_STARTIO    DriverStartIo;
  PDRIVER_UNLOAD     DriverUnload;
  PDRIVER_DISPATCH   MajorFunction[IRP_MJ_MAXIMUM_FUNCTION + 1];
} DRIVER_OBJECT, *PDRIVER_OBJECT;

Create a new header file in your project called func_decl.h and add the following code. This file will hold all the declaration of the functions we gonna use in Source.cpp file.

Why we need declaration? The compiler processes code line by line. If it encounters a function call before encountering its definition, it needs a declaration to know the function's signature (return type, name, parameters).

#pragma once
#include <ntddk.h>

void Cleanup(PDRIVER_OBJECT DriverObject);

This is our updated Source.cpp:

As you see we specify DriverUnload to a custom function called Cleanup, since we are calling that in DriverEntry(), before the actual definition and that’s why we already declared that in func_decl.h.

#include <ntddk.h>
#include "func_decl.h"

extern "C" NTSTATUS DriverEntry(_In_ PDRIVER_OBJECT DriverObject, _In_ PUNICODE_STRING RegistryPath)
{
	UNREFERENCED_PARAMETER(RegistryPath);

	KdPrint(("Hello from DriverEntry!\n"));

	DriverObject->DriverUnload = Cleanup;

	return STATUS_SUCCESS;
}

void Cleanup(PDRIVER_OBJECT DriverObject)
{
	UNREFERENCED_PARAMETER(DriverObject);

	KdPrint(("Hello from DriverUnload\n"));
}

Compile and replace the new driver in the Debugee machine and start the driver once again:

$> sc start MyFirstDriver

SERVICE_NAME: MyFirstDriver
        TYPE               : 1  KERNEL_DRIVER
        STATE              : 4  RUNNING
                                (STOPPABLE, NOT_PAUSABLE, IGNORES_SHUTDOWN)
        WIN32_EXIT_CODE    : 0  (0x0)
        SERVICE_EXIT_CODE  : 0  (0x0)
        CHECKPOINT         : 0x0
        WAIT_HINT          : 0x0
        PID                : 0
        FLAGS              :

Now if you attempt to stop, it will work and we can see the message as well:

$> sc stop MyFirstDriver

SERVICE_NAME: MyFirstDriver
        TYPE               : 1  KERNEL_DRIVER
        STATE              : 1  STOPPED
        WIN32_EXIT_CODE    : 0  (0x0)
        SERVICE_EXIT_CODE  : 0  (0x0)
        CHECKPOINT         : 0x0
        WAIT_HINT          : 0x0

Dispatch Routines

In addition to DriverUnload, the DRIVER_OBJECT also includes the MajorFunction member, which is also an important member.

typedef struct _DRIVER_OBJECT {
  CSHORT             Type;
  CSHORT             Size;
  PDEVICE_OBJECT     DeviceObject;
  ULONG              Flags;
  PVOID              DriverStart;
  ULONG              DriverSize;
  PVOID              DriverSection;
  PDRIVER_EXTENSION  DriverExtension;
  UNICODE_STRING     DriverName;
  PUNICODE_STRING    HardwareDatabase;
  PFAST_IO_DISPATCH  FastIoDispatch;
  PDRIVER_INITIALIZE DriverInit;
  PDRIVER_STARTIO    DriverStartIo;
  PDRIVER_UNLOAD     DriverUnload;
  PDRIVER_DISPATCH   MajorFunction[IRP_MJ_MAXIMUM_FUNCTION + 1];
} DRIVER_OBJECT, *PDRIVER_OBJECT;

MajorFunction is an array of pointers that specifies operations that the driver supports. Without these, a caller (client) cannot interact with the driver.
Each major function is referenced with an IRP_MJ_ prefix, where IRP is short for "I/O Request Packet". Common functions include:
- IRP_MJ_CREATE
- IRP_MJ_CLOSE
- IRP_MJ_READ
- IRP_MJ_WRITE
- IRP_MJ_DEVICE_CONTROL

A driver will typically need to support at least IRP_MJ_CREATE and IRP_MJ_CLOSE, as these enable the client that calls the driver to open and close the drivers handle. The prototype for a dispatch routine is as follows:

NTSTATUS SomeMethod(_In_ PDEVICE_OBJECT DeviceObject, _In_ PIRP Irp);

For now, let's create a simple implementation that returns a success status.

This is our first MajorFunction called CreateClose which does nothing, just prints the hello message in the debugger.
At the end of every MajorFunction, we need to set the IRP’s IoStatus and complete the IRP request by calling IoCompleteRequest.

NTSTATUS CreateClose(_In_ PDEVICE_OBJECT DeviceObject, _In_ PIRP Irp)
{
	UNREFERENCED_PARAMETER(DeviceObject);
	KdPrint(("Hello from CreateClose\n"));

	Irp->IoStatus.Status = STATUS_SUCCESS;
	Irp->IoStatus.Information = 0;

	IoCompleteRequest(Irp, IO_NO_INCREMENT);

	return STATUS_SUCCESS;
}

We can then point the create and close major functions at this routine.

IRP_MJ_CREATE - When a handle to the driver is created.
IRP_MJ_CLOSE - When a handle to the driver is closed.

DriverObject->MajorFunction[IRP_MJ_CREATE] = CreateClose;
DriverObject->MajorFunction[IRP_MJ_CLOSE]  = CreateClose;

In the DriverEntry function, the first step is to call IoCreateDevice(), which creates a device object for the driver. This device object serves as the interface between the system, including user-mode applications, and the driver. I/O requests (IRPs) are directed to this device object. Next, IoCreateSymbolicLink() is called to establish a symbolic link, allowing user-mode applications to access the device.

#include <ntddk.h>
#include "func_decl.h"

extern "C" NTSTATUS DriverEntry(_In_ PDRIVER_OBJECT DriverObject, _In_ PUNICODE_STRING RegistryPath)
{
	NTSTATUS status;
	PDEVICE_OBJECT deviceObject;

	UNREFERENCED_PARAMETER(RegistryPath);

	KdPrint(("Hello from DriverEntry!\n"));

	DriverObject->DriverUnload = Cleanup;
	DriverObject->MajorFunction[IRP_MJ_CREATE] = CreateClose;
	DriverObject->MajorFunction[IRP_MJ_CLOSE] = CreateClose;

	// create device object
	status = IoCreateDevice(
		DriverObject,
		0,
		&deviceName,
		FILE_DEVICE_UNKNOWN,
		0,
		FALSE,
		&deviceObject
	);

	if (!NT_SUCCESS(status)) {
		KdPrint(("[!] IoCreateDevice failed: 0x%08X\n", status));
		return status;
	}

	// create symlink
	status = IoCreateSymbolicLink(
		&symLink,
		&deviceName);

	if (!NT_SUCCESS(status)) {
		KdPrint(("[!] IoCreateSymbolicLink failed: 0x%08X\n", status));

		// delete device
		IoDeleteDevice(deviceObject);

		return status;
	}

	return STATUS_SUCCESS;
}

NTSTATUS CreateClose(_In_ PDEVICE_OBJECT DeviceObject, _In_ PIRP Irp)
{
	UNREFERENCED_PARAMETER(DeviceObject);
	KdPrint(("Hello from CreateClose\n"));

	Irp->IoStatus.Status = STATUS_SUCCESS;
	Irp->IoStatus.Information = 0;

	IoCompleteRequest(Irp, IO_NO_INCREMENT);

	return STATUS_SUCCESS;
}

void Cleanup(PDRIVER_OBJECT DriverObject)
{
	KdPrint(("Hello from DriverUnload\n"));

	// delete symlink
	IoDeleteSymbolicLink(&symLink);

	// delete device object
	IoDeleteDevice(DriverObject->DeviceObject);
}

Modified the Cleanup function to delete the symlink using IoDeleteSymbolicLink() and delete the device object using IoDeleteDevice(). Because in kernel it won’t clean them up for us, to avoid any leaks, we should clean up everything by ourself.

As mentioned earlier, the updated code will enable a userland application to open and close a handle to the driver. To facilitate this, the driver must first have an associated device object and a symbolic link.

#pragma once
#include <ntddk.h>

UNICODE_STRING deviceName = RTL_CONSTANT_STRING(L"\\Device\\MyFirstDriver");
UNICODE_STRING symLink = RTL_CONSTANT_STRING(L"\\??\\MyFirstDriver");

void Cleanup(PDRIVER_OBJECT DriverObject);
NTSTATUS CreateClose(_In_ PDEVICE_OBJECT DeviceObject, _In_ PIRP Irp);

User-Mode Code

Now that the new driver is ready, it’s time to write a user-mode (client-side) code which interacts with the driver from user-land, I created a new C++ console application in the Visual Studio solution.

To open a handle to the driver, a client can use the CreateFile API, where the 'filename' corresponds to the symbolic link of the driver device. Once the handle is no longer needed, it can be closed using the CloseHandle() API.

#include <Windows.h>
#include <stdio.h>

int main()
{
    HANDLE  hDriver;

    // open handle
    printf("[+] Opening handle to driver\n");

    hDriver = CreateFile(
        L"\\\\.\\MyFirstDriver",
        GENERIC_WRITE,
        FILE_SHARE_WRITE,
        nullptr,
        OPEN_EXISTING,
        0,
        nullptr);

    if (hDriver == INVALID_HANDLE_VALUE)
    {
        printf("[!] Failed to open handle: %d", GetLastError());
        return 1;
    }

    // little sleep
    printf("[+] Sleeping...\n");
    Sleep(3000);

    // close handle
    printf("[+] Closing handle\n");
    CloseHandle(hDriver);
}

Before compiling the um-client.exe, change the “Runtime Library” to Multi-threaded (/MT). And make sure you build them in Debug mode otherwise the KdPrint won’t work.

Copy the new driver and the client (um-client.exe) to the Debugee machine and started the driver:

$> sc start MyFirstDriver

Execute the application:

C:\Users\Victim> Desktop\um-client.exe
[+] Opening handle to driver
[+] Sleeping...
[+] Closing handle

Stop the driver:

$> sc stop MyFirstDriver

Now check the WinDBG for the KdPrint messages, as expected

The first print is when the driver loaded.
The second and third print is the create and close the handle of the driver by the user-mode application
The final print is driver unloaded. So now we have a working client which interacts with the driver.

Device Control

The next step is to expose some functionality in the driver that the client can invoke. For this, we can use the IRP_MJ_DEVICE_CONTROL major function. Its method signature should look like this:

NTSTATUS DeviceControl(_In_ PDEVICE_OBJECT DeviceObject, _In_ PIRP Irp);

Every driver can have multiple functionalities, so the client needs to specify which one it wants to interact with. This is done using 'Device Input and Output Controls' or IOCTLs. Create a new header file in the driver project called ioctl.h, and then add the following:

#pragma once

#define MY_DRIVER_DEVICE	0x8000
#define MY_CALCULATOR_IOCTL	CTL_CODE(MY_DRIVER_DEVICE, 0x800, METHOD_NEITHER, FILE_ANY_ACCESS)

The control codes should be built using the CTL_CODE macro. Here’s a quick overview of the parameters:

The first parameter is a DeviceType. You can technically provide any value, but according to Microsoft documentation, 3rd-party drivers should start from 0x8000.
The second parameter is a Function value. Similar to DeviceType, Microsoft suggests that 3rd-party function codes should start from 0x800. Each IOCTL in a driver must have a unique function value, so they are typically incremented (e.g., 0x800, 0x801, etc.).
The next parameter defines how input and output buffers are passed to the driver. METHOD_NEITHER tells the I/O manager not to provide any system buffers, meaning the IRP supplies the user-mode virtual address of the I/O buffers directly to the driver. In this case, the input buffer can be found at Parameters.DeviceIoControl.Type3InputBuffer of the PIO_STACK_LOCATION, and the output buffer at Irp->UserBuffer. There are risks associated with this, such as cases where the caller frees their buffer before the driver tries to write to it.
The final parameter indicates whether the operation is to the driver, from the driver, or both ways.

Let's add an functionality in the driver which takes user input via the user-mode application and does some mathematical calculation and return the result to the client.

First, I am creating a math.h header in the km-driver project and adding the following structures:

THE_ADDITION is used to take the user’s input, specifically two integers: FirstNumber and SecondNumber.
THE_ANSWER is used to send the result/answer back to the user.

We could implement this without structures, but let's make it more structured for clarity.

typedef struct _THE_ADDITION {
    int FirstNumber;
    int SecondNumber;
} THE_ADDITION, * PTHE_ADDITION;

typedef struct _THE_ANSWER {
    int Answer;
} THE_ANSWER, * PTHE_ANSWER;

Now, let’s implement the DeviceControl function, which the user-mode application (client) can invoke. First, we use IoGetCurrentIrpStackLocation, which returns a pointer to the IO_STACK_LOCATION structure. This structure represents the I/O stack associated with each IRP and contains information about the caller. For simplicity, we will refer to this structure as the "stack" in our explanation.

NTSTATUS DeviceControl(_In_ PDEVICE_OBJECT DeviceObject, _In_ PIRP Irp)
{
	UNREFERENCED_PARAMETER(DeviceObject);

	ULONG_PTR length = 0;
	NTSTATUS status = STATUS_SUCCESS;

	// get the caller's I/O stack location
	PIO_STACK_LOCATION stack = IoGetCurrentIrpStackLocation(Irp);

[::]

}

Using the stack, we can retrieve the specific IOCTL code that the caller has specified from Parameters.DeviceIoControl.IoControlCode. Next, we use a switch statement to direct the execution flow to the appropriate driver function based on the IOCTL code. Currently, we only have one IOCTL code defined, called MY_CALCULATOR_IOCTL. Finally, IoCompleteRequest is used to notify the caller that the driver has completed all I/O operations.

[::]

	// switch based on the provided IOCTL
	switch (stack->Parameters.DeviceIoControl.IoControlCode)
	{
	case MY_CALCULATOR_IOCTL:
	{
		KdPrint(("[+] Hello from MY_CALCULATOR_IOCTL\n"));

[::]

   }

	default:
		status = STATUS_INVALID_DEVICE_REQUEST;
		KdPrint(("[!] Unknown IOCTL code!\n"));
		break;
}

	IoCompleteRequest(Irp, IO_NO_INCREMENT);

	return status;
	
}

Let’s dive into the implementation of what MY_CALCULATOR_IOCTL does when a client interacts with this specific functionality:

First, we need to ensure that the input buffer size is sufficient. The expected buffer size can be checked using the InputBufferLength field from Parameters.DeviceIoControl.InputBufferLength.
Next, we retrieve the user-provided data from Parameters.DeviceIoControl.Type3InputBuffer. The data is cast to a pointer of type THE_ADDITION, as this is the expected input format for the MY_CALCULATOR_IOCTL IOCTL. If the user provides invalid data, it will not be processed and end with a status STATUS_INVALID_PARAMETER.

 		[::]

		// check that the input buffer length is
		// large enough to hold the expected struct
		if (stack->Parameters.DeviceIoControl.InputBufferLength < sizeof(THE_ADDITION))
		{
			KdPrint(("[!] Buffer too small to hold THE_ADDITION\n"));
			status = STATUS_BUFFER_TOO_SMALL;
			break;
		}

		PTHE_ADDITION question = (PTHE_ADDITION)stack->Parameters.DeviceIoControl.Type3InputBuffer;

		if (question == nullptr)
		{
			KdPrint(("[+] PTHE_ADDITION was null\n"));
			status = STATUS_INVALID_PARAMETER;
			break;
		}

		KdPrint(("[+] THE_ADDITION, first number: %d\n", question->FirstNumber));
		KdPrint(("[+] THE_ADDITION, second number: %d\n", question->SecondNumber));
		
		[::]

Next, we check the output buffer length, which can be retrieved from Parameters.DeviceIoControl.OutputBufferLength. To send the result back to the user-mode application, we access the UserBuffer from the IRP and cast it to a pointer of type THE_ANSWER because that’s what the driver returns as result.

We then perform the addition of FirstNumber and SecondNumber, which were provided by the user through the THE_QUESTION structure, and store the result in the THE_ANSWER structure.
Finally, we complete the I/O operation by setting the status of the operation and providing additional information about the processed data.

		if (stack->Parameters.DeviceIoControl.OutputBufferLength < sizeof(THE_ANSWER))
		{
			KdPrint(("[!] Buffer too small to hold THE_ANSWER\n"));
			status = STATUS_BUFFER_TOO_SMALL;
			break;
		}

		// cast the output buffer
		PTHE_ANSWER ans = (PTHE_ANSWER)Irp->UserBuffer;

		ans->Answer = question->FirstNumber + question->SecondNumber;
		KdPrint(("[+] THE_ANSWER, answer: %d\n", ans->Answer));

		length = sizeof(ans);

		break;
	}
	
	[::]
	
		Irp->IoStatus.Status = status;
		Irp->IoStatus.Information = length;
	
	[::]

In the DriveEntry, we must link the above explained DeviceControl function to the MajorFunction’s IRP_MJ_DEVICE_CONTROL:

DriverObject->MajorFunction[IRP_MJ_DEVICE_CONTROL] = DeviceControl;

Our driver is ready, this is the full code:

#include <ntddk.h>
#include "func_decl.h"
#include "ioctl.h"
#include "math.h"

extern "C" NTSTATUS DriverEntry(_In_ PDRIVER_OBJECT DriverObject, _In_ PUNICODE_STRING RegistryPath)
{
	NTSTATUS status;
	PDEVICE_OBJECT deviceObject;

	UNREFERENCED_PARAMETER(RegistryPath);

	KdPrint(("Hello from DriverEntry!\n"));

	DriverObject->DriverUnload = Cleanup;
	DriverObject->MajorFunction[IRP_MJ_CREATE] = CreateClose;
	DriverObject->MajorFunction[IRP_MJ_CLOSE] = CreateClose;
	DriverObject->MajorFunction[IRP_MJ_DEVICE_CONTROL] = DeviceControl;

	// create device object
	status = IoCreateDevice(
		DriverObject,
		0,
		&deviceName,
		FILE_DEVICE_UNKNOWN,
		0,
		FALSE,
		&deviceObject
	);

	if (!NT_SUCCESS(status)) {
		KdPrint(("IoCreateDevice failed: 0x%08X\n", status));
		return status;
	}

	// create symlink
	status = IoCreateSymbolicLink(
		&symLink,
		&deviceName);

	if (!NT_SUCCESS(status)) {
		KdPrint(("IoCreateSymbolicLink failed: 0x%08X\n", status));

		// delete device
		IoDeleteDevice(deviceObject);

		return status;
	}

	return STATUS_SUCCESS;
}

NTSTATUS CreateClose(_In_ PDEVICE_OBJECT DeviceObject, _In_ PIRP Irp)
{
	UNREFERENCED_PARAMETER(DeviceObject);
	KdPrint(("Hello from CreateClose\n"));

	Irp->IoStatus.Status = STATUS_SUCCESS;
	Irp->IoStatus.Information = 0;

	IoCompleteRequest(Irp, IO_NO_INCREMENT);

	return STATUS_SUCCESS;
}

NTSTATUS DeviceControl(_In_ PDEVICE_OBJECT DeviceObject, _In_ PIRP Irp)
{
	UNREFERENCED_PARAMETER(DeviceObject);

	ULONG_PTR length = 0;
	NTSTATUS status = STATUS_SUCCESS;

	// get the caller's I/O stack location
	PIO_STACK_LOCATION stack = IoGetCurrentIrpStackLocation(Irp);

	// switch based on the provided IOCTL
	switch (stack->Parameters.DeviceIoControl.IoControlCode)
	{
	case MY_CALCULATOR_IOCTL:
	{
		KdPrint(("[+] Hello from MY_CALCULATOR_IOCTL\n"));

		// check that the input buffer length is
		// large enough to hold the expected struct
		if (stack->Parameters.DeviceIoControl.InputBufferLength < sizeof(THE_ADDITION))
		{
			KdPrint(("[!] Buffer too small to hold THE_ADDITION\n"));
			status = STATUS_BUFFER_TOO_SMALL;
			break;
		}

		PTHE_ADDITION question = (PTHE_ADDITION)stack->Parameters.DeviceIoControl.Type3InputBuffer;

		if (question == nullptr)
		{
			KdPrint(("[+] PTHE_ADDITION was null\n"));
			status = STATUS_INVALID_PARAMETER;
			break;
		}

		KdPrint(("[+] THE_ADDITION, first number: %d\n", question->FirstNumber));
		KdPrint(("[+] THE_ADDITION, second number: %d\n", question->SecondNumber));

		if (stack->Parameters.DeviceIoControl.OutputBufferLength < sizeof(THE_ANSWER))
		{
			KdPrint(("[!] Buffer too small to hold THE_ANSWER\n"));
			status = STATUS_BUFFER_TOO_SMALL;
			break;
		}

		// cast the output buffer
		PTHE_ANSWER ans = (PTHE_ANSWER)Irp->UserBuffer;

		ans->Answer = question->FirstNumber + question->SecondNumber;
		KdPrint(("[+] THE_ANSWER, answer: %d\n", ans->Answer));

		length = sizeof(ans);

		break;
	}

	default:
		status = STATUS_INVALID_DEVICE_REQUEST;
		KdPrint(("[!] Unknown IOCTL code!\n"));
		break;
	}

	// set return information
	Irp->IoStatus.Status = status;
	Irp->IoStatus.Information = length;

	IoCompleteRequest(Irp, IO_NO_INCREMENT);

	return status;
}

void Cleanup(PDRIVER_OBJECT DriverObject)
{
	KdPrint(("Hello from DriverUnload\n"));

	// delete symlink
	IoDeleteSymbolicLink(&symLink);

	// delete device object
	IoDeleteDevice(DriverObject->DeviceObject);
}

Now, let’s create a user-mode executable to interact with the driver. To interact with an IOCTL, an IRP_MJ_DEVICE_CONTROL request need to be sent to the driver. In user-mode applications, this can be achieved using the DeviceIoControl API.

In real-world scenarios, we often don’t have access to the driver’s source code. In such cases, reverse engineering is required to identify the IOCTL codes, determine the expected input format, and understand how the results are returned. Based on this information, we can recreate the necessary structures or other components to communicate with the driver.

In this case, we already know the MY_CALCULATOR_IOCTL code and the associated structure. Therefore, we can simply reuse the existing headers for now.

#include <Windows.h>
#include <stdio.h>
#include "..\km-driver\ioctl.h"
#include "..\km-driver\math.h"

int main()
{
    HANDLE  hDriver;
    BOOL    success;

    // open handle
    printf("[+] Opening handle to driver\n");

    hDriver = CreateFile(
        L"\\\\.\\MyFirstDriver",
        GENERIC_WRITE,
        FILE_SHARE_WRITE,
        nullptr,
        OPEN_EXISTING,
        0,
        nullptr);

    if (hDriver == INVALID_HANDLE_VALUE)
    {
        printf("[!] Failed to open handle: %d", GetLastError());
        return 1;
    }

    // call MY_CALCULATOR_IOCTL
    printf("[+] Calling MY_CALCULATOR_IOCTL...");
    PTHE_ADDITION question = new THE_ADDITION{ 6, 9 };
    PTHE_ANSWER answer = new THE_ANSWER();
    DWORD bytesReceived = 0;

    success = DeviceIoControl(
        hDriver,
        MY_CALCULATOR_IOCTL,
        question,           // pointer to question
        sizeof(question),   // the size of question
        answer,             // pointer to answer
        sizeof(answer),     // the size of answer
        &bytesReceived,     // tells us the actual amount of data received
        nullptr);

    if (success) {
        printf("success\n");
        printf("[+] THE_ANSWER: %d\n", answer->Answer);
    }
    else {
        printf("failed: %d\n", GetLastError());
    }

    // close handle
    printf("[+] Closing handle\n");
    CloseHandle(hDriver);
}

The code is mostly self-explanatory. It creates the user input structure THE_ADDITION, which contains two members representing the two numbers to be added. This structure is sent to the driver. The output is then received in the THE_ANSWER structure, which is declared for this purpose. After execution, the code retrieves the result from the driver and prints the answer.

When reversing a real-world driver, the structure’s name is not important, only the types and sizes of the data being sent or received matters. Additionally, drivers don’t always explicitly expect a structured input; they can also accept plain, unstructured data.

Let’s build the updated driver and client, then switch to the debugee machine to execute them. From the results, we obtain the answer for the addition of 6 + 9 as 15, confirming that the driver successfully performed the calculation and returned the result.

$>C:\Users\Victim\Desktop\um-client.exe
[+] Opening handle to driver
[+] Calling MY_CALCULATOR_IOCTL...success
[+] THE_ANSWER: 15
[+] Closing handle

Checking the WinDBG, we can see the user input received from the client (via the KdPrint) and also the result of the calculation:

I believe this post provides a quick introduction to how drivers work and how clients interact with them. I’ve also included the blogs I referred — thanks to those resources. If you want to dive deeper, feel free to explore them!

References: