Not yet analyzed.
Based on the settings of your F-Secure security product, it will either move the file to the quarantine where it cannot spread or cause harm, or remove it.
A False Positive is when a file is incorrectly detected as harmful, usually because its code or behavior resembles known harmful programs. A False Positive will usually be fixed in a subsequent database update without any action needed on your part. If you wish, you may also:
Check for the latest database updates
First check if your F-Secure security program is using the latest updates, then try scanning the file again.
Submit a sample
After checking, if you still believe the file is incorrectly detected, you can submit a sample of it for re-analysis.
Note: If the file was moved to quarantine, you need to collect the file from quarantine before you can submit it.
Exclude a file from further scanning
If you are certain that the file is safe and want to continue using it, you can exclude it from further scanning by the F-Secure security product.
Note: You need administrative rights to change the settings.
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 Files
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 has 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.
For more information, see the description "SK".