EXE Files

The EXE executable file format is somewhat more complex than the COM file format. The EXE file consists of two primary sections. The first section is a header that tells DOS how to load the program (see fig. 15.6). The header includes two fields that identify the location of the EXE file’s single entry point in the program: the Code Segment (CS) and the Instruction Pointer (IP).

Figure 15.6  How an EXE file is loaded into RAM and executed.

The header also includes two size fields that specify the actual size of the executable program. When a virus infects an EXE file, it must increase the value in the size fields to equal the total of the executable program file size and the virus program size. For instance, when a virus that is 2 KB in size appends itself to a 10 KB file, it increases the value in these fields to 12 KB.

The second section of the EXE file, known as the program load image, contains the actual memory image of the program and its data.

SYS Files

The SYS executable file format differs from both the COM and EXE file formats in that SYS files have two entry points (see fig. 15.7). SYS format files are used primarily for device drivers. Like COM files, all SYS files must be 64 KB or less in size. The SYS file is composed of three major sections. The first portion of the SYS file contains the device header. Like the header of an EXE file, the device header contains entry point information and other fields.

Figure 15.7  How a SYS file is loaded into RAM.

The second and third sections of the SYS file contain the two device driver modules, which contain all the machine language code in the program.

Program files are often targeted for two primary reasons. Because each of the executable file types has a simple format, file viruses can piggyback themselves to program files with relative ease. Executable file types also are common targets for infection because of the frequency of their use. If a virus can infect an executable file, its capability to infect other programs increases.

Data Files with Macro Capabilities

Virus researchers have known for some time now that macro viruses exist. Only within the past year, however, have a large number of new macro viruses been created, at least one of which has been encountered in the wild.

Macro facilities enable a user to record a sequence of operations within the application. The user then uses a key combination to associate these operations. Later, pressing this key combination repeats the recorded steps. A given macro activated using a key combination, for example, might open a file, renumber the items within it, then close the file.

Macro systems have evolved greatly over the years. Most old programs that supported macros had a “global pool” of macros that always were available for use, regardless of what file the user happened to be editing. Individual document or spreadsheet files could not contain their own, local, macros.

Modern macro systems differ from their predecessors in several key ways. First, users now can write entire complex programs in a macro language. These programs have access to all the host application’s features, as well as many of the operating system’s features. Microsoft products, for example, enable users to write macros in a language that resembles Visual Basic.

These macros can perform various tasks for the user, including popping up dialog boxes, altering files on the system, or inserting the date and time in a document. They can also be used to write viruses!

The second difference found in modern macro systems is that the user can tote specific macros around in a document or spreadsheet data file. A user can create a macro for a specific spreadsheet, for example, and attach it directly to the spreadsheet file. Any time the file is used on a new machine, the accompanying macro is available for use. An inherent threat exists with this situation: just as normal macros can be attached and carried along with a given document or data file, so can macro viruses!

These modern macro languages, such as Word for Windows’ WordBasic, are interpreted by the host application and often are compatible across different operating systems. A Word for Windows 6.0 document that contains macros created on a PC, for instance, can be edited in Word for Macintosh. Because Word for Macintosh provides the same macro facilities as its DOS counterpart, the document’s macros also function on the Macintosh platform. This cross-platform compatibility means that a macro virus can spread from computer to computer, as long as the destination computer supports a macro-capable, compatible version of the host application.

Microsoft Word’s macro system actually offers a global pool macro area, as well as document-specific macros. Users can establish a set of global macros available for use regardless of the document being edited. They also can use the local macros that accompany a specific document during editing of that document.

In the Microsoft scheme, macros can copy themselves to and from the global and local pools (see fig. 15.8). The global pool provides the macros with the capability to migrate from one document to another. Upon execution, a macro can copy itself from a local pool to the global pool. Later, executing the same macro lets it copy itself from the global pool to a new document—a nice feature, as long as the user initiates the actions and knows of the results. Viruses can target this facility.

Figure 15.8  How macros can migrate from file to file.

The Word for Windows macro system also includes an auto-execution facility that makes it attractive to viruses. Just as DOS has its AUTOEXEC.BAT file that is executed during bootup, Word for Windows has an AutoExec macro that launches (if it is present in the global pool) when a user starts the word processor. This facility can serve to execute other macros and set up the user’s work environment—or a virus can exploit it to ensure that the virus macro executes upon Word for Windows startup.

In addition to the AutoExec macro, Word for Windows contains numerous other macros that activate during a normal editing session without directly being activated by the user. Any time the user opens a new document file, for example, a macro known as AutoOpen executes from the document’s local macro pool (if present). A virus could easily use this macro to copy itself to the global pool as soon as a user opens the document.