Igor Daniloff
Virus Bulletin
August 1998
Since their introductions, PCx have become increasingly complex through advances in both hardware and software. Computer viruses are also becoming more complex and intricate as their authors try to adapt them to changes in the computer environment.
Now there are viruses that infect PC boot sectors of disks, DOS, Windows, Windows'95, OS/2, and Linux program files, as well as documents created in Word and Excel. Virus authors have devised stealth tecniques to help avoid detection, and anti-debugging and anti-virus mechanismes to make initial detection, then analysis more difficult. They have incorporated polymorphism in boot sectors, files, and memory to make detection more laborious and time-consuming for anti-virus designers. Since the release of i386 processors, viruses have begun to use 32-bit instructions in their codes. Some polymorphic viruses employ 32-bit operands in their decryptors.
Unfortunately, viruses aim to survive and gain the upper hand under the existing conditions, using all conceivable software and hardware techniques. With the emergence of 286, and later 32-bit i386 processors, came protected (or virtual) operation mode. Thus far, virus authors have not successfully harnessed protected mode. Some have tried to master it, but their attempts have been unsuccessful because of changes with important operating system components.
In 1994, the boot virus PMBS was the first to tackle protected mode, but could not cope with other applications or drivers (EMM386, Windows, OS/2) also using that mode. In the same year, viruses Evolution.2761 and Evolution.2770 succeeded in tapping part of the power of the protected mode, but only when the processor was in the real mode. These viruses replaced the actual interrupt vector table with their own interrupt descriptor table (IDT), which they loaded with IDT register. How did the Evolution viruses could use this technique in everyday life? I doubt there is a PC user who runs i386-Pentium in real mode.
Although the i386 processor made its debut long ago, viruses have still failed to master its powerful protected mode. I believe that virus designers have cherished this hope for some time, and that one among them finally appears to have realized it.
PM.Wanderer, apparently written in Russia, is a file infector which uses a cruide form of protected mode. It is surprisingly stable, interacting more or less correctly with other programs that utilize this mode. The name is derived from the string 'WANDERER,(c)P.Demenuk'.
A resident polymorphic virus PM.Wanderer installs its resident part in the memory and toggles the processor to the protected mode, by utilizing the documented virtual control program interface (VCPI) of the extended memory supervisor (EMS, EMM386).
On starting an infected program, the virus polymorphic decryptor decodes the main virus body and passes control to it. The virus code determines a location in the upper addresses of DOS memory, writes itself to this memory, and hands over control to the copy higher in memory. Then it restores the code of the infected file in the program segment (for EXE files, it also configures the addresses of relocated elements) and begins to install resident component.
First, the virus checks whether there is an extended memory manager (EMS) in the system. It does this by retrieving the address of Int 67h (Extended Memory) though Int 21h function AX=3567h (Get Interrupt Vector), and checking whether the characters 'EM' exist in EMS header. Then the virus verifies whether its resident part is already installed by calling function AX=BABAh of Int 21h and locking for the answer AX=FA00h.
If there is no active EMM in the system, or the resident part of the virus is already installed (and in subsequent operation, if there is no VCPI or an error occurs installing the resident copy), the virus frees the memory reserved for installing the resident copy and passes control to the host program. This completes the life cycle of the virus in a system. However, if environmental conditions are favourable, the virus intercepts Int 01h and traces Int 21h looking, for the word 9090h (two NOPs) in the original Int 21h handler code of MS DOS version 5.00-7.00.
If this string is detected, the virus retrieves from a specific handler address the address of Int 21 handler kernel, which is usually located in the high memory area, and writes this address to its body. This address is subsequently used by the virus for calling the Int 21h handler kernel for infecting files.
Then the virus verifies the presence of VCPI and reserves the physical addresses of four memory pages. IT next retrieves the address of VCPI, page table, and the addresses of GDT (Global Descriptor Table. This consists of three elements: the first is the code segment descriptor, and the other two are used by the VCPI driver). The virus writes a reference to the pages allotted by the VCPI driver to the page table, and retrieves the physical address of the memory page of the segment in which the virus is currently located. It also gets GDT and IDT registers. Next, the virus creates three (code and data) descriptors and a descriptor for the task state segment (TSS) in GDT.
Finally, it prepares the values for the registers CR3, GDTR, IDTR, LDTR (Local Descriptor Table Register), TR (Task Register), and the address CS:EIP of the protected mode entry point. Using the VCPI tools, the virus toggles the processor to protected mode with the highest privilege level, known as the supervisor.
In the protected mode, the virus corrects IDT by creating two segment descriptors, then searches for the TSS descriptor. Next the virus defines two breakpoints: one at the first byte of the code of the current INT 21h handler (0000:0084h) and the other at the first byte of the code in BIOS at 0FE00:005Bh (linear address 0FE05Bh). The BIOS location usually holds the 'near jump to reboot'. The virus then corrects IDT to set debug exceptions at Int 01h and Int 09h. It also defines two handler descriptors: trap gate and interrupt gate.
After these preliminaries, the virus writes its code to the memory page and switches the processor back to the virtual mode in order to free the DOS memory in upper addresses and to return the control to the infected program. From this instant, the infected program begins its "normal" work, but Int 01h and Int 09h have been redefined by the virus as trap gate and interrupt gate in protected mode, respectively.
On receiving control, the virus-defined Int 09h handler verifies whether the two virus-defined breakpoints exist, and restores them if either has been zeroed. Using the register DR7, the virus checks whether the two breakpoints (0 and 1) are defined, without verifying their linear addresses. If either of the breakpoints is missing, the virus calls the procedure that instantly restores them to their initial status. The virus-defined Int 09h handler also keeps a close watch on the pressing of Ctrl-Alt-Del and `resets' all breakpoints when this key combination is used.
The virus-defined debug exceptions handler verifies whether either of the virus breakpoints has been reached by checking the command address. If control passed to this handler from the 'near jump to reboot' in BIOS, the virus resets all breakpoints just as the virus-defined keyboard handler does when the key combination Ctrl-Alt-Del is pressed.
If the exception was caused by the breakpoint of the original DOS Int 21h handler, the virus analyzes the AX register to determine the function of Int 21h, and behaves accordingly. Prior to analyzing this, the virus sets the resume flag (RF=1) in the stack's EFLAGS register that is intended to return control to the breakpoint. This flag is set should a debug exception take place while returning control to the breakpoint.
If Int 21h is called with AX=0BABAh, the virus the virus recognizes this as its 'Are you there?' call. If PM.Wanderer is installed it writes writes the value 0FACCh in the AX register and returns control to the original DOS Int 21h handler. On exiting from the DOS handler, the AL register is set to zero. The register value AX=0FA00h informs the non-resident virus that a copy is already active.
If Int 21h is called with either AX=4B00h (start program) or AH=3Dh and the lower 4 bits of AL set to zero (open file for reading), the virus decides to infect. The virus writes its code to 9000:0000h (linear address 90000h), prepares a stack, and toggles the processor to 8086 virtual mode with IRETD command at third and last privilege level.
In virtual mode, the virus code verifies the last two characters (OM or XE) of the filename extension, creates a polymorphic copy, and infects files longer than 4095 bytes. PM.Wanderer does not infect a files if seconds field of file's time-stamp is 34, assuming that the file is already infected, assuming the file is already infected, nor does the virus alter file attributes. Therefore read only files are not infected. Further, the virus does not infect a particular program with seven-character filename. I could not find the name of this file: the virus defines it implicitly by computing the CRC of itss name.
The virus does not take over Int 24h (Critical Error Handler), so when critical errors (for example, writing to write-protected disks) occur during infection, the standard DOS query - Retry, Ignore, Fail, Abort? - is displayed. The virus infects a file by calling the DOS Int 21h handler directly, using the address obtained from tracing Int 21h at installation. The virus code is prepended to the header of COM files and inserted into the middle of EXE files, immediately below the header. Prior to this, the relocations field in the header is zeroed by moving the original program code to the file end. The `real working code' of the virus is 3684 bytes long, but the size of infected files increases by more than 3940 bytes.
The virus uses a smart technique to exit the V-mode and to transfer control to the breakpoint of the DOS Int 21h handler that called the debug exceptions, so that DOS functions normally. Were the virus to infect a file while in P-mode, everything would be simple - it would be sufficient to execute the IRETD command. Since the virus has toggled to the V-mode with privilege level three, it is possible for the debug exceptions handler to switch back to P-mode. Therefore, the virus plays an elegant trick to surmount the situation.
If an error occurs during infection or while exiting from the virtual mode, the virus calls Int 21h with AX=4B00h. When Int 21h is called with AX=4B00h, control jumps to the first command of the DOS Int 21h handler. This command contains a virus-defined breakpoint. Control must now be transferred to the debug exceptions handler in P-mode. However, the V-mode monitor discovers the need to process the next debug exception. The point is that the virus debug exceptions handler has not returned the control to the breakpoint and is still busy processing the current debut exception. Therefore, the V-mode monitor terminates the Int 21h call, aborts processing the current debug exception, and returns control to the breakpoint with the values stored in the registers of the previous Int 21h call.
If the debug exceptions handler is passed AX=3506h (such a call for getting the INT 06 address usually exists in all programs compiled from high-level languages, such as C, Pascal), PM.Wanderer scans the linear address space 0-90000h looking for a string that obviously belongs to the Russian integrity checker ADinf. If this string is found, the virus modifies it in order to disable the alerts ADinf usually raises on detecting changes to files and disks.
It is clear from the above that conventional memory scanning methods are incapable of detecting the resident copy of the virus at level zero privilege in the protected mode. The resident copy can be detected only after toggling to the highest privilege level of protected mode with the help of GDT or IDT. However, this virus can be trapped by other conventional methods. Here, the linear addresses of the first two breakpoints (0 and 1) must be determined and compared with the values described above. The possible presence of PM.Wanderer in the memory can be decided from theese addresses. It is imperative that such operations be carried out only in a DOS session. In assembler language, this can be done as follows:
After infecting several thousand files, the virus behaves like a 'lodger' with all infected files remaining operative. A file becomes inoperative only if, after infection, its stack are located within the virus code. While infecting EXE files, PM.Wanderer does not modify the start SS:SP values in the EXE header. As already mentioned, the virus is capable of reproduction only if EMS (EMM386) is installed in the system. If EMM386 is installed with the /NOEMS option, when the virus toggles processor to protected mode, the system will reboot. The computer may also reboot if QEMM386 is installed.
The virus loses its reproduciability under Windows 3.1x and Windows 95. These operating systems cut off an already resident PM.Wanderer, because while loading they install their own handlers in IDT and zero all breakpoints. Prior to terminating a session and returning to DOS, Windows restores the previous status of the interrupt descriptor table. On pressing a key in DOS environment, the virus gets control, installs its own breakpoints, and continues its activities. Due to the absence of VCPI in a DOS session within Windows, the virus cannot return to the protected mode there. For the same reason, the virus is also inoperative under OS/2.
PM.Wanderer is the first virus to utilize i386 the protected mode and not conflict with the domimamt Microsoft operating systems, which also use that mode. It is possibly that future viruses may completely overwrite the supervisor with their own code supporting the DPMI, EMS/VCPI, XMS, and Int 15h extended memory interfaces. Who knows?
| Aliases | None known |
|---|---|
| Type | Memory resident in P-mode, polymorphic |
| Infection | COM and EXE files |
| Self-recognition in Memory | See description |
| Self-recognition in Files | Bit 1 and bit 4 in seconds field of file's time-stamp set |
| Hex Pattern in Files | The virus is polymorphic, and there is no useful hex pattern. |
| Hex Pattern in Memory | Virus works in P-mode, see description |
| Intercepts | In IDT: Int 09h for enabling breakpoints, Int 1 for infection |
| Payload | Patch the integrity checker ADinf in memory. |
| Removal | Under clean system conditions, identify and replace infected files |