Virtual Machine Detection

[jeffs7]

Hello,

I have a Win 2k8R2 guest running on VMware ESXi 5.5 and I am trying to figure out how a program is detecting that it is running inside a virtual machine.  I realize this is a very broad topic and there has been quite a bit written about it, but I wonder if there have been any major developments in the past few years on ways to find out what a piece of software is doing and then figure out what it is keying from.

I have tried process monitor, but nothing there seems particularly damning.  I have also enabled all the "usual" tricks, such as changing the ethernet address, removing VMware tools, and setting the following options in the VMX file:

monitor_control.virtual_rdtsc = "FALSE"
monitor_control.restrict_backdoor = "TRUE"
isolation.tools.getPtrLocation.disable = "TRUE"
isolation.tools.setPtrLocation.disable = "TRUE"
isolation.tools.setVersion.disable = "TRUE"
isolation.tools.getVersion.disable = "TRUE"
monitor_control.disable_directexec = "TRUE"
monitor_console.restrict_backdoor = "TRUE"
monitor_control.disable_chksimd = "TRUE"
monitor_control.disable_ntreloc = "TRUE"
monitor_control.disable_selfmod = "TRUE"
monitor_control.disable_reloc = "TRUE"
monitor_control.disable_btinout = "TRUE"
monitor_control.disable_btmemspace = "TRUE"
monitor_control.disable_btpriv = "TRUE"
monitor_control.disable_btseg = "TRUE"

None of this has helped.  It is a command line executable that is easily able to detect that it is running in a vm even though every other standard test (such as those performed by ScoopyNG) indicates it is bear metal.  Does anybody have any ideas on things I can try or ways to figure out what it is doing?  Thanks.

[Saju_C]

>>

I am trying to figure out how a program is detecting that it is running inside a virtual machine.

>>

What makes you to think that the program is able to understand that it is running inside a VM. Is there any visible log or message to tell this.

[jeffs7]

Yes, there is a message saying that it recognizes it is running inside a VM.  It is a pretty small command line program, so I feel like it cannot be tremendously complex, but it doesn't respond to any of the "usual" tricks.

[admin]

There are so many ways of detecting that you're running in a VM, it's hard to enumerate them all.  The best solution, for a small command line program, is to disassemble it.

[jeffs7]

Unfortunately, I was afraid of that.  I have already started trying to do this, but I am not getting great results.  Do you have any recommendations on possible decompiling packages (free or inexpensive, HexRays is much too costly for me)?

[admin]

Actually, the most obvious thing to try, which you haven't mentioned, is:

hypervisor.cpuid.v0 = FALSE

If that doesn't work, I would imagine that WinDbg should be able to provide the disassembly.

[JarryG]

Two of the best win dissassemblers are OllyDbg (free/share-ware) and IDA (proprietary). But I think it is not worth the effort. You can not prevent software detection of VM...

[MKguy]

As already mentioned there is a huge number of factors you have available to detect that you're running in a (VMware) VM. A basic but effective one is just checking the hardware devices like PCI devices for VMware vendor IDs. That's not really something you can "hide".

A simple lspci command on a Linux VM will list PCI devices like this:

# lspci | grep -i vm

00:07.7 System peripheral: VMware Virtual Machine Communication Interface (rev 10)

00:0f.0 VGA compatible controller: VMware SVGA II Adapter

00:11.0 PCI bridge: VMware PCI bridge (rev 02)

00:15.0 PCI bridge: VMware PCI Express Root Port (rev 01)

00:15.1 PCI bridge: VMware PCI Express Root Port (rev 01)

00:15.2 PCI bridge: VMware PCI Express Root Port (rev 01)

00:15.3 PCI bridge: VMware PCI Express Root Port (rev 01)

00:15.4 PCI bridge: VMware PCI Express Root Port (rev 01)

00:15.5 PCI bridge: VMware PCI Express Root Port (rev 01)

00:15.6 PCI bridge: VMware PCI Express Root Port (rev 01)

