AntiEXE.A -- Missing the Target?

On my return from the rigours of the VB conference in Jersey, I was confronted with three diskettes infected with a multitude of boot sector viruses -- these included Quox, NYB, and NewZealand.I. There was one other virus, which at first appeared to be several: AntiEXE.A, Newbug, D3, CMOS4... any other suggestions for aliases?

Problems are compounded when a virus has so many different names: would anti-virus vendors and researchers please agree on a standard naming convention? It is undoubtedly difficult when a virus appears in many places more or less at once, but such variations serve only to add to confusion in the 'real world'! For now, however, here is the story of one of those diskettes, a virus I call AntiEXE.A.

This boot sector virus has basic stealth capabilities, and infects the Master Boot Sector (MBS) of hard drives. It has been reported in the wild in the UK and in the People's Republic of China. Easy to find and remove, this creature has one interesting feature, which is that the payload specifically targets EXE files meeting certain criteria. The really interesting part is that I do not know which EXE files these are -- but more of that later. For now, let us dissect this little beast and see how it ticks.

Action on Booting

The BIOS loads the infected boot sector into memory at 0000:7C00h. The virus examines the interrupt vector table and modifies the Int D3h vector, a handler which is normally unused (apart from by the ROM BASIC interpreter), to point to the original Int 13h diskette Device Service Routine (DSR).

It then builds a stack for its own use, and in time-honoured tradition, subtracts 1 Kilobyte from the amount of memory which will become available to DOS after booting. It installs a replacement Int 13h DSR to do its work, copies itself to the area of memory which will be hidden from DOS, and continues execution from this hidden memory. As an aside, it is interesting to speculate why Stoned, the first virus to infect the MBS, subtracted 2 Kilobytes from memory in a similar fashion. It does not need this amount of memory -- perhaps it was just an attempt to arouse less suspicion by using round numbers.

Once the virus has become resident, the original boot sector is read into memory at 0000:7C00h. On a hard drive, this will have been stored at Track 0, Sector 13, Head 0. If booting from a hard drive which is already infected, control passes to the original boot sector, and the boot process continues as usual. Otherwise, the virus reads the MBS from the hard drive to a buffer in hidden memory and checks for the presence of its code. If infection has already taken place, control is passed to the original floppy boot sector, and the machine appears to boot as normal.

As stated, the virus will copy the Master Boot Sector of an uninfected hard disk, and replace it with its own code, copying the partition table data from the original MBS. Control will then pass to the original floppy boot sector, with the outcome that booting from an infected disk or diskette takes a moment longer. However, users are unlikely to notice any extra time spent during the boot process - the success of the Form virus proves this is the case!

Action when Resident

The virus intercepts the Int 13h diskette Device Service Routine. Strangely, the first action of the new DSR is to check for function code F9h, which, if present, it ignores. This may represent an attempt by the virus to avoid detection by, or to subvert, an anti-virus program. If so, either that anti-virus program or the theory being employed by the virus is flawed.

The virus will normally have the first hook into Int 13h, unless something very strange is going on. If a program added a subsequent hook into Int 13h without using interrupt tunnelling, which can be used to insert a handler into an interrupt handler chain, the program's Int 13h would usually be called first -- although this is not always the case. If the call is not for function 2 (Read Disk Sectors), the virus takes no further action. All other function codes result in a call to the original Int 13h routine, which is pointed to by the previously set up Int D3h vector.

On every read, there is a 3 in 256 chance that the payload will be activated: this is based on the current state of the least significant word of the BIOS RAM data area maintained by the system timer at 0000:046Ch. All reads to Track 0, Sector 1, Head 0 call an infection routine which is designed to stealth the original read.

When active, AntiEXE infects diskettes in both the A: and B: drives. The virus performs a series of calculations based on the diskette's Bios Parameter Block, stored in the boot sector, to determine where on this diskette to store the original boot sector. The virus neglects to check whether the area is being used, so loss and corruption of data may result.

The BIOS Parameter Block from the target diskette is copied to the viral image and the infection process is completed by writing the virus to the boot sector of the diskette. The next time someone boots from that diskette, the virus will have a chance to spread.

The DSR also checks to see whether the sector being read contains the virus code. If so, the original boot sector is returned instead, successfully spoofing several types of anti-virus or disk-editing software -- but the stealthing will not prevent a write to the infected area.

Checking for this virus, and removing it, is therefore best done from a clean boot environment, although this is not strictly necessary. Most anti-virus software vendors should be able to envisage several techniques to do this. I do not advocate this without absolutely precise identification; I have had too many days spoilt by people saying, 'But I disinfected it...'. In my view, the only safe way is for restoration to take place in a known clean environment, from known clean backups or system disks. I do feel disinfectors have a place, however -- they help protect against that human tendency to lose source code and master disks. Just check, and check again if you use one.

The Payload

As stated above, the payload is executed 3 in 256 times on any normal read issued via Int 13h. The beginning of every sector read in the call is examined to see whether it contains an EXE header for a file 200,768 bytes long with 3895 relocation items. If so, the image of the EXE file header read is corrupted, meaning that attempts to load the EXE file will fail, and attempts to copy that file will result in corruption.

To try to determine which EXE file was being targeted by this virus, I adopted the 'brute force and ignorance' approach, searching a large body of executable files for matching headers. It failed. If anybody with a large collection of EXE files would like to search them for this file header, I would be pleased to supply a program to do this - it would be nice to know what the author had in mind.

It has been suggested that the target of this virus is a Russian anti-virus program; however, I have not been able to confirm that. If so, the curious way the virus handles function call F9h to Int 13h would be explained. Additionally, if this proves to be true, then AntiEXE.A has spread around the world in an indiscriminate fashion, in search of its target, and will presumably continue to do so.

Detection and Removal

The virus makes itself noticeable through the one-kilobyte memory loss which occurs during booting, in addition to the fact that it intercepts Int 13H, reflecting it to Int D3H.

Removal should follow a cold boot from a known clean system diskette. Although the SYS command will remove the virus from floppies, the original boot sector will remain on the diskette; therefore, the better option would be to reformat it.

Conclusion

AntiEXE.A is a fairly run-of-the-mill boot sector virus which is spreading in the wild. It is not quite as badly written as some, but is nevertheless easily detected and removed. There is absolutely no excuse for any anti-virus software not to be able to detect it.

The only slightly worrying thing about this virus is that it would be a trivial exercise to modify it to damage commonly found executables. Doubtless researchers merely need to sit back and wait for this new development to happen. AntiWindows, anybody?

AntiEXE.A

Aliases:

D3, Newbug, CMOS4.

Type:

Memory-resident boot sector virus with stealth capabilities.

Infection:

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

Self-recognition in Memory:

None.

Self-recognition on Disk:

Checks for the hex pattern E901h 144Dh at offset 00h of boot sector.

Hex Pattern:

33FF 8EDF C416 4C00 8916 4C03
8C06 4E03 FA8E D7BE 007C 8BE6

Intercepts:

Int 13h. All Read calls (function 2) have a 3 in 256 chance of triggering the payload. All read calls to Track 0, Sector 1, Head 0 are redirected to the infection routine, causing diskettes in drive A or drive B to become infected.

Trigger:

Corrupts image of certain EXE files when read.

Removal:

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

Virus Bulletin: AntiEXE.A / webmaster@virusbtn.com

© 1998 Virus Bulletin Ltd.