Our Links
Aussie Wide
For Sale
Gold Coast
Kids & Teens
Make Home
Our Banners

Search Rookies
Gold Coast
Matt's Script's
ICQ E-Mail
Street Directory
White Pages
Yellow Pages
Site map

Chat Forums
Game Chat
Computer Help
100+ Forums

Free Email
AOL Email
Excite Mail
Hot Mail
Lycos Mail
Tech Email
Yahoo Mail

Rookies Frequently Asked Questions About Viruses

Questions answered in this document

Section A: Definitions
(What is ...?)


A1) What is a computer viruses (and why should I worry about them)?
A2) What is a Worm?
A3) What is a Trojan Horse?
A4) What are the main types of PC viruses?
A5) What is a stealth virus?
A6) What is a polymorphic virus?
A7) What are "fast" and "slow" infectors?
A8) What is a sparse infector?
A9) What is a companion virus?
A10) What is an armored virus?
A11) What is a cavity virus?
A12) What is a tunnelling virus?
A13) What is a dropper?
A14) What is an ANSI bomb?
A15) Miscellaneous Jargon and Abbreviations

Section B: Virus Detection
(Is my computer infected? What do I do?)


B1) What are the symptoms and indications of a virus infection?
B2) What steps should be taken in diagnosing and identifying viruses?
B3) What is the best way to remove a virus?
B4) What does a virus do?
B5) What are "false positives" and "false negatives"?
B6) Can an antivirus program itself be infected?
B7) Where can I get a virus scanner for my Unix system?
B8) Why does my scanner report an infection only sometimes?
B9) I think I have detected a new virus; what do I do?
B10) CHKDSK reports 639K (or less) total memory on my system; am I infected?
B11) I have an infinite loop of sub-directories on my hard drive; am I infected?
B12) Can a PC not running DOS be infected with a common DOS virus?
B13) My hard-disk's file system has been garbled: Do I have a virus?

Section C: Protection Plans
(What should I do to prepare against viruses?)


C1) What is the best antivirus program?
C2) Is it possible to protect a computer system with only software?
C3) Is it possible to write-protect the hard disk with software only?
C4) What can be done with hardware protection?
C5) Does setting a file's attributes to READ ONLY protect it from viruses?
C6) Do password/access control systems protect my files from viruses?
C7) Do the protection systems in DR DOS work against viruses?
C8) Does a write-protect tab on a floppy disk stop viruses?
C9) Do local area networks (LANs) help to stop viruses or do they facilitate their spread?
C10) What is the proper way to make backups?

Section D: Facts and Fibs About Computer Viruses
(Can a virus...?)


D1) Can boot sector viruses infect non-bootable DOS floppy disks?
D2) Can a virus hide in a PC's CMOS memory?
D3) Can a PC virus hide in Extended or in Expanded RAM in a PC?
D4) Can a virus hide in a PC's Upper Memory or its High Memory Area?
D5) Can a virus infect data files?
D6) Can viruses spread from one type of computer to another?
D7) Are mainframe computers susceptible to computer viruses?
D8) Some people say that disinfecting files is a bad idea. Is that true?
D9) Can I avoid viruses by avoiding shareware, free software or games?
D10) Can I contract a virus on my PC by performing a "DIR" of an infected floppy disk?
D11) Is there any risk in copying data files from an infected floppy disk to a clean PC's hard disk?
D12) Can a DOS virus survive and spread on an OS/2 system using the HPFS file system?
D13) Under OS/2 2.0+, could a virus infected DOS session infect another DOS session?
D14) Can normal DOS viruses work under MS Windows?
D15) Can I get a virus from reading e-mail, BBS message forums or USENET News?
D16) Can a virus "hide" in a GIF or JPEG file?

= Section A. Definitions and General Information =

A1) What is a computer viruses (and why should I worry about them)?

Fred Cohen "wrote the book" on computer viruses, through his Ph.D. research, dissertation and various related scholarly publications. He developed a theoretical, mathematical model of computer virus behaviour, and used this to test various hypotheses about virus spread. Cohen's formal definition (model) of a virus does not easily translate into "human language", but his own, well-known, informal definition is "a computer virus is a computer program that can infect other computer programs by modifying them in such a way as to include a (possibly evolved) copy of itself". Note that a program does not have to perform outright damage (such as deleting or corrupting files) in order to be classified as a "virus" by this definition.

The problem with Cohen's human language definition is that it doesn't capture many of the subtleties of his mathematical model--as indeed, few informal definitions do--and questions arise that can only be answered by checking his formal model. Using his formal definitions, Cohen classifies some things as viruses that most readers of Virus-L/ comp.virus (and many experts) would not consider viruses. For example, given certain circumstances on an IBM PC running DOS, the DISKCOPY program is classified as a virus by Cohen's formalisms.

This has led to some tension between what Cohen considers a "virus" and what is usually discussed on Virus-L. Several other definitions of "virus" have been proposed, but it is probably fair to say that most of us are concerned about things that are viruses by the following definition:

A computer virus is a self-replicating program containing code 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.

Probably the major distinction between Cohen's definition and "viruses" as we tend to use the word is that we see them as deliberately designed to replicate (although there is some debate over this too). Cohen's definition does *not* require this (and this would be difficult to build into his formal model).

Note that many people use the term "virus" loosely to cover any sort of program that tries to hide its possibly malicious function and\or tries to spread onto as many computers as possible, though some of these programs may more correctly be called "worms" (see A2) or "Trojan Horses" (see A3). Also be aware that what constitutes a "program" for a virus to infect may include a lot more than is at first obvious--don't assume too much about what a virus can or can't do!

These software "pranks" are very serious; they are spreading faster than they are being stopped, and even the least harmful of viruses could be life-threatening. For example, in the context of a hospital life- support system, a virus that "simply" stops a computer and displays a message until a key is pressed, could be fatal. Further, those who create viruses can not halt their spread, even if they wanted to. It requires a concerted effort from computer users to be "virus-aware", rather than continuing the ambivalence that has allowed computer viruses to become such a problem.

Computer viruses are actually a special case of something known as "malicious logic" or "malware". It can be important to understand the distinctions between viruses and these other forms of malware.

A2) What is a Worm?

A computer WORM is a self-contained program (or set of programs), that is able to spread functional copies of itself or its segments to other computer systems (usually via network connections).

Note that unlike viruses, worms do not need to attach themselves to a host program. There are two types of worms--host computer worms and network worms.

Host computer worms are entirely contained in the computer they run on and use network connections only to copy themselves to other computers. Host computer worms where the original terminates itself after launching a copy on another host (so there is only one copy of the worm running somewhere on the network at any given moment), are sometimes called "rabbits."

Network worms consist of multiple parts (called "segments"), each running on different machines (and possibly performing different actions) and using the network for several communication purposes. Propagating a segment from one machine to another is only one of those purposes. Network worms that have one main segment which coordinates the work of the other segments are sometimes called "octopuses."

The infamous Internet Worm (perhaps covered best in "The Internet Worm Program: An Analysis," Eugene H. Spafford, Purdue Technical Report CSD- TR-823) was a host computer worm, while the Xerox PARC worms were network worms (a good starting point for these is "The Worm Programs-- Early Experience with a Distributed Computation," Communications of the ACM, 25, no.3, March 1982, pp. 172-180).

A3) What is a Trojan Horse?

A TROJAN HORSE is a program that does something undocumented that the programmer intended, but that some users would not approve of if they knew about it. According to some people, a virus is a particular case of a Trojan Horse, namely one which is able to spread to other programs (i.e., it turns them into Trojans too). According to others, a virus that does not do any deliberate damage (other than merely replicating) is not a Trojan. Finally, despite the definitions, many people use the term "Trojan" to refer only to *non-replicating* malware, so that the set of Trojans and the set of viruses are disjoint.

A4) What are the main types of PC viruses?

Generally, there are two main classes of viruses. The first class consists of the FILE INFECTORS which attach themselves to ordinary program files. These usually infect arbitrary COM and/or EXE programs, though some can infect any program for which execution or interpretation is requested, such as SYS, OVL, OBJ, PRG, MNU and BAT files. There is also at least one PC virus that "infects" source code files by inserting code into C language source files that replicates the virus's function in any executable that is produced from the infected source code files (see D5 for a more detailed discussion of the issue of "executable" code).

File infectors can be either DIRECT-ACTION or RESIDENT. A direct-action virus selects one or more programs to infect each time a program infected by it is executed. A resident virus installs itself somewhere in memory (RAM) the first time an infected program is executed, and thereafter infects other programs when *they* are executed (as in the case of the Jerusalem virus) or when other conditions are fulfilled. Direct-action viruses are also sometimes referred to as NON-RESIDENT. The Vienna virus is an example of a direct-action virus. Most viruses are resident.

The second main category of viruses is SYSTEM or BOOT-RECORD INFECTORS: these viruses infect executable code found in certain system areas on a disk. On PCs there are ordinary boot-sector viruses, which infect only the DOS boot sector, and MBR viruses which infect the Master Boot Record on fixed disks and the DOS boot sector on diskettes. Examples include Brain, Stoned, Empire, Azusa and Michelangelo. All common boot sector and MBR viruses are memory resident.

To confuse this classification somewhat, a few viruses are able to infect both files and boot sectors (the Tequila virus is one example). These are often called "MULTI-PARTITE" viruses, though there has been criticism of this name; another name is "BOOT-AND-FILE" virus.

Aside from the two main classes described above, many antivirus researchers distinguish either or both of the following as distinct classes of virus:

FILE SYSTEM or CLUSTER viruses (e.g. Dir-II) are those that modify directory table entries so that the virus is loaded and executed before the desired program is. The program itself is not physically altered, only the directory entry of the program file is. Some consider these to be a third category of viruses, while others consider them to be a sub- category of the file infectors. LINK virus is another term occasionally used for these viruses, though it should be avoided, as "link virus" is commonly used in the Amiga world to mean "file infecting virus."

KERNEL viruses target specific features of the programs that contain the "core" (or "kernel") of an operating system (3APA3A is a DOS kernel virus and is also multipartite). A file infecting virus that *can* infect kernel program files is *not* a kernel virus--this term is reserved for describing viruses that utilize some special feature of kernel files (such as their physical location on disk or a special loading or calling convention).

