Chapter 3/ Hardware Briefing

subtle, you could alter the initial location of the jump so that it's buried deep

within the file. To evade checksum tools, you could patch the memory image

at runtime, a technique that I will revisit later on in exhaustive detail.

Synopsis

Now that our examination of real mode is complete, let's take a step back to

see what we've accomplished in more general terms. In this section, we have

modified address lookup tables to intercept system calls;

leveraged existing drivers to intercept data;

manipulated system data structures to conceal an application;

altered the makeup of an executable to reroute program control.

Modifying address lookup tables to seize control of program execution is

known as call table hooking. This is a well-known tactic that has been imple¬

mented using a number of different variations.

Stacking a driver on top of another (the layered driver paradigm) is an excel¬

lent way to restructure the processing of I/O data without having to start over

from scratch. It's also an effective tool for eavesdropping on data as it travels

from the hardware to user applications.

Manipulating system data structures, also known as direct kernel object

manipulation (DKOM), is a relatively new frontier as far as rootkits go.

DKOM can involve a bit of reverse engineering, particularly when the OS

under examination is proprietary.

Binaries can also be modified on disk {offline binary patching) or have their

image in memory updated during execution {runtime binary patching). Early

rootkits used the former tacdc by replacing core system and user commands

with altered versions. The emergence of file checksum utilities and the grow¬

ing trend of performing offline disk analysis have made this approach less

attractive, such that the current focus of development is on runtime binary

patching.

So there you have it: call table hooking, layered drivers, DKOM, and binary

patching. These are some of the more common software primitives that can

be mixed and matched to build a rootkit. Although the modifications we made

in this section didn't require that much in terms of technical sophistication

(real mode is a Mickey Mouse schcme if there ever was one), we will revisit

86 I Part I