Defeating WMI detection of VirtualBox take 2

My previous attempt to twart WMI detection of VirtualBox, by disabling the Plug and Play service, had the mildly obnoxious side effect of disallowing the OS to check if it was registered or not.

This resulted in that, already registered installations became unlicensed (The same issue applied to MS Office installations)

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\services\PlugPlay

Being that It is always hard to find time for fun/interesting research. I had to put this issue back into my ToDo list, until now. And I guess leaving a problem to fend for itself for a while makes you look at it in a more logical way then you previously did, at least this was true for this issue at this time.

So enters my second attempt to solve this issue.

The remaining culprit that enables one to detect the presence of VirtualBox through WMI(1) is the






As we have chosen not install VirtualBox Guest Additions, the device is missing it's driver (Error 28, I will come back to this one later). It is that device that is detected, DEV_CAFE. (If you need a quick fix goto 2.) 

My first thought was to ty to replace corresponding values in the registry, but that one did not work out either.

Microsoft Windows does not supply you with a command line option to install/remove/uninstall devices by default. They have however an application that is available in their Windows Driver Kit (WDK), called DevCon. 

DevCon sounded like the way to go, given the fact that I had to use a none pre-installed application anyway.

But once again, reality came repelling down the ceiling and smacked me in the head. DevCon was not able to remove a device that was not fully installed, remember the Error 28.

DevManView from Nirsoft(3) to the rescue! While DevCon was not able to remove the device, DevManView were!

So now that we have a working solution that we can script, it was time to figure out how to make it user friendly given that we have to use a 3rd party application.

The easiest way would have been to leave the "user" to move the application to the VM guest themselves... but why miss the opportunity to do something hideous?

So I decided to embed the binary in the batch script by Base64 encode DevManView.exe. The Base64 encoded part is then in the guest decoded, up on execution of the batch script.

I guess I could try to sugar coat this by pointing to the fact that it is a bit more user friendly..

Please remember to pick the version of DevManView corresponding to the guests O architecture.

An updated version of the script can be found at: https://github.com/nsmfoo/antivmdetection/

As always any kind of feedback is welcomed

/Mikael

(1) If you use previous versions of the antivmdetction script

(2) just right-click on the Base System Device and choose uninstall ;)

(3) http://www.nirsoft.net/utils/device_manager_view.html