A5) What is a stealth virus?

A STEALTH virus is one that, while "active", hides the modifications it has made to files or boot records. This is usually achieved by monitoring the system functions used to read files or sectors from storage media and forging the results of calls to such functions. This means programs that try to read infected files or sectors see the original, uninfected form instead of the actual, infected form. Thus the virus's modifications may go undetected by antivirus programs. However, in order to do this, the virus must be resident in memory when the antivirus program is executed and *this* may be detected by an antivirus program.

Example: The very first DOS virus, Brain, a boot-sector infector, monitors physical disk I/O and re-directs any attempt to read a Brain- infected boot sector to the disk area where the original boot sector is stored. The next viruses to use this technique were the file infectors Number of the Beast and Frodo (aka 4096, 4K).

Countermeasures: A "clean" system is needed so that no virus is present to distort the results of system status checks. Thus the system should be started from a trusted, clean, bootable diskette before any virus- checking is attempted; this is "The Golden Rule of the Trade".

A6) What is a polymorphic virus?

A POLYMORPHIC virus is one that produces varied but operational copies of itself. These strategies have been employed in the hope that virus scanners (see D1) will not be able to detect all instances of the virus.

One method of evading scan string-driven virus detectors is self- encryption with a variable key. These viruses (e.g. Cascade) are not termed "polymorphic", as their decryption code is always the same. Therefore the decryptor can be used as a scan string by the simplest scan string-driven virus scanners (unless another virus uses the identical decryption routine *and* exact identification (see A15) is required).

A technique for making a polymorphic virus is to choose among a variety of different encryption schemes requiring different decryption routines: only one of these routines would be plainly visible in any instance of the virus (e.g. the Whale virus). A scan string-driven virus scanner would have to exploit several scan strings (one for each possible decryption method) to reliably identify a virus of this kind.

More sophisticated polymorphic viruses (e.g. V2P6) vary the sequences of instructions in their variants by interspersing the decryption instructions with "noise" instructions (e.g. a No Operation instruction or an instruction to load a currently unused register with an arbitrary value), by interchanging mutually independent instructions, or even by using various instruction sequences with identical net effects (e.g. Subtract A from A, and Move 0 to A). A simple-minded, scan string-based virus scanner would not be able to reliably identify all variants of this sort of virus; rather, a sophisticated "scanning engine" has to be constructed after thorough research into the particular virus.

One of the most sophisticated forms of polymorphism used so far is the "Mutation Engine" (MtE) which comes in the form of an object module. With the Mutation Engine any virus can be made polymorphic by adding certain calls to its assembler source code and linking to the mutation- engine and random-number generator modules.

The advent of polymorphic viruses has rendered virus-scanning an ever more difficult and expensive endeavor; adding more and more scan strings to simple scanners will not adequately deal with these viruses.

A7) What are "fast" and "slow" infectors?

A typical file infector (such as the Jerusalem) copies itself to memory when a program infected by it is executed, and then infects other programs when they are executed.

A FAST infector is a virus that, when it is active in memory, infects not only programs which are executed, but even those that are merely opened. The result is that if such a virus is in memory, running a scanner or integrity checker can result in all (or at least many) programs becoming infected. Examples are the Dark Avenger and the Frodo viruses.

The term "SLOW infector" is sometimes used to refer to a virus that only infect files as they are modified or as they are created. The purpose is to fool people who use integrity checkers into thinking that modifications reported by their integrity checker are due solely to legitimate reasons. An example is the Darth Vader virus.

A8) What is a sparse infector?

The term "sparse infector" is sometimes used to describe a virus that infects only occasionally (e.g. every tenth program executed), or only files whose lengths fall within a narrow range, etc. By infecting less often, such viruses try to minimize the probability of being discovered.

A9) What is a companion virus?

A COMPANION virus is one that, instead of modifying an existing file, creates a new program which (unknown to the user) is executed instead of the intended program. On exit, the new program executes the original program so that things appear normal. On PCs this has usually been accomplished by creating an infected .COM file with the same name as an existing .EXE file. Integrity checking antivirus software that only looks for modifications in existing files will fail to detect such viruses.

A10) What is an armored virus?

An ARMORED virus is one that uses special tricks to make tracing, disassembling and understanding of its code more difficult. A good example is the Whale virus.

A11) What is a cavity virus?

A CAVITY VIRUS is one which overwrites a part of the host file that is filled with a constant (usually nulls), without increasing the length of the file, but preserving its functionality. The Lehigh virus was an early example of a cavity virus.

A12) What is a tunnelling virus?

A TUNNELLING VIRUS is one that finds the original interrupt handlers in DOS and the BIOS and calls them directly, thus bypassing any activity monitoring program (see D1) which may be loaded and have intercepted the respective interrupt vectors in its attempt to detect viral activity. Some antivirus software also uses tunnelling techniques in an attempt to bypass any unknown or undetected virus that may be active when it runs.

A13) What is a dropper?

A DROPPER is a program that has been designed or modified to "install" a virus onto the target system. The virus code is usually contained in a dropper in such a way that it won't be detected by virus scanners that normally detect that virus (i.e., the dropper program is not *infected* with the virus). While quite uncommon, a few droppers have been discovered. A dropper is effectively a Trojan Horse (see A3) whose payload is installing a virus infection. A dropper which installs a virus only in memory (without infecting anything on the disk) is sometimes called an "injector".

A14) What is an ANSI bomb?

An "ANSI bomb" is a sequence of characters, usually embedded in a text file, that reprograms various keyboard functions of computers with ANSI console (screen and keyboard) drivers. In theory a special sequence of characters could have been included in this FAQ sheet to reprogram your Enter key to issue the command "format c:" with a return character tacked on the end.

Such a possibility however, need not translate into much of a threat. It is rare for modern software to require the computer it runs on to have an ANSI console, so few PCs or other machines should load ANSI drivers. Also, few people use software that simply "types" output to the terminal device, so such an ANSI bomb in an e-mail or News posting would most likely not reprogram your keyboard anyway. Further, although FORMAT C: may be catastrophic under certain versions of DOS, it won't hurt Macintoshes and would probably have very unexpected, or no, effects on other systems.

If you are at all worried about the possibility of having something untoward happen on your PC due to an ANSI bomb *and* you have to load an ANSI driver (some communications software still requires it), look for one of the third-party ANSI drivers which abound on BBSes and FTP sites. Most of these have improved performance over DOS's ANSI.SYS *and* either do not support, or let you disable, keyboard re-mapping.

A15) Miscellaneous Jargon and Abbreviations

AV = antivirus. A commonly used shorthand, as in "av software".

BSI = Boot Sector Infector: a virus that takes control when the computer attempts to boot. These are found in the boot sectors of floppy disks, and the MBRs or boot sectors of hard disks (see A4 for more details). BSIs are also known as BSVs (Boot Sector Viruses).

CMOS = Complementary Metal Oxide Semiconductor: A memory area that is used in AT class, and higher, PCs for storage of system information. CMOS is battery backed RAM (see below), originally used to maintain date and time information while the PC was turned off. CMOS memory is not in the normal CPU address space and cannot be executed (see D2 for further discussion of issues concerning CMOS memory and viruses).

DBS = DOS Boot Sector: The first sector of a logical DOS partition on a hard disk or the first absolute sector of a diskette. This sector contains the startup code that actually loads DOS. This is often confused with the MBR. Some boot sector viruses infect the DBS rather than the MBR when infecting hard disks.

DETECTION = The ability of an antivirus program to detect that a virus is present, without necessarily reporting which particular virus it is (also see IDENTIFICATION and RECOGNITION, in this section).

DOS = Disk Operating System. We use the term "DOS" to mean any of the MS-DOS, PC-DOS, DR DOS or Novell DOS systems for PCs and compatibles, even though there are operating systems called "DOS" on other, unrelated machines.

GERM = The first generation of a virus. It normally cannot be produced again during the replication process and is usually created by compiling the source of the virus.

GOAT FILES = Programs which usually do nothing special (e.g., just exit, or simply display a message), that are used by antivirus researchers to capture samples of viruses. This is done to make it easier to disassemble and understand the virus, because the infected "goat" program is (usually) simple and does not clutter the disassembly. Alternative terms are BAIT FILES, DECOY FILES and VICTIM FILES. In any of these terms, the word "programs" often replaces the word "files".

IDENTIFICATION = The ability of an antivirus program (usually a scanner) to not only detect the virus and recognize it by name, but also to recognize it to a high degree of uniqueness. This allows third parties to understand which particular virus it is without seeing a sample of the virus. EXACT IDENTIFICATION occurs when every section of the non- modifiable parts of the virus body are uniquely identified. ALMOST EXACT IDENTIFICATION occurs if the identification is only good enough to ensure that an attempt to remove the virus will not result in damage to the host object by the use of an inappropriate disinfection method (also see DETECTION and RECOGNITION, in this section).

MBR = Master Boot Record: the first absolute sector (track 0, head 0, sector 1) on a PC hard disk, that usually contains the partition table but on some PCs may only contain a boot sector. The MBR is also known as the MBS (Master Boot Sector). This is *not* the same as the DOS Boot Sector, logical sector 0 (see above).

PARTITION TABLE = A 64-byte data structure that defines the way a PC's hard disk is divided into logical sections known as partitions. While there is often more than one partition table on a PC's hard disk, the most important is the one stored *in* the MBR. This one contains important extra information such as which partition (if any) should be booted from. The partition table is purely data, so is not executed. Some people erroneously use the term "partition table virus" as a synonym for "MBR virus".

RAM = Random Access Memory: the place programs are loaded into in order to execute; the significance for viruses is that, to be active, they must load themselves into part of the RAM. However, some virus scanners may declare that a virus is active when it is found in RAM, even though it may only be left in a buffer area following a disk read operation, rather than truly being active (see C8 for further discussion of this issue).

RECOGNITION = The ability of an antivirus program (usually a scanner) to detect a virus and to recognize it by name (also see DETECTION and IDENTIFICATION, in this section).

TARGETING VIRUS = A virus that tries to bypass or hinder the operation of one or more *specific* antivirus programs. Also known as RETALIATOR, RETRO and ANTI-ANTIVIRUS viruses.

