Partition Boot Records

You can partition a physical hard drive into several logical drives, each of which can contain its own operating system. Consequently, each logical drive needs its own Partition Boot Record to load the specific operating system present on that partition. The PBR always is located in the first track, sector, and head of each partition.

The PBR is most closely related to the floppy disk FBR. Like the FBR, each PBR has its own BIOS parameter block, which describes the important attributes about its logical drive. Each PBR also has its own bootstrap routine for loading the operating system that resides on the partition.

During system bootup, the MBR’s bootstrap routine determines which partition is active on the hard drive. It then loads the PBR from this partition by reading the first sector within the partition. If the PBR sector contains a valid signature, the MBR bootstrap routine transfers control to the PBR bootstrap routine. The PBR bootstrap routine can then load the remainder of the operating system on the partition.

The BIOS parameter block is the only section of the PBR that must remain intact (other than the signature at the end of the PBR) for DOS and other programs to properly understand the logical drive’s layout.

The PBR is often targeted because during the hard drive bootup process, the MBR bootstrap routine always loads and executes the active partition’s boot record. If a virus replaces the original PBR bootstrap routine with its own PBR bootstrap routine, you can rest assured that it will execute during a hard drive bootup.

System Services

Computer programs must call upon many low-level tasks during the course of their operation, including such tasks as reading and writing data to a floppy disk or displaying information on the monitor. ROM chips accompany most hardware add-ons, such as hard drives, video boards, and so forth. These chips contain machine language programs (routines) that handle most of the common requests that operating systems and applications make.

ROM-based software adheres to a well-known, published standard. If a program wants to write data to the hard drive, for example, it can call upon the routines on the hard drive ROM chips to perform the operation. Although the circuitry in each brand of hard drive might differ, this well-defined software interface allows programs to efficiently request services from hard drives and other peripherals without having to understand their internals.

ROM-based software is referred to as a system service provider. If a program needs to request a service from a peripheral, such as reading data from the hard drive, it can call upon the system service provider program in the ROM chip to communicate with the specific device and service the request.

The DOS operating system also offers system services to its applications. DOS installs its own service provider software in memory to service common requests, such as opening a file or writing data to a file. This DOS software works on top of the various hardware service providers and simplifies certain basic operations.

Many low-level tasks must be completed by the operating system, for example, before an application can open a file. As each task is processed, one or more requests might be made to the ROM-based hard drive system service. Figure 15.3 depicts system layering. The application requests a system service, such as opening a file. The application makes this request with a simple DOS call. DOS may make one or more low-level requests to the ROM service provider. Finally, the ROM service provider may interact with the hardware to service some requests. Because the typical program doesn’t care about how data actually is stored on the hard drive, as long as it can access it, DOS abstracts this for the program and offers a simple way to open files.

Figure 15.3  System layering.

Memory-resident programs, called TSRs, can hook into the system service provider software already resident in the computer’s memory and augment the services offered by the original service provider (see fig. 15.4). The “hooking” program can service all requests on its own or pass on some or all requests to the original service provider. It also can opt to modify information before passing it to a subservient service provider (one installed before the current service provider).

Figure 15.4  How resident file viruses hook into the operating system.

Most programs that hook into DOS or ROM services do so for legitimate reasons. Unfortunately, memory-resident viruses also can hook into these system services to damage data or spread to floppy disks and files.

Program Files

The most common executable file formats used under DOS are COM, EXE, and SYS. COM and EXE files are used for standard DOS programs, and SYS files are used for system device drivers. Although viruses have targeted each of these file formats, to date, reports of SYS file infections have been rare.

A program file consists of data and machine language instructions interpreted directly by the computer’s CPU. DOS program files contain one or two entry points, which are the locations in the program of the first instruction for the CPU to execute. You might compare a program to a notepad that contains a list of tasks. The entry point, then, would be the first task on the list. All COM and EXE files have a single entry point, while SYS files have two entry points. The CPU’s interpretation of a program’s instruction must always start with the instruction at the entry point. This makes the entry point an area that viruses can modify and thereby gain control of the computer. After the virus completes its dirty work, it can then transfer control to the original program.

Data files, by way of contrast, contain nonexecutable data. Because they contain no entry points, they cannot be infected with program-based computer viruses. They can be corrupted by a virus, but this generally results from sloppy coding. Replication is vital to the life of a virus, and writing to a data file results in a reproductive dead end.

COM Files

The COM executable file has the simplest DOS program file format. The COM file’s simplicity makes it a major target for file infecting viruses.

The contents of the COM file are loaded directly into memory and executed without modification (see fig. 15.5). The operating system transfers control to the first instruction in the memory image of the file. This first instruction is the COM file’s single entry point.

Figure 15.5  How a COM file is loaded into RAM and executed.

COM files have an upper size limit of approximately 64 KB.