Threat description


Category: Malware
Type: Virus
Platform: W32


Girafe is resident file virus infecting EXE and COM files. It uses the TPE encryption and is thus a polymorphic virus.

TPE is also known as TridenT Polymorphic Engine by the virus writing group that has written it. TPE is otherwise similar to MtE but it uses different methods to create polymorphic encryption/decryption pairs.


Automatic action

Depending on the settings of your F-Secure security product, it will either automatically delete, quarantine or rename the suspect file, or ask you for a desired action.

More scanning & removal options

More information on the scanning and removal options available in your F-Secure product can be found in the Help Center.

You may also refer to the Knowledge Base on the F-Secure Community site for more information.

Contact Support

F-Secure customers can request support online via the Request support or the Chat forms on our Home - Global site.

Technical Details

The actual code of the Girafe virus is appended to the host file after a random amount of garbage code and some randomised decryption code. Decryption code is randomised both by inserting do-nothing instructions and by selecting different encryption and looping methods.

The actual virus code remains constant, but it is encrypted. The virus contains a pseudorandom number generator which is randomised at the time the virus goes resident. Random number is seed is initialized based on the DOS time and the timer clock port.

Altogether 1333 bytes of the virus are solely for the purpose of generating random amounts of random NOP garbage and the encryption/decryption. Also some bogus code/data is sometimes added at the end of the encrypted area of the virus. This code is not used anywhere nor even copied into resident virus memory.

Encryption done is by one of the following methods: XOR, SUB, ADD, ADC and SBB. Both word and byte opcodes are used for these commands. The memory is addressed randomly by registers SI, DI or BX, with or without a constant random offset.

The virus only goes resident if the DOS version is at least 3.10. If INT 21h/AX=33DAh returns AH=0A5h the virus is already resident. It goes resident by reserving 2300h bytes (if available) from the current Memory Control Block if it is the last block in the MCB chain. The Program Segment Prefix is also adjusted.

The size of the resident virus is 3000 bytes. The rest of the reserved area is used for data, stack and various buffers. An INT 21h handler is set up by using DOS calls and the pseudorandom generator is randomised.

During installation, virus check the date. If it's Thursday there is a 1:60 chance (if DOS time has seconds=0) of calling a display routine before exiting into the host program.

The virus contains the texts " Amsterdam = COFFEESHOP! " and "[ MK / Trident ]". These texts are not displayed. Instead, the virus contains a quite visible display routine. This routine copies 731 bytes from the resident part of the virus to a buffer area already reserved above the virus. The segments are relocated so that the program runs at offset 100h. This program copies itself up to a higher area of the virus reserved memory and proceeds to generate and unpack a routine at the current offset 100h.

This routine (which is encoded and compressed) is 4064 bytes long. It displays a character graphics screen showing a cannabis leaf and the text "legalize cannabis", then it beeps and waits for a keypress.

Virus checks the first byte of the original file. If it is 'M', the file is treated as an EXE file, otherwise as a COM file.

Viruses INT 21h handler defines the following extra functions:

AX=33DAh returns AX=A503h, used as an "Are-you-there" call  AX=33DBh randomises the pseudorandom sequence based on the current time.  AX=33DCh does the video display screen, as described above.  

DOS functions 4B00h (load/exec) and 6C00h (extended open/create) are intercepted in order to infect files. If the given filename is longer than 127 characters the file is ignored. The filename is converted to upper case and the file is only considered for infection if it matches "*.EXE" or "*.COM". Files are ignored if the filename begins with one of the following two-letter pairs:

CO (COMMAND.COM, DOS command interpreter)  SC (SCAN.EXE, Mcafee antivirus)  CL (CLEAN.EXE, Mcafee antivirus)  VS (VSHIELD.EXE, Mcafee antivirus)  NE (NEMESIS.COM, behaviour blocker)  HT (HTSCAN.EXE, Tjissens antivirus)  TB (TBSCAN.EXE, Thunderbyte antivirus)  VI (VI-SPY.EXE, Vi-Spy antivirus)  IM (IM.EXE, Stiller's Integrity Master)  FI ?  GI \  RA -These three entries read "GIRAFE" combined, thus the name of the virus.  FE /  MT ?  BR ?  

There are also four blank entries in the two-letter table. These probably intended as room for adding more entries, or four such entries have been removed already.

During infection break is disabled, a dummy critical error handler is installed and the file attribute is cleared. File date/time are also preserved. The infection signature is 2 bytes at offset 12h, which is checksum field in EXE header. If these two bytes add up to 40h virus concludes the victim file to be already infected. Virus selects these two bytes by random to escape creating any constant bytes to the files.

'MZ' signature is used to determine whether the file is COM or EXE. COM files will not be infected unless they are smaller than 52 KB or at least 256 bytes. COM files starting with a byte which has the top-bit clear are ignored (this permits using 'M' to determine the exit method, and maybe has some other purpose). EXE files which have the first relocateable item at offset 40h or greater will not be infected if the byte at [ (dword ptr [ file:3Ch ] )+1 ] is 45h. EXE files are also ignored if the divmod (page) filesize is different from the actual filesize, if the maximum paragraphs value is specified as 0, or if the overlay number is not 0.

The infection routine generates a new copy of the virus in the same buffer that is used for the "legalize cannabis" program. Four of the random code features are controlled by a bitmask in the AL register on entry to the random/encrypt routine.

Two of these features can produce verbose and very verbose "NOP" output if the forces of random are working that way, one of them preserves the AX register over the random section using a PUSH AX ... POP AX pair and the last one prefixes a CS: segment override to the instruction that does the actual decrypt operation. This seems to be some sort of a debugging flag.

Afterwards the buffer contains a random amount of do-nothing instructions (including jumps and calls around random garbage data), followed by the randomly selected decryption routine (which is hidden amidst more random instructions and data), then comes a copy of the resident virus encrypted by the selected method (possibly with garbage instructions and/or data at the end).

The buffer contents are appended to the file and if that succeeds the file is patched so that the virus will be executed first. EXE files have BCh subtracted from the minimum and maximum memory requirements specified in the header, though not less than 50h for either value.


Suspect a file or URL was wrongly detected? Submit a sample to our Labs for analysis

Submit Sample

Give And Get Advice

Give advice. Get advice. Share the knowledge on our free discussion forum.

Learn More