SCAN STRING = A sequence of bytes (characters) that occur in a known virus but not, one hopes, in legitimate programs. Some scanners allow "wildcards"--positions that are matched by any character--in their scan strings. Authors of virus scanners reduce the likelihood of false positives (see A7) by carefully selecting their scan strings and often by only searching "likely" parts of target files.

SEARCH STRING = A synonym for scan string.

SIGNATURE = A poor synonym for scan string. We recommend that you avoid using this term and use "scan string" or "search string" instead.

TOM = Top Of Memory: the end of conventional memory--an architectural design limit--at the 640KB mark on most PCs. Some early PCs may not have a full 640KB, but the amount of memory is always a multiple of 64KB. A boot-record virus on a PC typically resides just below this mark and changes the value which will be reported for the TOM to the location of the beginning of the virus so that it won't be overwritten. Checking this value for changes can help detect a virus, but there are also legitimate reasons why it may change (see C10). A very few PCs with unusual configurations or memory managers may report in excess of 640KB.

TSR = Terminate but Stay Resident: these are PC programs that stay in memory while you continue to use the computer for other purposes; they include pop-up utilities, network software, and the great majority of common viruses. These can often be seen using utilities such as MEM and MSD.

VX = Virus eXchange. A shorthand usually reserved for those BBSes and FTP sites, and their community of users, that make their virus collections "openly" available for downloading. Exchange of virus samples between bona fide members of the antivirus community is not tagged with the VX label.

= Section B. Virus Detection =

B1) What are the symptoms and indications of a virus infection?

Many people associate destruction--file corruption, reformatted disks and the like--with viruses. Machines infected with viruses that do this kind of damage often display such damages too. This is unfortunate, as usually viruses can be detected or prevented from infecting long before they can inflict any (serious) damage, though many viruses have no "payload" at all. Note that viruses that simply reformat the hard disk shortly after infecting a machine tend to wipe themselves out faster than they spread, so don't get far.

Thus, the more successful viruses typically try to spread as much as possible before delivering their payload, if any. As these tend to be the viruses you are most likely to encounter, you should be aware that there are usually symptoms of virus infection before any (or much!) damage is done.

There are various kinds of symptoms that some virus authors have written into their programs, such as messages, music and graphical displays. The main indications, however, are changes in file sizes and contents, changing of interrupt vectors, or the reassignment of other system resources. The unaccounted use of RAM or a reduction in the amount reported to be in the machine are important indicators. Examination of program code is valuable to the trained eye, but even a novice can often spot the gross differences between a valid boot sector and some viral ones. These symptoms, along with longer disk activity and strange behavior from the hardware, may instead be caused by genuine software, by harmless "joke" programs, or by hardware faults.

The only foolproof way to determine that a virus is present is for an expert to analyse the assembly code contained in all programs and system areas, but this is usually impracticable. Virus scanners go some way towards performing this analysis by looking in that code for known viruses; some even use heuristic means to spot "virus-like" code, but this is not always reliable. It is wise to arm yourself with the latest antivirus software and to pay close attention to your system. In particular, look for any unexpected change in the memory map or configuration as soon as you start the computer. For users of DOS 5.0+, the MEM program with the /C switch is very handy for this. If you have DR DOS, use MEM with the /A switch; if you have an earlier DOS version, use CHKDSK or the commonly-available MAPMEM utility. You don't have to know what all the numbers mean, only that they have changed *unexpectedly*. Mac users have "info" options, which give some indication of memory use, but may need ResEdit to supply more detailed information.

If you run Windows on your PC and you suddenly start getting messages at Windows startup that 32-bit Disk Access cannot be used, this often indicates your PC has been infected by a boot-sector virus.

B2) What steps should be taken in diagnosing and identifying viruses?

Most of the time, a virus scanner program will take care of that for you. To help identify problems early, run a virus scanner:

1. On new programs and diskettes (write-protect diskettes before scanning them).
2. When an integrity checker reports a mismatch.
3. When a generic monitoring program sounds an alarm.
4. When you receive an updated version of a scanner (or you have a chance to run a different scanner than the one you have been using).

Because of the time required, it is not generally advisable to set a scanner to check your entire hard disk on every boot.

If you run into an alarm and your scanner doesn't identify anything or doesn't properly clean up for you, first verify that the version you are using is the most recent. Then get in touch with a reputable antivirus researcher, who may ask you to send in a copy of the infected file. (Also see C9; and F4 if you decide you need to ask for help on Virus- L/comp.virus.)

B3) What is the best way to remove a virus?

In order that downtime be short and losses low, do the minimum that you must to restore the system to a normal state, starting with booting the system from a clean diskette. It is *never* necessary to low- level format a hard disk to recover from a virus infection!

If backups of infected or damaged files are available and, in making them, appropriate care was taken to ensure that infected files have not been included in the backups (see D10), restoring from backup is the safest solution, even though it can be a lot of work if many files are involved.

More commonly, a disinfecting program is used, though disinfection is somewhat controversial and problematic (see D8). If the virus is a boot- sector infector, you can continue using the computer with relative safety (if the hard disk's partition table is left intact) by booting from a clean system diskette. However, it is wise to go through all your diskettes removing any infections as, sooner or later, you will be careless and leave an infected diskette in the machine when it reboots, or give an infected diskette to a someone who doesn't have appropriate defenses to avoid infection.

Most PC boot-sector infections can be cured by the following simple process--pay particular care to make the checks in Steps 2 and 3.

Note that removing an MBR virus in the following way may not be desirable, and may even cause valuable information to be lost. For instance, the One_Half virus gradually encrypts the infected hard drive "inwards" (starting from the "end" and moving towards the beginning), encrypting two more tracks at each boot. The information about the size of the encrypted area is *only* stored in the MBR. If the virus is removed using the method above, this information will be irrecoverably lost and part of the disk with unknown size will remain encrypted.

1. Boot the PC from a clean system floppy--this must be MS-DOS 5.0 or version 6.0 or higher of PC-DOS or DR DOS. This diskette should carry copies of the DOS utilities MEM, FDISK, CHKDSK, UNFORMAT and SYS.

2. Check that your memory configuration is "normal" with MEM (see C10 for assistance here). Check that your hard disk partitioning is normal--run FDISK and use the "Display partition information" option to check this. MS-DOS 5.0 (or later) users can use UNFORMAT /L /PARTN.

3. Try doing a DIR of your hard disk/s (C:, D:, etc).

You should continue with Step 4 *only* if all the tests in Step 2 and this step pass. Do *NOT* continue if you were unable to correctly access *all* your hard disks, as you will quite possibly damage critical information making permanent data damage or loss more likely.

4. Replace the program (code) part of the MBR by using the MS-, or PC-DOS FDISK /MBR command. If you use DR DOS 6.0, or later, select the FDISK menu option "Re-write Master Boot Record".

5. Replace the DOS boot sector using the command SYS C: (or whatever is correct for your first hard disk partition). For this step, the version of DOS on your boot diskette must be *exactly* the same as is installed on your hard disk (this may mean you have to first reboot with a clean boot diskette other than that used in Step 1). If you are using a disk compression system, such as DoubleSpace of DriveSpace, check the documentation on how to locate the physical drive on which the compressed volume is installed, and apply the SYS command to that instead. Usually this is drive H: or I:.

6. Reboot from your hard disk and check that all is well--if not (which is unlikely if you made the recommended checks), seek expert help.

7. As you will get re-infected by forgetting an infected diskette in your A: drive at boot time, you have to clean all your floppies as well. This is harder, as there is no simple way of doing this with standard DOS tools. You can copy the files from each of your floppies, re-format them and copy the files back, but this is a very tedious process (and prone to destructive errors!). At this point you probably should consider obtaining some good antivirus software.

FDISK /MBR will only overwrite the boot loader code in the MBR of the *first* hard drive in a system. However, a few viruses will infect both drives in a two drive system. Although the second hard drive is never booted from in normal PC configurations, should the second drive from such a machine ever be used as the first drive in a system, it will still be infected and in need of disinfecting.

B4) What does a virus do?

If an antivirus program has detected a virus on your computer, don't rush to post a question to this list asking what it does. First, it might be a false positive alert (especially if the virus is found only in one file--see C5), and second, some viruses are extremely common, so questions like "What does the Jerusalem virus do?" or "What does the Stoned virus do?" are asked here repeatedly. While this list is read by several antivirus experts, they get tired of perpetually answering the same questions over and over again. In any case, if you really need to know what a particular virus does (as opposed to knowing enough to get rid of it), you will need a longer treatise than could be given here.

For example, the Stoned virus replaces the disk's boot record with its own, relocating the original to a sector on the disk that may (or may not) occur in an unused portion of the root directory of a DOS diskette; when active, it sits in an area a few kilobytes below the top of memory. All this description could apply to a number of common viruses; but the important points of where the original boot sector goes--and what effect that has on networking software, non-DOS partitions, and so on--are all major questions in themselves.

Therefore, it is better if you first try to answer your question yourself. There are several sources of information about the known computer viruses, so please consult one of them before requesting information publicly. Chances are that your virus is rather well known and that it is already described in detail in at least one of these sources (see A6 for some help in finding these.)

B5) What are "false positives" and "false negatives"?

A FALSE POSITIVE (or Type-I) error is one in which antivirus software claims that a given object is infected by a virus when, in reality, the object is clean. This is a failure of *detection* (see A15). A FALSE NEGATIVE (or Type-II) error is one in which the software fails to indicate that an infected object is infected. Clearly false negatives are more serious than false positives, although both are undesirable.

Following from some of Fred Cohen's work, it has been proven that every virus detector must have an infinite number of false positives, false negatives, or both. This is expressed by saying that detection of viruses, either by appearance or behavior, is UNDECIDABLE. The interpretation and practical significance of this depends upon the interpretation of the terms used, and as with Fred's definition of the term "computer virus", there is some debate over this.

In the case of virus scanners, false positives are rare, but they can arise if the scan string chosen for a given virus is also present in some benign objects because the string was not well chosen. In modern scanners, most false positives probably occur because some virus encryption engines produce very "normal looking" code and scanners that only try to decide if a piece of code could have been generated by a known virus encryption procedure will occasionally detect "innocent" code as "suspicious". False negatives are more common with virus scanners because scanners will miss completely new or heavily modified viruses.

