Home / malware Virus:W32/Chimera.A
First posted on 25 June 2008.
Source: SecurityHomeAliases :
There are no other names known for Virus:W32/Chimera.A.
Explanation :
Virus:W32:Chimera.A is an appending parasitic file infector.
The virus body is located inside two layers of variable-key encryption. Chimera.A does not have any other payload in addition to spreading itself.
right]Virus
Chimera.A infects Portable Executable (PE) files on both fixed and removable drives that have drive letters between B and Z.
Infection
Files with extensions EXE and SCR and size between 20480 to 5242880 bytes are infected.
Files that have a non-zero checksum declared in their headers are not infected. This prevents the virus from infecting Windows system filesamong others.
The virus also checks files for an infection marker FFFF at file offset 0x1C before infecting. If the infection marker exists the virus knows it has already infected that particular file and does not infect it a second time.
An additional restriction is that only files with an optional header of 224 bytes in size are infected. This is not a very restrictive property as 224 bytes is a very common size for that particular part of the PE file header.
Location
The virus body is located at the end of the last section of the host file. When infecting a file the virus increases the size of the last section to accommodate the increase in size. The virus also increases the total size of the image in the file headers appropriately.
Files that have additional data in them after the last section are not infected as the virus would end up overwriting a part of the host rendering it in all likelihood non-functional. Section characteristics are altered to ensure the last section is readable and writable, and that the section containing the entry point is writable.
Function
Chimera.A consists of two parts: an initial 45-byte decryptor loop and a 4036-byte virus body which has another encryption layer. The outer decryptor is located at the entry point of the host. This ensures the virus will be executed every time the host is run. The 45 bytes that the initial decryptor replaces are stored within the virus body so the host can be returned to a functional state by the virus.
The outer loop decrypts the virus onto the stack using two 4-byte keys that change from infection to infection. The keys used for encryption are random and based on the elapsed tick count since the previous processor reset at the time of the infection. This way the virus body will be unique for each infection making detection more difficult. Once the virus body has been decrypted to the stack the virus transfers control to the beginning of the body.
After the initial decryptor has finished the virus body is still mostly obfuscated by a second encryption layer. Only the first 59 bytes of the body are in an unencrypted form. These bytes form the inner decryptor which decrypts the rest of the virus body.
The second decryptor is quite similar to the first decryption loop. The keys are again based on elapsed processor ticks as in the outer decryption layer. In both decryptors the decryption is performed 4 bytes at a time with a XOR-operation. Before each decryption an arithmetic operation is performed between the two 4-byte keys which are modified between the 4-byte decryption blocks by rotating one and sliding the other.
Once the second decryptor has finished the virus body is fully decrypted. Chimera.A then creates a thread for the virus body and replaces the initial decryptor loop at the entry point with the original code of the host. The host file is now ready to be executed leaving the viral thread running in parallel with the host executable.
In addition to encryption the virus has been further obfuscated by replacing the names of required Windows API functions with checksums.
When searching the Export Address Table (EAT) of kernel32.dll for the correct function the virus calculates a checksum for each function name it encounters in the EAT and compares it to the checksum it is searching for. If the checksums match the virus knows it has found the function it requires. A somewhat similar technique is used when the virus compares the file extension of a prospective new host file to .EXE and .SCR.Last update 25 June 2008
