英文资料，原版转载，给有需要和感兴趣的朋友参考下，呵呵，需要一定的基础啊。
文章作者：Alisa Shevchenko (Virus analyst, Kaspersky Lab )
原始出处：http://www.viruslist.com/en/analysis?pubid=204791949
The evolution of self-defense technologies in malware
This article explores how malware has developed self-defense techniques and how these techniques have evolved as it has become more difficult for viruses to survive. It also provides an overview of the current situation.
First we must define the meaning of the term “malware self-defense", which is not as unequivocal as it may seem at first glance. When malware attacks antivirus programs, this is clearly a form of self defense. When malware covering its tracks, this is also in some sense a form of self defense, although less obviously so. An even less obvious form of self defense is the very evolution of malicious programs. After all, one of the motivations behind virus writers searching for new platforms that can be infected and for new system loopholes is to spread new viruses in the wild, into areas where no one yet bothers to look for malicious code as nothing has been found there before.
In order to avoid confusion about what is considered a self-defense technology and what is not, this article examines only the most popular and obvious means of malware self-defense. First and foremost this includes various means of modifying and packing code, in order to conceal the presence of malicious code in the system and to disrupt the functionality of antivirus solutions.
Classifying malware self defense
Sources: polymorphism, obfuscation and encryption
Stealth viruses
Packers
Rootkits
Combating antivirus solutions
What will the future bring?
Trends and forecasts
Conclusion
Classifying malware self defense
There are many different kinds of malware self-defense techniques and these can be classified in a variety of ways. Some of these technologies are meant to bypass antivirus signature databases, while others are meant to hinder analysis of the malicious code. One malicious program may attempt to conceal itself in the system, while another will not waste valuable processor resources on this, choosing instead to search for and counter specific types of antivirus protection. These different tactics can be classified in different ways and put into various categories.
As the goal of this article is not to create a strict classification system for malware self-defense techniques, let's consider a classification system that will provide an understanding of this issue at an intuitive level. We take the two criteria which we believe are the most important, and from there we will create a scatterplot with two axes representing those two criteria.
The first criterion is a malicious program's level of self-defense activity. The most passive malware does not attempt to defend itself in any way, i.e. it does not contain any such code. Instead, the author creates a kind of protective shell for the program. More active self-defense systems involve deliberately aggressive techniques.
The second criterion is the degree to which a malicious program's self-defense mechanism is dedicated. The most narrowly dedicated forms of self defense are found in malicious programs that somehow disrupt the function of a specific antivirus program. More general self-defense mechanisms are designed to defend malicious programs against everything by making the virus presence in the system as undetectable as possible in every way.
We have used a scatterplot to present the different kinds of malware self-defense mechanisms. This diagram is merely a simple example that we can use as a guide to categorize different means of malware self-defense. This model is based on a careful analysis of malware behaviors, but is, necessarily, subjective.
Figure 1. A scatterplot of malware self-defense technologies
Malware self-defense mechanisms can fulfil one or more tasks. These include:
hindering detection of a virus using signature-based methods;
hindering analysis of the code by virus analysts;
hindering detection of a malicious program in the system;
hindering the functionality of security software such as antivirus programs and firewalls.
This article will only examine malicious programs written for the Windows operating system (and its predecessor, DOS) due to the rarity and relatively small number of malicious programs for other platforms. All of the trends examined in this article that apply to executable malware files (EXE, DLL and SYS), and to some extent also apply to macro viruses and script viruses, which is why I will not be addressing the latter separately.
Sources: polymorphism, obfuscation and encryption
It makes sense to examine polymorphism, obfuscation and encryption together, as they all fulfill the same end, albeit to different degrees. Initially, modification of malicious code had two goals: to make it more difficult to detect files and to make it more difficult for virus analysts to examine the code.
The history of malware began in the 1970s, but the history of malware self-defense didn’t start until the late 1980s. The first virus that attempted to defend itself from the antivirus utilities then in existence was the DOS virus Cascade (Virus.DOS.Cascade). It defended itself by partially encrypting its own code. This wasn’t very successful, however, since each new copy of the virus - despite being unique from previous copies - still contained an unaltered piece of code that gave it away every time. As a result, antivirus programs could still detect it. Nevertheless, virus writers were turning in a new direction, and in two years the first polymorphic virus appeared: Chameleon (Virus.DOS.Chameleon). Chameleon, also known as 1260, and its contemporary Whale, used complex encryption and obfuscation methods to protect their code. Two years later, we saw the emergence of so-called polymorphic generators, which could be used as out of the box defense solutions for malicious programs.
Why code modification can be used to hinder file detection, and how file detection works, needs some explanation.
Until recently, antivirus programs worked exclusively by analysis file code. The earliest signature-based detection methods focused on searching for exact byte sequences, often at a fixed offset from the beginning of the file, in a malicious program's binary code. Later heuristic detection methods also used file code, but with a more flexible, probability based approach to searching for common malware byte sequences. Obviously, it’s not difficult for malicious programs to get around that kind of protection if each copy of the program includes a new byte sequence.
This task is fulfillled by the application of polymorphic and metamorphic techniques, which essentially - without getting into the technological nitty-gritty – enable a malicious program to mutate at byte level when the program creates a copy of itself. Meanwhile, the program’s functionality remains unchanged. Encryption and obfuscation are primarily used to hinder code analysis, but when they are implemented in a certain way, the result can be a variation of polymorphism – an example here is again Cascade, where every copy of the virus was encrypted with a unique key. Obfuscation may just hinder analysis, but when it is applied in a different way to every copy of a malicious program, it hinders the effective use of signature-based detection methods. However, it cannot be said that any one of the abovementioned tactics is more effective than any other in terms of malware self-defense. It would be more correct to say that the effectiveness of these techniques depends on the specific circumstances and how the techniques are implemented.
The use of polymorphism only became relatively widespread in terms of DOS file viruses. There's a reason for this. Writing polymorphic code is a highly time-consuming task that is really only justified in cases when a malicious program is self-replicating: then each new copy contains a more or less unique byte sequence. The majority of contemporary Trojans aren't able to self-replication, and polymorphism is therefore irrelevant. That’s why since the end of the DOS file virus era, polymorphism has been seen less, and it was used mostly by virus writers who wanted to show off their skills rather than to create a particularly useful malicious function.
Figure 2. The polymorphic code of P2P-Worm.Win32.Polip
In contrast, obfuscation continues to be used today, as are other code modification methods that, to a large extent, make it more difficult to analyze code as opposed to hindering detection.
Figure 3. A diagram of the obfuscated code in Trojan-Dropper.Win32.Small.ue
Since behavioral detection methods arrived and began to squeeze out signature-based methods, code modification techniques have become less useful in hindering malware detection. This is why polymorphism and related technologies are not commonly used today and are only really a means for hindering the actual analysis of malicious code.
Stealth viruses
Concealing malicious programs in the system became the second method of self-defense against detection that was mastered by virus writers in the DOS era. This technique was first used in 1990; to be more precise, it was included in the arsenal of a virus we have already mentioned - Whale. Essentially, the concealed virus would one way or another intercept DOS system services and pass false data to the user or the antivirus program – for instance, "clean" boot sector contents, instead of the real contents which had been infected by the malicious program.
Stealth technologies for the DOS operating system were reborn as rootkit technologies for the Windows operating system 10 years later.
The mechanisms used to conceal viruses in the system are covered in more detail in the Rootkit section.
Packers
Gradually, viruses - malicious programs that can function only within a victim body and which are unable to exist as a separate file - are being replaced by Trojans, which are fully independent malicious programs. This process began when the Internet was still slow and more limited than it is today. Hard disks and floppy disks were small, which meant that the size of a program was very important. In order to reduce the size of a Trojan, virus writers began to utilize so-called packers - even back in the DOS era. Packers are dedicated programs that compress and archive files.
A side effect of using packers that can actually be useful from a malware point of view is that packed malicious programs are more difficult to detect using file methods.
When creating a new modification of an existing malicious program, the virus writer usually changes several lines of code, while leaving the heart of the program untouched. In the compiled file, the bytes for a certain sequence of code will also be altered and if the antivirus signature does not include that very sequence, then the malicious program will still be detected as before. Compressing a program with a packer solves this problem as changing even just one byte in the source executable results in an entirely new byte sequence in the packed file.
Figure 4. The visible difference between packed and unpacked code
Packers are still commonly used today. The variety of packing programs and their level of sophistication continue to grow. Many modern packers, in addition to compressing a source file, also equip it with additional self-defense functions aimed at hindering the unpacking and analysis of the file using a debugger.
Rootkits
Malicious programs for the Windows operating system started using stealthing technologies to hide their presence in the system in the first years of the new millennium. As mentioned above, this was approximately 10 years after stealthing programs appeared as a concept and was implemented for DOS. In early 2004, Kaspersky Lab encountered a surprising program that couldn't be seen in the Windows processes and files list. For many antivirus experts, this was a new beginning – understanding stealthing technologies for malicious programs for Windows – and it was the harbinger of a major new trend in the virus writing industry.
The term “rootkit” stems from Unix utilities that are designed to provide a user with unsanctioned root access within the system without being noticed by the system administrator. Today, the word rootkit covers dedicated utilities used to conceal information in the system, as well as malicious programs with functionality which enables them to mask their presence. These include the manifestations of any third-party registered applications: a string in the list of processes, a file on disk, a registry key or even network traffic.
How do rootkit technologies which are designed to conceal malicious programs in the system make it so difficult to detect the malicious programs using antivirus or other security software? It’s very simple: an antivirus utility is an external agent just like the user. Generally, if a user can't see something, then an antivirus program can't see it either. However, some antivirus solutions implement technologies which sharpen their vision, enabling them to detect rootkits when users cannot see them.
A rootkit is based on the same principle as DOS stealth viruses. A large number of rootkits have mechanisms which modify a chain of system calls (Execution Path Modification). This kind of rootkit may act as an hook located at a certain point of a route along which commands or information are exchanged. It will modify these commands or information in order to distort them or control what happens on the recipient's end without the recipient's knowledge. Theoretically, the number of points at which a hook can be located is limitless. In practice, there are currently several different methods commonly used to hook APIs and kernel system functions. Examples of this kind of rootkit include the widely known utilities Vanquish and Hacker Defender and malicious programs such as Backdoor.Win32.Haxdoor, Email-Worm.Win32.Mailbot, and certain versions of Email-Worm.Win32.Bagle.
Figure 5. Hooking ZwQueryDirectoryFile conceals
the driver file in the list of files
Another common type of rootkit technology is Direct Kernel Object Modification (DKOM), which can be viewed as an insider that modifies information or commands directly in their sources. These rootkits alter system data. A typical example is the FU utility; the same functions can be found in Gromozon (Trojan.Win32.Gromp).
A newer technology that officially corresponds to the rootkit classification conceals files in alternate data streams (ADS) in NTFS file systems. This technology was first implemented in 2000 in the malicious program Stream (Virus.Win32.Stream), and got a second wind in 2006 in the form of Mailbot and Gromozon. Strictly speaking, exploiting ADS is not so much a means of tricking the system as of taking advantage of little-known functions, which is why this particular technology isn't likely to become very widespread.
Figure 6. The malicious program Mailbot (Rustock) exploits
 |
发表于 2007-10-4 00:28:26
楼主
达人来翻译
本来想翻译一下给大家看的，结果发现那么长~~~~