Viruses are usually classed according to the following different aspects which

may overlap:

• according to target formats: executable viruses or document viruses;

• according to target component or device: for example viruses which take

over either boot sectors (boot viruses) or device drivers.

according to the programming language: assembly viruses, code source

viruses, interpreted language viruses (or script viruses).

• according to the behavior of the virus: armored viruses, slow or rapid

viruses, retroviruses, resident viruses, polymorphic viruses, stealth viruses,

etc.

• according to the nature of the final payload: spy viruses, corrupting

viruses, deletion viruses, destruction viruses...

• according to the way they operate: combined viruses, psychological

viruses (hoaxes, jokes)...

As the reader can imagine, there is a wide variety of viruses which are

worth reviewing. The classification we suggest has the advantage of being

functional (even though it is not the most popular one nor the most widely

used). It helps us to better comprehend some viruses which are usually left

out of the standard classifications. Another advantage is that the various

classes defined in such a way are quite always disjoint.

Polymorphism and stealth have not been taken into account in the classi-

fication presented here. Indeed, they are only anti-antiviral techniques that
are used by both viruses and worms, whatever the class they belong to (see

Section 4.4.6). A short but precise description of each class will be given

here27.

Although overwriting code does not carry any final payload (mainly to reduce

its size), it turns out to be a very dangerous virus insofar as it succeeds

in destroying all the infected executable files (the virus is a paylaod in itself).

At this stage, the following three scenarii are possible :

• the virus overwrites the first part of the target code. As a consequence,

the specific header of the executable file is erased. Let us recall that the

job of the header is to structure data and code in order to facilitate the

memory mapping (EXE header of 16 bits EXE files, Portable Executable

header of 32-bit Windows binaries, ELF header of Linux format...). As a

consequence, the infected progam will be unable to run. This overtwriting

scenario is the most commonly used infection mode (see Figure 4.4);

• the virus overwrites the middle or final part of the target code. This

scenario is viable if the virus installs a jump function which addresses

(points to) the beginning of the viral code. So it will take over the target

program and activate its jump functions, thus executing the virus first.

As the case may be, the target program may not run (it may be due,

for instance, to the fact that the original bytes of the target file replaced

by the jump instruction have not been restored in memory; the virus
then does not return control to the target program). Similarly, a failure

may occur in the execution process of the target program which aborts

(in this case, the virus does give control back to the target program but

since a part of the code has been overwritten the execution aborts). The

purpose behind that scenario is to produce a limited stealth effect (like a

normal execution process which suddenly aborts) whose aim is to make

the victim believe that his computer has been affected by a software

failure rather than a computer attack;

• the target code is merely replaced with the viral one. This technique is

rather unusual and easily detectable insofar as all the infected executables

(unless stealth features are applied) have a similar size.

Overwriting Viruses

Some viral programs do not attach to the beginning or end of the file, but write their code into the target program

itself. Most often this is done by simply overwriting whatever is there already. Most of the time, the virus will also

make a modification to the beginning of the program that points to the virus, but on occasion the virus will rely on

chance for a computer operation to stumble upon the code and run it.

Of course, if a virus has overwritten existing code, the original target program is damaged, and there is little or no

possibility of recovery other than by deleting the infected file and restoring from a clean backup copy. However,

some overwriting viruses are known to look for strings of null (or NUL) characters that may provide a space to

overwrite. If such a string can be identified, the viral code can be removed and replaced with nulls again. (The
Lehigh virus, for example, attaches "behind" the COMMAND.COM file, in a sense, but overwrites slack space at

the end of the file so as not to change the file size. The details of this virus will be explained in Chapter 12.)

Overwriting existing code is a very simplistic answer to the problem of adding code to an existing program without

changing the file size. By simply overlaying code that is already on the disk, the original size remains unchanged.

There are a few problems with this approach. The most obvious is that preserving file size is an ineffective means

of avoiding detection. Probably no competent anti-virus program using generic techniques would check file size

alone, without checking content, if only by a simple checksum.

Then there is the problem of how to make sure the virus is called when the infected program is run. If the code is

just inserted anywhere, it may not be in a part of the program that is used every time the program is run. (Every

programmer is aware of the Pareto Principle's application here: 20 percent of the code does 80 percent of the

work. Some code never gets called at all.) It is possible, by an analysis of the target program's code, to find an

entry point that is used extensively. It is also possible, and a lot easier, to place a jump at the beginning of the

program that points to the viral code.

The second problem is much more difficult to deal with. If the virus code overwrites existing portions of the

program code, how do you know whether the loss of that program code is fatal to the target program? Analysis of

this type, on the original code, is very difficult indeed. Successful overwriting viral programs tend to be short and

