Hare Krsna: ISKCON too far!

Ian Whalley

At the end of May, I received a virus sample. In itself, this is not unusual; however, it was not detected by any anti-virus product which the (very computer-savvy) user had, or could obtain. The sample was unpacked, and analysis started.

A swift look at the code revealed that the file was definitely unusual, and very probably infected. Disassembly was complicated by the virus' anti-debugging and -emulation techniques. Once these had been dealt with, the virus was taken apart without too much effort.

Overview

Hare is a multi-partite virus (Master Boot Sector of hard drives, floppy boot sector, COM and EXE files). It is a slow polymorphic (see below for a detailed description), and contains anti-debugging routines. It is encrypted in both files and boot sectors (viruses which encrypt themselves in the boot sector are becoming increasingly common).

The code of this sample, at 7610 bytes, is by no means the longest seen, but certainly makes it the largest non-Windows virus in the wild at the moment. This alone provided warning of the effort that would be involved in disassembly.

Functionality

Hare's code is, to say the least, tangled and complex. It uses many interesting techniques, including one which, in my opinion, is extremely dangerous, and could be used in the future by other viruses to greater effect. More of this later.

When the virus receives control from an infected program, it decrypts itself in memory (this involves executing three separate decryptors). Whilst doing this, it issues an Int 21h, AX=FE23h: if AX=000Dh is returned, this part of the virus is present in memory, and installation aborts.

If the virus handler is not present, Hare completes decryption, and installs itself at the end of the MCB chain (using the standard technique of walking the list looking for the Z block). It then passes control to the new resident copy.

Next, the resident component determines whether Windows is running, using Int 2Fh, AX=160Ah (Identify Windows Version and Type). If enhanced-mode Windows is present (including Windows 95), it notes the fact for future reference.

The virus then checks a sector on the track one beyond the end of the hard disk. This track is sometimes called the Landing Zone, Engineering Cylinder or Test Cylinder, although these terms are somewhat old-fashioned. If this starts with the identifier CCDDh, it is left alone; otherwise, the virus attempts to write a single sector of random data. The routine is flawed, however, and instead of filling a 512-byte buffer in memory with random bytes, it repeatedly places random data into the first word, which is then overwritten with the CCDDh marker anyway!

The data is used by the polymorphic encryption routines to create the header for new instances of the virus; consequently, replicants of Hare created on one PC will have very similar encryption loops. Because of the bug, the effect is not quite what the virus author had intended, but the polymorphic loops will still vary.

This polymorphic technique can foil anti-virus researchers: detectors and removers they create from one infected PC are likely to be incomplete. When an infected program or disk is taken to a clean PC, the random data which Hare writes to the sector will be different, and that PC will create samples of the virus which will look different from those samples which were seen before.

The routine that writes the random data is flawed - when setting the sector number to one (to write to the first sector on the extra track), the virus trashes the top two bits of the track number (which is stored at the top of CL to allow 10-bit track values).

If the disk in question has more than 256 tracks (very likely these days), the sector of random data will be placed somewhere in the middle of the disk, possibly over user data.

Hare then tests to see if its boot sector component is already resident, by issuing Int 13h, AX=5445h. If AX=4554h is returned, it assumes that it is. If it is not resident, it checks the MBR to see if it is already infected, and infects it if not.

MBR Infection

Whilst infecting the MBR, Hare introduces several interesting techniques. It attempts to use port-level access to the hard drive (to avoid BIOS-level boot sector protection).

If it cannot access the hardware directly, it traces Int 13h. It hooks Int 16h (Keyboard) before writing to the disk using Int 13h - it looks as if it is attempting to replace replies to BIOS questions (such as 'A program is about to write to the MBR. Do you wish this write to proceed?') with ones which allow the write to occur. It has not been possible, however, to verify this.

Hare does not leave the Partition Table intact in the infected MBR, so attempts to remove the virus with 'FDISK /MBR' will render the disk unbootable. Later, it must perform complex gyrations (see 'Loading from an Infected Boot Sector') to account for this.

It is worth noting that Hare correctly uses the Windows 95 call Int 21h, AX=3513h, CX=084Bh to lock the disk before attempting direct writes. If this is not carried out, Windows 95 will reject the write. The volume does not appear to be unlocked, but in normal use this should cause no ill effects.