One other serious problem could occur: A positive that is misdiagnosed. As an example, imagine a scanner faced with the Empire virus in a boot record that reports it as the Stoned virus. In this case, use of a Stoned-specific "cure" to recover from an Empire infection could result in an unreadable disk or loss of extended partitions. Similarly, sometimes "generic" disinfection (see D1) can result in unusable files, unless a check is made (e.g. by comparing checksums) that the recovered file is identical to the original file. The better generic disinfection products all store information about the original files to allow verification of recovery processes.

A particular type of false positive, where (part of) an *inactive* virus is detected, is known as a GHOST POSITIVE. Ghost positives usually occur in one of four situations (the first two of which are examples of antivirus programs "upsetting" each other):

Ghost positives can be caused when the disinfection routine of an antivirus program "unhooks" a virus from its target (be it a file or boot sector) but it does so in such a way that part of the virus code is left intact (though that code will never be executed). Another antivirus program might see this code and report it is an infection. In this case the second antivirus program is seeing a "ghost"--part of a virus that was there.

A scanner may "see" the unencoded scan strings of another scanner, left in memory after the first has run or held in memory by a resident scanner, and report these "ghosts" as active viruses (see C6 and C8).

As explained elsewhere (see D10) a copy of an infected diskette boot sector, sitting in the disk buffers, may be detected and reported as an active virus.

Disinfection procedures can result in virus "remnants" being left in "slack space" (disk space allocated to files but not actually occupied). As in the case of copies of infected diskette boot sectors being held in disk buffers, these remnants can be detected and incorrectly reported as being active. Ghost positives of this nature should disappear after running disk defragmentation or "optimization" programs with the option to "clean" slack space. Occasionally running a defragmenter (like MS- DOS 6's DEFRAG) after a full data backup (see D10), is a good idea anyway--especially before installing new software. Unfortunately, DOS's DEFRAG does not have a "clean slack space" option, though some third- party defragmenters do. There are also utilities that clean unallocated and slack space and these should remove ghost positives caused by "remnants".

B6) Could an antivirus program itself be infected?

Yes, so it is important to obtain this software from good sources, and to trust results only after running scanners from a "clean" system. But there are situations where a scanner appears to be infected when it isn't.

Most antivirus programs try very hard to identify viral infections only, but sometimes they give false alarms (see C5). If two different antivirus programs are both of the "scanner" type, they will contain "scan strings" from which they identify viral infections. If the strings are not "encoded", then they may be identified as a virus by another scanner type program. Also, if the scanner does not remove the strings from memory after it has run, then another scanner may detect a virus string "in memory". This often causes the second scanner to report that your system is "infected", *but* only after you have run the first scanner (which may be a memory resident one). The major contributors to this group are so tired of dealing with non-virus reports of this sort that they *strongly* recommend users to avoid antivirus software which doesn't keep its scan strings encoded in memory.

Some "change detection" antivirus programs add a snippet of code or data to a program in order to "protect" it. (This process is sometimes called "inoculation", but this term is also used for other antivirus techniques.) These file changes will likely be detected by other "change detection" programs, and may therefore raise a warning of a suspicious file change.

It is good practice to use more than one antivirus program but, by their nature, multiple antivirus programs may confuse each other!

B7) Where can I get a virus scanner for my Unix system?

Basically, you shouldn't bother scanning for Unix viruses at this point in time. Although it is possible to write Unix-based viruses we have yet to see any instance of a non-experimental virus in that environment. Someone with sufficient knowledge and access to write an effective virus would be more likely to conduct other activities than virus-writing. Furthermore, the typical form of software sharing in the Unix environment does not support virus spread as easily as some others.

This answer is not meant to imply that Unix viruses are impossible, or that there aren't security problems in a typical Unix environment--there are, and Fred Cohen's first experimental virus was implemented and tested on a Unix system. True viruses in the Unix environment are, however, unlikely to spread well.

There *are* special cases in which scanning Unix systems for non-Unix viruses does make sense. For example, a Unix system acting as a file server (e.g., PC-NFS) for PC systems is quite capable of containing PC file infecting viruses that are a danger to PC clients. Note that, in this example, the Unix system would be scanned for PC viruses, not Unix viruses. Also, *any* PC is vulnerable to PC MBR infectors, so special care should be taken to prevent booting a PC hosted Unix OS from a floppy infected with an MBR virus (see C12).

In addition, a file integrity checker (to detect unauthorized changes in executable files) on Unix systems is a very good idea. (One free program that can do this test, as well as other tests, is Tripwire, available by anonymous FTP from its "home" site of coast.cs.purdue.edu in /pub/COAST/Tripwire, and from several other antivirus sites.) Unauthorized file changes on Unix systems are very common, although they are not usually due to virus activity.

B8) Why does my scanner report an infection only sometimes?

There are circumstances where part of a virus exists in RAM without being active. If your scanner occasionally reports a virus in memory, it could be due to the operating system buffering diskette reads or harmlessly keeping disk contents that include a virus in memory, or after running another scanner, there may be scan strings left (again harmlessly) in memory. These are known as GHOST POSITIVE alerts (see C5 for more details).

B9) I think I have detected a new virus; what do I do?

Whenever there is doubt over a virus, you should obtain the latest versions of several (not just one) major virus scanners. Some scanning programs now use "heuristic" methods (F-PROT and TBSCAN are examples), and "activity monitoring" programs can report a program as being possibly infected when it is in fact perfectly safe (odd, perhaps, but not infected). If no scanner finds a virus, but a heuristic program raises some alarms (or there are other reasons to suspect a virus--e.g. change in size of files, change in memory allocation) then it is possible that you have found a new virus, although the chances are probably greater that it is an "odd but okay" disk or file. Start by looking in software documentation for the software may have a section explaining what to do if you think you have found a new virus.

B10) CHKDSK reports 639K (or less) total memory on my DOS system; am I infected?

If CHKDSK displays 639KB (654,336 bytes) for the total memory instead of 640K (655,360 bytes)--so that you are missing only 1KB-- it is possibly due to reasons other than a virus, but there are a few common viruses that take only 1KB from total memory (Monkey and AntiEXE). Non-virus reasons for a deficiency of 1KB include:

1. A PS/2 computer. IBM PS/2 computers reserve 1KB of conventional RAM for an Extended BIOS Data Area, i.e. for additional data storage required by its BIOS.
2. A computer with a BIOS, which is set to use the upper 1KB of memory for its internal variables. (Most BIOSes with this option can be instructed to use lower memory instead.)
3. Some SCSI controllers.
4. The DiskSecure antivirus program.
5. Mouse buffers for older Compaqs.
If you are missing 2KB or more from the 640KB, 512KB, or whatever the conventional memory normally is for your PC, the chances are greater that you have a boot-record virus (e.g. Stoned, Form or Michelangelo), although, even in this case there may be legitimate reasons for the missing memory:

1. Many access control programs for preventing booting from a floppy.
2. H/P Vectra computers.
3. Some special BIOS'es which use memory for a built-in calendar and/or calculator.

However, these are only rough guides. In order to be more certain whether the missing memory is due to a virus, you should:

1. run several virus detectors;
2. look for a change in total memory every now and then;
3. compare the total memory size with that obtained when cold booting from a "clean" system diskette. The latter should show the normal amount of total memory for your configuration (although several BIOSes now steal 1KB of conventional memory when booted from floppy but none when booting from a hard drive).

Note: In all cases, CHKDSK should be run without software such as MS- Windows or DesqView loaded, since these operating environments seem to be able to open DOS boxes only on 1KB boundaries (some seem to be even coarser); thus CHKDSK run from a DOS box may report unrepresentative values.

Note also that some machines have only 512KB or 256KB instead of 640KB of conventional memory.

B11) I have an infinite loop of sub-directories on my hard drive; am I infected?

Probably not. This happens now and then, when something sets the "cluster number" field of a subdirectory to the same cluster as an upper- level (usually the root) directory. On PCs the /F parameter of CHKDSK should be able to "fix" this (as should many other popular disk-repair programs), usually by removing the offending directory. *Don't* erase any of the "replicated" files in the "odd" directory, since that will erase the "copy" in the root as well (these are not really copies at all; just a second pointers to the same files).

B12) Can a PC not running DOS be infected with a common DOS virus?

Yes! There are three distinct possibilities here.

One is Novell's NetWare (and possibly other network operating systems), which boots from a DOS disk and loads a "standard" DOS executable that takes complete control of the system from DOS. This executable-- SERVER.EXE--could easily be infected by a DOS file infector. For example, a server's NetWare boot diskette may have to be taken from the server to a DOS PC to edit some of the configuration and startup files that have to be on that diskette. If the PC where the editing is done is infected with a file infecting virus, SERVER.EXE may well be infected when the new startup files are saved to the diskette. Such infections are virtually guaranteed to render SERVER.EXE inoperative and the server would fail at its next restart. No viruses are known to target the NetWare kernel specifically.

Another possibility is the case of a 386 (or better) system running NetWare or a self-loading OS, such as Unix, NeXTStep486, Windows NT or OS/2, since this system is still vulnerable to infection by MBR infectors (such as Stoned or Michelangelo), as these are operating system independent. Note that an infection on such a system may result in the disabling of non-DOS disk partitions (possibly beyond easy recovery) because the tricks and system conventions these viruses employ may not apply to operating systems other than DOS. The issue here is that MBR infectors are not really "DOS viruses" so much as "PC-BIOS viruses"--they can infect any machine with a PC-compatible BIOS.

Third, *any* OS that offers a "DOS box" or "DOS emulator" to run DOS programs can, potentially, run a virus-infected DOS program. Such activation of a virus should allow the virus to spread to any "targets" available to it under that DOS emulator. For example, a DOS program infected with a multipartite virus, when run under OS/2 would probably be able to infect other DOS executables, but not the MBR/DBS, as OS/2 only allows programs to read these critical areas of the hard drive. With the increasing sophistication and power of computing environments, DOS emulators running on non-PC computers are increasingly available and able to run DOS viruses.

B13) My hard-disk's file system has been garbled: Do I have a virus?