to look for extensive strings of NUL characters to replace (ZeroHunt is an example). The NUL characters tend to

be used to reserve stack space, and thus are not vital to the program. However, even if the original code is not

vital to the program, it may cause the program to exhibit strange behaviours if replaced, and thus lead to

detection of the viral infection.

We should also mention the Nina virus, which overwrites the beginning of a file, and the Phoenix family, which

overwrites a random section of a file. Both Nina and Phoenix append the overwritten part to the end of the

infected file. The Number of the Beast/512 virus and 1963 both overwrite the beginning of the file and then move
the contents of the overwritten section beyond the physical end of the file into a portion of the last cluster that the

file occupies. The clusters are always of a fixed size, and because it is very unusual for a file to exactly match a

multiple of the cluster size, there is generally some space past the "end" of the file that is, essentially, invisible to

the operating system.

While overwriting viral programs solve the (trivial and often irrelevant) problem of maintaining file size, they bring

with them some inherent problems, which appear, at this time, to severely limit their effectiveness. To this date,

while many overwriting viruses have been written, none have enjoyed great success nor have they become major,

widespread problems.

There is still one class of overwriting virus that we have not yet considered, and this is perhaps the lowest form of

virus writing. Some virus authors bypass the comparative complexities of the overwriting techniques just described

by using code like this:

if (infectable_obkect_exists)

then

(replace_object_with_self)

Such code makes it easier to guarantee that the infected program is viable. However, the fact that no attempt is

made to preserve the functionality of the target program drastically restricts the chances that such a virus will

survive. The non-functioning program draws attention to the presence of a problem, even if the implication of a

viral program is overlooked. In fact, it can happen that the infected file can be replaced by a fresh copy without

the victim ever realizing what the problem actually was, though in such a case the possibility of reinfection

remains. Where such an overwriter is detected by conventional anti-virus software, it's normally only possible to

erase the infected file. It can be replaced, but not repaired.

Recent worms have modified this approach by targeting and overwriting specific program files

(characteristically, .DLL files associated with email). The replacement file has the functionality of the file it

replaces, but is modified (subverted) to suit the purpose of the worm (that is, to propagate itself). We must

distinguish here between this type of overwriting (as performed by MTX) and that performed by LoveLetter.A,

which replaces graphics files with VBScripts but doesn't attempt to maintain the original content of the graphics

files.

In the world of prependers, the Rat virus uses a technique similar to overwriting. .EXE file headers are always

multiples of 512 bytes in size, so there is often an unused block of space in the header, itself, that the Rat

assumes to be available. The sURIV 2.01 works a bit harder: it moves the body of the file and inserts itself

between the header and original file, and then changes the relocation information in the header.

This type of virus was the first discovered and identified. It is also the

most popular one. The infection considers binary executable files as targets.

Moreover the virus spreads from the infected executable binary file whenever

the file is run. Consequently, the infection process is a low-level mechanism

which generally requires the use of assembly language. A description of the

different infecting mechanisms was presented in Section 4.4.

The way the virus will operate, in this case, is strongly dependent on

the executable file format. These different formats are described by characteristic

strutures which contain information about the way the binary code

(instructions and data) is organized, and about the way the data are mapped

into memory. Here are the main formats:

executable files *.COM. These programs require less than 64 Kb in memory

(only one segment of memory); in other words, the different segment

registers (CS (Code Segment), DS (Data Segment), SS (Stack Segment)

and ES (Extra Segment) contain the same value). MS-DOS creates a

256-bit structure whenever a *.COM file is run, denoted Program Segment

Prefix (PSP for short), which is prepended to the code into the memory.

The code then starts at offset 100H28. The main constraint lies in the

fact that the size of a *.COM file must not exceed 64K once the infection

has occurred;

• executable files *.EXE. These programs which use more than one segment

starts with a more complex format structure called the EXE header which

contains the Relocation Pointer Table as an essential structure. This table

can handle several segments during the memory mapping, and replaces

relative addressing (the file addresses on the disk) with absolute addressing

(the file addresses in the memory). While infecting the target, the

virus will increase the file size and possibly the number of segments. In

this case, the virus must modify and add adequate information to the

*.EXE header as well as to the Relocation Pointer Table in order to avoid

errors during the memory mapping process;

• PE executable files (Windows 32-bit executable files). The considered

structure is the PE header which is described in Section 4.4.3;

• Device drivers files (viruses which infect device drivers). The header of

these files are similar to those of the *.COM files or *.EXE files (only the
start offset differs);

• Windows VxD files;

• ELF executable files29 (Unix)(ELF header and header table).

Only the format of the target executable file will determine the way the

virus will operate. That is the reason why virus programmers need to get

information about the considered format.