Detect virtual machines

Hacker

Professional
Messages
1,046
Reputation
9
Reaction score
752
Points
113
Determine the fact of launching an application in VirtualBox, VMware Workstation, Virtual PC and Parallels Workstation
Not everyone wants his, ahem, new text editor to be explored by some nasty guys under a virtual machine. Detection of virtual machines is a mandatory functionality of a certain kind of software, and therefore our heading, well, absolutely cannot do without an overview of the corresponding methods!

How do I recognize a virtual machine?
Firstly, any virtual machine carries some specific hardware on board. This applies to the video adapter, hard drive, processor ID, BIOS version, MAC address of the network card.
Secondly, virtual machines leave traces in the system in the form of running auxiliary processes, drivers and other specific objects.
Thirdly, if you delve deeply into the registry of a virtual machine, you can find there a lot of all sorts of interesting keys that are specific only to virtual machines.
And fourthly, some manufacturers specifically leave opportunities to detect their products.

As for the general signs of the presence of a virtual machine, proposed at one time by Mrs. Rutkovskaya (the characteristic arrangement of the IDT, GDT and LDT tables, as well as the time it takes to perform operations by the processor), at the moment all these signs are difficult to analyze and reduce to any general the denominator, mainly due to the multicore and multi-facetedness of modern processors.

We analyze equipment
Let's start with the hard drive. If you look at the identifier of the hard disk in the device manager on a virtual machine, then you can see interesting lines in its composition:
Code:
DiskVirtual for VirtualPC DiskVBOX_HARDDISK for Virtual Box Prod_VMware_Virtual for VMware Workstation

The easiest way to find out the name of the hard disk is to read the value of the key named "0" in the HKLMHARDWARESYSTEMCurrentControlSetServicesDiskEnum registry key.
This place lists all disk drives in the system, and the first, just in the key named "0", will be the disk from which the system was booted.

I think you know how to read the register. First, we use the RegOpenKeyEx API to open the required key, then we read the value using RegQueryValueEx. It should look something like this:
Code:
... // Open the required registry key RegOpenKeyExA (HKEY_LOCAL_MACHINE, "HARDWARE \ SYSTEM \ CurrentControlSet \ Services \ Disk \ Enum", 0, KEY_QUERY_VALUE, & rKey); // Read the value of RegQueryValueExA (rKey, "0", NULL, & Type, (LPBYTE) RegKey, & RegPath); // Close everything that we opened earlier RegCloseKey (rKey); ...

Then everything is simple - we use strstr to find the strings we need in the read value and, depending on the comparison result, we draw a conclusion. The BIOS version is contained in the "SystemProductName" key in the HKLMHARDWAREDESCRIPTIONSystemBIOS branch. For example, for VMware there will be a line "VMware Virtual Platform", and for VirtualBox - "VBOX -1".

You can read this all using the same APIs - RegOpenKeyEx and RegQueryValueEx.

Video adapter data can be seen in HKLMSystemCarrentControlSetEnumPCI. This thread lists everything that is connected to the PCI bus, including the video card. For VirtualPC, this is a line like VEN_5333 & DEV_8811 & SUBSYS_00000000 & REV_00, which defines the S3 Trio 32/64 video adapter emulated by a Microsoft virtual machine - you can't find such equipment on real hardware today with fire (and I had one at the end of the last century. - Ed.). For VirtualBox, the video card is described by the sequence VEN_80EE & DEV_BEEF & SUBSYS_00000000 & REV_00, which stands for "VirtualBox Display", and for Parallels Workstation - the line VEN_1AB8 & DEV_4005 & SUBSYS_04001AB8 & REV_00 defines the "Parallels Display" video adapter.

In addition, in VirtualBox you can find the line VEN_80EE & DEV_CAFE & SUBSYS_00000000 & REV_00, which defines a certain "VirtualBox Device", while in Parallels Workstation, the lines VEN_1AB8 & DEV_4000 & SUBSYS_04001AB8 & REV_00 and VEN_1AB8 & DEV_4000406