Many things apart from viruses cause corruption of file systems.

With DOS machines possibly the most common is Microsoft's SmartDrive disk cache program that came with Microsoft Windows 3.1 and subsequent versions of MS-DOS. Most versions of this software not only cache disk- reads but, by default, also cache disk-writes. This means that recently "written" files (say from saving a document in your word processor) may not have all the information about the associated file system updates written to disk by the time you exit the application, close Windows and turn off your PC. Users who simply save work then turn their PC off are even more likely to suffer from disk caching induced problems like this.

Regardless of what caused your file-system corruption, you should probably seek expert help *before* trying to fix anything yourself. While there are many powerful and interesting-sounding utilities of the "disk fix" kind available, *all* of these have the stunning ability to render your file system all but unfixable (or at least, fixable to a much lesser degree) when presented with unusual situations their authors hadn't considered when designing the programs. Unfortunately, as these programs (by definition) do not recognize these situations, they confidently pronounce that you have such-and-such a problem then ask your permission to fix it. Even when these utilities have "undo" options, they often cannot restore your file system to its originally "broken" state to give human experts their best shot at fixing it. Thus, detecting whether it is safe to let one of these programs loose on your disks is something you should normally seek expert help in deciding.

= Section C. Protection plans =

C1) What is the best antivirus program?

None! Different products are more or less appropriate in different situations, but in general you should build a cost-effective *strategy* based on multiple layers of defense. There are three main kinds of antivirus software, plus several other means of protection, such as hardware write-protect methods (see D4). When planning your antivirus strategy you should also look closely at your backup policies and procedures (see 10).

1. ACTIVITY MONITORING programs. These try to prevent infection before it happens by looking for virus-like activity, such as attempts to write to another executable, reformat the disk, etc. An alternative term is BEHAVIOR BLOCKER.

Examples: SECURE and FluShot+ (PC), and GateKeeper (Macintosh).

These programs are considered the weakest line of defense against viruses on a system that does not have memory protection, because in such an environment it is possible for a tunnelling virus (see A12) to bypass or disable them.

2. SCANNERS. Most look for known viruses by searching your disks and files for "scan strings" or patterns, but a few use heuristic techniques to recognize viral code. Most now also include some form of "algorithmic scanning" in order to detect known polymorphic viruses. A scanner may be designed to examine specified disks or files on demand, or it may be resident, examining each program which is about to be executed. Most scanners also include virus removers.

Examples: FindViru in Dr Solomon's AntiVirus ToolKit, Frisk Software's F-PROT, McAfee's VirusScan (all PC), Disinfectant (Macintosh).

Resident scanners: McAfee's V-Shield, and F-PROT's VIRSTOP.

Heuristic scanners: the Analyse option in F-PROT, TBAV's TbScan and ChkBoot (from Padgett Peterson's FixUtils).

Scanners are the most convenient and the most widely used kind of antivirus programs. They are a relatively weak line of defense because even the simplest virus can bypass them if it is new and unknown to the scanner. Therefore, your virus protection system should not rely on a scanner alone.

3. INTEGRITY CHECKERS or MODIFICATION DETECTORS. These compute a small "checksum" or "hash value" (usually CRC or cryptographic) for files when they are presumably uninfected, and later compare newly calculated values with the original ones to see if the files have been modified. This catches unknown viruses as well as known ones and thus provides *generic* detection. On the other hand, modifications can also be due to reasons other than viruses. Usually, it is up to the user to decide which modifications are intentional and which might be due to viruses, although a few products give the user help in making this decision. As in the case of scanners, integrity checkers may be called to checksum entire disks or specified files on demand, or they may be resident, checking each program which is about to be executed (the latter is sometimes called an INTEGRITY SHELL). A third implementation is as a SELF-TEST, where the checksumming code is attached to each executable file so they check themselves just before execution. It is generally considered a bad idea to add such code to existing executables.

Examples: ASP Integrity Toolkit (commercial), and Integrity Master and VDS (shareware), all for the PC.

Integrity checkers are considered to be the strongest line of defense against computer viruses, because they are not virus- specific and can detect new viruses without being constantly updated. However, they should not be considered as an absolute protection--they have several drawbacks, cannot identify the particular virus that has attacked the system, and there are successful methods of attack against them too.

3a. Some modification detectors provide HEURISTIC DISINFECTION. Sufficient information is saved for each file so that it can be restored to its original state in the case of the great majority of viral infections, even if the virus is unknown.

Examples: V-Analyst 3 (BRM Technologies, Israel), the VGUARD module of V-Care and ThunderByte's TbClean.

Note that behavior blockers and scanners are virus *prevention* tools, while integrity checkers are virus *detection* tools.

Of course, only a few examples of each type have been given. All of these types of antivirus program have a place in protecting against computer viruses, but you should appreciate the limitations of each method, along with system-supplied security measures that may or may not be helpful in defeating viruses. Ideally, you should arrange a combination of methods that cover each others' weaknesses.

A typical PC installation might include a protection system on the hard disk's MBR to protect against viruses at load time (ideally this would be hardware or in BIOS, but software methods such as DiskSecure and Henrik Stroem's HS are pretty good). This would be followed by resident virus detectors loaded as part of the machine's startup (CONFIG.SYS or AUTOEXEC.BAT), such as FluShot+ and/or VirStop and/or ChkBoot. A scanner such as F-PROT or McAfee's VirusScan and an integrity checker, such as Integrity Master, could be put into AUTOEXEC.BAT, but this may be a problem if you have a large disk to check, or don't reboot often enough. Most importantly, new files and diskettes should be scanned as they arrive *regardless* of their source. If your system has DR DOS installed, you should use the PASSWORD command to write-protect all system executables and utilities. If you have Stacker or SuperStor, you can get some improved security from these compressed drives, but also a risk that those viruses stupid enough to directly write to the disk could do much more damage than normal. In this case a software write- protect system (such as provided with Disk Manager or The Norton Utilities) may help. Possibly the best solution is to put all executables on a disk of their own, with a hardware write-protect system that sounds an alarm if a write is attempted.

If you do use a resident BSI detector or a scan-while-you-copy detector, it is important to trace back any infected diskette to its source. The reason viruses survive so well is that usually you cannot do this, because the infection is found long after the infecting diskette has been forgotten due to most people's lax scanning policies.

Organizations should devise and implement a careful policy that may include a system of vetting new software brought into the building and free virus detectors for home machines of employees/students/etc who take work home with them.

Other antivirus techniques include:

1. Creation of a special MBR to make the hard disk inaccessible when booting from a diskette (the latter is useful since booting from a diskette will normally bypass any protection measures loaded in the CONFIG.SYS and/or AUTOEXEC.BAT files on the hard disk).

Some of these systems won't prevent attack by some MBR virus infections if booting from an infected floppy. This approach is less important now, as most newer PCs allow you to change the boot order so the first hard drive is tried *before* any of the floppy drives.

2. Use of Artificial Intelligence to learn about new viruses and extract scan patterns for them.

Examples: V-Care (CSA Interprint, Israel; distributed in the US by Sela Consultants Corp.), Victor Charlie (Bangkok Security Associates, Thailand; distributed in the US by Computer Security Associates).

3. Encryption of files (with decryption before execution).

4. Diskette "fences". There are three different approaches to this. One prevents executables from being accessed from floppy drives while another prohibits the use of unscanned (possibly "unclean") files or diskettes. A third method uses a non-standard diskette format so diskettes can only be used on (and therefore shared among) machines using the appropriate antivirus software (usually all those within a site or company). This last method is probably the most common diskette fence and provides better protection against boot sector viruses than the other "fence" types.

The workings of the first and third are probably fairly clear from these brief descriptions. The second approach works by writing special information to normally unused areas of the diskette as part of the scanning process and employing a driver in the users' machines prevents access to files that aren't marked as scanned (or to any part of a diskette that contains unscanned files). Alternatives include encrypting scanned files and drivers that only allow access to encrypted files, and so on. One advantage of this second type of system is that you only need scanners for "perimeter checking" machines, reducing the overhead and cost of keeping your scanners up to date.

Examples: D-Fence, Virus Fence, TbFence, DiskNet.

C2) Is it possible to protect a computer system with only software?

Not perfectly; although software defenses can significantly reduce your risk of being affected by viruses *when applied appropriately*. All virus defense systems are tools--each with its own capabilities and shortcomings. Learn how your system works and be sure to work within its limitations.

Using a layered approach, a very high level of protection/detection can be achieved with software only.

1. ROM BIOS--password (access control) and selecting to boot from the hard drive rather than from diskette. (Some may consider this hardware.)
2. Boot sectors--integrity management and change detection.
3. OS programs--integrity management of existing programs, scanning of unknown programs. Requirement of authentication values for any new or transmitted software.
4. Locks that prevent writing to a fixed or floppy disk.

As each layer is added, undetected invasion becomes more difficult. Nevertheless, complete protection against any possible attack cannot be provided without dedicating the computer to pre-existing or unique tasks. International standardization on the IBM PC architecture is both its greatest asset and its greatest vulnerability.

C3) Is it possible to write-protect the hard disk with software only?

The answer is no. There are several programs that claim to do this, but *all* of them can be bypassed with techniques already used by some viruses. Therefore you should never rely on such programs *alone*, although they can be useful in combination with other antivirus measures.

C4) What can be done with hardware protection?

Hardware protection can accomplish various things, including: write protection for hard disk drives, memory protection, monitoring and trapping unauthorized system calls, etc. Again, no single tool will be foolproof and the "stronger" hardware-based protection is, the more likely it will interfere with the "normal" operation of your computer.

The popular idea of write-protection (see D3) may stop viruses *spreading* to the disk that is protected, but doesn't, in itself, prevent a virus from *running*.

Also, some existing hardware protection schemes can be easily bypassed, fooled, or disconnected, if the virus writer knows them well and designs a virus that is aware of the particular defense.

