Video Screencast Help
Security Response

Virus Tricks of the Old School

Created: 26 Feb 2008 08:00:00 GMT • Updated: 23 Jan 2014 18:42:03 GMT
Liam O Murchu's picture
0 0 Votes
Login to vote

Old school virus methods appear to be invogue at the moment! Hot on the heels of Trojan.Mebroot, whichoverwrote the MBR, we have discovered a new worm that is revivinganother old school trick in order to hide itself. At first glance itappears to be a regular worm, but there is more going on here thanmeets the eye.

The worm in question is called W32.Joydotto and it initiallyappeared to be just another worm that spreads by copying itself and anautorun.inf file to all removable devices. However, upon closerexamination it was seen that the worm copies itself to removabledevices without using a file name for itself. By doing this the wormcannot be seen using any file-listing tools since there is no filenameto find. In addition to this the worm ensures its longevity by markingpart of the disk as being corrupted. In this way it will not beoverwritten because that part of the disk is thought to be corrupt. Infact the only way to find the worm on the disk is to know its exactlocation, along with the correct decryption keys. This information isonly stored in one place: a loader file that the worm uses to manifestand execute itself. This is a trick that some older dos viruses usedback in their heyday, however this trick has not been popular for quitesome time now.

The worm works in the following manner:

• It searches for all removable devices that contain a FAT partition.
• It then finds a random location on disk with enough space to store itself.
• It then encrypts itself using three randomly generated keys.
• It writes the encrypted data directly to the location found above (this way, no filename is needed).
• Next, it marks any clusters it used as being “corrupted / reserved.”
• It then creates a small loader file, which is stored as a regular file on the disk as [drive letter]:\Recycled\L.exe.
• Finally, it creates an autorun.inf file in the root of the disk that will run the small loader file. [1]

The loader files’ sole purpose is to find the encrypted worm,decrypt it, copy it to the system folder and execute it. In order tohide itself the encrypted worm is not stored as a regular file on thedisk. Instead, the worm requests raw access to the disk and writes datadirectly to the disk, not to a file. This method of writing does notrequire a file name to be used, it only requires an offset on disk andthe data to place at that offset. As shown below the worm is usingCreateFileA but the file name used is not in the typical format. Usingthe filename \\?\E: opens the entire disk as if it were one file.


Writing to the disk in this way means that the encrypted worm cannot beaccessed by filename becuase it had no filename to begin with. The onlyway the encrypted worm can be accessed is by knowing the exact locationon the disk where it is stored and exactly how much data is stored atthat location.

The loader file that will decrypt and execute the worm must containthis information in order to find the worm. Each loader file must alsocontain the three keys required to decrypt the worm. This informationchanges every time the worm is executed, so each loader file isslightly different from the last. Shown below is a comparison betweentwo loader files created during testing. The only difference betweenthem is the location of the worm on disk, the decryption keys used andthe checksum.

The problem with this way of writing to the disk is that the OS doesnot know that there is data stored at that location. Therefore, thenext time the OS writes to the disk it could overwrite the stored datasince the OS has no knowledge of it. To prevent this from happening theworm marks each cluster that was used to store the worm with the“corrupted/reserved” flag in the File Allocation Table. Now when the OStries to write a file to the disk, it will skip those bad clustersleaving the encrypted data intact. Shown below is the loop to modifythe File Allocation Table. To set a cluster to “corrupt/reserved” theflag 0xFFF7 is used.

Although the worm is using this trick to hide itself, it still needsan autorun.inf file and a loader file in order in start automatically.This is not a sophisticated approach but it does have some advantages.One is that the loader file is very small and can be changed veryeasily by the worms’ author if it becomes detected. Another is that ifthe user suspects that the loader file is malicious and submits it foranalysis, the analysts will only see that it reads some data from aspecific offset on disk and copies it to the system folder. The actualworm code itself would be harder for the user to extract from the disk.

