What it does:

Honestly, I have no idea. All it seems to do is replicate and append itself to almost all .exe files accessed by the user/system. There is a possibility it is some part of the malware I recently got rid of. However, it does not seem to affect normal execution of the exe it infects. This is really all it seems to do, replicate.

Tell tale signs:

all executables that are copied from a read only media, say a setup cd, to any writable media, fixed disk or removable drive, will suffer a slight increase in file size. Generally of the order of 8 to 12 KB. One consequence is that all setup executables that do a checksum verification of files being copied will emit error messages.

possibly responsible for the 0xc000007b exception error (BAD_IMAGE_FORMAT) when running .NET applications. But I am not at all sure of that. Could be a completely different issue.

Checking for infection:

I'm guessing that if you execute an infected file on an uninfected system, the system becomes infected and after that, you don't even have to execute the exe. just query it's existence on disk. So if you were to to a search for "*.exe" on all your local hard drives. At the end of the search, BAM! All the exe files on all your local hard drives are infected.


We've got a bit of a Shroedinger's cat situation. As soon as we interact with an exe file in any way on an infected system, the exe file becomes infected if it is writable. Before we interact with an infected file there is no way of knowing if it is infected or not.

I really hope a uninfected system can't be infected simply by querying and infected file... if that's the case, Microsoft better reconsider what business it want to pretend it's in.

Ok, so what do we have?

• Basically any .exe file accessed in any way on a writable disk gets infected.
• The file modification time is not changed. Only the file size, nothing else
• System files are infected as easily as user files. System file checker does not detect any problem and it doesn't seem to matter which service pack you are using. So here's one for you, windows update alarmists.
• A backup copy of the files are actually made to a system restore point if the system restore service is running. Basically the files foind it the System Volume Information folder/_restore{clsid}/*.exe are uninfected backups. Which is a bit odd, considering that even svchost.exe was infected. Maybe this is where it started.

Isolating the virus code

What I did was try a copy/rename an exe file to disk from a cd-rom using the msdos xcopy utility

in this case a file named taking a file called setup.exe file and copying it to setup.original.

setpu.original is not infected yet. The file sizes match. However, renaming it to .exe instantly infects it.

then I copy the setup.exe file to disk normally (Ctrl+C, Ctrl+V) so that it gets infected.

I use a hex editor (it too was infected but it was operating normally) to open both files. I padded the uninfected file with zero byes to make it the same length as the infected file and then run the comparison tool to find the differences between the 2 files. I repeated the process for a few other exe files and found there was a pattern to it all.

There were 3 more or less distinct blocks.



The most obvious sign of infection is given by the first block in green.



as soon as you open any exe file in a hex editor, if you see the 20 20 20 20, you know you're infected. Possibly this is here for the virus itself to detect if it has already infected a file or not. Given that an exe file, especially a system file can be accessed several hundred times in a session, it would get suspicious after a very short while. This bit does not change from file to file.

The second block in blue is what I believe defines the entry point of the executable file. I think it is modifying the exe so that the virus code is executed first (for reinfection?) then resume normal program execution.

The third block in red is the data appended at the end of each infected exe file. probably the virus code itself. this bit does not change from file to file but it can be padded with zero bytes. the virus code is 8.5 KB in size but usually padded to add 12288 bytes to the exe file.

Once I found all that, I tested different executable files checking for the 20 20 20 20 at offset 20 and for the first 32 bytes of the virus code in each of them and found that

• not all executables are infected. dll, ocx and src show no sign of the appended code
• MSDOS porgrams are uninffected. although cmd.exe is.
• exe files stored in archived form or packed in another file are safe. zip, rar cab, 7z etc.
• Files that are considered unsafe by those blasted security features in windows are actually safe. It seems that most setup files that contain attachments are left alone. Possibly because those executables would have some checksum verification for whatever data is attached to them which would give away the virus.

Solution:

Well, it wasn't detected by the antivirus I used. It got infected too anyway. It seems to be fully reversible although right now I just think I'll get rid of all infected exe files on the system or a radical reformat of everything after backing up only the uninfectable files (and I'm going on a limb in assuming it really does not infect anything else than certain types of .exe files). Then do a fresh reinstall of windows using read only setup discs. or backup of installation files that predate the first signs of infection. Which in my case is about 1 week.

ho boy...