On the possibilities of antiviruses. Part 1
Today the market for antivirus products is as varied as ever. What new technologies do not offer us antivirus companies; opportunities for 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 anti-virus is to protect the user's computer from previously unknown threats, 0-day viruses, so to speak. We will evaluate this functionality of antivirus today in practice. To do this, we will check our test programs with antivirus scanners, and we will use Virus Total as usual. At the same time, it should immediately be noted that with such testing, various HIPS technologies and the like will not be evaluated in any way, which allow the malicious functionality of the file to be determined on the fly by analyzing its behavior. That is, our test will be identical to a simple file checking antivirus product. Let's start.
We will test classic malware - the banal Trojan-Downloader. It is assumed that any software product that calls itself an antivirus, should easily recognize the threat. Our first test program is as follows:
')
We load the wonderful program on Virus Total and the following picture opens before us:
Our first test is recognized by only 18 of 43 anti-virus programs. Quite unexpectedly. Such well-known antiviruses as Avast, Comodo, Nod32, Panda and Symantec immediately surrendered. How did they manage to avoid such a primitive virus? Isn't it time for us to demand moral compensation from such “antiviruses”?
Go ahead, check whether antiviruses can cope with such a popular technique as the use of structural exceptions. The second test will look something like this:
Here we create our own exception handler, then perform an invalid operation, as a result of which control must be transferred to our handler. Can our experimental antiviruses cope with this:
The sample was recognized by 19 of 43 antiviruses. It is not known why, but SUPERAntiSpyware woke up and gave an unknown alarm. The rest of the results have not changed. Maybe antiviruses are not able to properly handle structural exceptions, but simply swear at the suspicious lines used by the program? Check this and encrypt the data section:
And now let's see what has changed:
Again, the same 18 out of 43 alarms, but now McAfee dropped out of action, and SUPERAntiSpyware again gives an unknown what alarm. Well, it's time to come up with something more complicated. We will use something that the antivirus hardly guesses. My choice fell on the CPUID command, with which you can get the name of the processor. This is done easily:
After executing this code in the variable szName will be the name of the processor. How can we use it? And what if, based on the result obtained, we additionally encrypt a data section? The only thing we need to achieve in this case is to keep the possibility of running the program on different processors. It is easy to see that usually in the name of the processor in the first place is the name of the company producing it. Will it notice the antivirus - that is the question))) Let's write a simple function:
Everything is simple here: first we skip the spaces, then we calculate something like a hash from the first word, and if the hash matches the standard, we calculate the key for the decryption based on this first word. It remains only to compile the function by any compiler and insert its assembly 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 it and not leave AMD offended, I think you yourself will guess. As a result, we get about the following:
Download the file and see the result:
Only 5 of 43 antivirus coped with the task. Moreover, SUPERAntiSpyware found the virus here clearly by mistake))) Well, and 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:
Sending the file:
Now 6 of 43 anti-viruses have responded. However, 4 of them could not determine the type of malware. This fact indicates that the antiviruses simply did not cope with the task - they could not decipher the body of the virus and gave the alarm only because the file was packed. In general, this is morally wrong: there is nothing wrong with the packaging of executable files. It is 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 coped with our latest test: Kaspersky and Microsoft. What is the reason - is unknown. Maybe with the fact that they managed to bring some kind of signature into the database? Or their signatures can break through XOR encryption? I think that you can put a fat point on this place, especially as Kaspersky is my favorite antivirus, and I have no complaints about Microsoft products (... well ... until Windows 8 came out).
Global conclusion: today proactive technologies are still far from perfect and they are not very difficult to deceive.
PS The article has not examined HIPS technology, which is able to determine the malicious functionality of a file on the fly, by analyzing its behavior. Therefore, not everything is as bad as it seems - if you, having checked the file with an antivirus and did not find anything, launch it for execution, then the antivirus will most likely give you a warning. But this topic is a completely different story.
One of the main functions of the anti-virus is to protect the user's computer from previously unknown threats, 0-day viruses, so to speak. We will evaluate this functionality of antivirus today in practice. To do this, we will check our test programs with antivirus scanners, and we will use Virus Total as usual. At the same time, it should immediately be noted that with such testing, various HIPS technologies and the like will not be evaluated in any way, which allow the malicious functionality of the file to be determined on the fly by analyzing its behavior. That is, our test will be identical to a simple file checking antivirus product. Let's start.
We will test classic malware - the banal Trojan-Downloader. It is assumed that any software product that calls itself an antivirus, should easily recognize the threat. Our first test program is as follows:
')
We load the wonderful program on Virus Total and the following picture opens before us:
Our first test is recognized by only 18 of 43 anti-virus programs. Quite unexpectedly. Such well-known antiviruses as Avast, Comodo, Nod32, Panda and Symantec immediately surrendered. How did they manage to avoid such a primitive virus? Isn't it time for us to demand moral compensation from such “antiviruses”?
Go ahead, check whether antiviruses can cope with such a popular technique as the use of structural exceptions. The second test will look something like this:
Here we create our own exception handler, then perform an invalid operation, as a result of which control must be transferred to our handler. Can our experimental antiviruses cope with this:
The sample was recognized by 19 of 43 antiviruses. It is not known why, but SUPERAntiSpyware woke up and gave an unknown alarm. The rest of the results have not changed. Maybe antiviruses are not able to properly handle structural exceptions, but simply swear at the suspicious lines used by the program? Check this and encrypt the data section:
And now let's see what has changed:
Again, the same 18 out of 43 alarms, but now McAfee dropped out of action, and SUPERAntiSpyware again gives an unknown what alarm. Well, it's time to come up with something more complicated. We will use something that the antivirus hardly guesses. My choice fell on the CPUID command, with which you can get the name of the processor. 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 in the variable szName will be the name of the processor. How can we use it? And what if, based on the result obtained, we additionally encrypt a data section? The only thing we need to achieve in this case is to keep the possibility of running the program on different processors. It is easy to see that usually in the name of the processor in the first place is the name of the company producing it. Will it notice the antivirus - that is 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 skip the spaces, then we calculate something like a hash from the first word, and if the hash matches the standard, we calculate the key for the decryption based on this first word. It remains only to compile the function by any compiler and insert its assembly 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 it and not leave AMD offended, I think you yourself will guess. As a result, we get about the following:
Download the file and see the result:
Only 5 of 43 antivirus coped with the task. Moreover, SUPERAntiSpyware found the virus here clearly by mistake))) Well, and 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:
Sending the file:
Now 6 of 43 anti-viruses have responded. However, 4 of them could not determine the type of malware. This fact indicates that the antiviruses simply did not cope with the task - they could not decipher the body of the virus and gave the alarm only because the file was packed. In general, this is morally wrong: there is nothing wrong with the packaging of executable files. It is 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 coped with our latest test: Kaspersky and Microsoft. What is the reason - is unknown. Maybe with the fact that they managed to bring some kind of signature into the database? Or their signatures can break through XOR encryption? I think that you can put a fat point on this place, especially as Kaspersky is my favorite antivirus, and I have no complaints about Microsoft products (... well ... until Windows 8 came out).
Global conclusion: today proactive technologies are still far from perfect and they are not very difficult to deceive.
PS The article has not examined HIPS technology, which is able to determine the malicious functionality of a file on the fly, by analyzing its behavior. Therefore, not everything is as bad as it seems - if you, having checked the file with an antivirus and did not find anything, launch it for execution, then the antivirus will most likely give you a warning. But this topic is a completely different story.
Source: https://habr.com/ru/post/136232/
All Articles