Introducing Code into the Kernel

The straightforward way to introduce code into the kernel is by using a loadable module (sometimes called a device driver or kernel driver). Most modern operating systems allow kernel extensions to be loaded so that manufacturers of third-party hardware, such as storage systems, video cards, motherboards, and network hardware, can add support for their products. Each operating system usually supplies documentation and support to introduce these drivers into the kernel. This is the easy route, and is the road we will take to introduce code into the kernel.

As its name suggests, a device driver is typically for devices. However, any code can be introduced via a driver. Once you have code running in the kernel, you have full access to all of the privileged memory of the kernel and system processes. With kernel-level access you can modify the code and data structures of any software on the computer.

A typical module would include an entry point and perhaps a cleanup routine. For example, a Linux-loadable module may look something like this:

 int init_module(void) { } void cleanup_module(void) { } 

In some cases, such as with Windows device drivers, the entry point must register function callbacks. In such a case, the module would look like this:

 NTSTATUS DriverEntry( ... ) {      theDriver->DriverUnload = MyCleanupRoutine; } NTSTATUS MyCleanupRoutine() { } 

A cleanup routine is not always needed, which is why Windows device drivers make this optional. The cleanup routine would be required only if you plan on unloading the driver. In many cases, a rootkit can be placed into a system and left there, without any need to unload it. However, it is helpful during development to have an unload routine because you may want to load newer versions of the rootkit as it evolves. Most example rootkits provided by rootkit.com include unload routines.^[3]

^[3] A set of basic rootkits known as the "basic_class" can be found at rootkit.com.