The algorithm of actions is as follows: we try to open the key we need, and if it opens successfully, then the equipment described by this key is available and we can conclude that a virtual machine is present:
Code:
... if (RegOpenKeyEx (HKEY_LOCAL_MACHINE, L "SYSTEM \ CurrentControlSet \ Enum \ PCI \ VEN_5333 & DEV_8811 & SUBSYS_00000000 & REV_00", 0, KEY_QUERY_VALUE, & rKey) == ERROR_SUCCESS) {RegKeyClose); // We're under VirtualPC return true; } ...

The processor ID is determined using the cpuid command. Thanks to it, you can get a lot of any useful information about the installed processor. The type of information issued by this command depends on the contents of the EAX register. The result of the command is written to registers EBX, ECX and EDX. You can read more about this command in any book on assembly programming.

For our purposes, we will use this instruction, having previously put the value 0x40000000 in the EAX register:
Code:
... _asm { mov eax, 0x40000000 cpuid mov ID_1, ebx mov ID_2, ecx mov ID_3, edx } ...
After executing this code on VMware Workstation, the variables ID_1, ID_2, and ID_3 will contain the values 0x61774d56, 0x4d566572 and 0x65726177, respectively (in symbolic representation, this is nothing more than "VMwareVMware"), on VirtualBox ID_1 and ID_2 will contain the value 0x00000340, and on Parallels Workstation in ID_1 0x70726c20, in ID_2 - 0x68797065 and in ID_3 - 0x72762020 (which corresponds to the line "prl hyperv").

Using the MAC address to identify the manufacturer of the network card is, of course, not the most reliable way (because the MAC address is quite easy to change), but nevertheless it can be used to detect virtual machines as an additional check.

You probably know that the first three bytes of the MAC address of a network card identify its manufacturer. Virtual machine manufacturers are no exception in this regard:

Code:
VMware (VMware Workstation) 00:05:69 00:0c:29 00:1c:14 00:50:56 Microsoft (Virtual PC) 00:03:ff 00:0d:3a 00:50:f2 7c:1e:52 00:12:5a 00:15:5d 00:17:fa 28:18:78 7c:ed:8d 00:1d:d8 00:22:48 00:25:ae 60:45:bd Dc:b4:c4 Oracle (VirtualBox) 08:00:20 Parallels (Parallels Workstation) 00:1c:42

The GetAdaptersInfo API function will help us to extract these first three bytes from the MAC address:
Code:
// We connect the lib, which // contains the function we need #include <iphlpapi.h> #pragma comment (lib, "IPHLPAPI.lib") ... // Determine the size of the buffer for the data // returned by the GetAdaptersInfo function (AdapterInfo , & OutBufLen); // Allocate memory for adapter data AdapterInfo = (PIP_ADAPTER_INFO) new (char [OutBufLen]); // Get information about the adapter GetAdaptersInfo (AdapterInfo, & OutBufLen); // Compare the first three bytes of the MAC address // with 00: 1c: 42 (Parallels Workstation) if (((BYTE) AdapterInfo-> Address [0] == 0x00) && ((BYTE) AdapterInfo-> Address [1] == 0x1c) && ((BYTE) AdapterInfo-> Address [2] == 0x42)) {delete (AdapterInfo); // We're under Parallels Workstation return true; } else {delete (AdapterInfo); return false; } ...

Helper processes, windows and other "suspicious" objects
For normal operation, almost all virtual machines require the installation of add-ons to the guest operating system, such as VBoxGuestAddition for VirtualBox or Parallels Tools for Parallels Workstation. Without these add-ons, working with a virtual machine is somewhat difficult (neither you have a normal screen resolution and full screen mode, nor interact with USB devices, nor normal network connection settings). In general, all virtual machine manufacturers do not recommend using them without these add-ons. And these very additions leave a very noticeable mark in the form of running processes:
Code:
VirtualBox VBoxTray.exe VBoxService.exe Parallels Workstation prl_cc.exe prl_tools.exe SharedIntApp.exe Virtual PC vmusrvc.exe vmsrvc.exe VMware Workstation vmtoolsd.exe

