AntiCMOS -- Brain Damage

The research community has been aware of the existence of AntiCMOS as a 'laboratory specimen' for some time: it is now, however, in the wild, having recently arrived in the UK from Italy. As a result of safe practice, it was detected before it infected anything, and then drawn to my attention.

Plus ca Change...

AntiCMOS is an exceptionally primitive boot sector virus, and infects both hard and floppy disks. Unusually for this type of virus, the original boot sector of infected diskettes is not stored anywhere, though a substantial amount of virus code appears dedicated to finding a place for it.

Overall impressions are that this is an extremely poor attempt at virus-writing. The author appears to have given up halfway through - hardly surprising, as he seems incapable of producing simple code. Diskettes infected by the virus will no longer be bootable, although they are still able to infect a hard drive.

The virus has virtually no error checking, makes no attempt to check if a disk is already infected, is obvious in operation, and is easy to detect and remove. However, it does replicate, it is in the wild and it has a particularly annoying payload.

On Booting

The virus creates a stack for its own use and stores the Int 13h disk handler interrupt vector in the viral image in memory. Two Kbytes at the top of available low memory are reserved by the virus so that its code will not be overwritten: the resultant memory loss is easily detectable. The virus then copies itself into this protected area of memory, and relocates to continue execution from there. Next, the disk controller is reset, and the virus examines a data area within itself to determine if the machine was booted from the floppy or the hard drive.

If the machine was booted from the hard drive, the virus will find the current active partition and copy its boot sector into memory. The data area in memory which determines the boot drive type is set to the value for a floppy drive, and a replacement Int 13h handler is installed. Control is then passed to the boot sector for the current active partition, and booting continues normally.

If the machine was booted from an infected floppy, the virus attempts to infect the Master Boot Sector (MBS) of the first hard drive. A single subroutine is used to infect both floppy and hard drives.

After infecting the hard drive, the virus begins a series of calculations based on the number of entries in the root directory, the number of sectors in the File Allocation Table and the number of sectors per track. This is presumably intended to identify the location of the original boot sector, had it been stored. At several points during this process, the virus can cause the system to hang.

A replacement Int 13h handler is then installed, and the virus passes control to the memory location into which a boot sector is loaded: this area still contains the virus code. Thus, the system will hang when booting from a floppy, even if this has been avoided so far.

Infection Routine

The infection process is identical for both floppy and hard drives. The contents of Track 0, Sector 1, Head 0 (the boot sector of a floppy, or MBS of a hard disk) are read into a buffer. The virus then overwrites the initial jump instruction in this buffer with its own value and copies the remaining virus code into the buffer. However, it does not overwrite the boot sector data or the partition table in this buffer (if present). Next, it writes its code to Track 0, Sector 1, Head 0 of the floppy or hard drive, but makes no attempt to retain the original boot sector of a floppy disk.

The replacement Int 13h disk handler represents more bungled coding. It checks to see if the requested access is to the hard or floppy drive: if the former, no further action is taken. If for a floppy, the handler attempts to determine if it is a read or write request. Regardless of the type of request made, the virus then takes the high nibble of the least significant timer count maintained by the BIOS, and subtracts the value of the byte at offset three of the MBS (remember -- this virus will only be active after booting from the hard drive). If the result is less than two, the trigger routine is called (see below).

Thus, triggering cannot be predicted, although it occurred with monotonous regularity during my experimentation. If the result is two or more, the diskette is infected. No check is made to see if the disk is already infected, no attempt is made to hide the operation by avoiding infection if the drive is already running, and no error checks are made. One side effect is a painful slowdown when accessing floppy disks.

Trigger Effects

The payload effectively destroys the data stored in the CMOS memory, which typically holds information on system configuration (including base and extended memory size), the type of disks installed, the primary display and the maths coprocessor.

Thus, when the PC next starts, it will go straight to BASIC in ROM BIOS (for genuine IBM-PCs with ROM BASIC): in essence, it will forget that it has a hard drive. The payload is annoying and highly visible; it does not physically destroy data, but may cause people to think their data has been lost.

If the infected machine is an IBM-PC with microchannel architecture, recovery is easily done by booting from a reference diskette for that machine, and using the automatic configuration feature. For other machines, the documentation supplied with the machine should be consulted. Of course, this is often easier said than done.

Removal

The virus does not store the original boot sector, making removal from the hard drives of machines formatted pre-DOS 3.31 problematic. For machines formatted with DOS 3.31 or later, boot from a write-protected system floppy and use the FDISK /MBR command to restore the original MBS. For pre-DOS 3.31 machines, copy the MBS with an appropriate utility, then boot from a DOS 3.31 or later disk and attempt FDISK /MBR: not a guaranteed fix, but if it does not work, there is still the backed-up MBS.

Copying a clean MBS table from an identically-configured PC, and using a disk editor to replace the partition boot table correctly, is another option. Removal from a floppy entails simply using the SYS command under clean conditions.

In Conclusion

I had to check and recheck my work very carefully during this disassembly, as I found it difficult to believe that even a 'tyro' virus writer could produce something quite so poor. It is almost easier to believe that it was produced by ten thousand monkeys playing with a keyboard. It is disturbing to think that this virus has 'escaped' into the wild -- it is so obvious, and so easily detectable, that anyone with an ounce of sense and/or an average scanner could find it. AntiCMOS is almost more of a Trojan than a viable virus, although it can (just) replicate. Seek and destroy.

AntiCMOS

Aliases:

None known.

Type:

Memory-resident boot sector virus.

Infection:

Master Boot Sector of hard drive, boot sector of floppy disk.

Self-recognition in Memory:

None.

Hex Pattern:

8826 0300 3D02 0073 03E8 CC00
E8E8 0058 1F2E FF2E 0700 33C0

Intercepts:

Int 13h for infection.

Trigger:

Overwrites CMOS RAM data area.

Removal:

Under clean system conditions, use the FDISK /MBR command. For further details, see text.

Virus Bulletin: AntiCMOS / webmaster@virusbtn.com

© 1998 Virus Bulletin Ltd.