EXEBug

Tim Twaits

It is rare that a virus introduces a completely new idea -- most are simply adaptations of existing viruses with small modifications or additions. The author of the CMOS1 virus, however, seems to have managed to find a new approach. To the best of my knowledge it is the first virus which modifies the non-volatile system configuration data in the CMOS RAM in anything other than a destructive way: hence the name CMOS1 [This is the name the virus was given at the time of the article. WebEd.].

In The Wild Origins

It was unusual to receive this virus from a user whose PC had been infected rather than from one of the many virus researchers and collectors. As such, it provides an insight into how a new virus is first detected and countered. The first suspicion of something amiss arose because of an error condition detected by the Windows 3.1 32-bit disk driver. It would have been easy to ignore the message, since Windows still ran successfully without using the 32-bit driver. Luckily somebody decided to investigate.

The first step taken was to attempt to scan the machine for known viruses. However, after performing a clean boot from a system diskette prior to running the virus scan, the hard drive could not be accessed. Armed with this knowledge of the symptoms, the investigator identified another infected machine. Both machines were immediately isolated and all associated diskettes quarantined.

At this point I received a copy of the virus. As soon as a recognition pattern had been extracted, a complete scan of all machines and disks was undertaken. In this case the virus had been contained and no new infections were discovered. The source of the infection was later traced to a golf game which had recently arrived from Taiwan. This game had also been sent to an office in South Africa, so the virus may well have spread further afield.

Operation

CMOS1 is primarily a master boot sector virus. When the computer is booted from an infected disk the virus gains control. It creates a 'hole' in memory by decrementing a data value in the ROM BIOS data area which contains the useable memory size. This has the direct effect of reducing the available DOS memory by 1K. The virus then installs its own Interrupt 13h handler, which intercepts all calls to the BIOS disk services, before allowing the boot sequence to continue normally.

CMOS Modifications

The CMOS battery backed RAM in an IBM compatible PC contains the non-volatile system configuration information. The CMOS1 virus modifies this information to indicate that there is no A: drive attached to the computer. This appears to be an attempt to force the PC to boot from the C: drive in all circumstances, thus ensuring that the virus is always resident in memory. This in itself provides cause for concern, but more worryingly, it seems as though the author then intended the machine to reboot from the correct drive.

If this strategy had been successful it would be impossible to achieve a clean boot and the virus would be very difficult to detect. Fortunately, the author has made a number of false assumptions which mean that the virus will never function as described on a truly IBM compatible machine. However, be warned -- presumably it worked (at least to some extent) on the virus author's machine.

This virus fails in its attempt to prevent a clean boot, but it must be asked whether such a feat is feasible. The answer to this could have a large impact on the viability of current virus detection procedures.

Because of the variations between PC BIOSes, it would appear that the boot sequence varies between machines. On the machines on which I tested this virus, the Power On Self Test routine detected the presence of a floppy disk drive regardless of the CMOS contents. This function appears to be reasonably standard, so this technique is highly unlikely to be the basis of a successful virus.

Infection

The virus always infects drive 80h (normally drive C) immediately after booting from an infected diskette. Further diskettes are infected when their contents are read. Thus simply inserting a diskette and typing DIR A: will cause the diskette to become infected. When infecting a disk, the virus needs to keep a copy of the original boot sector so that the boot sequence can be completed successfully after the virus code is executed.

On a hard disk the original MBS is stored in sector 17, cylinder 0, head 0. On a diskette an extra track (number 40 or 80, depending on the disk size) is formatted at the end of the normal data area. Creating this extra track has the advantage that the storage capacity of the diskette is not affected. However, not all systems can access this extra track successfully, and this will cause some machines to hang when booting from an infected diskette.

Stealth

The virus intercepts all requests to read the master boot sector and returns the contents of the original sector to the caller. This effectively hides the virus from scanning software unless a clean boot is achieved. It also provides the mechanism by which the virus invokes the original boot code at initialisation. The virus issues an INT 19h call to restart the system once the intercept handler is installed. The system then starts normally since the bootstrap code will now load the original boot sector.

All requests to write to the master boot sector are also intercepted, allowing the write operation to complete but then immediately re-infecting the disk. The result is that one can run utilities which modify the boot sector, such as FDISK, without displacing the virus.

The virus contains another feature, which could perhaps be described as stealth. As well as overwriting the code in the master boot sector, the virus also overwrites the partition table with invalid data. Thus when booting from a clean system diskette the hard drive cannot be accessed directly. Although one cannot scan the drive to detect the virus, the absence of logical drive C betrays its presence.

Increased Contagion And Trigger

In an attempt to make itself more contagious the virus will infect some EXE files written to drive A. The infection routine is primitive, as the file is simply overwritten by the virus. The program infects drive 80h immediately upon execution. This type of infection occurs whenever data starting with 4Dh (the EXE header identifier) is written to sector 3 on any cylinder of the diskette. This not only produces infected EXE files but will also corrupt any files which contain a sector starting with 4Dh.

While the creation of infected program files will undoubtedly help the virus to spread, it also significantly reduces the chance that the virus will survive in the wild. Since the infected programs are overwritten with the virus code they no longer retain their original function, providing an immediate signal that something has gone awry. While I do not think that it is beyond the (limited) technical ability of the virus author to devise a more sophisticated strategy, the code size has been restricted to less than 512 bytes, and there is simply no room for a routine which would make this virus truly multi-partite.

A proportion of EXE files written to fixed drives will be similarly modified, although in this case the modified program has a more disastrous effect. It will overwrite the first track of the first fixed drive, effectively making all data inaccessible. The data on any diskettes is also overwritten. These files are only produced when writing the EXE header to sector 3 on any cylinder in the range 512-767. The disk must contain a significant amount of data before this occurs.

Removal

After performing a clean boot, one can detect the presence of the virus both in the boot sector and in any files by using a simple search pattern. It is important to check data files as well as executables, since they may have been corrupted. If the machine is one which can be prevented from booting from the A drive, it is possible to erase the CMOS contents by removing its battery.

The virus can be removed from the Master Boot Sector on hard disks by copying the original contents which were stored by the virus (sector 17, cylinder 0, head 0) back to the boot sector (sector 1, cylinder 0, head 0) using a disk editor such as The Norton Utilities. Alternatively, the Master Boot Sector can be rewritten by using the FDISK /MBR command or by performing a low-level format. Be warned that because the virus corrupts the partition data stored within the Master Boot Sector, using the FDISK /MBR command will not recover the data stored on the drive; it will simply overwrite the virus code.

EXEBug.A

Aliases:: None known.
Type:: Resident semi multi-partite.
Infection:: Master boot sector and EXE files.
Recognition:: System Hard drive not accessible after clean boot. Windows 3.1 32-bit disk driver will not load. Location 28h in Master Boot Sector is 7Ch.
Hex Pattern:: B0FF E621 BA80 00B9 0100 B811 039C 9A?? ???? ??FE C680 E607
Intercepts:: Interrupt 13h for stealth (boot sector only) and infection.
Trigger:: Creates Trojanised EXE files when writing to certain areas of a disk. The programs destroy disks.
Removal:: See text.

Virus Bulletin: EXEBug / webmaster@virusbtn.com