To find a process by name, we'll use the CreateToolhelp32Snapshot, Process32First, and Process32Next functions:
Code:
#include <Tlhelp32.h> ... ... // For example, looking for the vmtoolsd.exe process wchar_t VMwareProcessName [] = {L "vmtoolsd.exe"}; PROCESSENTRY32 pe; HANDLE hSnapShot; hSnapShot = CreateToolhelp32Snapshot (TH32CS_SNAPPROCESS, 0); ZeroMemory (& pe, sizeof (PROCESSENTRY32W)); pe.dwSize = sizeof (PROCESSENTRY32W); Process32First (hSnapShot, & pe); do {if (memcmp (pe.szExeFile, VMwareProcessName, 24) == 0) // We're under VMware return true; } while (Process32Next (hSnapShot, & pe));

In addition to the processes themselves, the windows opened by these processes can become an unmasking feature. There can be quite a lot of windows in each of the considered virtual machines, and we will not list all of them, but will limit ourselves to one or two. So:

VirtualBox VBoxTrayToolWndClass Parallels Workstation CPInterceptor DesktopUtilites Virtual PC {0843FD01-1D28-44a3-B11D-E3A93A85EA96} VMware Workstation VMSwitchUserControlClass

Finding a window by class name is very easy - there is the FindWindow function for this:
Code:
... // For example, looking for a window for VMware HWND VMwareWindow = FindWindowA ("VMSwitchUserControlClass", NULL); if (VMwareWindow! = NULL) // We Are Under VMware Workstation return true; ...

In addition to processes and windows indicating the presence of a VM, you can find other "suspicious" objects - for example, if you dig into the guest OS of a virtual machine using the WinObj utility or some similar utility, you can find the following objects:
Code:
VirtualBox DeviceVBoxMiniRdrDN DeviceVBoxGuest Parallels Workstation Deviceprl_pv Deviceprl_tg Deviceprl_time DevicePrlMemDev DevicePrlMemDevPci DevicePrlMemDev Virtual PC DeviceVirtualMachineServices

It is very easy to check for a "suspicious" object, just try to open it using CreateFile:
Code:
... // For example, check VirtualBox if ((CreateFile (L "\\. \ VBoxMiniRdrDN", 0,0,0, OPEN_EXISTING, 0,0)! = INVALID_HANDLE_VALUE) || (CreateFile (L "\\. \ VBoxGuest ", 0,0,0, OPEN_EXISTING, 0,0)! = INVALID_HANDLE_VALUE)) // We're under VirtualBox return true; ...

What else is “suspicious” in the registry?
In addition to signs of specific hardware, you can see other traces left by virtual machines in the registry. Some of them are based in the HKLMHARDWAREACPIDSDT branch. It is enough to check for the presence of such keys in this place:
Code:
VirtualBox VBOX__ Parallels Workstation PRLS__ Virtual PC AMIBI VMware Workstation PTLTD__

We carry out the check in the same way as we checked the availability of certain equipment. We just try to open the key we need and, if successful, we conclude that there is a VM.

Opportunities provided by the manufacturer
Some vendors (notably VMware and Microsoft) specifically implement their product management capabilities that can be used for our purposes.

