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