Skip navigation

Lost password? | Help

Blog of Mixed Bag

Duh... Anything is in the bag.

Posts tagged with "VirtualPC"

Just Another VM Detection (was "VM Detection Combo")

, , , ...

I'm terribly sorry of the major mistake I've made for the "VM Detection Combo". I thank you for an anonymous person willing to point me of the mistake. Because of this, nearly the whole contents of the article needs to be rewritten. I've decided to roughly edit it. Changed its title and removed (primarily) the "IDTR & LDTR Modification Detection" method. Due to these changes, the VMDetectionCombo software is no longer applicable and is removed. To compensate this, I'm releasing most of the essential code of the software. There may be some leftovers. Again, I apologize for this mistake.

[edited article follows]

Read more...

A better VMware detection

, , , ...

Recently, I've been experimenting many VM detection methods gathered from the internet. Under Microsoft Windows 98/Me/XP, I found that the "Red Pill" and the "Scooby" methods are not reliable for detecting VM when run under VMware Workstation (untested in other versions; eg. ACE, GSX, Server, etc.). They are useless if the VMware guest OS has below line in its VM configuration file.
monitor_control.disable_directexec = "TRUE"


As far as I can understand, the setting will make VMware to interpret each CPU instructions rather than directly executes them (and by trapping them with exception handlers). This setting will make the VM runs slower. Other interesting result is that the SGDT, SIDT and SLDT instructions will behave EXACTLY like a real hardware does. So the global & local descriptors and the selector returned by the instructions will be like a real hardware. For example, both the GDT and LDT have "normal" addresses and accessible only in ring-0 and the LDT selector is zero. Just like the real hardware.

You may think that the VMware backdoor's "Get Version" command can solve the problem, but unfortunately there is a VM setting for disabling that command and some other commands. For disabling the "Get Version" backdoor command, the below line can be inserted in the VM configuration file.
isolation.tools.getVersion.disable = "TRUE"


But VMware has one mistake, even though the "Get Memory Size" command can be disabled, the command is required by all system softwares running inside the VM and these system softwares includes the BIOS. OK, here's the funny part... When the command is disabled and the VM is started, the BIOS will report the total memory as 4,094,302 MB! That's a total of 4 TB memory, regardless of the VM memory size setting. And guess what...? The BIOS will stop there and freezees. I don't know if it's a bug in the BIOS or a bug in the VMware code, but all I know is the "Get Memory Size" command is the most reliable method for VMware detection since no OSes would be able to boot up if the backdoor command is disabled. As far as I know...

I only interested in Windows platform based VM detection since it's my main work environment. As I mentioned earlier, I don't have any other VMware versions, so I don't know the result for those other versions. If anyone have tested the method, I want to know how it goes. Or even better, if you know a better method for VMware detection.

Currently, I'm experimenting on Parallels and am going to check Virtual PC, VirtualBox, Bosch and lastly QEMU using Microsoft Windows 98 & XP as the guest OS. I'll let you know how it goes when I get enough information.


References:
- Attacks on More Virtual Machine Emulators
- VMware Backdoor I/O Port
- On the Cutting Edge: Thwarting Virtual Machine Detection