Maximize
Bookmark

VX Heaven

Library Collection Sources Engines Constructors Simulators Utilities Links Forum

Cruncher - The First Beneficial Virus?

Eugene Kaspersky
Viruis Bulletin, June 1993, pp. 8-9
ISSN 0956-9979
June 1993

1
[Back to index] [Comments]

The first time I ever heard about the dispute over whether there could ever be such a thing as a useful virus was many years ago, when I was analysing the first virus I had ever seen. One of the articles which I read at the time was about the definition of a computer virus and the philosophical aspects of viruses. The article went on to discuss what the future might hold, and whether or not one could ever have a useful virus.

At the time, I was not ready to take a firm standing point on this issue - in fact, I’m still not ready to decide. For example, a well-written boot sector virus which looked for lost clusters could arguably be useful. Once you begin to consider the beneficial things a virus could do, the list is rather long. There is a multitude of small ‘housekeeping’ tasks which a virus could perform, all of which could be inserted into the virus’ algorithm.

I hope that this does not appear to be propaganda for the legitimacy of virus writing. Computer viruses bring immense problems with them, and seriously compromise the security of machines. However, life brings a lot of surprises, and to become fixed with one particular viewpoint is always a bad idea - one of these surprises was that the Earth is not flat, but round as a ball. In the 15th Century, who would have thought it!

However, regardless of all of the above, the question remains - can we have a useful virus? If we can, then the Cruncher virus could well be it.

The Virus Which Saves Your Disk Space

This virus takes its name from an internal text string ‘Cruncher V1.0ß’ which is inserted into the end of the virus body. This word has a special meaning in the world of file compression - ‘crunching’ is the name of one of the file-packing methods used by most popular data compressors.

On the face of it, Cruncher looks like an ordinary memory-resident parasitic COM-file infector. It hooks Int 21h when it is executed and then alters the Memory Control Block list, leaving itself neatly installed in high memory.

When Cruncher is memory-resident, it infects on the DOS Load and Execute function. During the infection process, the virus intercepts Int 24h (the DOS Critical Error Handler) to ensure that spurious error messages are not displayed. The virus does not alter the time and date stamp of infected files, nor their attributes.

So far, Cruncher appears to be almost an ANSI-standard file infector virus, but unfortunately things are not nearly as simple as this first analysis would show. The additional code in the virus makes up a complete data compression routine. The Cruncher virus compresses the body of the host file when it infects it - so a hard disk thoroughly infected by this virus will have more space on it than before the infection - with no resulting loss of data!

The Origin

The virus contains the text string ‘[ MK / Trident ]’. This message is present in several of the more complex hacker products, including the four versions of the TPE - the Trident Polymorphic Engine, which is rather like the MtE.

This means that virus writers can append that OBJ module to their viruses to make them polymorphic and difficult to detect. About six TPE-based viruses are known at this time, including the Girafe virus and the last version of the Coffeeshop and Civil War viruses.

The ‘MK’ label is present in several other viruses which are comparatively advanced - these are the MtE-based version of the Coffeeshop virus and WinVir-1.4, which is capable of infecting Windows executables.

Resident Operation

When the virus is memory-resident, it intercepts the main DOS interrupt Int 21h and checks function 4B00h (Load and Execute) and function 33E0h which is used by the virus as an ‘Are you there?’ call.

When a Load and Execute (AX=4B00h) function is trapped, the virus checks the file’s name and extension. Version one of the virus only infects COM files, although it excludes any files which have the first letters CO. Version two of the Cruncher virus infects both COM and EXE files, but excludes files which begin with the letters SC, CL, VS, NE, HT, TB, VI, FI, GI, RA, FE, MT, BR, or IM.

The virus opens the file and examines five bytes of its header to ensure that the file is not already infected. If the target file length is less than 256 bytes or above 61440 bytes, the virus will not infect it.

Slimming Down

If the file is deemed suitable for infection, the virus reads the whole file contents into one of two temporary segments (128k) of system memory. The virus then infects the file in memory, by appending the virus code and adding a jump instruction at the start of the host file.

Up to this point, the virus has acted like any other file infector- however, the virus now starts to pack the infected memory image of the file using the same algorithm as the DIET utility. This compression is used over the entire file, i.e. the host and the virus body.

The infection routine ends here, and the compressed file is copied back to disk. The virus closes the file, restores the file attributes and time/data stamp and releases the temporarily allocated segment of system memory which was used during infection. The result of this is that the virus code is now stored within the file compression - and therefore not immediately visible. The compressed file is completely DIET-compatible to the extent that it is possible to use the DIET utility to decompress the executable!

Unpacking and Installation

When an infected file is executed, the file begins to unpack itself, using the DIET algorithm. When the unpacking routine is complete, the virus installation code is executed. This checks the system memory to see whether the virus is already resident by using an ‘Are you there?’ call. If it is not, the interrupt handlers are hooked into place and the virus becomes memory-resident.

Detection Problems

Reliable detection of the Cruncher virus is a very difficult task because the actual virus code is hidden within the compressed file. In this case it is not acceptable to search for the decompression routine (effectively, the decryption routine) because that code has a perfectly legitimate role in other programs. It is also not possible to use a Hex pattern search (even with wildcards) as the contents of the compressed file will depend on the contents of the host file.

When a file is compressed using DIET, an algorithm developed by Lempel and Ziv is used. The compression is based on creating a dictionary of ‘words’ which make up the majority of the file. Compression of this type is known as ‘adapted word compression’, which can be thought of as creating ‘abbreviations’ for longer expressions - just as one abbreviates Terminate Stay Resident to TSR.

For example, by using this method the string ‘111122231111’ will be compressed to ‘11 [repeat 2 bytes from offset 0] 2223 [repeat 4 bytes from offset 0]’.

The contents of a file are therefore packed as the sequence of new words and pointers to words which have already occurred in that file.

This means that the byte sequences contained in the compressed file will depend not only on the contents of the virus code but also on the contents of the host file. Therefore the contents of the compressed infected file will differ vastly for different host files.

This presents rather serious problems when considering how to detect the Cruncher virus. I can see no way of detecting every single infection of the virus unless the entire file is unDIETed [Fattened? Ed.], and then scanned. However, this process is both time and resource consuming - if the target disk contained a number of legitimate DIETed files, the scan time for the disk could be unacceptably high.

It is probably possible to search for the strings ‘[ MK / Trident ]’ and ‘Cruncher V1.0ß’. Although these are nominally compressed, the brief experiments which I have conducted show that infected files are detected in 75% of cases - which is enough to raise the alarm, but not nearly enough for reliable detection.

CRUNCHER
Aliases:Cruncher-2092, Cruncher-4000
Type:Memory-Resident, Appending Parasitic, Polymorphic
Infection:COM files only (Cruncher-2092) COM and EXE files (Cruncher-4000)
Self-Recognition:
FilesChecks contents of first five bytes
Memory‘Are you there?’ call using INT 21h with AX=33E0h.
Hex Pattern:No simple search pattern is possible. Many infected files contain ‘corrupted’ incidences of the following strings Cruncher-2092:
[ MK / Trident ] Cruncher V1.0ß
Cruncher-4000:
*** CRUNCHER V2.0*** Automatic file compression utility
Trigger:None
Removal:File disinfection is possible but difficult. Under clean system conditions identify and replace infected files.
[Back to index] [Comments]
By accessing, viewing, downloading or otherwise using this content you agree to be bound by the Terms of Use! vxer.org aka vx.netlux.org
deenesitfrplruua