[vbox-dev] vm detection

Stéphane Charette stephanecharette at gmail.com
Mon Jan 4 13:23:15 PST 2010

>>> 2) vboxmanage can be used to customize the dmi strings, meaning that
>>> "innotek GmbH" and "VirtualBox" may not even appear in the dmidecode

I see you caught and corrected my typo with GmgH/GmbH.  Sorry about that.

> 80ee:beef is the graphics device.  While the graphics device probably won't
> change, unless we decide to change the vendor id at some point, I think the
> VirtualBox VMM device that the guest additions talks to (and VT-x currently
> relies upon for real-mode emulation) would be a slightly better choice for
> identifying the VirtualBox hardware.  The PCI VendorID:DeviceID for this
> device is 80ee:cafe.

Thank you for the info.  I guess the PCI device is still there, even
if the guest additions are not installed...hadn't thought of that.
That might work out nicely to identify VirtualBox.

While it seems the pci device route is most likely the best one, it is
unfortunate from a 3rd-party application point of view:  it means that
we need a list of possible virtualization software, and which devices
can be found on which VM.  VMWare uses one thing, VirtualBox something
else, etc.  Means that all software that wants to try and detect
virtualization (for whatever reason, and I know this is a
controversial topic) will need to keep a list of which devices
represent which virtualization package.  When I started looking into
this in December I thought perhaps there would be an easy way to
identify when running on bare metal versus virtualized.  I had
remembered seeing the infamous "red pill" code from years before,
though I had not kept up with the state of things since.

What I hadn't realized is that as the holes were discovered over the
past 6 years (red pill, no pill, etc.) I guess virtualization software
has worked to fill them in.  Makes sense in retrospect.  The other
thing I didn't know is if there was a common or loosely-agreed-upon
"back door" mechanism that virtualization products all implemented,
the way VMWare did with what is known today as the "Jerry" code -- I/O
on port 0x5658.  Looks like this is not the case.

I've documented all of the different techniques I found on this page:

Unless someone has a better idea, I'll start coming up with a list of
which PCI devices to look for indicating the presence of


More information about the vbox-dev mailing list