Protected Mode Supervisor?

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).

Installation

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.

Keyboard Handler

Debug Exceptions Handler 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.

File Infection

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.

Exit from the V-mode of DOS-machine

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.

Payload

Search for the Virus in Memory 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:

     .8086

     MOV AX,0BABAH            ;simulate that the virus is checking its
     INT 21H                  ;presence in the memory
     CMP AX,0FA00H            ;did the resident copy respond?
     JNE ExitCheckMemory
     .386P
     MOV EAX,DR7              ;read register DR7
     AND EAX,20AH
     CMP EAX,20AH             ;are 2 breakpoints defined?
     JNE ExitCheckMemory
     MOV EAX,DR1              ;read linear address of breakpoint 1
     CMP EAX,0FE05BH          ;is it set at 0FE00:005BH in BIOS?
     JNE ExitCheckMemory
     .8086
     MOV AH,9
     MOV DX,OFFSET VirusIsFound
     INT 21H                  ;alert about the possible presence of
     CLI                      ;virus in the memory
     JMP $+0                  ;"hang up" system
ExitCheckMemory:
     INT 20H                  ;terminate operation
     

Test

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.

Conclusion