The following image shows the state of the disk after the worm hasinfected it. The disk had been freshly formatted before infection andhad no files on the disk and no corrupted sectors. After infection, ascan be seen below, the disk contains three files (e:\autorun.inf ande:\Recycled\ and e:\Recycled\L.exe) which in total occupy 32,768 byteson disk. The image also shows 481,280 bytes in bad sectors – this isthe space reserved for the encrypted worm.


Although the worm is using some advanced techniques it does havesome defects in the way it works; some of the defects that may affectusers are shown below. Evidence of the first defect of the worm canactually be seen in the previous image. In the previous image the sizeof the bad sectors is 481,280 bytes. Therefore, we expect the wormexecutable to be around 481,280 bytes in size as well; however, theworm executable is in fact 96,256 bytes in size.

Since the worm only marks the clusters/sectors[2] that it used tostore itself as corrupt, something must be wrong; the worm should notbe using 481,280 bytes to store itself. After further analysis, thereason for this discrepancy was uncovered. The author of the worm madea mistake in the code. The mistake is that the worm first tries towrite itself to disk and afterwards marks the clusters as corrupted.The problem is that the worm does not check if the write was successfulor not. Even if the write was unsuccessful the clusters are stillmarked as corrupted.

The relevant code is shown below. After the Write_Sectors_Fnc iscalled there is no check to ensure that the write was successful,however the function to set the clusters flags is still called nomatter what the outcome was.

After this point in the code the worm tries to write the encryptedworm to disk a second time and the same mistake is made. In all, theworm continues this process five times until the device is infectedcorrectly. This means that 5 * 96,256 bytes are actually marked ascorrupted during infection. A little maths shows us that 5 * 96,256 =481,280; the size of the bad sectors we noticed above after infection.Due to this mistake the user loses almost half a megabyte of storagespace when the disk is infected even though the worm is just under100Kb.

The second defect of the worm is that it decides whether or not itshould infect a device by checking for the presence of an autorun.inffile in the root of the device. This is not the smartest choice and maylead to problems for some users in the following manner.

Let us assume that the user is infected, that the user notices anautorun.inf file on the removable device and that the user deletes thisautorun.inf file. In this scenario the worm will still be running fromthe %system% folder.
When the worm notices that the autorun.inf file is missing, it will try to re-infect the removable device.

The problem is that the worm has no knowledge of previous infectionson the removable device since it does not store the encryption keys itused for previous infections. Due to this the worm will mark newclusters as “corrupted” while leaving the old corrupted clusters stillin place. This process means that the user loses more storage space onthe removable device every time it is infected. The image belowhighlights this situation.

The image below shows the state of the disk after the secondinfection. To infect the disk a second time the autorun.inf file wasdeleted while the worm was still running. Although the size of thehidden executables remains constant, the size of the bad sectors hasdoubled.


Combining this defect with the previous defect means that every timethe device is re-infected the user will lose an additional 481,280bytes of storage space due to those extra bad sectors. Should a disklose storage space (as shown above) due to an infection ofW32.Joydotto, the lost storage space can be recovered by simplyformatting the disk.

This worm is interesting due to the fact that it has revived an oldtrick that was thought to be dead and buried. Trojan.Mebroot which wasdiscovered recently revived an old school favorite: that of overwritingthe MBR. The trick this worm uses was not as popular, but it is stillan effective technique for hiding files. The emergence of this wormdoes show that virus writers are looking to the past and are creatingnew worms using old and forgotten (but not quite) tricks.

Thanks to Senior Engineer Adam Blaszczyk for his help during this analysis.

[1] The file will be executed automatically only if autorun isenabled in the registry, the default value for autorun is “enabled” ifyou wish to disable autorun you may do so for all drives or on a driveby drive basis. There are many articles already available elsewherethat show how to do this.

[2] The File allocation table can only mark clusters as corrupt, notsectors, however the worm calculates which clusters contain itssectors, and marks those clusters as corrupted, for this reason theterm cluster and sector are interchangeable in reference to beingcorrupted.