A mailing list for professional antivirus researchers allowing them to alert other researchers to emerging or ongoing 'crisis' or 'emergency' virus events. These may be localized to a geographic or language-based region or known to be approaching a wordlwide scale. It also acts as a forum for these researchers to discuss such events, what precursors count as sufficient grounds to make posting alerts to users about a newly discovered virus and at what point involving the news media seems appropriate. Aside from the discussion list, another list facilitates the secure distribution of emergency samples and members of the list are expected to send samples of any viruses the organizations they work for consider worthy of raising public warnings about. Senior Computer Associates virus analysis staff are represented on the AVED mailing lists and board. (c.f. REVS)

 Backdoor (1)

A program that surreptitiously allows access to a computer's resources (files, network connections, configuration information, etc) via a network connection is known as a backdoor or remote access trojan. Note that such functionality is often included in legitimate software designed and intended to allow such access. For example, software that allows remote administration of workstations on a company network, or that allows helpdesk staff to 'take over' a machine to remotely demonstrate how a user can achieve some desired result, are genuinely useful tools (and even desirable in many settings). The difference between backdoors or remote access Trojans and remote administration tools is that the latter are designed into a system and installed and used with the knowledge and support of the system administrator's and the other support staff they involve.

Remote access trojans generally consist of two parts; a client component and a server component. In order for the trojan to function as a backdoor, the server component needs to be installed on the victim's machine. This may be accomplished by disguising the program in such a way as to entice victims into running it. It could masquerade as another program altogether (such as a game or a patch), or it could be packaged with a hacked, legitimate program that installs the trojan when the host program is executed.

Once the server file has been installed on a victims machine, often accompanied by changes to the registry to ensure that the trojan is reactivated whenever the machine is restarted, the program opens a port so that the hacker can connect. The hacker can then utilise the trojan via this connection to issue commands to the victim's computer. Some remote access trojans even provide a message system, where the hacker is notified every time their victim logs onto the Internet.

Here's an abbreviated list of things that a hacker can accomplish while controlling a victim's computer via a backdoor:

• Upload/download files
• Make changes to the registry
• Delete files
• Steal passwords and other confidential information
• Log keystrokes
• Rename files
• Display images or message boxes
• Disable the keyboard or mouse
• Hide the taskbar, start button or desktop icons
• Shutdown the computer or reboot the computer
• Print
• Run applications or terminate the currently running applications
• Detect and initialise capture devices such as web cams or microphones
• Disable antivirus or firewall software
• Start an FTP server on the victim's machine that could make it accessible to other unauthorised intruders

 

Under CPM, DOS and Windows 3.x, BIOS interfaces to the hardware were paramount to the proper operation of the machine. Specialized hardware that standard BIOSes were not written to recognize and handle had to either include a BIOS extension on its adaptor card or provide device drivers allowing access to the device (or both) if they were to be used other than by proprietary software written to their hardware interface. More advanced OSes for the PC - such as the various Unixes written for it, NT, Linux, Windows 95 and so on - only depend on the BIOS for its OS bootstrapping function, providing their own (or vendor-supplied) protected mode drivers for all the hardware devices they can use. (Windows 9x allows a degree of real mode compatibility so it can be used on older machines with 'odd' hardware that is not supported by native drivers, but there are performance overheads.)

Traditionally, the BIOS was supplied in a ROM chip plugged into a socket on the PC's mainboard. This arrangement allowed for the replacement of the BIOS, should that ever be necessary to accommodate new hardware requirements (or to supply bug fixes). More recently it has become standard practice to supply the BIOS in a flash memory (or flash ROM) chip, allowing updates to be written directly to the chip via software.

The BIOS should not be confused with the CMOS storage area that is used to store BIOS and mainboard configuration options and data.

 

Thus, the system boot sectors of diskettes and partitions (logical drives) on hard drives, and the MBRs of hard drives, normally all contain boot code of some kind. It is this code, or at least the room reserved for it, that boot viruses target. Once the BIOS completes its hardware checks, it simply reads the appropriate boot sector (depending on which device it is set to boot from first and whether that device is ready) without doing any 'sanity checking' on its contents.

 

As well as these system boot sectors, hard drives also have a special boot sector known as a master boot sector or master boot record. As the boot code is a program, it can also be infected by a computer virus. Boot sector infections normally start from leaving an infected diskette in a PC's floppy drive and rebooting the machine. When the viral boot code is read from the boot sector and executed, the virus copies itself to a 'safe' place in memory, hooks disk I/O functions, infects the hard drive and remains resident, lying in wait for uninfected boot sectors to present themselves (these will usually be on diskettes accessed in the floppy drives).

The safe memory location used by most boot viruses (and many file infectors too) is at the 'top of memory'. Brain - the first PC virus - was also the first PC boot sector infector. Although Brain was limited to diskette boot sectors, most boot viruses since typically infect the system boot sectors of floppy disks and the MBRs of hard drives. Perhaps the main advantage of this strategy is that the virus' code will always be the first to run, whichever drive type is booted from. Stoned was the first virus to implement this and in many ways remains the classic example of the technique.

