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