Virtual PC uses disabled (not “disabled”, but “alternatively gifted.” And actually they are “invalid.” - Ed.) Processor commands with opcodes 0x0F, 0x3F, 0x07 and 0x0B, an attempt to execute which on a real processor will throw an exception, while on Virtual PC everything goes fine. Using these commands, you can easily detect a virtual machine from Microsoft:
Code:
... __try { __asm { xor ebx, ebx mov eax, 1 __emit(0x0F) __emit(0x3F) __emit(0x07) __emit(0x0B) } // Мы под Virtual PC return true; } __except(EXCEPTION_EXECUTE_HANDLER)  return false; ...

In VMware Workstation, a small backdoor is implemented in the form of port number 0x5658 for interaction between the guest and the main OS. To use it, put the "magic" number 0x564d5868 in EAX (in symbolic representation - "VMXh"), and in ECX write one of the commands for interaction between the guest and the host OS (for example, the command 0x0A returns the version of the installed VMware Workstation). In short, it all looks like this:
Code:
... __try { __asm { mov eax, 0x564d5868 mov ecx, 0x0A mov edx, 0x5658 in eax, dx  } // Мы под VMware return true; } __except(EXCEPTION_EXECUTE_HANDLER)  return false; ...

Conclusion
As you can see, there are plenty of signs characteristic of virtual machines, and in order to see them, you don't need to dig very deeply at all.

WWW
https://carder.market/resources/threats-to-virtual-environments.152/ - a very good article about virtual machine detection. Its only drawback is that it is in English.
 

CreedX

Unknown
Messages
233
Reputation
4
Reaction score
226
Points
43
A lot can be detected when using a VM

This is how a websites detect VM
I program in javascript and i have work on some companies project in the past, WebGL was used to detect VM. WebGL can provide a lot of information about the OpenGL implementation including vendor information
This is how it implemented:
JavaScript:
var canvas = document.createElement('canvas');
var gl = canvas.getContext('webgl');

var debugInfo = gl.getExtension('WEBGL_debug_renderer_info');
var vendor = gl.getParameter(debugInfo.UNMASKED_VENDOR_WEBGL);
var renderer = gl.getParameter(debugInfo.UNMASKED_RENDERER_WEBGL);

console.log(vendor);
console.log(renderer);
This is the information been gotten
VirtualBox-VM-Win10-Chrome.png

Now, it is important to note that this depends on how the VM is configured. In Virtual Box for example, setting the graphics controller setting under Display to VMSVGA will report cause WebGL to use CPU based implementations of OpenGL which is browser dependent. However, this could still be a useful indicator that the client machine is running in a VM because most modern hardware has integrated GPUs and can provide access to OpenGL natively. Just keep in mind that CPU based OpenGL implementations do not necessarily mean it is a VM outright.
1620901711400.png

So you can change all parameter and set the VM well as not to detect but you need lot of time and expereience.
 

Robot999

BANNED
Messages
55
Reputation
0
Reaction score
20
Points
8
Please note, if you want to make a deal with this user, that it is blocked.
A lot can be detected when using a VM

This is how a websites detect VM
I program in javascript and i have work on some companies project in the past, WebGL was used to detect VM. WebGL can provide a lot of information about the OpenGL implementation including vendor information
This is how it implemented:
JavaScript:
var canvas = document.createElement('canvas');
var gl = canvas.getContext('webgl');

var debugInfo = gl.getExtension('WEBGL_debug_renderer_info');
var vendor = gl.getParameter(debugInfo.UNMASKED_VENDOR_WEBGL);
var renderer = gl.getParameter(debugInfo.UNMASKED_RENDERER_WEBGL);

console.log(vendor);
console.log(renderer);
This is the information been gotten
View attachment 2720
Now, it is important to note that this depends on how the VM is configured. In Virtual Box for example, setting the graphics controller setting under Display to VMSVGA will report cause WebGL to use CPU based implementations of OpenGL which is browser dependent. However, this could still be a useful indicator that the client machine is running in a VM because most modern hardware has integrated GPUs and can provide access to OpenGL natively. Just keep in mind that CPU based OpenGL implementations do not necessarily mean it is a VM outright.
View attachment 2723
So you can change all parameter and set the VM well as not to detect but you need lot of time and expereience.
I never knew this was possible i read this article on setting VM:
This is so nice to know about.
Please can you write article on hiding traces that can expose VM through WebGL.
 

Singular

Member
Messages
25
Reputation
0
Reaction score
5
Points
3
Hello, master hacker

Several virtual machines have virtual identification in hardware detection, but now there are some virtual machines that claim to remove virtual identification

Is it credible? Can they remove the virtualization identity of virtual machines?
 
Top