The big problem with hardware protection is that there are few (if any) operations that a general-purpose computer can perform that are used by viruses *only*. Therefore, making a hardware protection system for such a computer typically involves deciding on some (small) set of operations that are "valid but not normally performed except by viruses", and designing the system to prevent these operations. Unfortunately, this means either designing limitations into the level of protection the hardware system provides or adding limitations to the computer's functionality by installing the hardware protection system. Much can be achieved, however, by making the hardware "smarter". This is double- edged: while it provides more security, it usually means adding a program in an EPROM to control it. This allows a virus to locate the program and to call it directly after the point that allows access. It is still possible to implement this correctly though--if this program is not in the address space of the main CPU, has its own CPU and is connected directly to the hard disk and the keyboard. As an example, there is a PC-based product called ExVira which does this and seems fairly secure, but it is a whole computer on an add-on board and is quite expensive.

C5) Does setting a file's attributes to READ ONLY protect it from viruses?

Generally, no. While the Read Only attribute will protect your files from a few viruses, most simply override it, and infect normally. So, while setting executable files to Read Only a good idea (it protects against accidental deletion), it is certainly not a thorough protection against viruses!

In some environments the Read Only attribute does provide some additional protection. For instance, under Novell Netware a user can be denied the right to modify file attributes in directories on the server. This means that a virus that infects such a user's machine will be unable to infect files in those server directories if the files have their Read Only attribute set.

C6) Do password/access control systems protect my files from viruses?

All password and other access control systems are designed to protect the user's data from other users and/or their programs. Remember, however, that when you execute an infected program the virus in it will gain your current rights/privileges. Therefore, if the access control system provides *you* the right to modify some files, it will provide it to the virus too. Note that this does not depend on the operating system used--DOS, Unix, or whatever. Therefore, an access control system will protect your files from viruses no better than it protects them from you.

Under DOS, there is no memory protection, so a virus could disable the access control system in memory, or even patch the operating system itself. On more advanced operating systems (Unix, OS/2, Windows NT) this is much harder or impossible, so there is much less risk that such protection measures could be disabled by a virus. Even so, viruses will still be able to spread, for the reasons noted above. In general, access control systems (if implemented correctly) are only able to slow down virus spread, not to eliminate viruses entirely.

Of course, it's better to have access control than not to have it at all. Just be sure to not develop a false sense of security or come to rely *entirely* on your access control system to protect you.

C7) Does the protection systems in DR DOS work against viruses?

Partially. Neither the password file/directory protection available from DR DOS version 5 onwards, nor the secure disk partitions from DR DOS 6 were intended to combat viruses, but they do so to some extent. If you have DR DOS, it is very wise to password-protect your files (to stop accidental damage too), but don't depend on it as your only means of defense.

The use of the password command (e.g. PASSWORD/W:MINE *.EXE *.COM) will stop more viruses than the plain DOS attribute facility (see D5), but that isn't saying much! The combination of the password system plus a disk compression system may be more secure, because to bypass the password system a virus must access the disk directly, but under SuperStor or Stacker the physical disk will be meaningless to a virus. There may be some viruses that, rather than invisibly infecting files on compressed disks, very visibly corrupt such disks.

The main use of the "secure disk partitions" system, introduced in DR DOS 6, is to stop people from fiddling with your hard disk while you are away from the PC. The way this is implemented, however, may also help against a few viruses that look for DOS partitions on a disk.

Furthermore, DR DOS is not fully compatible with MS/PC-DOS, especially when you get down to the low-level tricks that some viruses use. For instance, some internal memory structures are "read-only" in the sense that they are constantly updated (for MS/PC-DOS compatibility) but not really used by DR DOS, so even if a sophisticated virus modifies them, it will not have any effect, or at least not that intended by the virus's author.

In general, using a less compatible system diminishes the number of existing viruses that can infect it. For instance, the introduction of hard disks made the Brain virus almost disappear; the introduction of the 80286 and DOS 4.0+ made the Yale and Ping Pong viruses next to extinct, and so on.

C8) Does a write-protect tab on a floppy disk stop viruses?

In general, yes. The write-protection on IBM PC (and compatible) and Macintosh floppy disk drives is implemented in hardware, not software, so viruses cannot infect a diskette when the write-protection mechanism is functioning properly (though many "friend of a friend" stories abound contesting this).

But remember:

1. A computer may have a faulty write-protect system (this happens!)--you can test it by trying to copy a file to a diskette that is apparently write-protected.
2. Someone may have removed the tab for a while, allowing a virus on.
3. The files may have been infected before the disk was protected. Even some diskettes "straight from the factory" have been known to be infected during the production process.

Thus, you should scan even new, write-protected disks for viruses. You should also scan new, pre-formatted diskettes, as there have been cases of infected, shrink-wrapped new diskettes.

C9) Do local area networks (LANs) help to stop viruses or do they facilitate their spread?

Both. A set of computers connected in a well managed LAN, with carefully established security settings, with minimal privileges for each user, and without a transitive path of information flow between the users (i.e., the objects writable by any of the users are not readable by any of the others) is more virus-resistant than the same set of computers if they are not interconnected. The reason is that when all computers have (read-only) access to a common pool of executable programs, there is usually less need for diskette swapping and software exchange between them, and therefore less chances for a virus to spread.

However, if the LAN has lax security and is not well managed, it could help a virus to spread like wildfire. It might even be impossible to remove the infection without shutting down the entire LAN. Stories of LAN login programs, shared copies of which are run on every workstation, becoming infected are, unfortunately, not uncommon.

A network that supports login scripting is inherently more resistant to viruses than one that does not *if* this is used to validate the client before allowing access to the network.

C10) What is the proper way to make backups?

A good backup regime is at the heart of any comprehensive virus defense scheme. No matter what combination of software and hardware defenses you install, nor what "policy" you implement, there is always the possibility that some new virus will be devised that can beat your defenses *or* that someone will fail to follow "proper protocol" with "foreign" media or file sources. In corporate settings, the possibility of the latter as a form of directed attack by disgruntled employees cannot be overlooked.

Planning to minimize the impact of a virus infection on your computing is much like planning to minimize the effect of an earthquake or fire. You cannot be sure where, when or even *if* you will ever be "hit"; the potential impact could fall anywhere in a very wide range of possible damage; being "completely safe" can involve enormous expense; and you cannot adequately test your preparations without exposing yourself to serious risk of damage. Therefore, finalizing on the defense scheme that suits you involves deciding on the level of loss you can afford to stand and probably settling on a system that, while not "perfectly watertight," is "good enough".

Despite the importance of a good backup scheme, it is really beyond the scope of this FAQ sheet to provide a definitive guide to planning your backup procedure--that could easily take another document the size of this! All this said however, we provide the following advice as, we hope, a good starting point.

Planning an effective backup scheme really starts with answering some important questions. Consider:

1. Who is dependent on the files on this system? Is it a home computer mostly used by the kids for games, a standalone workstation running a small business, a networked workstation in a medium-sized company or the same in a large corporate environment, or a server with many (hundreds) of users?
2. How long can the most important user be without access to these files? One hour, 2, 4, 8, a day, a week? Remember to assume that your problems will arise at the worst possible moment (like 24 hours before a tax audit is due to start!).
3. What proportion (and volume!) of files are "fixed" (in the sense that they seldom change) versus those that change? Do all changes have to be backed-up, or is a "once-some-given- time-period" backup acceptable?
4. What type of information is in the regularly changing files?

The answers to these (and other) questions help shape backup and recovery plans and are fairly well understood issues amongst computer systems professionals. Highly critical systems containing crucial data will be designed from the outset to have high redundancy (disk mirroring, disk arrays, UPSes, maybe even redundant servers), though such system options *alone* provide no real protection from virus attacks. You may opt for a backup system that records every change to any files on your system (server-only or clients and servers) or regular (often nightly) backup of changed data files, and so on.

When it comes to planning backup regimes with an eye to the possibility of recovering from a virus attack, you also have to consider that regularly backing-up executables (loosely, "programs") can cause problems. If you do and are infected by a virus, unless you can be *absolutely sure* of the date of first infection (despite sounding simple, this is not something that can commonly be done!), you may have quite a few problems finding the best backup set to restore from, as you will probably have several sets including infected executables.

For home or small business use, it may be best to maintain two kinds of backups. One would contain only your data files and one your operating system and program files (issues to consider are covered in the next two paragraphs). This may be facilitated by maintaining a strict separation of the two kinds of files, perhaps by putting the operating system and programs on one drive or partition and your data files on another. While this is probably not practical for many existing machines, enforcing adherence to the "rule" that data files should only be placed in appropriate sub-directories (folders) within a prescribed data directory may not be a bad thing.

The best way to manage backup of data files depends on the answers to too many of the questions listed above for us to give definitive advice here. While planning your backup regime, bear in mind that some viruses damage some kinds of data files, while others make small, occasional, random modifications as files are written to disk. While viruses with either of these "features" are quite rare, both of these possibilities mean that vital data files should probably be backed-up to long-cycle media sets as well as to shorter cycle sets and other steps taken to ensure you can recreate the sequence of changes. (For example, retain all transaction records so they can be re-entered.)

You should probably backup executables once after installing them and only *after* you are sure they are virus-free according to your current antivirus screening procedures. *Never* make a backup containing executables over media that hold *any* of your current backups. The more cautious of us maintain several cycles of executable backups. These precautions should ensure you don't face the problem outlined several paragraphs ago, and mean that should a newly installed program be infected with a virus your current defenses don't detect, you can easily restore your system and installed software to how it was before the infected software was installed, when you do become aware of its presence. You will probably have to manually reinstall any programs you installed subsequent to installing the infected program.

Having referred to this second kind of backup as "executables only", we should point out that a complete system backup is also acceptable for this type of backup. However, note that a sequence of full system backups with interim "incremental" backups (when only those files that have changed since the last complete backup are saved) is *not* what we are advocating. Such systems tend to be too "broad brush" to be truly useful for recovering from an unknown, future virus attack. Unfortunately, this tends to be the preferred/recommended backup scheme for small-to-medium sized systems (including most personal computers), and is typically what most popular backup software for such systems is designed to do. This doesn't mean that popular backup systems and software aren't useful, just that you have to exercise some care in using them (like excluding executable files from your incremental backups).

