Parent class: VirWare
Viruses and worms are malicious programs that self-replicate on computers or via computer networks without the user being aware; each subsequent copy of such malicious programs is also able to self-replicate. Malicious programs which spread via networks or infect remote machines when commanded to do so by the “owner” (e.g. Backdoors) or programs that create multiple copies that are unable to self-replicate are not part of the Viruses and Worms subclass. The main characteristic used to determine whether or not a program is classified as a separate behaviour within the Viruses and Worms subclass is how the program propagates (i.e. how the malicious program spreads copies of itself via local or network resources.) Most known worms are spread as files sent as email attachments, via a link to a web or FTP resource, via a link sent in an ICQ or IRC message, via P2P file sharing networks etc. Some worms spread as network packets; these directly penetrate the computer memory, and the worm code is then activated. Worms use the following techniques to penetrate remote computers and launch copies of themselves: social engineering (for example, an email message suggesting the user opens an attached file), exploiting network configuration errors (such as copying to a fully accessible disk), and exploiting loopholes in operating system and application security. Viruses can be divided in accordance with the method used to infect a computer:- file viruses
- boot sector viruses
- macro viruses
- script viruses
Class: Virus
Viruses replicate on the resources of the local machine. Unlike worms, viruses do not use network services to propagate or penetrate other computers. A copy of a virus will reach remote computers only if the infected object is, for some reason unrelated to the virus function, activated on another computer. For example: when infecting accessible disks, a virus penetrates a file located on a network resource a virus copies itself to a removable storage device or infects a file on a removable device a user sends an email with an infected attachment.Read more
Platform: Win9x
No platform descriptionDescription
Technical Details
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 two minutes.
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 directory.
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:support@vba.minsk.by
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.
Virus Hookers
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 accessed.
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.
Infecting Files
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 executable dropper.
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 exit instructions.
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.
Infecting Archives
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.
Infected Help
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 executed.
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.
Win95.SK.8699
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.
Read more
Find out the statistics of the vulnerabilities spreading in your region on statistics.securelist.com