Hare now directly modifies the IVT to revector Int 21h to its own handler - this will enable infection and stealth, of which more later. Next, it checks to see if Windows 95 is currently running (Int 2Fh, AX=160Ah; returns BH=04h if Windows 95 is active): if so, it installs its Int 13h hook. Interestingly, it only does this in the presence of Windows 95. After performing the actions described under 'Deletion of system file', it returns control to the host program, which is allowed to execute normally.

Deletion of System File

Next comes Hare's most interesting feature. It searches the MS-DOS environment data area for an environment variable starting 'WI', which will match either WINDOWS or WINBOOTDIR: these point to the main Windows directory on Windows 95 systems. When this is located, Hare takes the value, appends to it the string '\SYSTEM\IOSUBSYS\HDFLOP.PDR' (thus obtaining a complete path to the file HDFLOP.PDR), and calls the original Int 21h handler to delete it (Int 21h, AH=41h).

Why does it do this? Documentation on the area is limited, but the file HDFLOP.PDR contains the Windows 95 port-level driver for floppy disk drives. Readers familiar with previous discussions on the impact of viruses on Windows 95 will be aware that this OS does not normally propagate boot sector infections: it uses direct access to floppy disks, so Int 13h hooks installed by a virus to monitor and infect floppy disks are never called.

Unfortunately, to be able to do port-level access in this way, Windows 95 requires the file HDFLOP.PDR. If this is not present, the system uses old-style Int 13h access to floppy disks. This is a problem, as now any Int 13h handlers will be triggered, and infection can take place as before.

Worse, Windows 95 does not warn the user of this scenario: browsing through the contents of the System applet in Control Panel does reveal that the system is not running at peak performance, but normal users do not look here every day.

Thus, after the next reboot, Hare will be able to infect the boot sectors of floppy disks. Better yet, if the virus is removed, this driver file is still missing, and any subsequent boot virus infection will be able to infect floppy disks in the same way.

In Memory: Int 21h

The Int 21h handler intercepts the functions FE23h (Are You There?), 36h (Get Disk Free Space), 4Ch (Exit), 31h (TSR), 00h (Terminate), 4B00h (Load and Exec), 11h/12h (Find First/Next by FCB), 4Eh/4Fh (Find First/Next by Name), 3Dh (Open Existing File) and 3Eh (Close File).

The Get Disk Free Space handler is rather peculiar - when this function is called, the virus checks the address of the calling process's PSP. If it is different from that of the last process which called this function, it performs a genuine Get Disk Free Space call via the original Int 21h handler, saves the number of free clusters, and returns the values unchanged. If it is the same, it still performs the genuine call, but replaces the value for the number of free clusters with the saved one, and returns to the caller.

The reasons for this are not obvious - a couple of possible explanations for this have been suggested. Firstly, one particular anti-virus product, InVircible, periodically calls Int 21h, AH=36h to see if the amount of free disk space is dropping. If it detects a drop, it warns that a fast-infecting virus may be in memory. Hare's technique of returning the same value every time the process asks will foil this.

The second possible explanation is that Hare is again attempting to fool anti-virus researchers. An oft-used technique for replicating viruses is to place the virus in memory, do a DIR to note the lengths of the goat files and amount of free disk space, run the goat files, and then do another DIR.

Even if the virus has file length stealth, the change in the amount of free disk space will reveal if the virus has infected anything. Hare will not show any change, however, as each DIR command will return the same value for the free space (each call is issued by COMMAND.COM).

Exit, TSR, and Terminate calls are dealt with in the same way: the name of the currently executing program is extracted from the PSP, and that file is opened, infected, and closed.

On Load and Execute, the virus uses a much more complicated handler. After re-deleting the file HDFLOP.PDR, the virus hooks Ints 24h (Critical Error) and 1Bh (Control Break). It then gets, saves, and clears the file's attributes, before going on to examine the filename. It does not infect files whose names match the patterns TB*.*, F-*.*, IV*.*, CH*.*, or COMMAND*.*, nor those containing the letter V.

After infection, the file's time-stamp and attributes are reset (the virus modifies the time-stamp of infected files to set their seconds field to 34), and the handler is complete.

