Baby Steps in Windows Device Driver Development: Part 2, “Hello World” Driver

Baby Steps in Windows Device Driver Development: Part 1, Install the Tools and Configure Kernel Debugging

May 30, 2011

tags: Drivers, WindowsInternals

one comment

As part of the Windows Internals course at SELA, I recently designed a set of exercises that serve as an introduction to Windows device driver development. Their purpose is to obtain a very cursory familiarity with what it means to build, deploy and load a driver, and consider some of the things available to kernel-mode components which make them way cooler than user-mode applications.

Some of this work can be turned easily into a series of blog posts, which you can enjoy outside of the course’s context. However, if you’re looking for background on Windows subsystems and components, what it means to deliver DPCs and interrupts, how IRQLs limit driver execution, why threads are scheduled the way they are, how synchronization mechanisms work, how memory is allocated and memory addresses are translated, and many other extremely important details on how Windows works—Windows Internals is the course for you. (And so is “the book”—Windows Internals, 5th Edition.)

First and foremost, you need to set up an environment in which you will build, deploy, and load your driver. We will be using a host machine on which we’ll build and debug, and a target virtual machine to which the driver will be deployed. My own setup is a Windows 7 64-bit physical host and a Windows XP 32-bit target VM, running VMWare Workstation.

1. Download the Debugging Tools for Windows (both 32- and 64-bit editions) and install them on the host machine.

2. Download the Windows Driver Kit and install it on the host machine.

3. Set up a virtual machine running Windows XP or a newer version. (The instructions below are applicable to Windows XP or Windows Server 2003, 32-bit editions.)

4. Go to My Computer | Properties | Advanced Settings and choose Startup and Recovery | Edit. You should see an OS boot choice similar to the following:

multi(0)disk(0)rdisk(0)partition(1)\WINDOWS="Windows XP Professional" /fastdetect

5. Add /debug /debugport=com1 to the line above.

6. In the virtual machine’s settings, redirect the COM1 port to a pipe called \\.\pipe\com_1. (This step depends on your virtualization product. For example, in VMWare Workstation you will need to add a new serial port.)

7. Launch WinDbg and select File | Kernel Debug. On the COM tab, use the following settings:

8. Click “OK”.

9. Start the virtual machine and make sure the debugger connection is established. You can hit Ctrl+Break in WinDbg to issue a breakpoint to the virtual machine, and then use any kernel-mode WinDbg commands. (Try!process 0 0 for a process list.)

10. Register at OSR Online, download the OSR Driver Loader, and copy the appropriate OSRLoader.exe to your target virtual machine. (For example, Windows XP 32-bit free build version is in the WXP\i386\FRE subdirectory of the ZIP archive you downloaded.)

In the next part, we will compile our first driver and load it onto the system using OSR Driver Loader.

Baby Steps in Windows Device Driver Development: Part 2, “Hello World” Driver

June 4, 2011

tags: Drivers, WindowsInternals

3 comments

In this installment, we will compile and deploy our first driver. You should have all the tools installed already.

Windows device drivers are reactive programs—all they really do is respond to events, somewhat similar to GUI programs. The kinds of events drivers recognize include:

· Loading the driver into memory and unloading it from memory

· Adding a new hardware device for which the driver is responsible

· Transitioning to a power-savings mode

· Reading and writing from a device

· Handling an interrupt arriving from a device

A driver handles these events by registering functions that Windows invokes. In this post, we will use only two of these functions, invoked when a driver is loaded and unloaded.

Type the following into your favorite code editor and save it as HelloWorldDriver.c:

#include <ntddk.h>

void DriverUnload(
PDRIVER_OBJECT pDriverObject)
{
DbgPrint("Driver unloading\n");
}

NTSTATUS DriverEntry(
PDRIVER_OBJECT DriverObject,
PUNICODE_STRING RegistryPath)
{
DriverObject->DriverUnload = DriverUnload;
DbgPrint("Hello, World\n");
return STATUS_SUCCESS;
}

This is your first driver. Very simple indeed—all this driver does is print a couple of debugging messages when you load it and unload it. You will need a couple of build files that tell the build engine what to do with your sources. Here are the files:

File name: SOURCES

TARGETNAME = HelloWorldDriver
TARGETPATH = obj
TARGETTYPE = DRIVER

INCLUDES = %BUILD%\inc
LIBS = %BUILD%\lib

SOURCES = HelloWorldDriver.c

File name: makefile.def

!INCLUDE $(NTMAKEENV)\makefile.def

To compile the driver, open the build environment for your target OS from the Windows Driver Kits start menu folder. The “checked” build is akin to Debug mode, and the “free” build is equivalent to Release mode.

All that’s left now is to compile the driver. In the WDK build environment command prompt, navigate to the directory containing your driver’s source code, the SOURCES and makefile.def files, and then run the buildcommand. If there have been no errors, you should see a .pdb file and a .sys file created in a subdirectory.

And now—deployment time. Copy your files over to the target system (preferably a virtual machine) and run the OSR Driver Loader. Point it to your driver’s location, click “Register Service” and then “Start Service”. Your driver should be running!

If you want to see the debugger output, you need to use a utility like Sysinternals DebugView. In DebugView, hit Ctrl+K to enable kernel debug spew, and then start/stop your driver a few times. You should see load and unload messages pile up in the DebugView window.

How far is this driver of ours from being useful? From talking to actual hardware? Quite far, and I’m not sure we’ll make it that far However, in the near future we sure are going to run some interesting code in kernel mode and in the somewhat farther future see how rootkits use drivers to hide processes and files.

Date: 2016-04-22; view: 1350