00:15.7 PCI bridge: VMware PCI Express Root Port (rev 01)

00:16.0 PCI bridge: VMware PCI Express Root Port (rev 01)

00:16.1 PCI bridge: VMware PCI Express Root Port (rev 01)

00:16.2 PCI bridge: VMware PCI Express Root Port (rev 01)

00:16.3 PCI bridge: VMware PCI Express Root Port (rev 01)

00:16.4 PCI bridge: VMware PCI Express Root Port (rev 01)

00:16.5 PCI bridge: VMware PCI Express Root Port (rev 01)

00:16.6 PCI bridge: VMware PCI Express Root Port (rev 01)

00:16.7 PCI bridge: VMware PCI Express Root Port (rev 01)

00:17.0 PCI bridge: VMware PCI Express Root Port (rev 01)

00:17.1 PCI bridge: VMware PCI Express Root Port (rev 01)

00:17.2 PCI bridge: VMware PCI Express Root Port (rev 01)

00:17.3 PCI bridge: VMware PCI Express Root Port (rev 01)

00:17.4 PCI bridge: VMware PCI Express Root Port (rev 01)

00:17.5 PCI bridge: VMware PCI Express Root Port (rev 01)

00:17.6 PCI bridge: VMware PCI Express Root Port (rev 01)

00:17.7 PCI bridge: VMware PCI Express Root Port (rev 01)

00:18.0 PCI bridge: VMware PCI Express Root Port (rev 01)

00:18.1 PCI bridge: VMware PCI Express Root Port (rev 01)

00:18.2 PCI bridge: VMware PCI Express Root Port (rev 01)

00:18.3 PCI bridge: VMware PCI Express Root Port (rev 01)

00:18.4 PCI bridge: VMware PCI Express Root Port (rev 01)

00:18.5 PCI bridge: VMware PCI Express Root Port (rev 01)

00:18.6 PCI bridge: VMware PCI Express Root Port (rev 01)

00:18.7 PCI bridge: VMware PCI Express Root Port (rev 01)

03:00.0 Serial Attached SCSI controller: VMware PVSCSI SCSI Controller (rev 02)

0b:00.0 Ethernet controller: VMware VMXNET3 Ethernet Controller (rev 01)

[JarryG]

Even if this all is hidden, it is still quite easy to detect hypervisor. Some instruction must be intercepted by hypervisor and that introduces delay to processing. If you know how many cpu-ticks certain instruction takes, all you need is timer to check it.

If OP wants to know more about it, I recommend reading some of Joanna Rutkowska's work: "Blue Pill" (virtualization-based rootkit) and "Red Pill" (detection-software for such a rootkit). But simply put: it is quite easy to detect if software is running in VM, and is nearly impossible to prevent it.

[admin]

JarryG wrote:

Even if this all is hidden, it is still quite easy to detect hypervisor. Some instruction must be intercepted by hypervisor and that introduces delay to processing. If you know how many cpu-ticks certain instruction takes, all you need is timer to check it.

That approach presumes that you have instruction timing data for the physical CPU at the time the detection software is written.  If nVidia releases a new x86 processor next year, detection software written this year has no baseline against which to benchmark said instruction(s).  Moreover, some physical CPUs (e.g. those previously manufactured by Transmeta) may exhibit anomalous timings that result in false positives for a timing-based detection scheme.  Finally, the timers themselves can be virtualized, which can make timing-based detection more difficult.

Having said that, detecting a VMware hypervisor is not that difficult.  We don't generally try to hide our presence from the guest, though we do have options to defeat certain tests, such as the one used by Hyper-V.

[tund3010]

Hello Jeffs,

I have to prevent VM detection too.

I have tried some tips as you said, added to VMX file

SMBIOS.reflectHost = TRUE

cpuid.1.eax = “00000000000000110000011010101001″

cpuid.1.edx = “10111111111010111111101111111111″

but it can not help to hide VM. Can you hide your VM? Could you share your knowledge about it?

Thank you,!