Blog of Mixed Bag

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

I've used GSM mobile phone for years but I'll be frank. I'm a new user in the world of CDMA network mobile telecommunication. At first when I heard of that CDMA is better than GSM, I was curious and believed it. Now that I finally got my hands on a USB CDMA modem, I can see it for myself. Both as a consumer and as a programmer.

As a consumer...
There isn't any significant difference between CDMA and GSM except the data bandwidth. I can't argue that CDMA network has far greater speed over GSM network (up to 5 times). It's the second place after UMTS/3G network. You'll want this instead of GSM or the ancient 56k phone lines. Most CDMA devices are well designed although some don't. Talking about those that don't, I want to give BIG bold red WARNING to all consumers who are considering to purchase Venus VT-21 USB CDMA modem or any other types. Let me tell you: DON'T! - Don't even consider buying that product. It's an unstable device which has undergone THREE revisions (VT-10, VT-11, VT-21) but still doesn't solve a problem where the device will get unresponsive when it's overheated. Don't say I didn't warn you...

And as a programmer...
Ugh... The CDMA network sure is more complicated than GSM. In general, CDMA is more analog than GSM. The fact that CDMA has larger data bandwidth than GSM is because it was designed after the GSM. Thus it uses newer base of technology. But alas... it was designed by a commercial company and not by a telecommunication organization. Although it's accepted as a standard by telecommunication industry, it's only for the hardware part. There is minimal standard for the interface between the hardware to the software or vice versa. This makes CDMA device manufacturer to provide propietary interface. The largest manufacturer which is largely adopted by other ones is Qualcomm. So most of the devices in the market have similar interface (but not the same). Regardless, since Qualcomm is a commercial company, the specification for the interface is not an open specification. Although there is a publicly (and freely) accessible specification, it only covers the "outer" part of the interface. The core itself, which is about 80% of the specification is most probably not free. This forces programmers to purchase the specification and may need to do that for EACH AND EVERY manufacturer. How's that? Feeling sick already?