A few boot viruses, such as Form (which is perhaps most notable for its perseverance), infect the system boot sectors of both diskettes and hard drives. Some multipartite viruses have boot sector components that only infect MBRs while others have boot sector parts that only infect diskette or hard drive system boot sectors. Boot viruses can be polymorphic (for example, the boot component of the complexly multipartite Win95/Fono, can employ stealth techniques (Brain and many more since), and use many of the other techniques from the usual arsenal of virus tricks.

In the early history of virus development, boot infectors were most commonly responsible for actual infections and featured prominently in the WildList. This was because of the high incidence of diskette sharing, that being by far the most common method of transferring data before connecting PCs to LANs and WANs became popular. Multipartite viruses with diskette boot sector components were the next most common viruses at that time, with Junkie probably being the best-known and most prevalent example. Straight file infectors barely showed in the WildList in those days. These patterns were entirely overturned as macro viruses embedded in documents became common and network (and particularly Internet) connectivity increased.

 CHS

Cylinder, Head, Sector. The notation by which the location of a disk sector is supplied to some disk access routines. In this usage, the term 'track' is analogous to cylinder and 'side' (or occasionally 'surface') is analogous to head, but CHS/Cylinder, Head, Sector has the advantage of being non-ambiguous.

Its significance in antivirus work is that boot sector viruses (particulalry MBR infectors) commonly make a 'safe' copy of the original contents of the sector they infect, and this is often located by a fixed CHS address. Thus, you may see descriptions of such viruses saying something like 'the original MBR is saved to 0,0,7' meaning, in this case, that the original MBR was saved to the seventh sector on head (or 'side') zero of cylinder (or 'track') zero.

 Class Infector

A class infector is a macro virus whose code resides in one or more class modules. Class infectors became popular among macro virus writers shortly after the SR-1 (Service Release 1) version of Word 97 became available. With that version of Word, Microsoft introduced an undocumented antivirus feature that prevented the successful replication of most existing Word macro viruses. Under that version of Word, the most that earlier viruses can do is infect the normal template. They are not able to spread from there to documents. (This feature is present in all later versions of Word, including Word 98 for the Macintosh). Class infection, per se, was not necessary to subvert the SR-1 measures, but the first virus writer who realized what was happening coincidentally moved to infecting the default document class object.

 Cluster Virus

Apart from directly infecting host files as appenders and prependers do, there are other ways to intercept calls to an executable file and have some other code run instead of, or before, the code from the intended file. One such method is cluster infection, used by a small number of DOS viruses.

On a FAT file system this method usually involves saving the virus' code to the hard drive then altering the directory entry of an 'infected' file. The required directory entry change is to set the field that points to the first cluster of the file to the cluster holding the virus code and record the original initial cluster of the infected file in an unused field in the directory entry. When the user tries to execute an infected program, the operating system reads the virus from the apparent first cluster of the executable file and runs it. The virus does whatever else it is designed to do then loads and executes the original file, using the correct first cluster information it saved during the infection process. Dir-II was the first cluster virus and in the wild for some time.

Because the cluster infection technique interferes with the linking of cluster chains apparently assigned to a file, these viruses are occasionally referred to as 'link viruses', although this usage should be avoided.

 Collection Virus

See Zoo Virus (c.f. In the Wild).

 Companion Virus

There are other methods of infecting a system other than the most commonly used one of modifying an existing file (see Parasitic Virus. Given the way command-line interpreters (or shells) of several operating systems work, a virus can copy itself onto the system as an entire program yet be sure that much of the time, attempts to invoke a program will result in the virus' code being run first. Such programs are known as companion viruses and there are several forms of this infection method.

For example, under DOS (and at least from the command-line or 'Command Prompt' of its Windows relatives), if the shell is given a command that does not begin with a fully-specified filename, it searches the current directory, then each directory in the PATH environment variable (in the order they are listed), for a COM file matching the command name, then an EXE file and then a BAT file. Thus, a companion virus can 'infect' an EXE file by copying itself to the same directory as that file and using its filename but with a COM extension. (Similarly a BAT file could be 'infected' by copying the virus code to either an EXE or COM with the same filename.) Once the virus has done its work, it loads and executes the original program file. If the virus acts quickly the user is unlikely to notice the short delay this introduces and the fact the target runs 'normally' also reduces the likelihood of user suspicion. This infection technique is known as the program execution order companion method or the execution precedence companion method.

Another companion infection method should be obvious from the preceding description of DOS' command interpretation process. Known as the path order companion method or the path precedence companion method, it depends on a copy of the virus being made in a directory earlier in the path than the directory housing the target. The virus file is given the same name as the target file (although it need not have the same extension - any executable extension will do) so the virus program will be found and executed instead of its target. As with execution order companions, path companions must take steps to ensure the original program runs after the virus has done its thing. Unlike execution order companions, path companions should also be successful on operating systems that do not depend on filename extensions to determine whether a file is 'executable', so long as they have something akin to the concept of a PATH variable.

Yet another companion infection method involves renaming the target program to a non-executable extension then copying the virus to the same location, filename and extension as the target. When the user calls the program, instead of the intended one running, the virus is executed. Again, to avoid immediate detection, such renaming companion viruses must load and execute the original program. This approach has the advantage of being more likely to work under GUI shells (such as the Windows desktop) because such environments usually record full path and filenames when configuring desktop and menu shortcuts and the like. Under such an environment, path and execution order companions will have little effect as they leave the original program intact. Of course, replacing the original program as a renaming companion virus must, makes them much more visible to integrity checking methods.

Although quite simple (because they are not required to alter existing executable files), companion viruses have been rarely seen until recently, when another companion infection technique started to become popular. Windows 95 and NT introduced (or, more correctly, promoted) more complex techniques for controlling how the usual operating system shell (normally Windows Explorer) handles files. Complex inter-relationships between file extensions and more finely described file types exist in the registry. For example, handling of EXE files is defined through a series of values in HKEY_CLASSES_ROOT. This sequence includes a handler for the 'opening' of EXE files. Normally the shell just loads and executes EXE files, much as earlier versions of Windows and DOS did. However, this can be usurped by altering the appropriate registry values so another program runs. So long as the introduced handler launches the original EXE 'as normal', the user will not become suspicious.

Companion infection methods that do not involve replacing the target program defeat simple integrity checkers that only look for modifications to existing programs. For this reason, good integrity checkers also monitor the addition of new program files to a system. (c.f. Appender, Cavity Infector, Overwriter, Prepender)

 Constructor Kit

Some virus writers are not content with writing their own viruses and have wondered about bringing the 'opportunity' of becoming a virus writer to the masses. The solution to this is usually some form of 'construction kit' - a program even a non-programmer can run, feed some parameters into and then produce a virus. Many have been produced over the years covering simple COM and/or EXE infectors, polymorphics, batch, macro and script viruses. Perhaps the best-known of the early ones were the Virus Construction Laboratory (VCL) and Phalcon/Skism Mass-Produced Code Generator (MS-MPC).

 Data Diddlers

This is a popular name for a virus that contains a data modifying payload. This type of virus may, for example, change 0's to 9's in an Excel spreadsheet or, like Jal.A, it may replace certain words. Unfortunately, the changes made by some of these viruses may be almost unnoticable in large amounts of data. Hence, users may not realize that they are infected for quite some time, necessitating possibly lengthy and costly clean-up procedures.

 DDoS, DDOS

Distributed Denial of Service. Attempts to DoS large sites using most forms of resource exhaustion attack, and particularly network bandwidth wasting strategies, are often impossible for a single attacking machine because of the sheer scale of resources available to the attacked site. One solution to this is the distributed denial of service approach, whereby a number of machines with 'attack services' installed on them are simultaneously commanded to attack a target system. Each of these DDoS 'agents' contributes part of the total 'load' that eventually topples the attacked service or server, or each agent contributes part of the bandwidth necessary to clog the network connections to the attacked server. See also Denial of Service.

By late 1999, code from several DDoS systems had been captured from compromised machines. These were mostly the agents (the part that implements the attack service), but a few examples of masters - the component that keeps track of the agents availability and sends the commands to begin and end an attack - were also captured. At the time, some networks of these DDoS agents were discovered to contain several hundred active agents. Although most of these systems have been designed and written for Unix (and particularly Linux) machines, some implementations for PCs also exist. (Refer to the DDoS entry in the virus encyclopedia for more details.)

 EEPROM

Electrically Erasable and Programmable Read-Only Memory.

A type of ROM whose contents are non-volatile but modifiable through the application of appropriate chip reprogramming voltages. EEPROM was an advance on EPROM technology, replacing the requirement for a source of ultra-violet light with a purely electronic mechanism to erase a chip's contents. Some early 'updateable BIOSes' were shipped on EEPROM chips, but flash memory has become the preferred non-volatile memory technology for holding BIOSes in recent years.

 EICAR

European Institute for Computer Antivirus Research.

A group of academics, researchers, law enforcement specialists and other technologists united against 'writing and proliferation of malicious code like computer viruses or Trojan Horses, and, against computer crime, fraud and the misuse of computers or networks' (to quote from the mission statement on the EICAR web site).

 Embedded tags or cross site scripting

This vulnerability occurs when a web server performs inadequate checks on content provided by third parties. A remote attacker may be able to embed a script in a piece of text which is then reproduced onto a web site. Legitimate users of the system may then inadvertently run the script when the innocently connect to the attackers information.

 Entry Point Obscuring Virus

One technique virus writers have tried to make it more difficult for a scanner to detect a virus is entry point obscuration. Simple parasitic viruses alter the code at the entry point of their hosts in some way. Some alter the fields in the executable's header so the pointer to the start of the program's code points to where the virus' code has been inserted or added to the file. Others leave the header alone, but alter the original program code at the entry point itself, either inserting the virus there, or inserting or overwriting code to jump to the virus' code elsewhere in the executable. These approaches pose no problems for virus scanners as most scanners adopted entry point tracing techniques long ago to speed up their scanning. Entry point tracing meant that instead of grunt scanning a whole executable file, only the parts of an executable that were likely to contain a virus' code were scanned.

Entry point obscuring (EPO) viruses employ various methods in attempts to complicate entry point tracing, by inserting the virus' code elsewhere in the target executable than at the entry point of the host program's code. Several approaches have been used. The crudest is randomly inserting the virus' code into the target and 'hoping' both that this does not corrupt the program and that execution branches through the code at the insertion point often enough to give the virus a chance to replicate. More sophisticated methods involve disassembling the host looking for a suitable code sequence (such as an interrupt call or a long jump) to replace with a call to the virus. A minor variation on this, but easier to implement, is to simply scan the host for a suitable byte sequence. However, this involves the risk that the target sequence may be found somewhere that it does not represent the intended machine code sequence and thus infection will corrupt the executable. The first viruses to use EPO techniques were Omud and Lucretia.

 EPO

Entry Point Obscuring.

 EPROM

Erasable and Programmable Read-Only Memory.

A type of ROM whose contents are non-volatile but modifiable through the application of appropriate chip reprogramming voltages. Before reprogramming an EPROM, it has to be exposed to source of ultra-violet light. Some early 'updateable BIOSes' were shipped on EPROM chips, but EEPROMs became more popular. More recently, flash memory has become the preferred non-volatile memory technology for holding BIOSes.

 False Positive, False Negative

These terms derive from their use in statistics. If it is claimed that a file or boot sector is infected by a virus when in reality it is clean, a false positive (or Type-I) error is said to have occurred. Conversely, if a file or boot sector that is infected is claimed to not be infected, a false negative (or Type-II) error has been made. From an antivirus perspective, false negatives probably seem more serious than false positives, but both are undesirable. False positives can cause a great deal of down-time and lost productivity because proving a program cannot replicate under some condition or other is generally much more time consuming than discovering the conditions under which a viral program will replicate.

With good known-virus scanners, false positives are rare. However, they can arise if the scan string for a virus is poorly chosen, say because it is also present in some benign programs. False negatives are a more common problem with virus scanners because known-virus scanners tend to miss completely new or heavily modified viruses. False positives have, historically, been quite a problem for scanners that make heavy use of heuristic detection mechanisms.

Another related, serious problem is the situation where a scanner detects a virus, but incorrectly identifies which. Such misdiagnosed positives can lead to terrible problems if the scanner, or its user, then engages in a virus-specific disinfection routine based on detailed knowledge of the 'detected' virus' characteristics. 'Generic disinfection' procedures are not entirely immune from such problems either.

 Fast Infector

When programs infected with common file infectors (such as Jerusalem in days of yore, and many others since) are run, the virus code usually gets control first. It then checks it has not already gone resident, copies itself into memory, and hooks a system interrupt or event handler associated with the host platform's 'load and execute' function. When that function is subsequently called, the virus' infection routine runs, checking whether the program that is about to run has been infected already, and infecting it if not.

In contrast, a fast infector not only infects programs as they are executed, but even those that are just opened. Even more aggressive fast infectors will infect suitable targets as they are accessed in the most peripheral of ways, such as by reading their directory information as happens during a 'DIR' listing under DOS, or Explorer accessing a directory to display its contents under Windows. Thus, if a fast infector is active in memory, running a virus scanner or integrity checker can result in all of the virus' potential victim files being infected. Early examples were the Dark Avenger and Frodo viruses and more recently CIH became very widespread, partly as a result of being a fast infector. (c.f. Slow Infector)

Note that, technically, most macro viruses are fast infectors. For example, Word macro viruses tend to infect the Word application environment (by deliberately targeting one or more global templates) so they are always present in the Word environment following initial infection. Also, most utilize some form of auto or system macros, or standard event handlers, which are normally triggered during the opening, closing or other user-initiated processing of document files (saving, for example) within the Word application environment. However, unlike executable infectors, such macro viruses are not spread by normal virus scanners, as the finding and opening of files occasioned by the use of a scanner happens outside the host application's environment (i.e. it is the operating system's file processing functions being used, not those of Word, Excel, etc and thus the viral macros are not invoked during this processing of the files).

Also note that residency is associated with fast infection. This was a poorly chosen term, as it was settled on before multi-threaded or multi-process operating systems were targeted by viruses. A virus can be written for such systems to run as a separate process from its host, staying loaded as long as it takes it to find and infect all potential victim files, then exit (this has been done, for example by Libertine.31672.). As this results in the near-immediate infection of all hosts, the term 'fast infector' probably seems a good description for such a virus despite it being a direct action infector. However, the term 'fast infector' is intended for resident viruses that infect on most file accesses - the development of such viruses resulted in the addition of memory scanning to on-demand virus scanners.

 FAT

File Allocation Table.

A crucial part of the standard file systems employed in all versions of DOS and Windows 9x. The FAT records the chaining of disk clusters and the final cluster in a file. A file's first cluster is stored in its directory entry and also acts as an offset into the FAT's chaining table so the rest of the file can be located.

FAT16 file systems were limited to logical drives with a maximum of 65,536 clusters. Thus, as drives got larger, slack space wastage increased as the cluster size had to be increased to keep the cluster count at or under 65,536. FAT32 file systems, introduced in the OEM Service Release 2 (OSR2) version of Windows 95 and supported by Windows 98, ME and Windows 2000, extend the FAT file system to support huge drives (up to 2 Terabytes) and allow much larger drives to retain relatively efficient, smaller cluster sizes, reducing slack space wastage.

Technically, most so-called FAT hard drive partitions are actually FAT16 partitions, but the number is usually assumed. Standard sized 'DOS format diskettes' still use the original FAT12 standard, which has always been used on DOS diskettes.

 Flash Memory

Flash memory became of interest to antivirus researchers when the full measure of CIH's payload was decoded. Because the BIOS of most Pentium-class and later PCs is shipped on a flash memory chip and most mainboard and system designs result in write-mode for that memory being readily enabled, the BIOS of a PC can no longer be considered 'carved in stone'.

Fortunately, some BIOSes are write-protected, requiring special measures be taken to allow flash write enabling to be activated (such as opening the case and setting jumpers or switches). However, testing reveals in many systems that appear to have such a feature, it often does not work. To date, viruses that attempt to re-flash a victim's BIOS and 'succeed' (in that the contents of the BIOS change) all result in the 'trashing' of the BIOS, rendering the victim machine unbootable. That is, unbootable as in you cannot put a special recovery diskette in the floppy, bootup and run a program to re-flash a good copy of the BIOS program back into the flash memory chip. That is, unbootable as in all that happens is the power supply and CPU cooling fans, and the hard drives, spin up because that's what they do when power is applied. Specialist equipment is needed to re-program the flash chip once it is removed from the mainboard, and as more mainboard designs move to surface-mount flash chips rather than socketed ones, that option is not available for an increasing number of machines.

 Generator Kit

See Constructor Kit.

 Germ

A first generation sample of a virus. Technically, the term is reserved for forms of the virus that are in some way 'special', such that another sample the same as the one being referred to could not be produced as the result of a normal infection event. Examples include the initial, unencrypted form of encrypted or polymorphic viruses and 'virus code only' samples of simple prependers and appenders, as would be produced by compiling their source code. Germ samples are infective but not themselves the result of a natural infection incident.

 Ghost Positive

This is a specific form of false positive, in which the error is due to 'leftover pieces' or 'remnants' of a virus that are incorrectly detected and reported as an infection. As the virus is not present, no longer present (in the sense that it cannot be activated through normal actions of the user or system), or present but inactive, it is erroneous for a scanner to report an (active) infection. (Usually only part of the virus will be present anyway.)

For example, under DOS or Windows, accessing a diskette to obtain a listing of its root directory causes the diskette's system boot sector to be read because details from the BPB must be obtained to correctly access the rest of the disk's contents. Imagine a diskette that had previously been infected with a boot virus and disinfected by writing a very short boot program that simply displays a message warning the diskette is not a functional system diskette. Such a short program could easily leave a couple of hundred bytes of the virus' boot sector code intact if the disinfecting program did not overwrite the rest of the boot sector. Some scanners may see this part of the virus' code and consequently report the virus' presence. (See also Slack Space.)

In the early days of scanner development, some scanners would false alarm on other scanners, or report viruses in memory after another scanner had run. This was usually a form of ghost positive caused by one scanner 'seeing' the scan strings of another scanner. The simple solution to this was to not store scan strings in plain text, but to cipher them in some way. Of course, once this was done, the scanner had to work with them ciphered, as deciphering them even just in memory could still lead to their detection in-memory on a subsequent scanning run.

 Global Template

Although many applications have mechanisms for their users to extend the default functionality and/or appearance of the application, some allow this (partially) via template files. Originally used as a means to provide standard document, spreadsheet, etc formatting, the template files of some applications (like the document files on which they are based) have been extended to hold all manner of customizations (such as keyboard shortcuts and personalized menu layouts) and macros (that add functionality by automating routine processes and the like). Some products, such as Word and Excel, have gone a couple of steps further and provide for one or more specially named template files and/or directories to be automatically loaded as the application starts up and also allow 'Add-In' functionality to be implemented in templates.

For example, Word for Windows looks for the file 'Normal.dot' in certain directories (while the Macintosh version looks for a file of Word Template type named 'Normal' in matching folders) and loads it into its environment without warning. Should a normal template contain any auto macros that should run when such a template is loaded, they are run, any menu or shortcut customizations it contains are applied, and any system macros or standard event handler macros in the template will become active, running when the corresponding Word command or event occurs. Word and Excel both support a 'startup' directory, although in slightly different ways. Word will open and integrate any template files stored in its startup directory into its runtime environment, just as it integrates the contents of the normal template. Excel opens and integrates any standard Excel file type stored in its startup directory into its runtime environment. Registered Add-Ins are also loaded when the application starts and if they are templates, will be loaded from wherever they are registered. Thus, for Word, the normal template, any templates in its startup folder and any Add-Ins loaded as templates are all 'global templates', with any customizations and macros they contain becoming available throughout the Word environment.

Infection of global templates is thus an attractive proposition to macro viruses written for such application environments, as it provides a simple form of 'residency'. This will improve its likelihood of infecting more documents and thus improve its chances to spread.

The term 'global template' is also often, but incorrectly, used to mean 'Word's normal template'. This is almost certainly a carryover from earlier versions of Word's macro language, where the normal template could often be referred to via the referent 'Global:', rather than by its full path and name. Even in many of those versions of Word, this usage was, at best, sloppy because of the possibility (if not the actuality) of other 'global' templates.

 Goat File

1. Some generic approaches to virus detection create 'dummy' program files which are written to the drives of the machines being monitored. These files are regularly checked for modification, or created, checked and then deleted. Such files are sometimes called 'goat files', 'decoy files' or 'bait files' because they are not intended to be run for any practicable purpose, and act solely as 'bait' to trap and detect the presence of an active virus.

2. Goat file is also widely used to refer to the 'standard' files antivirus researchers commonly use to replicate viruses onto. Such files can make it easier to analyze the virus, because the researchers know what parts of the infected files they are dealing with are part of the original 'goats', and thus can readily ignore that code during their analysis of the virus. Different researchers generally use different goats.

 Hardware Damage

There has been much debate about whether viruses, or any other software, can cause physical harm or 'damage' to computer hardware. Most claims that such is possible turn out to be one of three kinds - appeals to ancient and usually badly documented stories of hardware destroyed by software shenanigans, accelerated wear and tear, and misunderstanding the difference between damaging hardware and trashing software stored in some form of (semi-)permanent storage. Dealing with each briefly...

There are several reports of ancient hard drives that (reputedly) had no sanity checking in their control mechanisms. The usual claim is that such drives could be taken out of service (even 'destroyed') by directing the drive to seek for a cylinder (track) past the last physical cylinder location. Stories also persist about early PC monitors that could have internal electronic components 'fried' (even setting the monitor on fire if left long enough) by programming the display adapter to use out of specification frequencies for the monitor. A variation on the latter is the 'blow up a monitor by stopping the guns from scanning so they bombard a continuous beam at one tightly focussed spot' claim.

Similar stories and speculation exist about 'overusing' a device. These include claims that certain (usually unspecified and ancient) monitors could be damaged by various means or rendered 'practically unusable' via accelerated phosphor burn and the like. Notions of wearing disks out quickly by repeatedly seeking back and forward between the very first and last cylinders and repeatedly updating the contents of CMOS RAM or EEPROMs or Flash memory are also common.

These first two kinds of stories are pretty much relegated to the scrap heaps of history now, but another type of claim has recently had quite an airing. The CIH virus renders a PC unusable by re-flashing the flash memory chip holding the BIOS. The routine in CIH effectively trashes the BIOS. However, although it leaves the machine unusable (and often leaves the mainboard effectively irreparable) this is not an example of software damaging hardware. The hardware is all still fully functional, but just happens to be built into a bad design that prevents the (economical) return of the system to a working state. For the user faced with a mainboard replacement because a virus payload triggered, this may seem like splitting hairs, but there is a clear technical distinction between the CIH virus rendering a poorly designed system board irreparable and software damaging hardware.

 Heuristic Detection

Apart from precise identification of known viruses, scanners can (and do) employ various forms of less-precise detection. The essential idea behind such heuristic detection mechanisms is to relax the detection rules somewhat, detecting code that is almost bound to be indicative of virus infection (or other forms of malware functionality) and at the same time very unlikely to be seen in 'innocent' programs.

For example, various kinds of unusual settings in the headers of PE (Windows 32-bit executable) files may be strongly indicative of virus-related 'tampering'. If it is also known that such 'odd' headers are never produced by any PE compiler/linker combinations, detecting such things and flagging the files to the user as 'suspicious' may be a good heuristic for detecting certain kinds of new PE infecting virus that the scanner does not yet detect as a known virus.

Similarly, code analysis of a VBA macro can, in most cases, quickly and reliably determine whether the macro has code that copies itself to other documents and templates. However, that alone is not sufficient as a macro virus heuristic as it is common for legitimate macro programs to have installation routines that are themselves macros that copy other macros around. The designer of a good heuristic macro virus detector will attempt to prevent raising false positive alarms on such macro installation packages by requiring the heuristic detector to find more than just code that copies a macro to a global template (the usual installation location for such macro programs). Careful tuning of the importance (or 'weight') attached to various virus-like features can greatly reduce the rate of such false positives. An approach that combines positive and negative heuristics is generally considered best. A positive heuristic is a programmatic feature the scanner considers increases the likelihood it is looking at a virus and a negative heuristic is a feature that reduces that likelihood.

Often scanners that include heuristic detection capabilities have these disabled by default. This can be because they add extra overhead to the scanning process, but it can also be because the heuristics are fairly 'liberal'. Particularly in the latter case, you should only enable the scanner's heuristic detection if a new virus is suspected, as it's results may further focus your attention on the likely affected files. Heuristics should also be enabled and set to their highest levels on e-mail gateway scanners and other 'interception points' if there is an unavoidable business need to allow infectible file types into an organization. Some scanners with heuristic detection abilities allow the user to set the 'sensitivity' of the heuristics and again, these should be set to highest sensitivity for e-mail gateway scanners.

 Hoax

A hoax is a message, typically distributed via E-mail or newsgroups, which is written to deliberately spread fear, uncertainty and doubt. Just like the viruses they purport to describe, they are sent from user to user/s, slowing network and Internet traffic and causing damage 'per se', by wasting users time and by prompting well meaning, (albeit unnecessary) clean up procedures. These messages may be regarding completely fictitious viruses and trojans, or they may be misleadingly warning users about legitimate programs (a common target of past hoaxes was screensavers and more recently, Windows utilities). Hoaxes prey on the lack of technical knowledge and the goodwill of all those that receive a hoax. Generally, hoaxes are warnings about threats to your computer. They tend to follow a standard pattern, and should you receive an e-mail that contains the following characteristics, view it with doubt, if not downright suspicion.

• Reports of a virus that can do massive damage to your pc - many even going so far as to say that critical hardware will be destroyed.
• May sound unnecessarily technical (although often meaningless), thus taking advantage of many users fears of technology/the unknown.
• May quote bogus announcements from Antivirus Industry experts, some even going so far as to provide a correct link to an AV site (which strangely enough, if visited, will most likely tell you that it's a hoax).
• The message may be written in emotive language. That is, the message may be colored with upper case text and contain large numbers of exclamation marks (in order to emphasize the severity of the perceived threat and make the user more likely to forward the message).
• Asks that you forward the message to as many people as possible. This is the most obvious line in a hoax. Warnings from reputable expert sources do not ask you to forward their notifications. It is this part of the text of the message in particular, that should immediately make wary users skeptical.

 Immediate Acting

Usually of payloads; code that runs when the virus or Trojan carrying it first runs. For example, one of the reasons the mass mailing viruses W97M/Melissa and VBS/LoveLetter spread so far and so fast was because their mass mailing code runs the first time the virus' macro (Melissa) or script (LoveLetter) is run. Whether that functionality is disabled so as to not execute on subsequent runs of the virus or Trojan is immaterial. (c.f. Logic Bomb)

 Joke Program

There is no firm definition of a joke program, but, there are many programs about that are so classified. In general, they aim to entertain either the recipient or the supplier of the program, although it is probably the case that the joke is usually at the expense of the recipient. Human nature seems to turn many of these recipients into senders though, once they realize the program did no obvious harm beyond briefly increasing their personal anxiety levels (which was, in fact, the purpose of the person who sent the program to them).

So, what is a joke program? Joke programs are usually seen as programs that do no real damage but in some way attempt to raise the program user's concern for the contents of their computer. A classic example is a program that suggests the user's hard drive is about to be reformatted unless they click the 'Cancel' button in time and then starts a ten-second countdown - when the user tries to click the 'Cancel' button, the button jumps away from the cursor. If left to run until the countdown completes, a message is displayed explaining that it was dangerous to run a program sent via e-mail. Although such programs do not perpetrate any direct harm against the user, they can represent a serious risk. The problem that many such 'harmless' joke programs introduce is that some users panic and, decide that rather than risking the loss of their files, they would be better off turning their machine off. In so doing, they will lose any unsaved changes to current work and may corrupt the file system on their machine, causing even greater losses.

 Logic Bomb

Usually of payloads; code that only runs when particular logical conditions are met while executing the virus or Trojan carrying it. For example, many viruses have payloads that only run on a certain date or between two dates or times, whereas others have payloads that only run after a specific number of files or boot sectors have been infected, and yet others check for any number and manner of other conditions.

Logic bombs that depend on date, time or elapsed time triggers are often called time bombs. Those that will normally run when a virus or Trojan first executes are referred to as immediate acting.

 Macro Virus

Macro viruses consist of instructions in Word Basic, Visual Basic for Applications and other application macro languages. They often reside in documents or other file types that are traditionally thought of as 'just data', and although that is not critical to determining whether something is a macro virus or not, it has been a crucial factor in the relative success of certain kinds of macro viruses. Another factor contributing to the success of macro viruses in the popular Microsoft Office application suite and related products (such as Microsoft Project) is that not only can the document files of these applications carry macro code, those macros can automatically run when certain basic events (such as opening and closing documents) occur and/or when the user expects that standard functions within the application should occur (such as selecting the Save item from the File menu).

While few users tend to think of 'documents' as capable of being infected, any application which supports document-bound macros that automatically execute or usurp standard application functions is a potentially welcoming platform for macro viruses. By the late 1990s, documents had become much more widely shared than diskettes (assisted by the extensive adoption of networking technologies and particularly Internet e-mail) and document-based viruses dominated prevalence statistics. This seems likely to continue for the early years of the 21st century.

 Malware

Malicious software.

A catch-all term for 'programs that do bad or unwanted things'. Generally, viruses, worms and Trojans will all be classed as malware, but several other types of programs may also be included under the term. One example of a good use for the term is where the best classification of a program as a worm or a virus may be unclear, you could still refer to it as 'a piece of malware'.

 Mass Mailer

A virus that distributes itself via e-mail to multiple addressees at once is known as a mass mailer. Probably the first mass mailer was the CHRISTMA EXEC worm of December 1987 (and a couple of copycats in succeeding years), but the technique then all but disappeared until the Melissa outbreak of 1999. There have, however, been many mass mailers since Melissa.

An important distinction between mass mailers and slow mailers, at least in terms of threat assessment, is the scale or rate at which they send infective messages. In sending a large number of messages (and hence copies of themselves) at once, mass mailers aim to achieve rapid, widespread distribution. Presumably their writers hope enough recipients of these messages will be lulled into running the attachments (or simply opening the messages in the case of HTML-embedded script viruses) to ensure the virus' distribution outstrips spread of news about the outbreak and/or updates to virus scanners and other countermeasures. With the apparently ever-growing number of people on the Internet through the late 1990s, there was a continuous supply of fresh, very naïve, inexperienced users to be fooled into double-clicking what they should not. Through the use of 'obvious' social engineering tricks, viruses such as VBS/VBSWG.J had a fair shot at their fifteen minutes of fame.

Mass mailers often have the '@mm' suffix to their names, making the additional threat they may pose readily identifiable to the informed (although Computer Associates do not generally use this naming convention). Mass mailers are often referred to as 'worms', but this usage is not entirely accepted, and as 'e-mail worms' (perhaps to distinguish them from 'real worms').

 Master Boot Record

The boot sector at the beginning of a hard drive (sector location 0,0,1 in CHS notation) is known as the master boot sector or, more commonly, the master boot record. Boot code in this disk sector is loaded by the BIOS, should it attempt to boot from the hard drive. Normally, the MBR's boot code checks the MBR's partition table to determine which partition to load an OS from. It then loads the contents of the boot partition's system boot sector (the first sector in the partition) and transfers control to that load location. This should be the beginning of the boot code of that partition and it is up to that code to 'know' how to boot the OS on that partition.

The master boot record is usually referred to as such or as the MBR, sometimes as the master boot sector (or MBS) and occasionally, but incorrectly, as the partition table (which is actually just a part of the contents of the MBR). Normally the master boot record of a DOS or Windows machine is created when partitioning the drive with FDISK, although all manner of third-party partitioning and boot management tools may also write to the partition table and/or the MBR's boot code.

Because the MBR contains a program (the boot code) it can be infected by a suitably crafted virus. The details of this are covered in more detail in the Boot Sector Infector item.

 Master Boot Record Infector

A virus that infects master boot records. In reality, a virus that only infected MBRs would not be very successful because its chances of replicating would be very limited as new hard drives are seldom added to systems. Its chances of spreading would be even more limited as it is even rarer for hard drives to be moved from machine to machine. MBR infectors usually also infect other boot sectors (particularly those on diskettes) or are multipartite, infecting program files and MBRs (and possibly other boot sectors as well). For a detailed consideration of general boot sector infection issues, see the Boot Sector Infector item.

 MBR

Master Boot Record.

 Multipartite Virus

A virus that infects two or more different target types is generally referred to as a multipartite virus. Early multipartite viruses infected boot sectors and DOS executables, but more esoteric combinations have been seen.

 Network Creeper

Viruses that spread to new hosts by finding writable network drives (or 'shares') and copying themselves there or infecting files on those shares are sometimes referred to as network creepers. Note that a distinction is made between network creepers and other viruses that just happen to infect files on network shares because they infect files on all local and mapped drives. To be a network creeper, a virus has to specifically search for shared network resources, and will find ones that are not currently in use by its host machine. VBS/Netlog has shown how surprisingly successful this technique can be when depending solely on Microsoft Networking and open shares (ones with write-access but no password).

Some antivirus researchers consider network creepers to be worms

 Nuker

Now a generic term for several TCP/IP DoS attacks, but originally made (in)famous by the WinNuke DoS attack which crashed Windows machines that had not been suitably patched or firewalled.

 Oligomorphic Virus

An encrypted virus that has several forms of its decryption code, selecting between them (usually randomly) when writing its decryptor to a new replicant. (See Polymorphic Virus for more details.) ,

 Overwriter

In general, the simplest form of virus is a program that just copies itself over the top of other programs. Such viruses are known as overwriters and are commonly the first types of viruses written for newly 'virused' platforms (e.g. Phage, the first PalmOS virus, discovered in late 2000, was a simple overwriter). Because they do not preserve the functionality of their host programs, overwriters tend to be very obvious and thus not very 'successful'. (c.f. Parasitic Virus)

 Parasitic Virus

Parasitic viruses are those that modify some existing code resource to effect replication. The major distinction here is that companion viruses are not parasitic, and the standalone 'worms' (such the mass mailers and network creepers) tend not to be parasitic. Overwriters tend not to be considered parasitic either. Although macro virus infection necessitates the modification of document files, it has been common for macro viruses to remove pre-existing macros, making them more akin to overwriters. Thus, usually only those macro viruses with a replication method that retains (some of) the pre-existing macros from a target are considered parasitic. Some researchers consider such viruses parasitic only if macros within a module used by the virus are retained.

 Partition Boot Sector

A confusing term, at best. It seems to mainly be used to mean the system boot sector of the active partition. Unfortunately, without some additional context, it seems likely this term would easily be mistaken to be a reference to the master boot sector because this houses the partition table.

 Partition Table

Partition tables are a crucial part of how DOS and related operating systems understand the layout of partitions (or logical drives) on hard disks. For the sake of interoperability, most OSes that run on PCs also follow the dictates of these fundamental partition information resources.

A partition table is a 64 byte data array located at offset 1BEh of master boot records and the boot sectors of extended partitions. Each table has space for only four 16 byte partition definition entries. Each such entry records such data as the beginning and ending sector of the partition, a partition type indicator byte and whether the partition is marked 'active' (or 'bootable'). Beginning and ending sector locations are recorded in absolute CHS terms (relative to any drive geometry translation the BIOS may be set to use).

As the partition table, per se, is just data it cannot be infected. Occasionally the term 'partition virus' or 'partition table virus' is seen or heard. It is a misconception and what is meant is usually a boot virus that infects MBRs.

 POC

See Proof of Concept.

 Polymorphic Virus

In a sense, polymorphic viruses were an extension of the simpler idea of encrypted viruses. Although the replicants of encrypted viruses vary, they can still be detected (albeit imprecisely identified) by simple string scanning because they have a constant decryptor. The development of polymorphism was an attempt to overcome that shortcoming of encrypted viruses.

The simplest approach to not having a constant decryptor was for the virus writer to produce several implementations of the decryption algorithm and slot just one of those forms into the small unencrypted area of each replicant. A very similar method was to have several different encryptor/decryptor pairs, randomly selecting among them at infection time. The very simplest form of this approach employs just two forms of the decryption code or two encryption/decryption pairs and thus is sometimes referred to as bimorphism. More complex variations on this approach involve more than two forms, but still a number fixed by the fact that the code for each decryptor or encrypt/decryptor pair is present in the virus' code. Whale was the first example of this approach, carrying 30 encryptor/decryptor pairs in its code. Aside from adding some overhead to analyzing the virus, such approaches were still not difficult for scanners to deal with - all the scanner developers had to do was add a scan string for each decryptor.

True polymorphism, however, requires more complexity than simply selecting from a group of constant encryptor/decryptor pairs. Viruses in the V2Px family were the first truly polymorphic viruses, employing such techniques as inserting a variable number of 'do nothing' or 'noise' instructions between the 'viral' instructions, interchanging equivalent but different instructions, and swapping code blocks where the order of execution of the blocks was not important to the overall effect of the code. Such code permutations could be applied to all of a virus' code or just to the decryption routine of an encrypting virus.

One of the most sophisticated forms of polymorphism at the time, in some ways setting the standard against which subsequent polymorphs were judged, was the 'Mutation Engine' (or MtE). It was distributed in the form of an object module which could be linked to the code of a virus body (the code responsible for replication), making that virus polymorphic. More recently, polymorphic viruses have 'benefited' from the advance of 32-bit computing, with some polymorphic engines theoretically capable of reproducing their host virus into 4 billion different forms. Scanning technology has obviously had to evolve well past simple string scanning to deal with such complexity while not labeling every other 'innocent' executable a virus too.

 POST

Power On Self Test.

When a PC is powered up or restarted, the first thing the BIOS does is perform some basic tests for the existence and/or functionality of various hardware components (e.g. whether there is enough RAM to run the rest of the BIOS code, whether there is functional display adaptor with text-mode capabilities, etc). Should any of these tests fail, the BIOS simply beeps to indicate the error, and stops - the machine just freezes. The number of beeps describes which of the sub-system tests failed. Unfortunately, there is no explicit standard between manufacturers (and even between models) for these error codes, so you need to contact technical support or the manufacturers web site to obtain this information.

 Prepender

A virus that inserts a copy of its code at the beginning of the code of its victim file is known as a prepender or prepending virus. (c.f. Appender, Cavity Infector, Companion Virus, Overwriter)

 Proof of Concept

A term broadly applied to mean the first implementation of an idea that had previously only been discussed as a theoretical possibility or concept. In antivirus circles it is commonly used to describe a virus that is the first to infect a given platform or implement a given infection technique. Employed thus, it often has a pejorative connotation, particularly if used in a phrase such as 'It is just a proof of concept' which usually means the virus is very simplistic and possibly quite obvious or buggy (or both), and thus unlikely to pose a real-world threat itself.

 RAM

Random Access Memory.

The memory transient programs are loaded into so they can be executed. It is also the memory that must be used for revisable data storage, regardless of the location of the program manipulating the data (e.g. a PC's interrupt table is stored at a fixed location in system RAM even though it is initialized and used by the BIOS, because the OS and user programs need to be able to alter interrupts). Viruses must use some of this for themselves if they are to remain active on a machine (i.e. if they are to go resident). Thus, scanners check memory, at least for signs of known memory-resident viruses.

In the early days of virus scanner development, many scanners would declare that a virus was active simply when it is found in RAM. This could, and often did, cause a particular type of false positive known as ghost positives through the 'detection' of part of a virus' code that was, for example, left over in a buffer area of RAM rather than truly being active. (c.f. ROM)

 RAT

1. Remote Access Trojan (occasionally Remote Access Trapdoor).

2. Remote Administration Tool. There are legitimate remote administration tools included with many network management products, with helpdesk and other support software, and the like. These are installed with the system administrator's knowledge and consent (although not necessarily with that of the end-users). Many programs that are clearly designed to harass, annoy and spy on unsuspecting users who are fooled into running their server part (that is, programs that better fit the first expansion of this acronym) are referred to as 'remote administration tools' in an attempt (usually by their writers, resellers, agents, etc) to legitimize them. Such tools that have 'silent' installation modes and such useful administration functions as the ability to repeatedly open and close the CD-ROM tray of the 'administered' machine are perhaps better thought of as 'remote antagonism tools' and should be treated as such

 Registry

The registry is a database used by the Windows32 operating system (Win9x/ME/NT/2000/XP) to store configuration settings. The Registry is broken down into several major sections, for example; HKEY_Current_User (where all the preferences for the current user are stored) or HKEY_Local_Machine (where settings are stored for hardware, installed applications and the operating system).

Many Windows applications write data to the Registry. The Registry can be edited, although extreme caution must be used when doing so. Actions such as altering registry settings, deleting files from system areas and modifying the content of system files are difficult and potentially dangerous operations that SHOULD NOT be undertaken unless users are aware of the risks involved.

Experimenting with registry settings is likely to result in lost files and/or unusable programs and can even cause the operating system to become corrupted.

Microsoft defines the registry thus:
"In Windows 32-bit operating systems, the tree-structured hierarchical database where general system hardware and software settings are stored."
(quoted from http://www.microsoft.com/hwdev/GLOSSARY1.HTM#R 23/11/2001)

 Remnant

There are many approaches to disinfecting virus-infected objects. As a result, some people are surprised to learn that not all products remove all traces of a virus when disinfecting. Should this happen, the remaining virus code will not be 'active' - it will not be able to gain control in the flow of execution - so the disinfected object is still 'safe'. These snippets of leftover code are sometimes referred to as remnants.

Because this does happen and not all scanners use the same methods to detect any given virus (just as they do not all use the same methods to disinfect), these remnants may be detected by some scanners. If this happens, it may cause them to raise an alert that the original virus is still present or that a new variant of that virus may have been detected. This is a special form of false positive known as a ghost positive.

 Remote Access Trojan

A program that surreptitiously allows access to a computer's resources (files, network connections, configuration information, etc) via a network connection is known as a remote access Trojan, or RAT. Note that such functionality is often included in legitimate software designed and intended to allow such access. For example, software that allows remote administration of workstations on a company network, or that allows helpdesk staff to 'take over' a machine to remotely demonstrate how a user can achieve some desired result, are genuinely useful tools (and even desirable in many settings). The difference between remote access Trojans and remote administration tools is that the latter are designed into a system and installed and used with the knowledge and support of the system administrator's and the other support staff they involve. Remote access Trojans are also commonly referred to as remote access trapdoors and backdoors, although the terms trapdoor and backdoor tend to have their own specialized and slightly different meanings.

 Resident

A property of most common computer viruses. A resident virus is one which is normally running and active in the environment in which it is infective. Thus, resident DOS executable infectors load into memory, hook one or more interrupts and remain in memory, waiting for some trigger event such as a file being opened. When the trigger event occurs, the virus' infection code runs, attempting to infect one or more suitable targets (usually the file(s) being processed by the system or function call they have hooked). As boot code is only executed at the very beginning of the boot process, boot viruses have to be resident to have a chance to infect any other targets. The more common macro viruses are also resident, for example, installing themselves into global templates in Word and Excel. (c.f. Direct Action)

 Retro-virus

Loosely based on the biological concept with the same name, computer viruses that attack antivirus products are sometimes referred to as retro-viruses. Examples range from including code that is known to cause code emulators to exit early, through disabling loading of well-known antivirus products and disabling resident antivirus products by patching them in memory to deleting the checksum data files of products offering such features.

 REVS

Rapid Exchange of Virus Samples list.

A mailing list for antivirus companies, allowing their virus analysis staff to securely send samples of 'emergency' viruses to other antivirus developers and for the lab staff to discuss emerging 'virus emergencies'. REVS member companies are expected to send samples of any 'urgent' viruses they isolate to the mailing list no later than the time they make press releases or other public announcements about such viruses.

Computer Associates is represented on the REVS lists. (c.f. AVED)

 ROM

Read-Only Memory.

Apart from its contents normally not being modifiable, ROM is usually also non-volatile. This type of memory is traditionally used to hold a PC's BIOS and little else, although various kinds of 'modifiable ROM' memory technologies, such as EPROM, EEPROM and flash memory, have been used through the years, with flash memory being preferred in recent years.

 Slack Space

In more general usage, slack space is the disk space 'wasted' by the difference between a file's real size and the minimum storage unit of the file system storing it. For example, on a FAT32 file system under Windows 9x, disk cluster size may be 4KB (4096 bytes). What this means is that regardless of their actual sizes, all files from 1 to 4096 bytes will remove 4096 bytes of free disk space from the drive as the file system cannot allocate drive space in units smaller than a cluster. Thus, if you created ten one byte files, despite having only stored ten bytes of data, you will have used 40960 bytes of disk space. In a sense this is a waste of 40950 bytes of disk space, which is said to be 'slack space'. (There are solutions to this 'problem' of wasting disk space, such as sub-block allocation methods and the like, and these are employed in more advanced file systems.)

An important thing to be aware of is that few popular operating systems overwrite this unused space between the end of a file and the end of the last cluster the file occupies. Thus, pieces of 'inert' virus code can be found in various kinds of 'slack space'. Whilst this is unlikely to be seen when scanning files, such code may be detected in memory and incorrectly reported as an active infection once the contents of (cluster-sized) disk buffers are copied elsewhere (see Ghost Positive for an example with boot sectors).

There are, however, other kinds of slack space that can be of more significance to virus writers. For example, the internal format of Win32 portable executables (the PE format) is section based, with files consisting of a header and one or more sections containing code, data resources and the like. Each section, including the header, is 'padded out' to the nearest whole multiple of the file alignment size (which is specified in the header). This arrangement means that PE files can contain sections that do not completely fill the last section assigned to them in the file, just as the final cluster assigned to a file may not be filled. Some viruses have taken advantage of this section slack space, perhaps most notably CIH (see also Multiple Cavity Infector).

 Slow Infector

Most resident viruses attempt to maximize their hit rate by infecting at least the commonly used programs on a system. Some go so far as to attempt to infect all possible targets (see Fast Infector). However, infecting many targets tends to increase the likelihood of being detected so some resident viruses only infect files as they are modified or created. This beats integrity checking methods, as the addition of a new file or modification of an existing one reported by an integrity checker would normally be expected so the user will ignore the reported change, assuming it to be entirely due to (legitimate) reasons for the file's creation or modification. An early example is the Darth Vader virus. A related, though different, technique for reducing the likelihood of detection is that of the sparse infector.

 Slow Mailer

A slow mailer is a virus that distributes itself from victim machines via e-mail but not in the 'explosive' manner attributed to mass mailers. Ska (aka Happy99) and Kak are classic examples of slow mailers, respectively sending itself once to each addressee the victim sends e-mail to or embedding itself in all outgoing HTML messages the victim sends. Despite the mass mailers such as Melissa and LoveLetter hogging the media spotlight, Ska and Kak are also excellent examples of how slow mailers 'last the distance'. For example, several sources of prevalence statistics show roughly twice as many Kak incidents in 2000 as LoveLetter incidents, with the explosive nature of LoveLetter - then the most prevalent virus in history - seen in the fact that most LoveLetter incidents were recorded in a single month (May).

Slow mailers often have the '@m' suffix to their names, making the additional threat they may pose readily identifiable to the informed.

 Slow Polymorphism

A term occasionally applied to polymorphic viruses that only morph their code 'occasionally' rather than each time they replicate, as is more common. This is an 'anti-antivirus research' technique.

 Sneakernet

The network of inter-personal contacts that existed before ethernet made LANs commonplace and long before the Internet as we know it today existed. The name is a play on 'sneaker' and 'ethernet' and refers to the sharing patterns seen when data files and programs were mainly distributed and copied between workmates, other professional colleagues and friends via diskette. As all diskettes have boot sectors and most PCs will attempt to boot from a diskette left in a floppy drive, boot sector infectors were the most prevalent viruses when sneakernet was the predominant sharing mechanism.

 Social Engineering

1. There are two main ways to obtain technical or administrative information about a computer system. The first is from the machines and systems themselves and the second is from the administrators and users of the machines. Surreptitious or unauthorized attempts to obtain such system information are known as hacking or cracking if the attempt involves obtaining the information from the machines and as social engineering if they involve manipulating or 'tricking' a person into divulging the information.

2. By extension of the previous meaning, the term social engineering is often used to describe the 'tricks' used by mass mailing viruses to entice recipients messages with viral attachments to run (or 'view') those attachments.

 SR-1

Service Release 1.

A Service Release is an incremental update and/or bug-fix version of an application, similar to the better-known term Service Pack (or SP). SR-1 is usually of significance in antivirus issues when talking about Word 97 SR-1, as this release introduced some subtle changes to Word's VBA environment that had implications for the replication mechanisms of most Word macro viruses written prior to its release. (See also Class Infector.)

 Stealth Virus

Aside from infecting seldom (see Slow Infector and Sparse Infector), some viruses take other steps to make themselves difficult to detect. For example, stealth boot viruses intercept attempts to read the boot sector (where they reside) and return copies of the original boot sector so it is seen as it was prior to infection - the first PC virus, Brain, is an example of this. More sophisticated boot sector stealth also intercepts write functions, preventing the viral code being overwritten and perhaps redirecting such writes to the 'safe' copy of the original boot sector. Stealth file infectors typically hide any file size increases they are responsible for when a file's properties are read from the disk - Number of the Beast and Frodo were early examples. Macro viruses have also attempted many stealth techniques, such as replacing the standard list of macros with a list from which the virus' macros are missing, and preventing users from accessing the Visual Basic Editor. For their stealth functions to work, a virus must be 'resident'.

With executable viruses, this residency means the virus' modifications go undetected by antivirus programs as well as preventing the user from noticing changes (such as in file sizes and the like). However, with macro viruses, such stealth mechanisms only help prevent the user noticing or reporting changes because virus scanners look directly at the document files containing the viruses and are not dependent on internal functions of Word - the only functions a macro virus can usurp - in order to detect these viruses.

In general, to counter stealth mechanisms you must be able to re-establish a 'clean' environment. With boot and program stealth, restarting from a clean system is necessary to ensure there is no possibility of the normal system functions being interfered with. With stealth macro viruses a clean user environment is needed. This can be attained by assuring that all global templates and other code resources that may be loaded during the host application's startup phase, and as a result of loading a (potentially) infected document, do not get a chance to run.

 TOM

Top Of Memory. The end of a PC's conventional memory, which, as a matter of architectural design, was limited to 640KB on most PCs and is always a multiple of 64KB. Early PCs were seldom fully populated with RAM, with 64KB, 128KB and 512KB being common values for very early models.

During startup, the BIOS initializes a value in the BIOS Data Area (BDA) noting, in kilobytes, how much conventional memory it found. Boot sector viruses typically read this value, copy their code to just below the memory location it represents and then decrease the value in the BDA. This means the virus' resident code ends up above the TOM subsequently reported to the operating system or to any programs (boot viruses load before the OS). With OSes such as DOS, this ensures the virus' code is not overwritten, but with some more complex OSes this may not be the case. Monitoring the TOM value in the BDA for unexpected changes can help detect a virus, but there are legitimate reasons for it to change.

It is a common misconception that PCs reporting less than 640KB of conventional memory necessarily have a virus. While it is the case that boot viruses (and many simple DOS executable infectors) steal RAM from the TOM, this is far from the only explanation for less than 640KB being reported. For example, many expansion cards that have their own BIOSes and other common BIOS extensions (such as on SCSI controllers embedded in a PC's main logic board) liberate a small amount of conventional RAM from the TOM for their own purposes (1KB, 2KB and 4KB are common amounts for this). Similarly, many system BIOSes have an option to move the Extended DIOS Data Area (EBDA) to the TOM, accounting for 1KB of RAM if enabled. Further, the various startup modes of Windows 9x and ways of getting to a DOS prompt to discover the TOM setting of a machine can also affect what is reported (for example, a machine in the current author's test network variously reports 640KB, 639KB and 636KB depending whether a straight DOS boot is made, the DOS prompt is accessed from inside Windows and whether safe mode is used or not).

 Trigger

The condition that determines the launching of a virus' or Trojan's payload is usually called the trigger or trigger condition. Trigger is also used as a verb to indicate the activation of a payload. (See also Logic Bomb, Time Bomb; c.f. Immediate Acting.)

 TSR

Terminate but Stay Resident.

This term is properly used of DOS programs that stay loaded in memory and functional, but allow the user to return to DOS and continue using the PC for other purposes. It is a type of poor person's multi-tasking and in the early days of DOS was very much a black art as several important details of undocumented DOS internals had to be understood before a reliable TSR could be written, and many stability problems were attributed to TSRs. The DOS MEM utility (with the '/C' parameter), and many third-party utilities, can display a list of what TSRs are loaded and have 'followed the rules'.

 Virus

A computer virus is a self-replicating program that explicitly copies itself and that can infect other programs by modifying them or their environment such that a call to an infected program implies a call to a possibly evolved copy of the virus. Note that 'program' takes a fairly liberal interpretation here, involving much more than the 'obvious' application programs (executables) in a typical computer system. Almost any code that is executed or interpreted may be 'virusable' so long as, when running in its normal execution context, that code has write access to some other executable object (note this need not be the same kind of executable object!).

Some not immediately obvious targets for viruses include the boot code in the system boot sectors and MBRs of PC disks and hard drives. These are clearly programs, but are often overlooked because they do not reside in files and thus are not readily accessible to the user, or even 'visible'. Other less than obvious programs include scripting facilities built into applications, either in the form of sophisticated macro languages such as Visual Basic for Applications (VBA), or the simpler procedural languages for automating many applications such as the scripting feature of popular Windows IRC clients like mIRC and Pirch.

Another important feature of viruses is that, unlike their biological namesakes, they need not be parasitic. Various companion infection methods exist and mechanisms that involve altering the behavior of the host program's environment, rather than altering the program itself, can be sufficient to classify a program as viral (so long as it is also self-replicating).

Worms are, in some ways, similar to viruses in that they make copies of themselves. However, there is a deal of disagreement between researchers over how to classify worms. See the worm entry for more discussion of this issue.

When discussing viruses, it is common to hear talk about obvious symptoms and damaging payloads. Some viruses display symptoms, and some cause damage to files in a system they have infected, but neither symptoms nor damage are essential in the definition of a virus. A non-damaging virus is still a virus, not a prank.

There are no 'good' viruses. Viruses are seldom intentionally installed. Users (and, more importantly in corporate settings, system administrators) must be able to control their computers. This requires that they have the power to install and remove software, and that no software is installed, modified, or removed without their knowledge or permission. As viruses are usually surreptitiously self-installed and modify other software in the system without user or administrator awareness, they break these requirements of system administration. Further, their removal can be difficult and costly and viruses will occupy drive space and space on backup media and use CPU cycles and RAM that has not been budgeted for.

Many viruses cause intentional damage. But many more cause damage that may not have been intended by the virus' writer. For instance, when a virus finds itself in a very different environment from that for which it was written, a non-destructive virus can suddenly become very destructive. A good case in point are many common (or formerly common) boot viruses: while a particular boot virus might not contain any code to damage computers running Windows NT, booting an NT machine with such a virus is likely to result in system repairs the user or system administrator may not have been prepared for.

Even if a virus causes no direct damage to a computer, the user's or administrator's inexperience with viruses can mean that damage occurs during the 'clean up' process. Many organizations have shredded floppies, deleted files, and done low-level formats of hard disks in their efforts to remove viruses. Even when removal is done perfectly, with no damage to the infected system or files, it is not normally done when the machine is first infected, and the virus in that machine has had a few weeks to spread. The social costs of infection include a loss of reputation and good will which in a business setting can be significant.

 Warhead

Another term for Payload.

 WildList

Although there are many thousands of known viruses, few actually cause any real-world concern, and those that do are often said to be 'in the wild'. However, the term 'in the wild' has been used in many different contexts and with many different shades of meaning. In an attempt to clear this situation up, as it regards computer viruses, antivirus researcher Joe Wells instigated what he called the WildList. Its purpose was to provide a listing of viruses that could (or should) be considered 'in the wild' by set criteria.

The approach chosen was quite simple - from a reasonably sized and distributed group of reporters (comprised of antivirus researchers and other IT professionals working in, or closely with, the antivirus community), collate monthly reports of virus infection incidents that have been verified by the reporter receiving a sample of the virus involved. The criteria applied to counting these reports were equally simple - if two or more reporters claimed to have received two or more independent, sample-verified reports of infection by the same virus, that virus would be listed on the WildList.

In reality, the WildList consists of two parts. Those viruses currently reported and meeting these criteria are listed first (in what is sometimes called 'the top-half of the list'). That is the WildList and such viruses can be said to be 'in the wild'. However, as an indication of viruses that may be 'bubbling under', all viruses reported to have met the 'two or more independent, sample-verified reports' criterion by only one WildList reporter are also listed. This is often referred to as 'the bottom-half of the list' and such viruses can be said to have been 'reported from the field'.

The WildList has been used as a 'reference standard' by many antivirus testing organizations that require 100% detection of acknowledged 'in the wild' viruses for tested products to attain various, 'desirable' certification levels. The list has not, however, been without its critics and it must be acknowledged that the WildList does not list all viruses that have been seen 'in the field'. That it should be such a list is a common expectation of those with different backgrounds where the term is also used (for example, the general computer security community uses the term 'in the wild' and members of that community are accustomed to the term meaning 'an exploit of a security hole has been seen used in a real-world attack').

An archive of the WildLists and details about the organization that compiles and maintains it are available from http://www.wildlist.org.

 Worm

The term 'worm' does not have a firm definition, although there is less disagreement over the claim that the 'Internet Worm' (or 'Morris Worm') of 1988 was one of the first and the best-known (at least until W97M/Melissa - see below). Some people use the term 'classic worm' (and a few 'real worm') to distinguish such self-contained programs that break into a system via remotely exploitable security flaws (such as buffer overflows) and self-instantiate (i.e. their replication mechanism, per se, is directly responsible for their code running on new target host systems, rather than requiring some external action such as a user running a program or restarting the system as with viruses). The Ramen and Lion (or '1i0n') Linux worms (that were enjoying some success in April 2001) are 'classic worms', as just described.

However, since the late-1990s the term 'worm' has been widely adopted within antivirus circles as meaning something like 'a virus that spreads via network connections'. However, an immediately obvious weakness of this definition is that most file infectors blithely infect files on any drive available to them, including any on mapped network drives. Thus, given an environment where client machines commonly map network drives (i.e. most corporate LANs), most file infecting viruses would be worms. As the point of the late-1990s adoption of the term 'worm' was to emphasize the additional threat posed by mass mailing viruses, this informal definition was changed to something like 'a virus that overtly spreads via network connections' or 'a virus that overtly spreads via external network connections'.

Worms, under this definition, really came to the fore with the release and widespread distribution of W97M/Melissa.A in late March 1999. In fact, accepting this definition of 'worm', the most common type of worm seen to date is the co-called 'e-mail worm' or mass mailing virus.

Aside from e-mail worms, the open share, or network creeper attack is another form of 'network copying virus' worm. This was probably first successfully implemented in VBS/Netlog. Netlog's attack takes the simple expedient of randomly selecting tracts of the IP network address-space then attempting to connect to a Microsoft Network share named 'C' on whatever machine (if any) happens to be on each of the IP addresses in the chosen network address range. A variation on this is network creeper attack, as seen in ExploreZip and some later 'worms', uses Windows' network enumeration API to find all the machines the host explicitly knows on the network and these are then attacked, thus saving time of not having to try many unknown addresses to find potentially exploitable machines.

 Zoo Virus

Those viruses not known to have accounted for any real-world infection incident, or that have been bypassed by computing developments, perhaps despite having once been common, are known as zoo viruses.

Many thousands of trivial, uninteresting viruses are held in antivirus developer virus collections and are widely considered to pose little, if any, real threat. However, they are kept closely guarded to prevent whatever consequences may befall their victims, should they ever be released. As these viruses are not known to have occurred outside such collections, they are likened to rare and exotic animals that are seldom or ever seen other than in nature parks and zoos. The term 'collection virus' is a synonym. (c.f. In the Wild)

Other viruses that are often referred to as zoo viruses are those left behind by technological advances. A classic example is Brain - widely regarded as the first PC virus. It only infected diskette boot sectors, and only those of 360 KB diskettes at that. These days, that probably seems a most unusual design decision, but given the computing milieu of the time, it made sense. The main (in fact, all but only) means of software or data exchange between PCs at the time was via diskette (see Sneakernet). With hard drives being very expensive and most software running on single floppy systems (and running well on dual-floppy systems), users were accustomed to booting from a system diskette, swapping the disk in the A: drive for a program disk and putting their data disks in the B: drive. Thus, booting from and swapping diskettes was common practice (in fact, booting from diskette was 'normal').