Defeating malware’s Anti-VM techniques (CPUID-Based Instructions)



You should by now be aware of everything, cause the topic’s title clearly describes the contents of this post. As you know, almost all of the modern malware programs use some bunch of packers or protectors and using such tools cause malware to be weaponized with Anti-VM techniques which makes it impossible for reverse-engineers and analyzer to detect what’s happening inside the malware (or sometimes they implement their own methods to detect the VM presence). Reverse-engineers always prefer to run the malware inside a Virtual Machine environment to avoid their computer to be affected by malware programs and this gives them lots of features like creating a snapshot from malware’s (VM) previous state. In the rest of the post, I’m gonna show you some of the popular methods that use CPUID instruction in order to detect whether they’re running on a virtual machine or not.


CPUID is an instruction-level detection method and these kinds of methods are really hard to detect, as you know to trap on every execution of CPUID, you should either execute the instructions step by step(which is really slow and almost impossible) or instrument the target program. If you use instrumentation, then you might also defeat anti-instrument techniques. Let see some examples.


As this great article in cyberbit describes: The first method:

  • CPUIDThis instruction is executed with EAX=1 as input, the return value describes the processors features. The 31st bit of ECX on a physical machine will be equal to 0. On a guest VM it will equal to 1.

The second method:

  • “Hypervisor brand”: by calling CPUID with EAX=40000000 as input,1 the malware will get, as the return value, the virtualization vendor string in EAX, ECX, EDX. For example:
    • Microsoft: “Microsoft HV”
    • VMware : “VMwareVMware”

The Practical Implementation

For the first example I write the following code :

The above code set eax=1 and executes the CPUID instruction, after that the result of ecx is checked to determine whether the 31st bit is set or not, the result is finally saved on “IsUnderVM” variable. Now the second example:

The above code set eax=0x40000000 and then compares the ecx and edx against 0x4D566572 and 0x65726177 which are known and static values for VMWare products, like the first example, the result will finally save into “IsUnderVM”. Note that, this implementation of method only works on VMWare, but if you want it to work in other vendors like VirtualBox or Hyper-V, then you have to detect what is their vendor string, it’s simple but as long I currently don’t have VBox or Hyper-V VM then you should do it by yourselves if you want to test it on other vendors. Let see how it works! The following picture is the first example when running on a host machine.  

The following picture is the second example when running on a host machine.


How to defeat?

Now you might ask yourselves, Is it possible to change the CPUID results of the target virtual machine from host perspective? Yep! Fortunately, all the popular virtual machine vendors give the host machine an opportunity to modify CPUID and CPU features. This is because everytime your virtual machine fetches a CPUID instruction and wants to execute it, a VM-Exit happens and now hypervisor passes the execution to VMM, so this the best time of modifying CPUID result to bypass the above Anti-VM techniques. In VMWare, you can find where your virtual machine is located, then find .vmx (config file) of your target VM then add the following line at the end of the file:

The bypass for the second method is really dependent on the implementation. This might not work in your case but in my case, I can easily add the following lines to the .vmx config file.

Now the second method gives the wrong results to the malware. There is a good question here, which you can read in order to perform the same thing in VirtualBox. The other vendors also give the same features to you so you can search for changing CPUID in your vendor and get the same results.



In this post, I described an Anti-Anti-VM technique in which you can use them to circumvent an Anti-VM malware. In the future posts, I’ll describe more about other Anti-VM techniques and the way you can defeat them, so make sure to stay connected! I Also recommend you to read these papers.

This post is written in cooperation with my friend Sina

Advanced or Not? A Comparative Study of the Use of Anti-debugging and Anti-VM Techniques in Generic and Targeted Malware
Towards an understanding of anti-virtualization and anti-debugging behavior in modern malware


Leave a Reply

This site uses Akismet to reduce spam. Learn how your comment data is processed.