On all Find First/Next calls, the virus can do limited file length stealth - it examines the time-stamp of files encountered and subtracts 7680 bytes from the length of files tagged as infected. This results in infected files appearing to be larger than they were before, albeit not as much so as they actually are.

The Close Calls functions invoke a handler which will infect the file if it is deemed necessary - it first extracts the filename by manipulating the SFT (System File Table), performs the name checks described above, and then, where applicable, infects.

On Open Existing File requests, if Hare determines that the file is infected, it is disinfected (on disk) before the call is allowed to proceed. This will temporarily remove the virus from the file in question, which will be reinfected when the file is closed.

In Memory: Int 13h

The Int 13h handler performs stealthing of infected boot sectors, and also infects the boot sectors of floppy disks as they are used.

This latter is accomplished by first ensuring that the floppy in question is not already infected - the virus reads the boot sector (it retries three times; just what the manuals say should be done), and subtracts the word at offset 100h from that at offset 102h. If the result is CCFFh, the boot sector is deemed infected.

If the floppy is not already infected, Hare formats an extra track at the end of the floppy disk, encrypts the virus code, and writes the body to the extra track, and the loader code to the boot sector.

Loading from an Infected Boot Sector

When a computer is booted from an infected hard drive, the virus shuns the standard approach of immediately installing an Int 13h handler - this would make life much easier for it, as its own stealth features would allow DOS to see a valid partition table.

Instead, Hare copies the partition table back into the MBR whilst loading; thus, when the OS loader comes to look, the partition table is where it is supposed to be. It then knocks 9KB off base memory by the standard technique of modifying the word at 0000:0413h, intercepts Int 1Ch (System Timer Tick), and passes execution to the code of the original Master Boot Record.

Using a technique already seen in several other viruses, Hare monitors Int 1Ch to watch the operating system load. When it determines that it is safe to do so, it intercepts Ints 13h, 21h, and 28h (DOS Idle Interrupt). The first time the system issues an Int 28h (which will happen as soon as a program waits for input), Hare re-corrupts the partition table (which was fixed to allow the OS to load). It is now in a position to infect files and disks as they are accessed.

Trigger

On 22 August and 22 September, the virus' trigger routine is activated. First, it displays the message:

"HDEuthanasia" by Demon Emperor: Hare Krsna, hare, hare...

Next, it attempts to wipe all data from all hard drives on the system with garbage.

Conclusion

Despite the many new and interesting techniques displayed by Hare.7610, the virus has several bugs. It is generally unstable, and replications will sometimes not execute properly (this includes MBR infections), and will hang the machine. The destructive trigger also sometimes fails. The fact remains, however, that Hare is in the wild across the world, and appears to be spreading. So far, it has been found in the wild in Canada, Russia, the Netherlands, Switzerland, the UK, and the USA: it appears that such a wide distribution was achieved via the Internet.

[Note: Two variants of Hare.7610 have been discovered, Hare.7750 and Hare.7786. As well as bug fixes, they will occasionally (one in sixteen times the system is booted from an infected disk) change the random data sector. This means that the polymorphic algorithm will change periodically on any given computer. Hare.7750 was distributed via posts on the Usenet groups alt.cracks, alt.crackers, alt.sex, and alt.comp.shareware.]

Hare.7610

Aliases:: Krsna, HDEuthanasia.
Type:: Slow, polymorphic, multi-partite virus.
Self-recognition in Files:: Seconds field of time stamp set to 34.
Self-recognition in Boot Sectors:: Word at offset 102h in BS minus word at offset 100h equals CCFFh.
Self-recognition in Memory:: Int 13h, AX=5445h, expects return of AX=4554h. Int 21h, AX=FE23h, expects AX=000Dh on return.
Hex Pattern:: None possible.
Intercepts:: Int 13h, 16h, 1Bh, 1Ch, 21h, 24h, 28h.
Trigger:: On 22 August/September, prints message and attempts to trash disks.
Removal:: Identify and replace infected files. Format infected diskettes. Replace hard disk MBR with known clean copy (FDISK /MBR must not be used).

Virus Bulletin: Hare.7610 / webmaster@virusbtn.com