Rootkit Design

An attacker typically designs a rootkit to affect a particular OS and software set. If the rootkit is designed with direct hardware access, then it will be limited to that specific hardware. Rootkits can be generic to different versions of an OS, but will still be limited to a given OS family. For example, some rootkits in the public domain affect all flavors of Windows NT, 2000, and XP. This is possible only when all the flavors of the OS have similar data structures and behaviors. It would be far less feasible to create a generic rootkit that can infect both Windows and Solaris, for example.

A rootkit may use more than one kernel module or driver program. For instance, an attacker may use one driver to handle all file-hiding operations, and another driver to hide registry keys. Distributing the code across many driver packages is sometimes a Good Thing because it helps keep the code manageable as long as each driver has a specific purpose. It would be hard for an attacker to manage a monolithic "kitchen-sink" driver that provides every feature known to man.

A complex rootkit project might have many components. It helps to keep things organized in a large project. Although we won't develop any examples that are quite so complex in this book, the following directory structure might be used by a complex rootkit project:

 /My Rootkit     /src/File Hider 

One Rootkit, One System

One rootkit should be enough for any system. A rootkit is invasive and alters data on the system. Although attackers generally keep this invasive alteration to a minimum, installing multiple rootkits may cause alterations of alterations, leading to possible corruption. Rootkits assume, in most cases, that the system is clean. A rootkit may perform checks for anti-hacker software (such as desktop firewalls), but it usually doesn't check for another rootkit. If another rootkit were found to be already installed on the system, the attacker's best strategy might be to "fail out" (that is, stop executing due to an error).

File-hiding code can be complex and should be contained in its own set of source-code files. There are multiple techniques for file hiding, some of which could require a great deal of code. For example, some file-hiding techniques require hooking a large number of function calls. Each hook requires a fair amount of source code.

 /src/Network Ops 

Network operations require NDIS^[1] and TDI^[2] code on Microsoft Windows. These drivers tend to be large, and they sometimes link to external libraries. Again, it makes sense to confine these features to their own source files.

^[1] Network Driver Interface Specification

^[2] Transport Driver Interface

 /src/Registry Hider 

Registry-hiding operations may require different approaches than file-hiding features. There may be many hooks involved, and perhaps tables or lists of handles that need to be tracked. In practice, registry-key hiding has been problematic due to the way keys and values relate to one another. This has caused some rootkit developers to craft rather complex solutions to the problem. Again, this feature set should be confined to its own set of source files.

 /src/Process Hider 

Process hiding should use Direct Kernel Object Manipulation (DKOM) techniques (described in Chapter 7). These files may contain reverse-engineered data structures and other information.

 /src/Boot Service 

Most rootkits will need to be restarted if the computer reboots. An attacker would include a tiny service here that is used to "kick start" the rootkit at boot time. Getting a rootkit to restart with the computer is a complex topic. On the one hand, a simple registry key change can cause a file to lauch on boot-up. On the other hand, such an approach is easily detected. Some rootkit developers have crafted complex boot capabilties that involve on-disk kernel patches and modifications to the system boot-loader program.

 /inc 

Commonly included files containing typedefs, enums, and I/O Control (IOCTL) codes will go here. These files are typically shared by all other files, so deserve their own special location.

 /bin 

All the compiled files will go here.

 /lib 

The compiler will have its own set of libraries elsewhere, so the attacker could use this location for her own additional libraries or third-party libraries.