Question

Is there a way to identify, from within a VM, that your code is running inside a VM?

I guess there are more or less easy ways to identify specific VM systems, especially if the VM has the provider's extensions installed (such as for VirtualBox or VMWare). But is there a general way to identify that you are not running directly on the CPU?

Was it helpful?

Solution

A lot of the research on this is dedicated to detecting so-called "blue pill" attacks, that is, a malicious hypervisor that is actively attempting to evade detection.

The classic trick to detect a VM is to populate the ITLB, run an instruction that must be virtualized (which necessarily clears out such processor state when it gives control to the hypervisor), then run some more code to detect if the ITLB is still populated. The first paper on it is located here, and a rather colorful explanation from a researcher's blog and alternative Wayback Machine link to the blog article (images broken).

Bottom line from discussions on this is that there is always a way to detect a malicious hypervisor, and it's much simpler to detect one that isn't trying to hide.

OTHER TIPS

Red Hat has a program which detects which (if any) virtualization product it's being run under: virt-what.

Using a third-party-maintained tool such is this is a better strategy long-term than trying to roll your own detection logic: more eyes (testing against more virtualization products), etc.

A more empirical approach is to check for known VM device drivers. You could write WMI queries to locate, say, the VMware display adapter, disk drive, network adapter, etc. This would be suitable if you knew you only had to worry about known VM host types in your environment. Here's an example of doing this in Perl, which could be ported to the language of your choice.

It depends on what you are after:

  • If the VM is not hiding from you on purpose, you can use some known hook. LIke looking for VmWare drivers or the presence of certain strings in memory or certain other tell-tale signs.

  • If the VM is really wanting you to do special things for it, it will have some obvious hook in place, like modifying the ID of the processor or adding some special registers that you can access to detect it. Or s a special device in a known location in memory (presuming you can get raw access to the physical memory space of your world). NOte that modern machine designs like the IBM Power6 and Sun UltraSparc T1/T2 are designed to ALWAYS run a hypervisor, and never directly on raw hardware. The interface to the "hardware" that an OS uses is in fact the interface ot a hypervisor software layer, with no way to get around it. In this case, detection is trivial since it is a constant "yes". This is the likely future direction for all computer systems that can afford the overhead, look at the support in recent designs like the Freescale QorIQ P4080 chip, for example (www.freescale.com/qoriq).

  • If the VM is intentionally trying to hide, and you are chasing its presence, it is a game of cat-and-mouse where the timing disturbance and different performance profile of a VM is almost always going to give it away. Obviously, this depends on how the VM is implemented and how much hardware support there is in place in the architecture (I think a zSeries mainframe is much better at hiding the presence of a VM or stack of VMs under your particular OS than a regular x86 machine is, for example). See http://jakob.engbloms.se/archives/97 for some discussion on this topic. It is possible to try to hide as a VM, but detection is quite likely to always win if it tries hard enough.

I once ran across an assembly code snippet that told you if you were in a VM....I googled but couldn't find the original article.

I did find this though: Detect if your program is running inside a Virtual Machine.

Hope it helps.

In most cases, you shouldn't try to. You shouldn't care if someone is running your code in a VM, except in a few specific cases.

If you need to, in Linux the most common way is to look at /sys/devices/virtual/dmi/id/product_name, which will list the name of the laptop/mainboard on most real systems, and the hypervisor on most virtual systems. dmidecode | grep Product is another common method, but I think that requires root access.

Here is a (java + windows) solution to identify whether underlying machine is physical or virtual.

Virtual Machines Examples:

Manufacturer

  • Xen
  • Microsoft Corporation
  • innotek GmbH
  • Red Hat
  • VMware, Inc.

Model

  • HVM domU
  • Virtual Machine
  • VirtualBox
  • KVM
  • VMware Virtual Platform

    import java.io.BufferedReader;
    import java.io.InputStreamReader;
    import java.util.ArrayList;
    import java.util.List;
    
    public abstract class OSUtil {
    
    public static final List<String> readCmdOutput(String command) {
        List<String> result = new ArrayList<>();
    
        try {
            Process p=Runtime.getRuntime().exec("cmd /c " + command);
            p.waitFor();
            BufferedReader reader=new BufferedReader(
                    new InputStreamReader(p.getInputStream())
                    );
            String line;
            while((line = reader.readLine()) != null) {
                if(line != null && !line.trim().isEmpty()) {
                    result.add(line);
                }
            }
        } catch (Exception e) {
            e.printStackTrace();
        }
    
        return result;
    }
    
    public static final String readCmdOutput(String command, int lineNumber) {
        List<String> result = readCmdOutput(command);
        if(result.size() < lineNumber) {
            return null;
        }
    
        return result.get(lineNumber - 1);
    }
    
    public static final String getBiosSerial() {
        return readCmdOutput("WMIC BIOS GET SERIALNUMBER", 2);
    }
    
    public static final String getHardwareModel() {
        return readCmdOutput("WMIC COMPUTERSYSTEM GET MODEL", 2);
    }
    
    public static final String getHardwareManufacturer() {
        return readCmdOutput("WMIC COMPUTERSYSTEM GET MANUFACTURER", 2);
    }
    
    public static void main(String[] args) {
        System.out.println("BIOS Serial: " + getBiosSerial());
        System.out.println("Hardware Model: " + getHardwareModel());
        System.out.println("Hardware Manufacturer: " + getHardwareManufacturer());
    }
    }
    

You can use the output to decide whether it is a VM or a physical machine:

Physical machine output:

BIOS Serial: 2HC3J12
Hardware Model: Inspiron 7570
Hardware Manufacturer: Dell Inc.

Virtual machine output:

BIOS Serial: 0
Hardware Model: Innotec GmBH
Hardware Manufacturer: Virtual Box

One good example is that apparently doing a WMI query for the motherboard manufacturer, and if it returns "Microsoft" you're in a VM. Thought I believe this is only for VMWare. There are likely different ways to tell for each VM host software.

This article here http://blogs.technet.com/jhoward/archive/2005/07/26/407958.aspx has some good suggestions and links to a couple of ways to detect if you are in a VM (VMWare and VirtualPC at least).

You might be able to identify whether you're in a virtual machine by looking at the MAC address of your network connection. Xen for example typically recommends using a specific range of addresses 00:16:3e:xx:xx:xx.

This isn't guaranteed as it's up to the administrator of the system to specify what MAC address they like.

In Linux systems, you can try to search for common files on /proc.

Example, the existente of /proc/vz/ tell you is a OpenVZ.

Here's a full guide to detect VM's environent under Linux without have to "drink pills" :)

TrapKIT provides ScoopyNG, a tool for VMware identification -- it attempts to work around evasion techniques, but doesn't necessarily target any virtualization software other than VMware. Both source and binaries are available.

If it VM does the job well, it should be invisible to the client that it's being virtualized. However, one can look at other clues.

I would imagine that looking for known drivers or software specific to the VM environment would be the best possible way.

For example, on a VMWare client running Windows, vmxnet.sys would be the network driver, displayed as VMware accelerated AMD PCNet Adapter.

Licensed under: CC-BY-SA with attribution
Not affiliated with StackOverflow
scroll top