How Knowledge about Structure of Computer Viruses helps in Providing Security

Computer viruses are considered to have three parts to their structure: the infection mechanism, the trigger, and the payload. I will not go into elaborate detail on the constituent parts,  since this is an article on protection against viruses, rather than a treatise on how to build them. However, keeping the model in mind will help you to read and understand virus warnings.

Infection Mechanism

The first, and only necessary, part of the structure is the infection mechanism. This is the code that allows the virus to reproduce, and thus to be a virus. The infection mechanism itself has a number of parts to it.

The first function is to search for, or detect, an appropriate object to infect. The search may be active, as in the case of some file infectors that take directory listings in order to find programs of appropriate size and format. Alternatively, the search may be passive, as in the case of macro viruses that infect each document as it is saved.

There may be additional decisions taken once such an object is found. Some viruses (sparse infectors) actually may try to slow the rate of infection in order to avoid detection. Fast infectors, on the other hand, aim to infect as many objects as possible, in as short a time as possible. Most viruses will check to see if the object has already been infected with a test like the following pseudo-code (multiple infections tend to be rather conspicuous):

BEGIN
IF (infectable_object_found)
AND (object_not_already_infected)
THEN (infect_object)
END

The next action will be the installation of a copy of the virus code into the infectable object itself. This may entail one or more of a number of operations, depending on the virus or worm type:

+ The writing of a new section of code to the boot sector.
+ The addition of code to a program file.

+ The addition of macro code to the Microsoft Word NORMAL.DOT file.
+ The addition of code to standard system programs to intercept network services so as to send an infected file attachment to harvested email addresses.

There are additional sub-functions at this step as well, such as the movement of the original boot sector to a new location, or the addition of jump codes in an infected program file to point to the virus code. There may also be changes to system files, to try to ensure that the virus will be run every time the computer is turned on.

At the time of infection, a number of steps may be taken to try to keep the virus safe from detection. The original file-creation date may be conserved and used to reset the directory listing, in order to avoid a change in date. The virus may have its form changed, in some kind of polymorphism. The active portion of the virus may take charge of certain system interrupts, in order to make false reports when someone tries to look for a change to the system. There may also be prompts or alerts generated, in an attempt to make any odd behavior noticed by the user appear to be part of a normal, or at least innocent, computer error.

Trigger

The second major component of a virus is the payload trigger. The virus may look for a certain number of infections, a certain date and/or time, a certain piece of text, or may simply blow up the first time it is used. (For obvious reasons, these latter viruses are not widespread.) As noted, a virus does not necessarily need to have either a trigger or a payload. A virus with a trigger and payload but no replication mechanism is not, in fact, a virus, but may well be described as a Trojan. A simple trigger mechanism might work like this:

BEGIN
IF (date_is_Friday_13th)
THEN (set_trigger_status_to_yes)
END

Payload

The payload mechanism is similarly simple in conception:

BEGIN
IF (trigger_status_is_yes)
THEN (execute_payload)
END

If a virus does have a trigger, then it usually has a payload (the term warhead is sometimes preferred). The payload can be anything, from a simple, one-time message, to a complicated graphical display, to reformatting of the hard disk, to mailing a copy of the virus to addresses in the victim’s address book. However, the bigger the payload, the more likely it is that the virus will be noticed. You may have seen lists of symptoms to watch for. Some signs often quoted include text messages, ambulances running across the screen, and letters falling down to the bottom of the screen.

Nonetheless, checking for payloads isn’t a very good way to detect (let alone keep free of) viruses. The most successful viruses are generally far less conspicuous. Sometimes the only time a characteristic display is observed is when the virus first infects (as with WM/Concept, for instance). Most times, there is no display at all, and it’s only when anti-virus software sounds an alert that a problem is noticed, thus inspiring the Berkeleyesque thought that sometimes there is only a virus problem because anti-virus software perceives the presence of a virus.

Some of the most successful viruses are sub-clinical in their effects: they have no payload, and their presence causes no significant effect on the health of the victim system, except the psychological damage to the system’s owner who is then identified as a Typhoid Mary. Many viruses have less impact on victim systems than the common cold does on human beings.

We have to wonder whether it’s helpful that all viruses are regarded as if they were the computer equivalent of Ebola or Marburg. The panic that results from routine detection of unremarkable viruses may be more damaging (at least psychologically) than the presence of the virus on the infected system could ever be. We don’t suggest completely abandoning attempts to detect and remove viruses, of course, but less disinformation about the nature of the threat would remove much of its sting.