40hex nº10:(40HEX-10.007):15/03/1993 << Back To 40hex nº 10
40Hex Issue 10 Volume 3 Number 1 File 007 A Case Against Simple Encryption And For Polymorphism ~ ~~~~ ~~~~~~~ ~~~~~~ ~~~~~~~~~~ ~~~ ~~~ ~~~~~~~~~~~~ In a well-crafted virus, every line of code should serve a definite purpose. No byte should be wasted. Is encryption, long used by virus programmers, still a viable method of eluding scanners and, if not, is encryption any longer a necessary part of a virus? The type of encryption found in the typical virus is a simple XOR loop or another similar type of operation, i.e. rotate, add, etc. The idea behind encryption was to change the virus during each iteration so that scanners would not be able to detect it. However, such simple encryption hardly serves this job, as most scanners simply scan for a pattern found in the encryption. Only a handful delve deeper than the decryption routine. So the sole purpose of simple encryption such as that seen in most viruses nowadays seems to be to hide text strings from archaic text searching programs (remember those virus books that touted CHK4BOMB as the best thing since rotten Jello?). But is it worth including encryption solely for this purpose? I think not. Few people search files for unusual text strings and the extra code needed to encrypt a file for this purpose may hardly be justified to overcome this obstacle. As mentioned previously, waste should be frowned upon in viruses. Unquestionably, the ultimate goal of a virus is to avoid detection while spreading to the greatest number of hosts. It has been established that simple decryption patterns do not aid a virus in avoiding detection from scanners. And encryption is certainly not a vital part of the replication process. Thus simple attempts at encryption do not add anything of value to the virus. Yet these weak encryption routines _are occasionally_ necessary, but only as stepping stones for fledgling virus programmers entering the realm of polymorphism. Without a few simple encryption routines and knowledge of their use under his belt, a virus programmer would be hard-pressed to create a truly polymorphic virus. Therefore, it should be noted that simple encryption should be used only as part of the learning process. However, remember also that such encryption pales in the face of modern virus scanners and polymorphism is a far better alternative. Polymorphism is perhaps the best technique modern viruses use to avoid scanners. The other alternative, stealth techniques, is limited in utility and is rendered helpless in the face of simple memory scans. A combination of the two is desirable, yet it is not always possible to implement both in a virus of limited size. So let us examine polymorphism. Polymorphism, in its simplest form, merely consists of a fixed-length decryptor with a few bytes which may be altered during each infection. This is merely a small step up from the simple encryption routine. A few extra XOR statements in the code are all that is necessary for implementing such a routine. However, this is, once again, only a small step up; most such fixed- length decryptors may be detected by a couple scan strings with wildcards. More powerful polymorphism is necessary for evasion of scanners. The MtE and the recently introduced TPE are both powerful products which allow every virus to include polymorphism. However, it is important to note that viruses utilising such products may be detected by existing scanners. Therefore, it is desirable to write a new polymorphic routine from scratch. This will allow for longer survival of the virus. The chief problem with good polymorphism is that the virus should be able to detect existing infections of itself in files. Otherwise, the virus could grow beyond limit and much disk space would be taken up in redundant infections. Two methods are commonly used; the infection marker byte and the time stamp. However, such a check is inherently limiting as the virus scanner is then able to use said check to its advantage; it need not check files, for example, save those which have the seconds field set to eight. Then again, a scanner which functions in this manner would be helpless in detecting another virus utilising the identical polymorphic routine but with a different infection stamp. The second major difficulty with good polymorphic routines is simply the size. MtE, for example, adds over 2,000 bytes of code. A working, albeit limited, polymorphic routine is possible in half this size, yet it would still be 1,000 bytes, a size larger than most viruses. Increased size, of course, increases the disk access time. While generally irrelevant in a harddisk-based environment, this increased infection time becomes crucial when infecting files on floppy diskettes. There are precious few ways of alleviating this problem; the only real solution is to decrease the functionality of the polymorphic routine and thereby compromise its worth. Taken as a whole, the advantages in utilising polymorphic routines should outweigh the disadvantages. The increased difficulty of scanning may allow the virus to slip through the cracks even after a virus scanner claims to detect it reliably. Take, for example, MtE. To this day, many virus scanners fail to accurately report MtE infections; some still trigger false positives. To reiterate a previous point - simple decryption routines are worthless, as they fail to serve their main purpose of aiding in the evasion of scanners. Even simple polymorphic routines are easily defeated by scanners; true polymorphism or no encryption at all are only alternatives. Dark Angel Phalcon/Skism 1993