About the capabilities of antiviruses. Part 1
Today, the market for antivirus products is as diverse as ever. What new technologies do antivirus companies not offer us; Possibilities of proactive protection, code emulation, heuristic analysis, "cloud" technologies, etc. etc. are present in the description of almost every self-respecting antivirus. But how effective these advertised technologies are is a big question. Let's try to figure it out.
One of the main functions of the antivirus is to protect the user's computer from previously unknown threats, 0-day viruses, so to speak. Today we will evaluate this functionality of antiviruses in practice. To do this, we will check our test programs with antivirus scanners, and Virus Total will be used, as usual. At the same time, it should be noted right away that with such testing various HIPS technologies and the like will not be evaluated in any way, which allow you to determine the malicious functionality of a file on the fly by analyzing its behavior. That is, our test will be identical to a simple file check by an antivirus product. Let's start.
We will test the classic malware - the banal Trojan-Downloader. It is assumed that any software product that calls itself an antivirus should recognize the threat without any problems. Our first test program is as follows:
We upload the miracle program to Virus Total and the following picture opens before us:
Our first test was recognized by only 18 out of 43 antiviruses. Quite unexpectedly. Immediately surrendered such notorious antiviruses as Avast, Comodo, Nod32, Panda and Symantec. How did they manage to bypass such a primitive virus? Isn’t it time for us to demand moral compensation from such “antiviruses”?
Go ahead, check to see if antiviruses can handle such a popular trick as using structural exceptions. The second test will look something like this:
Here we create our own exception handler, then we perform an invalid operation, as a result of which control should be transferred to our handler. Will our experimental antiviruses be able to cope with this:
The sample was recognized by 19 out of 43 antiviruses. It is not known why, but SUPERAntiSpyware woke up and issued an unknown alarm. Otherwise, the results have not changed. Maybe antiviruses are not at all capable of correctly handling structural exceptions, but simply swearing at suspicious lines used by the program? Check this and encrypt the data section:
Now let's see what has changed:
Again, the same 18 out of 43 alarms, but now McAfee is out of order, and SUPERAntiSpyware again issues an unknown alarm. Well, it's time to come up with something more complicated. We will use something that the antivirus is unlikely to guess about. My choice fell on the CPUID command, with which you can get the processor name. This is done easily:
After executing this code, the processor name will appear in the szName variable. How can we use it? But what if, based on the result, an additional section of the data is encrypted? The only thing we need to achieve in this case is to maintain the ability to run the program on various processors. It is easy to see that usually in the name of the processor in the first place is the name of the company that produces it. Does this antivirus notice - that’s the question))) Let's write a simple function:
Everything is simple here: first, we omit the spaces, then we compute something like a hash from the first word, and if the hash matches with the reference value, we calculate the decryption key based on this first word. It remains only to compile the function with any compiler and insert its assembler code into the program. Since I have an Intel processor on my computer, I calculated the hash from the word Intel. So our fourth test will not work on all processors. And how to fix this and not leave AMD offended, I think you yourself will guess. As a result, we get approximately the following:
Download the file and see the result:
Only 5 out of 43 antiviruses completed the task. And SUPERAntiSpyware found the virus here obviously by mistake))) Well, what will happen if we also encrypt the program code? For example, create a window, find out what text it contains, and then decrypt the program code based on the information received. It may look like this:
Send the file:
Now 6 out of 43 antiviruses have reacted. However, 4 of them could not determine the type of malware. This fact indicates that antiviruses simply did not cope with the task - they could not decrypt the body of the virus and issued an alarm only because the file was packed. In general, this is morally wrong: there is nothing wrong with packaging executable files. It’s not our fault that the antivirus program cannot work correctly with packed files. Conclusion number one - always check your software after packaging in order to avoid unpleasant incidents. Conclusion number two - only two antiviruses really managed our last test: Kaspersky and Microsoft. What it is connected with is unknown. Maybe with the fact that they managed to bring some kind of signature into the database? Or can their signatures break through XOR encryption? I think,
Global conclusion: today proactive technologies are still far from perfect and they are not very difficult to fool.
PS The HIPS technology, which is able to determine the malicious functionality of a file on the fly by analyzing its behavior, remained unexamined in the article. Therefore, not everything is as bad as it seems - if you scan the file with an antivirus and find nothing, run it, the antivirus will most likely give you a warning. But this topic is a completely different story.
One of the main functions of the antivirus is to protect the user's computer from previously unknown threats, 0-day viruses, so to speak. Today we will evaluate this functionality of antiviruses in practice. To do this, we will check our test programs with antivirus scanners, and Virus Total will be used, as usual. At the same time, it should be noted right away that with such testing various HIPS technologies and the like will not be evaluated in any way, which allow you to determine the malicious functionality of a file on the fly by analyzing its behavior. That is, our test will be identical to a simple file check by an antivirus product. Let's start.
We will test the classic malware - the banal Trojan-Downloader. It is assumed that any software product that calls itself an antivirus should recognize the threat without any problems. Our first test program is as follows:
We upload the miracle program to Virus Total and the following picture opens before us:
Our first test was recognized by only 18 out of 43 antiviruses. Quite unexpectedly. Immediately surrendered such notorious antiviruses as Avast, Comodo, Nod32, Panda and Symantec. How did they manage to bypass such a primitive virus? Isn’t it time for us to demand moral compensation from such “antiviruses”?
Go ahead, check to see if antiviruses can handle such a popular trick as using structural exceptions. The second test will look something like this:
Here we create our own exception handler, then we perform an invalid operation, as a result of which control should be transferred to our handler. Will our experimental antiviruses be able to cope with this:
The sample was recognized by 19 out of 43 antiviruses. It is not known why, but SUPERAntiSpyware woke up and issued an unknown alarm. Otherwise, the results have not changed. Maybe antiviruses are not at all capable of correctly handling structural exceptions, but simply swearing at suspicious lines used by the program? Check this and encrypt the data section:
Now let's see what has changed:
Again, the same 18 out of 43 alarms, but now McAfee is out of order, and SUPERAntiSpyware again issues an unknown alarm. Well, it's time to come up with something more complicated. We will use something that the antivirus is unlikely to guess about. My choice fell on the CPUID command, with which you can get the processor name. This is done easily:
mov edi, offset szName
mov eax, 080000002h
BYTE 0fh, 0a2h; CPUID
mov [edi], eax
add edi, 4
mov [edi], ebx
add edi, 4
mov [edi], ecx
add edi, 4
mov [edi], edx
add edi, 4
mov eax, 080000003h
BYTE 0fh, 0a2h; CPUID
mov [edi], eax
add edi, 4
mov [edi], ebx
add edi, 4
mov [edi], ecx
add edi, 4
mov [edi], edx
add edi, 4
mov eax, 080000004h
BYTE 0fh, 0a2h; CPUID
mov [edi], eax
add edi, 4
mov [edi], ebx
add edi, 4
mov [edi], ecx
add edi, 4
mov [edi], edx
After executing this code, the processor name will appear in the szName variable. How can we use it? But what if, based on the result, an additional section of the data is encrypted? The only thing we need to achieve in this case is to maintain the ability to run the program on various processors. It is easy to see that usually in the name of the processor in the first place is the name of the company that produces it. Does this antivirus notice - that’s the question))) Let's write a simple function:
unsigned int ParseName(char *str)
{
char *p=str;
while(*p==' ') p++;
unsigned int hash=p[0]*34+p[1]*344+p[2]*1152+p[3]*44233+p[4]*234321;
if(hash==29948155)
{
return p[0]+p[1]*0x100+p[2]*0x10000+p[3]*0x1000000;
}
return 0x75273451;
}
Everything is simple here: first, we omit the spaces, then we compute something like a hash from the first word, and if the hash matches with the reference value, we calculate the decryption key based on this first word. It remains only to compile the function with any compiler and insert its assembler code into the program. Since I have an Intel processor on my computer, I calculated the hash from the word Intel. So our fourth test will not work on all processors. And how to fix this and not leave AMD offended, I think you yourself will guess. As a result, we get approximately the following:
Download the file and see the result:
Only 5 out of 43 antiviruses completed the task. And SUPERAntiSpyware found the virus here obviously by mistake))) Well, what will happen if we also encrypt the program code? For example, create a window, find out what text it contains, and then decrypt the program code based on the information received. It may look like this:
Send the file:
Now 6 out of 43 antiviruses have reacted. However, 4 of them could not determine the type of malware. This fact indicates that antiviruses simply did not cope with the task - they could not decrypt the body of the virus and issued an alarm only because the file was packed. In general, this is morally wrong: there is nothing wrong with packaging executable files. It’s not our fault that the antivirus program cannot work correctly with packed files. Conclusion number one - always check your software after packaging in order to avoid unpleasant incidents. Conclusion number two - only two antiviruses really managed our last test: Kaspersky and Microsoft. What it is connected with is unknown. Maybe with the fact that they managed to bring some kind of signature into the database? Or can their signatures break through XOR encryption? I think,
Global conclusion: today proactive technologies are still far from perfect and they are not very difficult to fool.
PS The HIPS technology, which is able to determine the malicious functionality of a file on the fly by analyzing its behavior, remained unexamined in the article. Therefore, not everything is as bad as it seems - if you scan the file with an antivirus and find nothing, run it, the antivirus will most likely give you a warning. But this topic is a completely different story.