Some of the main topics in this chapter are
Current estimates place the total number of computer viruses at or above 10,000, with between three and six new viruses written each day. This chapter describes the major classes of viruses, explains how they work, and details their behavior under Windows NT.
A computer virus is a program that performs self-replication by using files or boot sectors as its medium of propagation. Some viruses perform an activity in addition to replicating (known as a payload), such as displaying a message on a computer monitor, seeking out and deleting specific files, or formatting a hard drive. This behavior, however, is not prerequisite for a virus.
Most viruses are written in assembly language, a low-level language one step removed from the machine language of the computer chip. A few viruses have been written in higher level languages, such as C or Pascal, but using such languages typically results in undesirably bulky viruses. Macro viruses, written to target data files with macro capabilities, are an exception to this pattern.
Fortunately, as of the time of this writing, no viruses have been discovered that specifically target and infect the Windows NT operating system. Many of today's DOS and Windows viruses, however, can infect and propagate under Windows NT.
Every floppy disk has a boot record, or FBR. The boot record occupies the first sector on the disk and contains information that describes the contents of the floppy disk to the operating system. The boot record also contains a boot strap routine, a machine language program designed to load the operating system from the disk. When a computer is started with a floppy disk in the primary drive, the computer retrieves the boot record from the disk and executes its boot strap routine. The boot strap routine then loads the rest of the operating system, if one is present, from the disk. A message such as Non-system Disk. Insert a new disk and press any key might also appear.
Users frequently make the mistake of leaving disks in floppy drives. This seemingly benign error actually represents the sole vector of infection for the boot record virus. Boot viruses understand that the computer always loads and executes the boot strap routine when booting from floppy disks. Consequently, boot viruses replace the original floppy boot strap program with a viral boot strap program, enabling the virus to gain control of the system as soon as the computer starts. The virus then can infect the hard drive, destroy data, and wreak havoc on the computer. If the floppy disk boot strap routine is infected, the following sequence of events enable the virus to spread:
2. The computer detects a floppy disk in the primary floppy drive. It loads the boot record from the floppy disk and executes its boot strap routine, which is the viral boot strap routine.
3. The viral boot strap routine locates the (first) hard drive on the computer and infects its Master Boot Record or one of its partitions' boot.
4. The viral boot strap routine installs itself as a memory-resident program in the computer's memory.
5. The viral boot strap routine loads a backup copy of the original boot strap routine and executes it.
6. The disk boots normally.
7. The memory-resident virus infects additional floppy disks as they're accessed.
Each physical hard drive has exactly one Master Boot Record (MBR). Like the floppy boot record (FBR), the MBR also has two primary components. The first is a partition table, which denotes the allocation of all sectors on the drive and their respective partitions. Many application programs (and the operating system itself) make use of the information stored within the partition table to understand the disk's characteristics, such as how many partitions (logical drives) exist on the drive.
The second component of the MBR is a boot strap routine. During a system reset, a standard MBR boot strap routine first determines which partition is the active partition (the one from which the user wants to boot). The MBR loads and transfers control to the active partition's Partition Boot Record (PBR). The PBR, like the FBR, then loads the operating system present on the partition.
The MBR boot strap routine is the most common target for floppy boot viruses. Most FBR viruses infect hard drives by replacing the MBR boot strap routine with a viral boot strap routine. If the MBR boot strap routine is infected, the following sequence of events enables the virus to execute:
2. The computer has no floppy disk in the primary drive. The computer loads the MBR and executes its boot strap routine. This is the viral boot strap routine.
3. The viral boot strap routine installs itself as a memory-resident program in the computer's memory.
4. The viral boot strap routine loads a backup copy of the original (uninfected) MBR boot strap routine and executes it.
5. The original MBR boot strap routine locates the active partition and loads its PBR.
6. The MBR boot strap routine transfers control to the PBR boot strap routine.
7. The PBR loads and executes the operating system stored on the active partition.
8. The memory-resident virus infects floppy disks as they're accessed.
The MBR is the single most common target for boot viruses on the hard drive, but the Partition Boot Record(s) are less commonly infected. The PBR is most closely related to the FBR. Each partition (logical drive) on the physical hard drive has its own Partition Boot Record. The PBR contains a series of bytes that comprise the BPB or BIOS Parameter Block. These bytes describe the geometry and contents of the logical drive. The PBR also contains a boot strap routine that is charged with loading and executing the operating system present on the logical drive.
Some FBR viruses infect hard drives by replacing the PBR's boot strap routine with a viral boot strap routine. These viruses typically only infect the PBR of the current active partition (the bootable partition), because this constitutes the most likely partition that will actually boot, giving the virus a chance to spread. If the PBR boot strap routine has been infected, the following sequence of events enables the virus to execute:
2. The computer has no floppy disk in the primary drive. The computer loads the MBR and executes its boot strap routine.
3. The MBR boot strap routine determines which partition (logical drive) is active. The MBR boot strap routine locates and retrieves the PBR from the active partition.
4. The MBR then executes the PBR boot strap routine. Remember, the PBR contains the viral boot strap routine.
5. The viral boot strap routine installs itself as a memory-resident program in the computer's memory.
6. The viral boot strap routine loads a backup copy of the original (uninfected) PBR boot strap routine and executes it.
7. The original PBR loads and executes the operating system on active partition.
8. The memory-resident virus infects floppy disks as they're accessed.
The most common executable files used under DOS are COM, EXE, and SYS files. COM and EXE files are used for standard DOS programs, and SYS files are used for system device drivers. Although viruses have targeted each of these file formats, to date, reports of SYS file infections are rare. The basic file virus replicates by attaching a copy of itself to an uninfected executable program. The virus then modifies the new host program so that when you execute the program, the virus executes first.
A file-infecting virus gains control of the computer when the user or operating system executes an infected program. The infected program is usually modified so that the virus immediately usurps control. After the virus machine code begins executing, it can immediately seek out and infect other executable programs on the computer (this is called direct action infection), or it can establish itself as a memory-resident addition to the operating system. As a resident program, the virus can then infect subsequent executable files, as the operating system or other programs execute, copy, or access them for any reason.
After either type of virus has had a chance to do its mischief, it transfers control back to the host program. The host program can then execute normally, and the user is unaware of the infection.
The direct action file virus attempts to infect one or more programs as soon as an infected program is launched. After the virus has completed its infection, it relinquishes control of the computer to the host program.
DOS provides system services to efficiently and systematically traverse the many files and directories present on a drive. The direct action virus uses these services to locate new files to infect the same way that a file-finding program might locate files that contain a certain text-string.
The memory-resident file virus works in a manner similar to its boot record cousins. When an infected program launches, the virus installs itself as a memory-resident addition to the operating system. From this point, any time the user or another program makes a request to the operating system to execute or access a file, the virus intercepts the request and takes control of the computer.
The resident virus can then infect program files as the user references them. If the virus is memory-resident at the time the user references files, the virus gains control at the time of this DOS request. As the virus learns of the service request, it can infect the specified program and then pass the original request along to DOS. DOS then runs the (newly infected) program normally.
Today, the number of Windows 3.1 viruses is small but growing. Windows viruses come in the same direct-action and memory-resident flavors as the DOS-based viruses previously described. The difference between DOS and Windows viruses is their infection targets. DOS viruses infect standard COM, EXE and SYS files; Windows viruses are designed to infect only Windows New Executable (NE) EXE files.
A Windows NE file is a new type of EXE file that actually contains two independent program components. The first component of the NE file is a standard DOS executable program. This DOS executable can actually be up to 640 KB in size, like any other DOS program; however, this DOS program is typically a stub program that displays a This program requires Microsoft Windows. message. If you launch a Windows NE executable from DOS or from a DOS box (a window that has a DOS session running in it) under Windows 3.1, this DOS stub executes and runs as a standard DOS program would.
The second part of the NE executable file is the Windows executable. This part of the file has its own unique format, executable code, and resources that specify how the program operates under Windows. If the program is launched from within Windows, this part of the program is loaded and executed. Therefore, Windows viruses spread by modifying this component of the NE file.
Note that such a NE file could actually be simultaneously infected by a DOS virus and a Windows virus. If such a file were executed from DOS, then the DOS component, and hence the DOS virus, would launch. Conversely, if the file were run from Windows, then the Windows component, and hence the Windows virus, would execute.
The Tentacle virus is currently the only Windows 3.1 virus that has been found "in the wild." This virus was recently distributed over the Internet and has been found at numerous sites around the world. Later sections in this chapter discuss how this and other Windows 3.1 viruses function under Windows NT.
As of this writing, only a single Windows 95 virus has been constructed. This virus was dubbed "Boza" by virus researcher Vesselin Bontchev because of its poor design and programming. Boza infects 32-bit, Portable Executable (PE) files used by Windows 95 and Windows NT. The PE format has many things in common with the Windows 3.1 NE format; it differs enough, however, that viruses designed to infect one cannot work with the other.
Like the NE format, PE files contain two independent program components. The first component is a standard DOS executable program. Once again, this DOS program is typically a stub program that displays a message saying, This program cannot be run in DOS mode. If a Windows NE executable is executed from DOS, this DOS stub executes and runs as a standard DOS program would. The second part of the PE executable file is the 32-bit Windows executable. This part of the file has its own unique format, executable code, and resources that specify how the program operates under Windows 95 or Windows NT. If the program is launched from within Windows 95 or from a DOS box under Windows 95, this part of the program is loaded and executed. Windows 95 viruses can spread by modifying this component of the PE file.
Most 32-bit Windows programs written for Windows 95 run just fine under Windows NT. However, the Boza virus is an exception. Boza detects whether or not it is running under Windows 95 or NT and refuses to execute if it is being launched from Windows NT. Although Boza restricts itself in this way, there is no guarantee or reason why future viruses will do so.
In addition to the new PE file format, Windows 95 and NT also introduce several new types of executable files. No viruses have been constructed, however, to infect these other types of files.
Today's word processing and spreadsheet applications provide robust macro facilities that can be used to augment and enhance the application's working environment. Many of the older applications had simple macro systems. The user could record a sequence of operations within the application and then tell the application to associate this sequence of operations with a specific keystroke. Later, the user could perform the same sequence of operations by hitting the specified key. This permitted the user to perform redundant or complex operations with ease.
Newer applications provide much more complex macro systems. Today's applications enable the user to write entire macro-programs that run within the word processor or spreadsheet environment. These macro programs can do everything that their simple counterparts could do and more. In addition, modern applications enable these macros to be "attached" directly onto word processing and spreadsheet files. For example, you can program a special macro for a given Excel file, give this file to your friend, and then your friend can use your macro with the Excel file on his computer.
The capability to tote macros around with a data file is a very powerful feature. Unfortunately, such a facility also makes it possible to create macro viruses. Today's word processing and spreadsheet files not only contain data, clip-art, and text, but they also contain executable macro-programs. And where there are executable programs, viruses can flourish.
When a user loads a word processor or spreadsheet data file into an application, the application also loads any macros that are attached to the file. If one or more of the macros meet certain criteria, the application executes these macros as soon as they are loaded. Macro viruses rely on this auto-execution facility to gain control of the application's macro system as soon as an infected file is loaded. After the virus has been loaded and executed, it waits for the user to edit a new document.
The second that the user edits and saves a new document, the macro virus kicks into action. The macro attaches its viral macro programs to the new document and enables the application to save the document normally. In the blink of an eye, the virus has spread to another file, doing so in a completely discrete fashion; the user is given no indication of the infection. If this new file is opened on another computer, the virus loads, is launched by the application, and finds other unsuspecting files to infect.
Finally, most computer viruses are written in assembly language, an arcane, machine-specific programming language. This assembly language construction limits their capability to run on many different types of computers and makes them difficult to program. Macro viruses, however, have no such constraints. Macro programming languages are well documented and easy to program.
The following sections describe several major categories of viruses, based on their behavior. These classes of viruses are singled out because their behavior and capability to infect can be affected when running under Windows NT.
Multipartite viruses infect boot records and program files by using both mechanisms to spread. For example, when you run an application infected with a multipartite virus, the virus activates and infects the hard disk's MBR. Then, the next time you boot the workstation, the virus activates from the MBR and starts infecting floppy disks and program files. Only a small number of computer viruses have multipartite functionality because of relative complexity involved. The common One-Half virus is an example of such a virus. One-Half also employs stealthing techniques and is polymorphic or mutating (see the following section for more information).
Stealth viruses attempt to conceal their presence from the user. Most stealth viruses conceal themselves only while the virus is active in memory and hooked into the operating system as a memory resident program. These viruses actively intercept system requests that might reveal information about the viral infection and alter the system service output to conceal their presence.
Stealth viruses are typically classified as having size stealth capabilities, read stealth capabilities, or both. Size stealthing applies exclusively to file infecting viruses. When a virus infects a program file, the virus usually attaches a copy of itself onto the target program file. This results in the target file growing in size by the length of the virus. Because a user might notice such a difference in file size, the size stealthing virus masks the size increase. (Believe it or not, some users, especially antivirus researchers, do remember the size of certain executable files on their systems.)
By examining the infected file's contents, a user can see the virus and the changes it has made to the program. This type of stealthing is somewhat like hiding during a game of hide and seek by placing a lampshade over your head. Most users don't examine the binary contents of their program files, however, and if they don't notice any change in the overall computer performance or in the size of their programs, they probably won't notice the viral infection.
With read stealthing, when the operating system or another program makes a request to read an infected boot record or file, the virus intercepts the request and provides the requester with the original, uninfected contents. The Stoned.Monkey virus, for example, uses read stealthing. This read stealthing works properly under DOS, Windows 3.1, and Windows 95. If a user executes a disk editing utility to examine the MBR contents where Stoned.Monkey hides, she won't find any evidence of infection. Stoned.Monkey's memory resident handler is called any time the disk is accessed, and it checks to see whether any attempts are being made to read the MBR. If so, the virus provides a backed-up copy of the original item in place of the infected copy. This stealthing can be defeated by specially written tools and antivirus programs but goes undetected by the average disk utility.
Read stealthing also conceals viruses in program files. Usually, the read stealthing file virus possesses size stealthing capabilities, as well; it would be useless for a program to hide content changes to an infected file, yet still show the increased file size. For example, the Tremor virus uses both read stealthing and size stealthing to conceal its presence in infected files.
Most stealth viruses can conceal their presence only while resident and active in the computer's memory. If they are not installed as a memory-resident program, any infection is visible. This is why most antivirus manufacturers instruct users to boot from a write-protected, uninfected floppy disk before scanning for, or repairing, virus infections.
Companion viruses only infect program files; they are unique, however, because they don't attach themselves to existing program files. Instead, the companion virus infects by creating a new file and causing DOS to execute this new program rather than the original one.
Companion viruses use numerous strategies. One such virus creates a COM file with the same file name and in the same directory as an existing EXE file.
When a user types the name of a file to execute at the DOS prompt and both a COM and EXE file of the same name reside in the same directory, the DOS command interpreter (COMMAND.COM, for example) always executes the COM file and ignores the EXE file.
This type of companion virus, for example, could create a file named FORMAT.COM in the DOS directory, knowing that FORMAT.EXE is a popular and frequently executed file that also resides in the DOS directory. (The average user could easily overlook the addition of a new file with such a name. In addition, some companion viruses actually conceal the file by changing its attribute to hidden.)
This technique ensures that when a user attempts to execute the FORMAT program, DOS loads the companion virus rather than the original program. Finally, the companion virus runs the original FORMAT.EXE program, and the user is unaware of the infection.
The Windows NT operating system constitutes a paradigm shift from other Microsoft operating systems. It differs from other current PC operating systems in a number of ways:
The remainder of this chapter describes how each of the major types of viruses described functions under Windows NT, given the differences between NT and previous Microsoft operating systems.
The following virus classes are detailed: MBR viruses (on floppy and hard drive), PBR viruses (on floppy and hard drive), direct action file viruses, memory resident file viruses, multipartite viruses, companion viruses, macro viruses, Windows 3.1 viruses, and Windows 95 viruses. Finally, the possibility of native Windows NT viruses is discussed.
NOTE: Boot record viruses, Windows 3.1 viruses, and Windows 95 viruses do not function properly on non-Intel-based Windows NT installations (such as a DEC-Alpha or Power PC). Only DOS-based file viruses executed with an emulated 80x86 DOS box function properly.
MBR viruses are typically acquired in two different ways. The first method involves booting off of an infected floppy disk. The second method involves running a dropper program from a DOS session that directly "drops" the virus onto the MBR of the hard drive; multipartite computer viruses sometimes attempt this type of infection.
MBR Infection by Booting Off of an Infected Floppy Disk. The Windows NT operating system is still susceptible to infection from a floppy disk. Because NT does not have control of the computer during system boot-up, booting from an infected floppy enables the virus to infect the MBR of any of the physical drives on the system by using the usual techniques. This vector of infection is quite common, and we can expect to see more of this type of infection in the future.
MBR Infection by Running a Dropper Program or Multipartite Virus. Dropper programs and multipartite viruses infect the MBR of the hard drive by using BIOS or DOS services to directly write to the hard drive. Because Windows NT prevents all such writes from within an NT DOS box, this type of infection can be completely prevented while NT is running.
If the computer in question has the capability to dual-boot to DOS or Windows 95, however, then the user could boot to one of these operating systems and execute the dropper program or multipartite virus normally.
NOTE: Although DOS-based virus dropper programs are completely neutered under Windows NT DOS boxes, native Windows NT programs can be constructed to modify the contents of the hard drive MBR.
The NT Boot-up Process with MBR Infection. After a virus is present in the MBR, future system reboots enable the virus to become memory resident in the usual fashion. In addition, if the virus contains any type of payload that is triggered during boot-up, this trigger mechanism functions just as it would under a DOS or Windows 95 system. The virus has the same control because the Windows NT operating system has not yet loaded; therefore, the virus executes as a real-mode program with full access to the entire PC. Thus, viruses such as Michelangelo and One-Half are still able to cause significant damage to Windows NT systems.
Upon boot-up, after the virus has installed itself in memory, it passes control to the original system MBR, which then transfers control to the Windows NT boot-record. This boot record then loads the Windows NT loader, which loads the rest of the operating system. During this loading process, NT switches into protected mode and installs its own protected-mode disk drivers. These protected-mode drivers are used for all further disk operations; consequently, the original BIOS disk drivers and any virus that hooked into these drivers are never activated or used in any way.
Accordingly, after Windows NT starts using its own drivers, the resident MBR virus is effectively stopped in its tracks. Furthermore, unlike Windows 95, Windows NT does not support a compatibility mode which enables disk requests to be sent to the original real-mode disk drivers (and potentially a virus). These Windows NT characteristics have the following implications.
You typically acquire Partition Boot Record viruses in one of two different ways. The first method involves booting off of an infected floppy disk. The second method involves running a dropper program from a DOS session that directly drops the virus onto the boot record of the active partition; multipartite computer viruses sometimes attempt this type of infection.
Like MBR viruses, Partition Boot Record viruses are unable to replicate under Windows NT. The PBR virus is disabled because during the boot-up process, NT switches into protected mode and installs its own protected-mode disk drivers. These protected-mode drivers are used for all further disk operations; consequently, the original BIOS disk drivers and any virus that hooked into these drivers is never activated or used in any way.
Boot Record Infection by Booting Off an Infected Floppy Disk. The Windows NT operating system is still susceptible to this type of infection. Because NT does not have control of the computer during system boot-up, booting from an infected floppy enables the virus to infect the boot record of the active partition on the system by using the usual techniques. This vector of infection is quite common, and we can expect to see more of the same in the future.
Boot Record Infection by Running a Dropper Program or Multipartite Virus. Dropper programs and multipartite viruses infect the boot record of the hard drive by using BIOS or DOS services to directly write to the hard drive. Because Windows NT prevents all such writes from within an NT DOS box, this type of infection is completely prevented while NT is running.
If the computer in question also has the capability to boot to DOS or Windows 95, however, then the user could boot to one of these operating systems and execute the dropper program or multipartite virus normally.
Again, while DOS-based virus dropper programs are completely neutered under Windows NT DOS boxes, native Windows NT programs can be constructed to modify the contents of the active Partition Boot Record.
Damage Due to Boot Record Virus Infection. As described, hard drives can still become infected with boot record viruses by booting off of an infected floppy disk. Boot record viruses infect PBRs by relocating the original PBR to a new (and you hope, unused) location of the drive and then replacing the original boot record with the viral boot record. Usually, PBR viruses place the original, uninfected boot record at the end of the infected drive.
Depending on the type of file system that is being used on the Windows NT boot partition, different problems can arise, as outlined in the following section.
Damage Due to Boot Record Virus Infection on FAT Systems. If the virus places the original boot record at the end of the drive and does not take steps to protect this sector, Windows NT or another operating system can inadvertently overwrite the saved boot record. This causes the system to crash during boot-up, because the virus will inevitably try to load and execute the original (corrupted) boot record. The same behavior can also occur under DOS and Windows 95. Some viruses avert this problem by marking the reserved sector as "bad" or as "used." The virus could also decrease the size of the last partition (by altering the partition table in the MBR) so that the specified sector is inaccessible to the operating system.
If the virus corrupts or replaces the contents of the BPB (BIOS Parameter Block) within the PBR and relies on stealth functionality to hide these changes, Windows NT is unable to access the drive after the protected-mode disk drivers are in use. This is analogous to the Stoned.Empire.Monkey problem described earlier.
Standard Partition Boot Record viruses should not cause any additional problems on FAT-based, Windows NT systems. The virus is completely disabled as soon as the NT protected-mode drivers are loaded and in use.
Damage Due to Boot Record Virus Infection on NTFS Systems. During installation of a bootable NTFS partition, the Windows NT installer places an operating system loader program on the sectors immediately following the NTFS boot record. When the MBR loads and executes the Windows NT PBR during system boot-up, the PBR immediately rereads itself and these additional boot strap sectors into memory and transfers control to them. The NTFS boot record and these additional sectors comprise a multisector boot strap program that is capable of loading and launching the bulk of the Windows NT operating system.
If a boot record virus infects the NTFS boot record, it effectively overwrites the first sector of the multisector boot strap program, causing important routines and data to be lost. Following is the sequence of events in the NTFS boot-up process with a boot record infection:
2. During the NTFS boot-up, the computer loads and executes the original MBR. The MBR boot strap routine then loads and transfers control to the viral PBR of the active NTFS partition.
3. The virus then installs itself in memory and transfers control to the original NTFS PBR, which is retrieved from the end of the physical drive where the virus stored it.
4. At this point, a small routine in the uninfected NTFS boot record attempts to load the entire NTFS boot strap program (comprised of what should be the original NTFS boot record and the following sectors). However, the first sector of the multisector boot strap program has been replaced by the viral PBR. Thus, a corrupted copy of the boot strap program is loaded and executed. This corrupted copy consists of the viral PBR followed by the remaining original boot strap sectors.
5. Executing this corrupted program results in a system crash, and Windows NT fails to start up.
Most PBR viruses cause an NTFS-based, Windows NT system to crash during boot-up. If the boot record virus has stealth capabilities, however, Windows NT might be able to properly load.
The following describes the boot-up sequence if a stealth PBR virus has infected the drive.
2. During the NTFS boot-up, the computer loads and executes the original MBR boot strap routine. The MBR boot strap routine then loads and transfers control to the viral Partition Boot Record of the active NTFS partition.
3. The virus then installs itself in memory and transfers control to the original NTFS Partition Boot Record boot strap routine, which is retrieved from the end of the physical drive where the virus stored it.
4. At this point, the uninfected boot strap attempts to load the entire multisector NTFS boot strap program (comprised of what should be the original NTFS boot record and the following sectors). The virus's resident handler intercepts the load request and substitutes the original boot record for the viral boot record. It also loads the other boot strap sectors, as requested.
5. Control transfers to the multisector boot strap program and Windows NT boots normally.
You can install Windows NT within an existing DOS/Windows 95 FAT-based partition, which gives the user the option of either booting into Windows NT or into the old DOS or Windows 95 operating system. Windows NT provides this dual-boot service by making a backup copy of the DOS/Windows 95 boot record during its installation and saving this backup copy to a file called BOOTSEC.DOS in the root directory of the DOS/Windows 95 partition. Windows NT then replaces the boot sector of the FAT-based drive with the Windows NT boot sector.
Each time the user reboots the system, the Windows NT loader asks the user which operating system he would like to start. If the user requests a boot-up into DOS or Windows 95, then the Windows NT loader loads and executes the original boot record contained in the BOOTSECT.DOS file and boots the computer into a standard DOS/Windows session.
Unfortunately, if the boot record of the DOS/Windows 95 partition is infected with a virus before Windows NT is installed, a copy of this virus is placed within the BOOTSEC.DOS file during installation. Consequently, each time the user boots the system into DOS or Windows 95, the virus gains control of the system. In addition, because the virus is not located within the boot record of the drive, it is not detected by Windows NT-unaware antivirus tools.
To fix this problem, the user must use a disk editor to locate the original DOS/Windows 95 Partition Boot Record that was saved by the virus (presumably at the end of the drive). The user must then replace the BOOTSEC.DOS file with this non-viral PBR.
Viruses such as Michelangelo and One-Half are capable of doing damage during the boot-up process but are completely disabled after Windows NT starts using its protected mode disk drivers. Thus, infection of floppy disks or files (in the case of a multipartite virus) is prevented in all instances (that is, in DOS boxes, and so on).
Viruses that do not save the active Partition Boot Record's BPB information or the Master Boot Record's partition table can prevent NT from booting or make certain drives inaccessible. Furthermore, all non-stealth boot record viruses (such as the extremely common Form virus) that infect bootable NTFS partitions corrupt the multisector operating system boot strap loader and cause Windows NT to crash during boot-up. When booting from an infected floppy disk, buggy virus infection mechanisms can also cause data loss under all file systems supported by NT.
Most DOS file viruses function correctly under a Windows NT DOS box. As previously mentioned, file viruses typically come in two flavors: direct action viruses and memory resident viruses. These two types of viruses have different behaviors under Windows NT.
Direct Action File Viruses. Direct action file viruses function in exactly the same manner as they do under a standard DOS or Windows 95 system. These viruses typically use the standard DOS system services that are thoroughly emulated in Windows NT DOS boxes.
Some older or poorly written direct action viruses might employ behaviors that cause them to crash or work improperly under a Windows NT DOS box. However, such a case is the exception rather than the rule.
Memory Resident File Viruses. In most cases, memory resident file viruses are able to stay memory resident within the confines of a Windows NT DOS box. After the virus is resident within a given DOS box, it is able to infect any programs accessed or executed within that DOS box, assuming the user who launched the virus has the correct access to modify the target program.
The virus is unable to spread to other DOS boxes --each DOS box has its own protected memory space. Nothing prevents a user, however, from executing infected programs in several DOS boxes. Thus, several independent copies of the virus can be active and infectious at once.
Furthermore, if the virus in question has infected the command shell (that is, CMD.EXE or NDOS.COM) used in Windows NT DOS boxes, then every time the user opens a new DOS box, he automatically launches the memory resident virus into the box's memory space.
Windows NT emulates most DOS functionality within its DOS boxes and in some ways provides more compatible support than Windows 95 DOS boxes. Memory resident viruses, which hook into the DOS system services within a DOS box, can gain control and are able to infect files any time the system services are utilized by DOS or other programs.
For example, when a user executes a DOS program on a standard DOS machine (that is, not Windows NT/95), the command shell (COMMAND.COM or NDOS.COM, for example) generates an EXECUTE PROGRAM system service request to the DOS kernel. Many viruses intercept this system service to infect program files as the user executes them. Windows NT provides the same functionality in its DOS boxes and enables viruses to intercept this system service and infect at will.
Furthermore, Windows NT enables users to launch native Windows applications directly from the DOS box's command line. Under the NDOS command shell, any Windows (NT/95/3.1) program that is launched from a DOS box's command line causes the NDOS command interpreter to generate an EXECUTE PROGRAM system service request.
Thus, if a memory resident virus were to hook into the EXECUTE system service, it could potentially infect these Windows programs as they are executed. The vast majority of DOS viruses, however, are incapable of correctly infecting native Windows executable programs. If such a virus were to infect the DOS stub component of the NE/PE file, it would inadvertently overwrite and corrupt the Windows component of the program located at the end of the file.
The default command shell (CMD.EXE) that ships with Windows NT does not generate the EXECUTE system service request when Windows executables are launched from a DOS box; memory resident computer viruses are unable to infect native Windows programs launched from a CMD.EXE based NT DOS box.
Stealth File Viruses. Most memory resident, stealth file viruses function properly within Windows NT DOS boxes. Some stealth viruses might function improperly, however, if they use undocumented DOS functionality that is not fully supported by Windows NT DOS boxes.
However, such a stealth virus is only able to conceal its changes from programs executing within the same DOS box as the virus. For instance, if a Windows 3.1, 32-bit Windows, or DOS program running in another DOS box accesses an infected file, the virus's resident stealth handler does not activate and consequently fails to conceal the viral changes.
Companion File Viruses. Companion file viruses come in both resident and direct action varieties. These viruses should function properly under a Windows NT DOS box in most instances (see "Memory Resident File Viruses" and "Direct Action File Viruses"). Again, if the virus employs undocumented DOS functionality, it might not work properly inside of a Windows NT DOS box.
Companion viruses rely on the functionality of the DOS command interpreter to spread. This reliance can also cause some companion viruses to fail if the command interpreter used in the NT DOS box differs significantly from the standard COMMAND.COM interpreter assumed by most viruses. (The default Windows NT command interpreter has no such incompatibilities.)
Damage by File Viruses. Windows NT provides file-level access control, which prevents protected files from becoming modified by DOS-based file viruses. The access control provided by Windows NT is significantly more robust than DOS's simple read-only attribute and cannot be bypassed by DOS programs.
If an infected program is run by a system operator with root privileges or the Windows NT system is set up without access control, however, the virus can modify all files to which the operator has access.
If we assume that the typical Windows NT configuration does not employ NT's security features, then viruses are able to damage files as they do on a standard DOS system. For instance, viruses that corrupt program files unintentionally during the infection process are still able to do so under Windows NT DOS boxes. On the other hand, file viruses that attempt to trash the hard drive by using direct disk access are thwarted under Windows NT because Windows NT prevents all direct access to hard drives.
Although Windows NT prevents DOS programs from writing directly to hard drives, it does not prevent DOS programs from directly writing to floppy disks--multipartite DOS viruses launched from within a DOS box might be capable of infecting or damaging floppy disks.
Luckily, when launched in a DOS box or on a standard DOS system, most multipartite viruses attempt to infect the hard drive's MBR or Partition Boot Record to gain control during boot-up. Because Windows NT prevents direct hard drive writes from within a DOS box, these viruses are effectively neutered.
DOS-based file viruses only function properly within a DOS box under Windows NT. Under all other circumstances, these viruses fail to function correctly and are non-viral in nature.
DOS File Viruses under Windows NT--System Susceptibility During Boot-up. If one of the files responsible for Windows NT boot-up becomes infected with a DOS-based computer virus, Windows NT is likely to fail to load properly. This occurs because DOS-based viruses require the DOS kernel to function, and DOS is necessarily absent during Windows NT boot-up (because NT does not utilize DOS in its operation). The absence of the DOS kernel during the boot-up process, therefore, causes infected executables to crash after the infected program executes.
DOS File Viruses--The Bottom Line. Most DOS file viruses propagate under Windows NT DOS boxes as they do on standard DOS systems. The built-in Windows NT file and directory protection prevents infection of protected files; however, the system must be explicitly configured to provide this protection. Unfortunately, many users might be unaware of, or inconvenienced by, this protection and disable it.
Multipartite viruses (viruses that infect files and boot sectors) are no longer able to infect hard drive boot records or master boot records from within DOS boxes. If the virus relies on this behavior for propagation, it will be neutered by Windows NT's direct-disk access restrictions. However, multipartite file viruses are still able to infect floppy disk boot records, if they are so inclined (although this behavior is rare).
DOS file viruses only function within DOS boxes. Although it is possible for native Windows NT system files to become infected (direct-action viruses search for files all over the hard drive), the infected system files are likely to fail to function properly and cause the machine to crash during Windows NT boot-up.
If a resident DOS file virus is launched from within a DOS box, only files referenced from within the infected DOS box can potentially become infected. Thus, any Windows NT antivirus product that executes outside of a DOS box (such as a 32-bit Windows app) can safely scan the computer without the possibility of infecting clean files; memory scanning is not necessary to properly detect and repair virus infections.
Most of the native Windows 3.1 viruses function under Windows NT as they do under Windows 3.1 because Windows NT was designed to faithfully execute Windows 3.1 programs.
At least one Windows 3.1 virus uses DPMI (DOS Protected Mode Interface) to hook into the standard Windows system services and establish itself as a memory resident Windows TSR. The Ph33r virus hooks into the Windows 3.1 EXECUTE PROGRAM system service and is notified every time a user or another Windows 3.1 process executes a Windows 3.1 program. Upon notification, the Ph33r virus can infect the Windows 3.1 executable file before it is executed.
Viruses that hook into these services also function under Windows NT as they do under Windows 3.1. Under Windows NT, however, the Windows 3.1 TSR virus previously described will only be notified about the execution of standard Windows 3.1 executables. For instance, if a user launches a native 32-bit Windows NT/95 application, the Windows 3.1 subsystem under Windows NT (and any Windows 3.1 TSRs hooked into its system services) is not made aware of the 32-bit program's execution. Consequently, only Windows 3.1 executables launched on the Windows NT system are susceptible to infection or corruption by traditional, resident Windows 3.1 viruses.
Furthermore, Windows NT enables the user to specify whether each Windows 3.1 application is launched in either a common Windows 3.1 memory area or in its own separate memory area. This functionality is provided so that users can prevent misbehaved Windows 3.1 applications from interfering with one another. If the user loads an infected Windows 3.1 application in its own memory area, then the resident virus does not receive notification of system service requests (such as EXECUTE PROGRAM requests) from other Windows 3.1 applications. Such a virus is effectively neutered.
Direct action Windows 3.1 viruses spread normally in most cases; Windows NT faithfully emulates all the standard Windows 3.1 services that can be used to locate and modify programs.
All macro viruses written for applications that run on Windows 3.1 or Windows 95 function correctly under Windows NT if the host application works correctly under Windows NT. For example, because Word for Windows version 6.0+ works both on Windows 95 and Windows NT, the Concept virus works correctly under both platforms, as well.
The file-level protection that Windows NT provides can be used to prevent unauthorized use of documents (limiting potential infection); however, these macro viruses can still be spread through electronic mail or publicly accessible files on a network.
Macro viruses continue to propagate under Windows NT systems. Given the necessity of information-sharing in the enterprise environment, the macro viruses might surpass their file and boot-record cousins as the most common viral threat.
Windows NT presents a much greater challenge to virus writers. First, the basic Windows NT operating system requires at least 12M of conventional RAM, a high-speed microprocessor, and tens of megabytes of hard drive space. Most currently sold machines are not powerful enough to provide a bare-bones Windows NT setup for software development. Consequently, virus writers might not be able to afford the appropriate hardware to develop complex, native Windows NT viruses.
Unfortunately, these same virus writers might be able to afford a Windows 95-based computer. Such a computer can also be used to develop simple, 32-bit Windows viruses capable of infecting both Windows 95 and Windows NT.
In addition to the Windows NT hardware requirements, the native Windows NT/95 executable file formats are also more complex than those found in DOS. Windows 3.1 also employs similar executable file formats that might account for the much smaller number of native Windows viruses. Furthermore, far less documentation is available on the 32-bit file formats, requiring virus writers to spend time reverse engineering their file structure.
Finally, the Windows 3.1 architecture permits Windows applications to call standard DOS system services directly, as if they were DOS applications. This permits virus writers with only a superficial understanding of the Windows 3.1 operating system to create viruses by using standard DOS-based virus algorithms.
The Windows NT and Windows 95 operating systems do not enable 32-bit applications to use the DOS system services, although Windows 3.1 programs running in these environments are enabled to use these services. Therefore, virus writers have to gain a fairly detailed understanding of the Windows 32-bit API in order to create native Windows NT/95 viruses.
This probably reduces the number of native Windows NT/95 viruses encountered in the short term. As more detailed documentation is published in popular books and magazines and as virus authors freely distribute their creations, however, native 32-bit Windows 95 and NT viruses will undoubtedly increase in number.
The Windows NT operating system is definitely susceptible to DOS-based computer viruses. In many instances, Windows NT prevents viruses from spreading as they do under DOS or Windows 95; however, these same viruses can still intentionally or unintentionally cause significant damage to the Windows NT operating system, its programs, and its data. As previously described, DOS-based viruses can be split into two categories: boot record viruses and file viruses.
The Windows NT architecture severely limits the functionality of boot viruses, should the MBR or boot record of the hard drive become infected. If Windows NT is able to start up on an infected system, the infecting boot virus is never activated because NT's protected mode disk drivers are used instead of the viral disk drivers. Thus, standard boot viruses are unable to propagate under the Windows NT operating system. Unfortunately, these viruses can still cause serious damage to NT systems, as shown in the following list.
In addition, if Windows NT is installed on top of a DOS or Windows 95 partition, it provides the user with a special mechanism for dual booting between the Windows NT and DOS/Windows 95. To provide this dual boot functionality, Windows NT maintains a copy of the original DOS/Windows 95 boot record (present on the drive before Windows NT installation) and uses this copy in the DOS/Windows 95 boot-up process.
Unfortunately, if the boot record of the DOS/Windows 95 partition is infected before Windows NT installation, the copy of the boot record maintained by Windows NT also contains this infection. Furthermore, the copy of the boot record is stored within a file (not in the traditional boot area of the hard drive); therefore, non-Windows NT-aware antivirus tools are unable to detect and repair this infection, leaving the system vulnerable to any boot record virus present on the system at the time Windows NT is installed.
As Windows 95 and Windows NT become the predominant operating systems on PCs, you can expect to see a reduction in the number of boot virus infections because these operating systems subvert their primary method of infection. However, for the time being, these viruses can still cause serious damage to Windows NT systems, and traditional tools might not be able to recover from infection.
Most of the DOS-based and Windows 3.1-based file viruses function properly under Windows NT. Under the NTFS file system, Windows NT enables the user to protect files on a per-file or per-directory basis; however, this security feature might have little effect on DOS/Windows 3.1-based file viruses. Specifically, the following holes are still open to viruses under Windows NT:
Currently, DOS/Windows 3.1 file viruses are unable to infect native Windows NT executable files, although they might unknowingly try to do so and cause damage. In addition, a hybrid file virus can be written to infect both DOS and 32-bit Windows executable files. In fact, this basic concept has already been observed: The recently released Ph33r virus has the capability to infect both DOS and Windows 3.1 executable files.
The new macro viruses also function properly under Windows NT. These viruses do not rely on the underlying operating system to propagate and therefore have no difficulty infecting any Windows NT machine that supports Win Word or other macro-capable products.
Finally, although no native Windows NT viruses exist today, their future appearance is unquestioned. Even though Windows NT provides a significant amount of memory and file protection, native VDD-based (Virtual Device Driver) viruses will have the capability to modify memory, infect or damage files, and directly access both hard drives and floppy disks. They will be able to intercept any system service and infect programs or floppy disks at will. In short, they will have the same capabilities as their DOS cousins on an unprotected DOS machine.
The following set of steps details a number of simple precautions you can take to reduce your chances of getting a virus under Windows NT. After each precaution you see one or more scenarios that can be averted by using the described technique. Finally, each precaution is also accompanied by a resolution section that helps simplify the recovery effort if your computer contracts a virus.
2. Configure your computer (in the CMOS setup) so that it boots from the hard drive, not from floppy disks. In addition, scan all floppy disks with an antivirus program.
3. Make sure to create Windows NT Emergency Disks when installing Windows NT. If you haven't created emergency disks, use the RDISK.EXE program found in the WindowsNT\System32 directory to create these disks. Update these disks any time you make changes to your system configuration.
NOTE: The One-Half virus is a multipartite, "in the wild" virus that infects the MBR of hard drives. Each time the user reboots or resets the computer, the virus gains control during the boot process and encrypts two additional cylinders of the hard drive.Although the Windows NT Emergency Disk can remove the virus from the MBR, it is unable to decrypt those sectors of the hard drive that the virus has already garbled. Therefore, you should always scan your computer with an antivirus program before using any generic emergency tools. An updated antivirus program can identify the virus strain exactly and take the appropriate steps to remove the virus and undo all reversible virus-specific damage.
5. Use an on-access antivirus scanner to protect yourself against Macro and other viruses. The on-access scanner runs in the background and constantly searches for viruses each time you access files and disks. (All three products listed in Table 29.1 provide on-access scanning.)
| Product | Company | URL |
| Norton Antivirus for Windows NT | Symantec | http://www.symantec.com |
| VirusScan for Windows NT | McAfee | http://www.mcafee.com |
| InocuLAN for Windows NT | Cheyenne | http://www.cheyenne.com |
© Copyright, Macmillan Computer Publishing. All rights reserved.