Having said all this, there are still a few other problems to consider, especially: Which files should you count as "data" files? This can be problematic as most people immediately think of their word-processor and spreadsheet files, and the like, as data, and that's about it. What about the files in which your programs store their configuration information? In a sense, these are as much "your data" as they are program files, because they reflect your preferred screen colors and layouts, default fonts, personalized button bars and so on. When you look at the time people spend finding the (often obscure) options settings in their programs and making them work "just right", and how upset they can be if they lose these settings, it makes sense to treat such configuration files as you treat other "personal data files" in your backup regimes. Similarly, people tend to treat system configuration files (in DOS/Windows PCs CONFIG.SYS, AUTOEXEC.BAT, WIN.INI, SYSTEM.INI at a minimum!) as part of the system, often ignoring the (sometimes considerable) fine-tuning these configuration files go through *between* system and executable backups.

One last point--it cannot be stressed enough that you *MUST* have a full, working copy of the software you need to restore your backups in a safe place. You must be able to guarantee that this software is not virus infected should you ever have to use it, *AND* that it is fully usable should you be facing a machine that has had its entire hard drive "wiped clean".

= Section D. Facts and Fibs About Computer Viruses =

D1) Can boot sector viruses infect non-bootable DOS floppy disks?

Any DOS diskette that has been properly formatted contains some executable code in its boot sector. (There is some debate as to whether this code should be called a program or not. The important thing here is that this code is *executed* at system startup if the diskette is in the system's boot drive.) If a diskette is not "bootable", all that boot sector (normally) does is print a message (on a PC, typically something like "Non-system disk or disk error; replace and strike any key when ready"). However, the boot sector is still executable and therefore vulnerable to infection. Should you accidentally boot your machine with a "non-bootable" diskette in the boot drive, and see that message, it means that any boot virus that may have been on that diskette *has* run, and had the chance to infect your hard drive, or whatever. So, when talking about viruses, the words "bootable" and "non- bootable" are misleading. All formatted diskettes are capable of carrying boot sector viruses.

Most current computers will try to boot from their (first) floppy drive before trying to load an operating system off their hard disks. Because of this and the fact that every floppy disk is possibly infected with a boot sector virus, it is a *very* good idea to set your computer to try to boot from its hard disk. Many newer PCs offer the option to select boot order in their system CMOS setup routines. If your computer has such an option, set it to try to boot from your hard disk first.

D2) Can a virus hide in a PC's CMOS memory?

No. The CMOS RAM in which PC system information is stored and backed up by batteries is accessible through the I/O ports and not directly addressable. That is, in order to read its contents you have to use I/O instructions rather than standard memory addressing techniques. Therefore, anything stored in CMOS is not directly "in memory". Nothing in a normal machine loads the data from CMOS and executes it, so a virus that "hid" in CMOS RAM would still have to infect an executable object of some kind in order to load and execute whatever had been written to CMOS. A malicious virus can of course *alter* values in the CMOS as part of its payload, but it can't spread through, or hide itself in, the CMOS.

Further, most PCs have only 64 bytes of CMOS RAM and the use of the first 48 bytes of this is predetermined by the IBM AT specification. Several BIOS'es also use many of the "extra" bytes of CMOS to hold their own, machine-specific settings. This means that anything that a virus stores in CMOS can't be very large. A virus could use some of the "surplus" CMOS RAM to hide a small part of its body (e.g. its payload, counters, etc). Any executable code stored there, however, must first be extracted to ordinary memory in order to be executed.

This issue should not be confused with whether a virus can *modify* the contents of a PC's CMOS RAM. Of course viruses can, as this memory is not specially protected (on normal PCs), so any program that knows how to change CMOS contents can do so. Some viruses do fiddle with the contents of CMOS RAM (mostly with ill-intent) and these have often been incorrectly reported as "infecting CMOS" or "hiding in CMOS". An example is the PC boot sector virus EXE_Bug, which changes CMOS settings to indicate that no floppy drives are present.

D3) Can a PC virus hide in Extended or in Expanded RAM in a PC?

Yes. If one does though, it has to have a small part resident in conventional RAM; it cannot reside *entirely* in Extended or in Expanded RAM. Currently there are no known XMS viruses and only a few EMS viruses (Emma is an example).

D4) Can a virus hide in a PC's Upper Memory or in High Memory Area?

Yes, it is possible to construct a virus which will locate itself in Upper Memory Blocks (UMBs--640K to 1024K) or in the High Memory Area (HMA--1024K to 1088K). Some viruses (e.g. EDV) do hide in UMBs and at least one, Goldbug, will use the HMA if it is available.

It might be thought that there is no point in scanning in these areas for any viruses other than those that are specifically known to inhabit them. However, there are cases when even ordinary viruses can be found in Upper Memory. Suppose that a conventional memory-resident virus infects a TSR program and this program is loaded high by the user (for instance, from AUTOEXEC.BAT). Then the virus code will also reside in Upper Memory. Therefore, an effective scanner must be able to scan this part of memory for viruses too.

D5) Can a virus infect data files?

Some viruses (e.g., Frodo, Cinderella) modify non-executable files. However, in order to spread, the virus code must be executed. Therefore "infected" non-executable files cannot be sources of further infection. Such "infections" are usually mistakes, due to bugs in the virus.

Even so, note that it is not always possible to make a sharp distinction between executable and non-executable files. One person's data can be another's code and vice versa. Some files that are not directly executable contain code or data which can, under some conditions, be executed or interpreted.

Some examples from the PC world are OBJ files, libraries, device drivers, source files for any compiler or interpreter (including DOS BAT files and OS/2 CMD files), macro files for some packages like Microsoft Word and Lotus 1-2-3, and many others. Currently there are viruses that infect boot sectors, master boot records, COM files, EXE files, BAT files, OBJ files, device drivers, Microsoft Word document and template files, and C source code files, although any of the objects mentioned above theoretically can be used as an infection carrier. PostScript files can also be used to carry a virus, although no currently known virus does this.

Aside from the above, however, there is an increasing possibility of viruses spreading through the sharing of data files. More and more we see the ease with which software producers give their programs the ability to embed "objects" of many kinds into document files, and into fields in databases and spreadsheets. Perhaps the best-known of these systems are Object Linking and Embedding (OLE) in MS Windows and the OpenDoc format. As these embedded objects often have the ability to "display" themselves we see that many files traditionally thought of as data-only, will increasingly be containers carrying data and executable code. We are not aware of any virus that specifically targets such executable "objects", but it is now a trivial task to embed executable files into some kinds of document files so they will be run when the icon representing them is clicked in the finished document. There is nothing to prevent infected executables being embedded in this way, and thus for viruses to be spread through the distribution of "data files".

D6) Can viruses spread from one type of computer to another?

The simple answer is that no currently known viruses can do this. Although some disk formats may be the same (e.g. Atari ST and DOS), the different machines interpret the code differently. For example, the Stoned virus cannot infect an Atari ST as the ST cannot execute the virus code in the boot sector. The Stoned virus contains instructions for the 80x86 family of CPUs that the 680x0 CPU family (used in the Atari ST) can't understand or execute.

The more general answer is that such viruses are possible, but unlikely. Such a virus would be quite a bit larger than current viruses and might well be easier to find. Additionally, the low incidence of cross- platform sharing of software means that any such virus would be unlikely to spread--it would be a poor environment for virus growth.

A related, but different, issue is that of viruses running under operating system emulators on machines other than those for which the operating system was originally designed. This is covered in some detail elsewhere in the FAQ sheet (see C12).

D7) Are mainframe computers susceptible to computer viruses?

Yes. Numerous experiments have shown that computer viruses spread very quickly and effectively on mainframe systems. To our knowledge, however, no non-research computer virus has been seen on mainframe systems. (Despite often being described as such, the widely reported Internet Worm of November 1988 was not a computer virus by most definitions, although it had some virus-like characteristics.)

Many people think that computer viruses are impossible on mainframe computers, because their operating systems provide means of protection (e.g., memory protection, access control, etc.) that cannot by bypassed by a program, unlike the operating systems of most personal computers. Unfortunately, this belief is false. As demonstrated by Fred Cohen in 1984, access controls are unable to prevent computer viruses--they can only slow down the speed with which viruses spread. If there is a transitive path of information flow from one account to another on a mainframe computer, then a virus can spread from one account to the other, without having to bypass any protections.

Consider the following example. The attacker (A) has an account on a machine and wants to attack it with a virus. In order to do this, A writes a virus and releases it. Due to the protection provided by the operating system, the virus can only infect the files writable by A. On a typical system, those would be only the files owned by A.

However, A is not alone on the system. A works with B on some joint projects. At some time, B might want to check how far A has progressed in her/his part of the project. This might involve running one of the programs that A has written--programs that are now all infected with A's virus.

On a sytem with protection based on discretionary access controls (e.g., Unix, VMS, and most other popular OSes), the program that is being executed usually runs with the privileges of the user who is executing it--not with those of the program's owner. (In the few instances where this is not the case, it presents a different kind of security threat, unrelated to viruses.) That is, when B runs A's infected program, the virus in it will run with B's privileges and will be able to infect all programs writable by B.

At some later time, A and B's boss, C, might want to check whether they have completed that joint project. Even if the boss has reasons to suspect A (e.g., as a disgruntled employee), s/he is likely to trust B and execute one of her/his programs. This results in the virus running with C's privileges (which are likely to be significantly greater than those of A and B) and infecting all programs writable by C. Quite possibly, these programs will include many owned by other employees, thus creating many more distribution chains that nobody suspects.

The virus may interfere somehow with C's normal work, which causes C (who is probably not very knowledgeable about such things as computer security and viruses) to ask the system administrator, D, for help. If D executes one of C's infected programs (and s/he is much more likely to trust a respectable person like C--who is quite probably D's boss as well--than any of C's employees), this will cause the virus that A wrote a long time ago to run with system administrator privileges and do whatever it wants with the system--infect other users' files, attack other systems, etc.

