Copy Link
Add to Bookmark
Report
40Hex Issue 10 File 007
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
