This is a parasitic Windows virus. It spreads under Windows95/98, installs
its copy into Windows memory, hooks file access functions and infects PE
(Windows Portable Executable) files. The virus also affects Windows help
files (.HLP) – it modifies them so that when they are activated, the virus
code is dropped on disk and executed. The virus also adds its droppers to
four types of archives: RAR, ZIP, ARJ and HA. The virus droppers in HLP
files and archives have DOS COM file format and are executed in DOS box,
but they are able to install virus code into Windows memory as well as
infected Windows executables (see below).
The virus code is encrypted with polymorphic routines in both DOS droppers
and Windows PE files. In case of Windows files the virus also uses “Entry
Point Obscuring” technology: the virus code does not get control immediately when an infected file is executed. The JMP_Virus
instruction in most of cases is places somewhere in infected file body, not
in file header and not at file startup address, and is executed only when
corresponding program’s branch takes control.
The virus is “slow infector”: before infecting it checks many conditions
and as a result affects very few files on the computer – only just about
ten EXE files in standard Windows95/98 installation. The same for HLP files
and archives – very few of them may be infected. The virus also delays its
infection routine for one minute before first infection, and infects HLP
files and archives only in case there was no access to these files during
The virus is very dangerous. When disk files are accessed, it checks their
names and in case of several anti-virus program (ADINF, AVPI, AVP, VBA,
DRWEB) the virus deletes all files in all directories on all disks from C:
till Z: that the virus is able to delete, and then halts the system by the
Fatal_Error_Handler VMM call.
There is one more victim file that is deleted by virus each time it
installs itself into the system. It is COMMAND.PIF file in the Windows
The virus has bugs which are lethal under some Windows95/98 configurations
– on infecting the virus causes “blue screen” with standard “General
protection fault” message.
While installing into the system the virus depending on its random counter
(in one case from 48) displays the message:
1997 VBA Ltd. E-mail:email@example.com
Installing Memory Resident
The virus “resident” copy does work on VxD (Ring0 – Windows kernel) level.
DOS programs and Windows applications cannot access this area by standard
methods, so the virus uses several tricks to install its code to there.
When DOS dropper is executed, the virus checks is Windows installed and
returns to DOS, if it is not. Otherwise the virus by using DMPI calls gets
access to Local Description Tables (processor’s protect mode memory
allocation tables), patches them and switches its DOS 16-bit code to
protect mode 32-bit. The virus code then works as a part of Windows kernel
and can access all necessary Windows functions.
When infected PE file is run, the virus also patches system memory
allocation tables and switches its code from application level (Ring3) to
kernel level (Ring0). The virus then passes control to the same
installation routine as infected DOS droppers do.
The installation routine, when takes control, allocates a block of system
memory, copies the virus to there, hooks Windows functions and releases
control. The original virus copy then either returns to DOS (in case of DOS
dropper), or restores host PE file data and code and returns.
The virus hooks three Windows functions. The first one is callback
procedure for I/O port trapping. The virus hooks port 534Bh and uses it in
its “Are you here?” calls. Reading from this port under infected system
conditions returns 21h (“!” character) in the AL register. Both DOS and
Windows virus installation routines try it before installing memory
resident. The number of this port was used to name the virus – 534Bh is
“SK” in ASCII.
The second hook is “standard” for resident Windows infectors – it is File
System API hook. It intercepts file opening, renaming and file attribute
get/set functions. On these calls the virus runs its infection routines.
The third hook intercepts the “Install FileSystemApiHook” function itself
(the one that is used to install previous hook). This call is used by virus
to hide its hooker: when a new hook is installed, Windows calls this
function. At this moment the virus intercepts that, removes its own IFS API
hook, installs new one (that is requested), and then re-installs its virus’
hook. As a result the virus hooker is always on the top in the list of
hooks, and it is the first one to receive control when disk files are
There is another trick in virus IFS API hooker: to access file system
drivers (the destination of FileSystem calls) the virus uses address of
“native” system handler. The virus gets this address from purely documented
field in the caller’s stack, and by using this address performs direct
calls to necessary file functions.
When the IFS API hooker gets control and the infection routine is activated
for the first time, it infects the Windows shell application (usually –
EXPLORER.EXE). To locate it the virus opens the SYSTEM.INI file in the
Windows directory, scans it for the “shell=” instruction and infects it.
This file is always run, so the virus cannot modify it. To fix this problem
the virus uses “upgrading” trick. The virus copies this file with another
name (adds one to the last letter in file name: EXPLORER.EXE ->
EXPLORER.EXF, for instance), infects new file and forces Windows to
“upgrade” original file with infected one. To do that the virus uses
standard way: it creates the WININIT.INI file in the Windows directory and
write necessary “Rename” instructions to there.
If Windows shell is already infected, the virus infects the file that is
accessed. First of all it checks file name extension. In case of .EXE, .SCR
and .DLL files the virus jumps to PE file infecting routine; in case of
.HLP file the virus patches it with its dropping code; in case of .RAR,
.ZIP, .ARJ and .HA archives the virus inserts into their contents its own
Infecting Windows PE
While infecting PE files the virus encrypts and writes its code to the
Relocation (Fixup) section and as a result overwrites these data. Because
of way Windows uses to load applications to the memory, in most of cases it
does not pay any attention for relocations – all applications are loaded to
the same addresses, and no relocations are used. In few cases when an
application is loaded by another host application to host’s memory, Windows
loader processes relocation table and makes necessary changes in
application’s code. To fix this the virus modifies PE header fields: clears
Relocation flags in Characteristic field (that means then that there is no
relocations in file) and sets to zero address of Relocation section. As a
result affected application just cannot be loaded at another address (to
address space of another application), but work perfectly as stand-alone ones.
The virus then makes necessary changes in Relocation section header: sets
its characteristics as Readable and Initialized, depending on its random
counter (in 1 case from 8) changes section name to random one, encrypts its
body and writes to there. The virus also checks the Relocation section size
– is it big enough for virus code, and infects files only in case the virus
code fills in the section body. As a result the virus does not increase PE
files size while infecting them.
To get control when infected programs run, the virus does not modify Entry
address in PE header. It uses another more complex way – it patches
randomly selected code in victim program body and writes JMP_Virus routine
to there. As a result the virus code is not executed immediately when
infected program is activated. It is executed only in case patched branch
gets control. In some cases, when this branch is executed very seldom (if
it is error handling routine, for instance) the virus may “sleep” in
program for long time and then jumps out in some extra situation.
To locate position in program to patch, the virus reads blocks of victim
file and scans it for C/Pascal subroutines. These routines have standard
headers and footers, and virus just needs to find them and to see that
there is enough space for its JMP_Virus code between subroutine entry and
The JMP_Virus routine that passes control from patches subroutine to the
main virus code is not just a single JMP instruction. It is more
sophisticated: it is polymorphic loop that decrypts main virus code before
passing control to it – it has up to 168 bytes of code.
Summary, the infected programs run looks like follows: Windows loads and
executes the program, and its routines start to do some work. The virus
“sleeps” at the moment because patched subroutine have been not executed
yet. When this code gets control, the virus JMP_Virus routine is activated.
It decrypts the main virus code (that is placed in the Relocation section)
and jumps to decrypted code. The virus installation routine gets control,
copies virus to the Windows memory, installs virus hooks, restores patched
host’s subroutine and returns control to it.
It is necessary to note that in some cases (when Windows shell is being
infected, or no C/Pascal routine found) the virus writes its JMP_Virus
patch directly to program’s Entry address. In this case the virus code gets
control immediately when infected file is run.
The virus affects four types of archives: RAR, ZIP, ARJ and HA. While
infecting them the virus parses archives internal formats, adds DOS dropper
to the end of archive as a last item, and carefully modifies archive
structure, including CRC fields. The only archives are infected: that have
not less than ten files and have at least one COM or EXE file. The virus
addition to archives is a DOS COM file that has random generated name and
COM or EXE extension.
In case of RAR archives the virus has one more branch comparing with other
archive infecting routines. This branch looks for “stored” files in the RAR
archives, and if a file has specific date and time stamp, the virus reads
end executed stored data. This trick allows virus to run other programs
without any user’s action – it can be used to “upgrade” the virus, to run a
spy or any other kind of programs. This virus feature looks like a
“backdoor” that can be used by virus author to get control on other PCs.
The possibility to infect Windows help files is based on the fact that
these files have their own script sub-programs (macros). These scripts are
automatically executed when WinHelp activates help files, and script
language is powerful enough to access disk files, create and execute them.
The virus uses this feature to infect Windows help files. It writes its DOS
dropper to the end of HLP file as an “overlay” (the HLP file header has
“file length” field in its header, and virus dropper is out of this data),
modifies HLP internal structure and adds its own script to there. This
script has ten instruction that are written to the [CONFIG] section
(“|SYSTEM” in terms of HLP internals) which is automatically processed when
infected help file is activated. These ten virus instructions extract and
execute a small (about 380 bytes) virus loader. The virus script creates
this loader as a DOS file (with random name) on the C: drive, write a code
to there and executes it – and the virus loader takes control.
The virus loader’s code in HLP script is converted to ASCII 7bit form –
each byte is converted to two alphabetical letters. When this code takes
control, it converts itself back to binary code, then gets name of host HLP
file (which the virus scripts passes as an argument), reads HLP file
header, gets offset of virus “overlay” code, reads it, overwrites its own
COM file and re-executes it. The virus DOS dropper gets control, and virus
installs itself into the memory, e.t.c.
There is one exception in this routine that causes problems. The virus
loader’s code is converted to ASCII 7bit, but the loop that restores this
code has opcodes that are out of 80h limit. When these strings are saved
from Windows HLP file to DOS file, Windows processes them as text strings
and converts high-ASCII characters according to installed codepage.
Needless to say, that under different codepages the result of convertation
is different. The only codepage brings correct code – this is Russian
codepage (that does mean that virus author had Russian language support
installed on its computer). If no Russian support is installed in the
system, the virus loader code is corrupted, it cannot work and halts when
In addition it is necessary to note that while dropping its COM file the
virus script checks the presence of NT specific file C:\NTLDR and returns
if this file is found.
This is improved virus version. It is very closed to original one, but uses
more methods in its encryption and more strong polymorhpic engine. It also
uses a trick to disable anti-virus monitors: it locates the GK95.VXD
anti-virus component (AVP and F-SECURE) loaded into the Windows memory and
disables them by a patch. The HLP files infection routine is fixed in this
virus version – it does work with any codepage, not under Russian one only.