A trivial improvement of the above scenario (in terms of speeding up the virus' spread) would be for the attacker to place the virus in some kind of Trojan Horse--for example, in an attractive game or utility--placed in a publicly accessible area.

Why, then, are there so many fewer viruses for mainframe computers than for personal ones? The answer to this question is complex. First, writing a well-made mainframe virus--one that does not cause problems and is likely to remain unnoticed--is not a trivial task. It requires a lot of knowledge about the operating system. This knowledge is not commonly available and the typical youngster who is likely to hack a quick-and-dirty PC virus is unlikely to possess it or be in a position to learn it. People who possess this knowledge are likely to use it in more constructive, satisfying, and profitable ways. Second, the culture of software exchange in the mainframe world differs considerably from that of the PC world--we don't see many VMS users running around with a bootable tape of the latest game... Third, very often it is easier to attack a mainframe computer by using some security hole or a Trojan Horse, instead of by using a virus.

So, computer viruses for mainframe computers are definitely possible and several already exist. Also, some IBM PC viruses can infect any IBM PC compatible machine, even if it runs a "real" OS like Unix. For more information, refer to questions D6 and E7.

Forms of malware other than computer viruses--notably Trojan Horses--are far quicker, more effective, and harder to detect than computer viruses. Nevertheless, on personal computers many more viruses are written than Trojan Horses. There are two reasons for this:

1. Since a virus is self-propogating, the number of users to which it can spread (and cause damage) can be much greater than in the case of a Trojan;
2. It's almost impossible to trace the source of a virus since (generally) viruses are not attached to any particular program.

For further information on malicious programs on multi-user systems, see Matt Bishop's paper, "An Overview of Malicious Logic in a Research Environment", available by anonymous FTP on Dartmouth.edu (IP = as pub/security/mallogic.ps.

D8) Some people say that disinfecting is a bad idea. Is that true?

Disinfection is completely "safe" only if the disinfecting process completely restores the non-infected state of the object. That is, not only must the virus be removed from the object, but the original length must be restored exactly, as well as any system attributes (such as time and date of last modification, fields in the header, etc). Sometimes it is necessary to be sure that the object is placed on the same sectors of the disk that it occupied prior to infection (this is particularly important for some system areas and some files from programs which use certain kinds of self-checking or copy protection).

None of the currently available disinfecting programs do all this. For instance, because of the bugs that exist in many viruses and because some infection processes involve overwriting (part of) the objects of infection, some of the information about the original object may be irrevocably destroyed. Sometimes it is not even possible to detect that this information has been destroyed and to warn the user. Furthermore, some viruses corrupt information very slightly and in a random way (Nomenklatura, Ripper), so that it is not even possible to tell which objects have been corrupted.

Therefore, it is usually better to replace infected objects with clean backups, provided you are certain that your backups are uninfected (see D10), or from the original media. You should try to disinfect files only if they contain some valuable data that cannot be restored from backups or recompiled from their original source.

D9) Can I avoid viruses by avoiding shareware, free software or games?

No. There are many documented instances in which even commercial "shrink wrapped" software was inadvertently distributed containing viruses. Avoiding shareware, freeware, games, etc, only isolates you from a vast collection of software (some of it very good, some of it very bad, most of it somewhere in between...).

The important thing is not to avoid a certain type of software, but to be cautious of *any and all* newly acquired software and diskettes. Merely scanning all new software media for known viruses would be rather effective at preventing virus infections, especially when combined with some other prevention/detection strategy such as integrity management of programs.

D10) Can I contract a virus on my PC by performing a "DIR" of an infected floppy disk?

Assuming the PC you are using is virus free before you perform the DIR command, then the answer is "No".

When you perform a DIR, the contents of the boot sector of the diskette are loaded into a buffer for use in determining disk layout etc, and certain antivirus products will scan these buffers. If a boot sector virus has infected your diskette, the virus code will be contained in the buffer, which may cause some antivirus packages to produce a message like "xyz virus found in memory...". In fact, the virus is not a threat at this point since control of the CPU is never passed to the virus code residing in the buffer. Even though the virus is really not a threat at this point, this message should not be ignored. If you get a message like this, and then reboot from a clean DOS diskette and scan your hard-drive and find no virus, then you know that the false positive was caused by an infected boot-sector loaded into a buffer, and the diskette should be disinfected before use. The use of DIR will not infect a clean system, even if the diskette it is being performed on does contain a virus (see C8 also). Please note, however, that running DIR on a diskette can result in the infection of a clean diskette if the PC is already infected.

Despite our categorical "No" answer above, there is a small risk that a virus infection could be transferred from a floppy through a DIR listing. If you use an ANSI console driver that allows key remapping, it is possible that a specially prepared diskette could reprogram your keyboard so that pressing a particular key caused an infected program on the diskette to run the next time the reprogrammed key was pressed. The risk of such an attack is very low and can easily be negated following the general advice for preventing ANSI bombs (see A14).

Mac users with system software prior to version 7.0 should be aware of a greater threat in their environment. Various system resources (which can contain executable code) are loaded from the automatic access to a diskette that is part of the system building its desktop view of the diskette's contents. When such a resource is required, the most recently loaded one will be used. Thus, if a diskette with a virus- infected resource in the Desktop file is in your Mac's drive, and an uninfected copy of that resource has not subsequently loaded from elsewhere, the next time that resource is required the infected copy will be executed, along with the virus. This kind of attack was removed with the introduction of version 7.0 (and later) of the system software, which handles such things quite differently. A common Mac virus, WDEF, uses this infection path, as do a few others.

Early versions of AmigaDOS are susceptible to a threat similar to the Mac WDEF virus--on inserting a diskette into the drive, the operating system runs the Disk Validator from the diskette. At least one Amiga virus, Saddam, attaches itself to Disk Validator to help it spread. Version 2.0 of AmigaDOS eliminated the threat of this type of attack by removing the need for the Disk Validator.

D11) Is there any risk in copying data files from an infected floppy disk to a clean PC's hard disk?

Assuming that you did not boot or run any executable programs from the infected disk, the answer generally is no. There are two caveats:

1. You should be somewhat concerned about checking the integrity of these data files as they may have been destroyed or altered by the virus.
2. If any of the "data" files are interpretable as executable by some other program (such as a Lotus macro) then these files should be treated as potentially malicious until the symptoms of the infection are known.

The copying process itself is safe (given the above scenario) although you should be concerned with what type of files are being copied to avoid introducing other problems.

D12) Can a DOS virus survive and spread on an OS/2 system using the HPFS file system?

Yes, both file-infecting and boot sector viruses can infect HPFS partitions. File-infecting viruses function normally and can activate and do their dirty deeds, and boot sector viruses can prevent OS/2 from booting if the primary bootable partition is infected. Viruses that try to address disk sectors directly cannot function under OS/2 because the operating system prevents this activity.

D13) Under OS/2 2.0+, could a virus infected DOS session infect another DOS session?

Each DOS program is run in a separate Virtual DOS Machine (their memory spaces are kept separate by OS/2). However, any DOS program has almost complete access to the files and disks, so infection can occur if the virus infects files; any other DOS session that executes a program infected by a virus that makes itself memory resident would itself become infected.

Also, bear in mind that generally all DOS sessions share the same copy of the command interpreter. Hence if *it* becomes infected, the virus will be active in *all* DOS sessions.

D14) Can normal DOS viruses work under MS Windows?

Most of them cannot. A system that runs exclusively MS Windows is, in general, more virus-resistant than a plain DOS system. The reason is that most resident viruses are not compatible with the memory management in Windows. Furthermore, most existing viruses will damage Windows applications if they try to infect them as normal (i.e. DOS) EXE files. The damaged applications will stop working and this will alert the user that something is wrong.

Virus-resistant however, is by no means virus-proof. For instance, most of the well-behaved resident viruses that infect only COM files (Cascade is an excellent example), will work perfectly in a "DOS box". All non- resident COM infectors will be able to run and infect too. Aside from DOS viruses, MS Windows users can also contract several currently known Windows-specific viruses, which are able to infect Windows applications properly (i.e., they are compatible with the NewEXE file format).

Any low level trapping of Interrupt 13, as by resident boot sector and MBR viruses, can also affect Windows operation, particularly if protected disk access (32BitDiskAccess=ON in SYSTEM.INI) is used.

D15) Can I get a virus from reading e-mail, BBS message forums or USENET News?

In general terms, the answer is no. E-mail messages and postings on BBSes and News are text data and will not be executed as programs. Computer viruses are programs, and must be executed to do anything, so the simple act of reading online messages doesn't pose a threat of catching a computer virus.

There are a few provisos to be made. If your computer uses ANSI screen and keyboard controls, you may be susceptible to an ANSI bomb (see A14). An ANSI bomb may, merely by being placed in text read on the screen, temporarily redefine keys on the keyboard to perform various functions. It is, however, very unlikely that you will ever see an ANSI bomb in e-mail, or that it could do significant damage while you are reading mail.

Another possibility is that mail can be used to send programs. To do this program files have to be encoded into a special form so the binary (8-bit) program files are not corrupted by transfer over the text-only (7-bit) e-mail transport medium. Probably the commonest of these encoding schemes is uuencoding, though there are several others. If you receive an encoded program, you normally have to use a decoding program or special option in your e-mail program to extract it and decode it before it can be run. Once you have extracted the program though, you should then treat it as you would any other program whose source you do not know, and test it before you run it.

A third possibility is with the newer, highly-automated online systems. Some of these attempt to make online access much easier for the user by automating such features as file transfer and program updates. At least one commercial online service is known to have the capability of sending new programs to the user and to invoke those programs while the user is still online. While there is no reason to assume that any service that does this *will* infect you, any time things are going on that you are not being told about, you are at greater risk.

D16) Can a virus "hide" in a GIF or JPEG file?

The simple answer is "no". The complete answer is more complex.

GIF and JPEG (.JPG) files contain compressed graphical information. Every now and then, rumors arise that is possible to infect those files with a virus in such a way, that it will spread when you display one of these images. This is technically impossible--no part of the GIF or JPEG format contains code that is executed by the viewer program.

It *is* possible to use the least significant bit of the color information for each pixel in GIF files to store additional information, without visibly altering the quality of the picture contained in the file. This is called "steganography" and is sometimes used to transmit secretly encrypted messages. Since a virus is nothing more than information, it is possible to "encode" it into a GIF file and transmit it this way. However, the recipients must be aware that the GIF file contains such hidden information and take some deliberate steps to extract it--it cannot happen against their will.

----End Of Virus FAQ's Page----

---- Rookie

Press Here For Rookie's !!!
Press here To Go Back To Rookie's


Web and banner design by Rookie