Как определить виртуальная машина или нет windows

8 ответов

gwmi -q "select * from win32_computersystem"

Domain:   ...
Manufacturer: Microsoft Corporation
Model: Virtual Machine
Name : .....
....

System Manufacturer:       Microsoft Corporation    
System Model:              Virtual Machine    
System Type:               x64-based PC

System Manufacturer:       HP
System Model:              ProLiant BL460c G6
System Type:               x64-based PC

FOR /F "tokens=*" %a IN ('wmic bios get bioscharacteristics^|find /c "33"') DO set USBlegacy=%a

FOR /F "tokens=*" %a IN ('wmic path win32_pnpentity get ^|find /c "ACPI Fan"') DO set ACPIfan=%a

Одним жуть каким прохладным январским утром от знакомого прилетел вопрос — как на C# определить, не запущена ли программа в ОС (оконное приложение в ОС Windows 7 или новее) на виртуальной машине.

Требования к такому детектору были достаточно жёсткими:

1. Должен быть полностью в исходных кодах,
2. Должен собираться с помощью Visual Studio,
3. Должен работать из-под аккаунта непривилегированного пользователя (нельзя использовать методы, требующие, к примеру, установки драйверов устройств, или иных операций, для которых нужны права администратора),
4. Разрешено использовать .NET Framework 4.5 и никаких лишних зависимостей (типа Visual C++ Redistributable Package).

Под катом описание реализованного детектора на C# (в следующей части — с некоторыми элементами C++) и приличным количеством неприличного кода с использованием Visual Studio 2015 Community.

Структура публикации

• 1 уровень. Изучение матчасти и простейших существующих решений:
  • немного теории касательно виртуализации,
  • реализация проверки ВМ с помощью данных из Windows Management Instrumentation (WMI).
• 2 уровень. Поиск статей и публикаций про детектирование запуска в виртуальных машинах:
  • допиливаем реализацию с WMI,
  • работа с инструкцией CPUID.
• 3 уровень. Поиск материалов с хакерских конференций:
  • допиливаем работу с CPUID,
  • делаем сводную таблицу параметров и результатов тестирования.

1 уровень. Изучение матчасти и существующих решений

Немного теории касательно виртуализации

Прежде, чем пытаться писать детектор сферического коня в вакууме виртуальной машины, следует кратко обозначить, как в рамках задачи мы понимаем термин «виртуальная машина».

Понятие виртуализации можно поделить на две категории (1):

• Первая — виртуализация ресурсов. Рассмотрим на живом примере, почему принцип работы сервиса хранения файлов Dropbox можно трактовать как виртуализацию ресурсов:
  1. Мы точно знаем, как загружать/выгружать файлы, и как взаимодействовать с сервисом, но как это всё работает внутри мы с уверенностью сказать не можем => инкапсуляция.
  2. У каждого пользователя есть свой уникальный аккаунт, у каждого аккаунта установлена квота на размер сохраняемых файлов, для каждого аккаунта можно настраивать разрешения на доступ индивидуально (хотя по факту данные разных пользователей вполне могут храниться на одном и том же носителе информации) => разделение ресурсов.
  3. Скорее всего, под капотом Dropbox находится не один и не два компьютера, а как минимум пара сотен серверов, функционирующих и обрабатывающих команды от клиентов в рамках системы Dropbox как единое целое => кластеризация.
• Вторая — виртуализация платформ — создание программных систем на основе существующих аппаратно-программных комплексов, зависящих или независящих от них (1).

Во второй категории сразу введём два термина: система, предоставляющая аппаратные ресурсы и ПО для виртуализации (хостовая система, host) и эмулируемая система (гостевая система, guest).

При этом в реальности в роли «гостевой системы» могут выступать:

1. Абсолютно всё аппаратное и программное обеспечение эмулируемой системы — такой тип виртуализации называется полной эмуляцией или симуляцией. Примеры программ, обеспечивающих такой тип виртуализации: Bochs, QEMU.
2. Всё программное обеспечение и только часть аппаратного (часть достаточная для обеспечения изоляции гостевой системы) — такой тип виртуализации назовём частичной эмуляцией или нативной виртуализацией. Примеры программ, обеспечивающих такой тип виртуализации: VMWare Workstation, VMWare ESXi, Microsoft Hyper-V, Oracle VirtualBox.
3. Также существуют частичная виртуализация, паравиртуализация, виртуализация уровня операционной системы и виртуализация уровня приложений. Во всех трёх случаях физически ОС у нас одна, а гостевыми системами считаются либо отдельные процессы, либо отдельные группы процессов (например, user-mode процессы).

Итог сего экскурса: в рамках статьи и создания детектора виртуальной машины нас будут интересовать только нативная виртуализация платформ (то есть проверять мы будем только запуск в окружении Hyper-V, VirtualBox или других программ, использующих нативную виртуализацию). При этом далее термин «виртуальная машина» мы будем трактовать согласно определению с сайта VMWare: «это строго изолированный контейнер ПО, содержащий операционную систему и приложения» (2).

Реализация проверки ВМ с помощью данных из Windows Management Instrumentation (WMI)

После того, как цель (определение факта работы программы в окружении с частичной эмуляцией) была более-менее уточнена, найдём самые известные виртуальные машины этого типа (далее для краткости ВМ) и способы отличить запуск ОС на реальном железе от запуска в окружении этих ВМ.

Прочитав замечательно свёрстанные рекламные страницы разработчиков популярных программ виртуализации, в голове вырисовывается некая общая схема их работы (разумеется схема работы программ, а не разработчиков):

• Есть хостовая ОС. Не ограничивая общности будем считать, что она одна.
• На хостовой ОС установлена программа для обеспечения виртуализации (далее гипервизор).
• Гипервизор предоставляет интерфейс для установки и последующей работы гостевой ОС.

Примечание

: имеют место случаи, когда хостовая ОС и гипервизор есть единое тонкое целое, что позволяет уменьшить расходование ресурсов компьютера по сравнению с использованием хостовой ОС и гипервизора по отдельности (примеры: VMWare ESXi или Windows Hyper-V Server).

Вот только на практике почти в каждом гипервизоре имеется возможность установить «гостевые дополнения» (guest additions) — специальный набор программ и драйверов, дающих гипервизору
расширенный контроль за функциями гостевой ОС (проверка, а не зависла ли гостевая ОС, динамическое изменение доступной ОС оперативной памяти, «общая» мышка для хостовой и гостевой ОС). Однако, как же реализуют такое действо, если, согласно рекламе, «ВМ — это строго изолированный контейнер ПО»?

Получается, что гостевые дополнения, устанавливаемые на гостевую ОС, каким-то строго определённым образом взаимодействуют напрямую с гипервизором, запущенным в хостовой ОС. То есть если программа определения ВМ сможет воспользоваться таким взаимодействием — она докажет, что ОС запущена на ВМ! Правда, по условиям задачи доказательство надо проводить из-под User-Mode без использования собственных драйверов…

Сразу вырисовываются следующие места для проверки:

• Поиск определённого оборудования в системе, которого на физической машине просто не может быть.
• Поиск аппаратных интерфейсов, которые реализованы только в ВМ (или наоборот, только на физической машине).

Собственно, если ввести в поисковой строке «detect hyper-v C#» или «detect vmware C#», примерно на это и натыкаешься, осталось только обобщить.

Наиболее полное описание различных критериев проверки было найдено в статье 2013 года в журнале Хакер (3),— возьмём статью за основу. А для получения соответствующих данных об оборудовании и процессах ОС воспользуемся механизмом Windows Management Instrumentation (WMI) — дословно «инструментарием управления Windows». В частности, через WMI можно несложно, быстро и без прав администратора получить большое количество информации об оборудовании, которое видит ОС.

Для получения данных через WMI нам понадобится построить запрос на языке WQL (WMI Query Language), который по сути является сильно упрощённым SQL. Например, если мы хотим получить через WMI имеющуюся в ОС информацию о процессорах, требуется выполнить следующий запрос:

SELECT * FROM Win32_Processor

Ответ на этот запрос — набор объектов типа Win32_Processor с заранее известными названиями полей (подробный список доступных полей и классов см. в 4). Разумеется, если нам не требуются все-все поля, вместо * можно перечислить через запятую только необходимые. В WQL-операторе SELECT, по аналогии с SQL, также поддерживается условие WHERE, позволяющее делать выборку только по объектам, значения в полях которых удовлетворяют указанным условиям.

Для «затравки» научимся получать следующие данные из WMI-объектов следующих типов (данные и ожидаемые в ВМ значения взяты из 3):

Реализуем получение данных об оборудовании через WMI в отдельном проекте в виде библиотеки TTC.Utils.Environment.

Структурируем проект следующим образом:

1. Entities — объекты с данными (сущности), полученными от WMI.
2. Services — сервисы; например, служба, инкапсулирующая взаимодействие с WMI-обёрткой .NET.
3. Interfaces — интерфейсы; например, интерфейс сервиса работы с WMI.
4. Queries — объекты, содержащие параметры запросов к WMI, с помощью которых извлекаются заданные типы сущностей.

Хочется, чтобы пользователь данной библиотеки мог написать примерно такой код:

var bios = wmiService.QueryFirst<WmiBios>(new WmiBiosQuery());
var processors = wmiService.QueryAll<WmiProcessor>(new WmiProcessorQuery());

и не волновался по поводу механизма взаимодействия с WMI, построения запроса или преобразования ответа в строго типизированный класс языка C#.

Что ж, реализовать такое на самом деле не очень сложно.

Сначала подключим к проекту ссылку на библиотеку System.Management (именно в ней находятся классы .NET для доступа к WMI). Далее опишем интерфейс сервиса IWmiService (реализация этого интерфейса будет извлекать данные и преобразовывать их в строго типизированные объекты):

/// <summary>
/// Интерфейс сервиса получения данных Windows Management Instrumentation (WMI).
/// </summary>
public interface IWmiService
{
    /// <summary>
    /// Получение первой записи из указанного запроса к WMI.
    /// </summary>
    /// <typeparam name="TResult">Тип сущности, в которую выгружаются результаты запроса.</typeparam>
    /// <param name="wmiQuery">Объект, содержащий параметры WMI-запроса.</param>
    /// <returns>Сущность с результатами запроса.</returns>
    TResult QueryFirst<TResult>(WmiQueryBase wmiQuery)
        where TResult : class, new();

    /// <summary>
    /// Получение набора записей из указанного запроса к WMI.
    /// </summary>
    /// <typeparam name="TResult">Тип сущности, в которую выгружаются результаты запроса.</typeparam>
    /// <param name="wmiQuery">Объект, содержащий параметры WMI-запроса.</param>
    /// <returns>Коллекция сущностей с результатами запроса.</returns>
    IReadOnlyCollection<TResult> QueryAll<TResult>(WmiQueryBase wmiQuery)
        where TResult : class, new();
}

Теперь установим как будут выглядеть сущности в нашем проекте. Предположим для детектирования нам потребуются следующие поля из WMI-объектов типа Win32_BaseBoard:

public class WmiBaseBoard
{
    public string Manufacturer { get; private set; }

    public string Product { get; private set; }

    public string SerialNumber { get; private set; }
}

В идеале надо писать DTO, чтобы с его помощью транслировать данные из результата WML-запроса в вышеуказанную сущность, но если постулировать, что свойства сущностей в проекте будут 1 к 1 соответствовать полям объектов из результатов WML-запроса, то делать DTO на каждую сущность значит писать достаточно много однообразного кода.

/// <summary>
/// Указание, какому свойству сущности соответствует поле объекта WMI.
/// </summary>
[AttributeUsage(AttributeTargets.Property)]
public class WmiResultAttribute : Attribute
{
    public WmiResultAttribute(string propertyName)
    {
        PropertyName = propertyName;
    }

    /// <summary>
    /// Имя поля в объекте WMI.
    /// </summary>
    public string PropertyName { get; }
}

Разметив свойства сущности указанными атрибутами, получим:

public class WmiBaseBoard
{
    internal const string MANUFACTURER = "Manufacturer";
    internal const string PRODUCT = "Product";
    internal const string SERIAL_NUMBER = "SerialNumber";

    // ReSharper disable UnusedAutoPropertyAccessor.Local
    [WmiResult(MANUFACTURER)]
    public string Manufacturer { get; private set; }

    [WmiResult(PRODUCT)]
    public string Product { get; private set; }

    [WmiResult(SERIAL_NUMBER)]
    public string SerialNumber { get; private set; }
    // ReSharper restore UnusedAutoPropertyAccessor.Local
}

Осталось разобраться с объектом, который будет хранить запрос. Уверен, вы обратили внимание, что в предыдущем примере кода названия полей WQL-результатов запроса вынесены в internal-константы. Это было сделано специально чтобы не дублировать их в классе запроса. Кстати, получился интересный побочный эффект — с использованием такой модели вы не сможете прочесть из WMI данные поля некоторого WMI-объекта пока не укажете, в какое свойство какой сущности он должен извлекаться.

using System.Management;
/// <summary>
/// Базовый класс данных параметров запроса к WMI.
/// </summary>
public class WmiQueryBase
{
    private readonly SelectQuery _selectQuery;

    /// <summary>
    /// Конструктор запроса к WMI.
    /// </summary>
    /// <param name="className">Название таблицы, к которой производится запрос.</param>
    /// <param name="condition">Условие запроса.</param>
    /// <param name="selectedProperties">Результирующие столбцы запроса.</param>
    protected WmiQueryBase(string className, 
        string condition = null, string[] selectedProperties = null)
    {
        _selectQuery = new SelectQuery(className, condition, selectedProperties);
    }

    /// <summary>
    /// Объект со сформированным SELECT-запросом к WMI.
    /// </summary>
    internal SelectQuery SelectQuery
    {
        get { return _selectQuery; }
    }
}

using TTC.Utils.Environment.Entities;
public class WmiBaseBoardQuery : WmiQueryBase
{
    public WmiBiosQuery()
        : base("Win32_BaseBoard", null, new[]
        {
            WmiBios.MANUFACTURER,
            WmiBios.PRODUCT,
            WmiBios.SERIAL_NUMBER,
        })
    {
    }
}

При такой структуре классов *Query есть только одна неприятность: неудобно формировать параметры WHERE-части WML-запроса внутри класса. Приходится действовать по старинке и ручками формировать строку в зависимости от параметров:

using System.Text;
using TTC.Utils.Environment.Entities;
public class WmiNetworkAdapterQuery : WmiQueryBase
{
    private static readonly string[] COLUMN_NAMES =
        {
            WmiNetworkAdapter.GUID,
            WmiNetworkAdapter.MAC_ADDRESS,
            WmiNetworkAdapter.PNP_DEVICE_ID,
        };

    public WmiNetworkAdapterQuery(WmiNetworkAdapterType adapterType = WmiNetworkAdapterType.All)
        : base("Win32_NetworkAdapter", null, COLUMN_NAMES)
    {
        if (adapterType == WmiNetworkAdapterType.Physical)
            SelectQuery.Condition = "PhysicalAdapter=1";
        else if (adapterType == WmiNetworkAdapterType.Virtual)
            SelectQuery.Condition = "PhysicalAdapter=0";
    }
}

Хорошо: данные по сущностям раскидали, запросы писать с грехом-пополам научились, осталось только разобраться как будет выглядеть сервис, работающий с указанными классами:

/// <summary>
/// Сервис получения данных Windows Management Instrumentation (WMI).
/// </summary>
public class WmiService : IWmiService
{
    /// <summary>
    /// Извлечение заданных в запросе столбцов из полученных записей WMI с приведением типов.
    /// </summary>
    /// <typeparam name="TResult">Тип сущности, в которую выгружаются результаты запроса.</typeparam>
    /// <param name="managementObject">Объект, полученный в результате запроса WMI.</param>
    /// <returns>Сущность с результатами запроса.</returns>
    private static TResult Extract<TResult>(ManagementBaseObject managementObject)
        where TResult : class, new()
    {
        var result = new TResult();
        foreach (var property in typeof(TResult).GetProperties())
        {
            var wmiAttribute = (WmiResultAttribute)Attribute.GetCustomAttribute(property, typeof(WmiResultAttribute));
            if (wmiAttribute != null)
            {
                var sourceValue = managementObject.Properties[wmiAttribute.PropertyName].Value;
                var targetType = Nullable.GetUnderlyingType(property.PropertyType) ?? property.PropertyType;
                object targetValue;
                if (sourceValue == null)
                {
                    targetValue = null;
                }
                else if (targetType == typeof(DateTime))
                {
                    targetValue = ManagementDateTimeConverter.ToDateTime(sourceValue.ToString()).ToUniversalTime();
                }
                else if (targetType == typeof(Guid))
                {
                    targetValue = Guid.Parse(sourceValue.ToString());
                }
                else
                {
                    targetValue = Convert.ChangeType(
                        managementObject.Properties[wmiAttribute.PropertyName].Value, targetType);
                }
                property.SetValue(result, targetValue);
            }
        }
        return result;
    }

    /// <summary>
    /// Получение набора данных из указанного запроса к WMI.
    /// </summary>
    /// <param name="selectQuery">Запрос для получения данных.</param>
    /// <param name="searcher">Существующий объект для выполнения запросов к WMI.</param>
    /// <returns>Результирующая коллекция объектов в таблице.</returns>
    private ManagementObjectCollection QueryAll(SelectQuery selectQuery, ManagementObjectSearcher searcher = null)
    {
        searcher = searcher ?? new ManagementObjectSearcher();
        searcher.Query = selectQuery;
        return searcher.Get();
    }

    /// <summary>
    /// Получение первой строки данных из указанного запроса к WMI.
    /// </summary>
    /// <param name="selectQuery">Запрос для получения данных.</param>
    /// <param name="searcher">Существующий объект для выполнения запросов к WMI.</param>
    /// <returns>Результирующая коллекция объектов в таблице.</returns>
    private ManagementBaseObject QueryFirst(SelectQuery selectQuery, ManagementObjectSearcher searcher = null)
    {
        return QueryAll(selectQuery, searcher).Cast<ManagementBaseObject>().FirstOrDefault();
    }

    public TResult QueryFirst<TResult>(WmiQueryBase wmiQuery)
        where TResult : class, new()
    {
        var managementObject = QueryFirst(wmiQuery.SelectQuery);
        return managementObject == null ? null : Extract<TResult>(managementObject);
    }

    public IReadOnlyCollection<TResult> QueryAll<TResult>(WmiQueryBase wmiQuery)
        where TResult : class, new()
    {
        var managementObjects = QueryAll(wmiQuery.SelectQuery);
        return managementObjects?.Cast<ManagementBaseObject>()
            .Select(Extract<TResult>)
            .ToList();
    }
}

Кстати, было бы ещё лучше разделить Extract на два метода: первый извлекает информацию из типа класса, второй заполняет экземпляры (иначе метод QueryAll для второго и последующих элементов выходной коллекции делает ненужную работу по повторному изучению структуры его типа). Но конкретно для целей детектирования виртуалки мы вряд ли будет ожидать более 10 объектов за один запрос, поэтому предлагаю списать эту задачу с пометкой «не реализовано, ибо природная лень». Но если у кого-то дойдут руки до такой модификации — с радостью приму вашу доработку.

Послесловие

Чтобы не заканчивать эту часть статьи только библиотекой, сделаем самое простое приложение, использующее возможности данной библиотеки для детектирования нескольких самых популярных виртуальных машин фирм VMWare, Microsoft, Parallels и Oracle на осове вышеизложенных критериев.

Создадим отдельный проект — консольное приложение TTC.Utils.VMDetect и создадим в нём такой класс DemoTrivialVmDetector:

/// <summary>
/// Тестовый класс для проверки запуска из-под ВМ.
/// </summary>
class DemoTrivialVmDetector
{
    private readonly IWmiService _wmiService;

    public DemoTrivialVmDetector(IWmiService wmiService)
    {
        _wmiService = wmiService;
    }

    public MachineType GetMachineType()
    {
        var wmiProcessor = _wmiService.QueryFirst<WmiProcessor>(new WmiProcessorQuery());
        if (wmiProcessor.Manufacturer != null)
        {
            if (wmiProcessor.Manufacturer.Contains("VBoxVBoxVBox"))
                return MachineType.VirtualBox;
            if (wmiProcessor.Manufacturer.Contains("VMwareVMware"))
                return MachineType.VMWare;
            if (wmiProcessor.Manufacturer.Contains("prl hyperv"))
                return MachineType.Parallels;
        }

        var wmiBaseBoard = _wmiService.QueryFirst<WmiBaseBoard>(new WmiBaseBoardQuery());
        if (wmiBaseBoard.Manufacturer != null)
        {
            if (wmiBaseBoard.Manufacturer.Contains("Microsoft Corporation"))
                return MachineType.HyperV;
        }

        var wmiDiskDrives = _wmiService.QueryAll<WmiDiskDrive>(new WmiDiskDriveQuery());
        if (wmiDiskDrives != null)
            foreach (var wmiDiskDrive in wmiDiskDrives)
            {
                if (wmiDiskDrive.PnpDeviceId.Contains("VBOX_HARDDISK"))
                    return MachineType.VirtualBox;
                if (wmiDiskDrive.PnpDeviceId.Contains("VEN_VMWARE"))
                    return MachineType.VMWare;
            }

        return MachineType.Unknown;
    }
}

Весь код, включая библиотеку и простейшее тестовое приложение, выложен в репозитории на github, отзывы и комментарии приветствуются.

В следующей части мы чутка структурируем работу с известными ВМ и с помощью ассемблерной инструкции CPUID попробуем детектировать уже неизвестные ВМ.

Источники

1. Виртуализация: новый подход к построению IT-инфраструктуры
2. Виртуализация при помощи VMWare
3. Детектим виртуалки (xakep.ru)
4. WMI: Win32 Provider (MSDN)

12 ответов:

Unfortunately there is not an unique answer. Each virtual machine has a sort of bridge you can use but you have to write specific checks for each VM you want to detect (examples are VC++ specific but you can easily adapt them to your compiler). Note that in theory you should not be able to determine if you’re running under a VM or not.

VMWare

VMWare uses IN instruction to handle guest to host communication. Normally this instruction is not available in user-mode and it throws an exception but VM handles it. If we catch the exception then we know we are not running under VMWare (or we are privileges to execute IN instruction). Second test to determine if we have privileges or we are running under WMWare is almost useless but that’s standard detect code and I write it here for completeness (we just check for an expected string VMXh in EBX register, note we had to initialize some registers with required values.)

bool IsRunningInsideVmWare()
{
    bool flag = true;

    __try
    {
        __asm
        {
            push    edx
            push    ecx
            push    ebx

            mov     eax, 'VMXh'
            mov     ebx, 0
            mov     ecx, 10
            mov     edx, 'VX'

            in      eax, dx
            cmp     ebx, 'VMXh'
            setz    [flag]

            pop     ebx
            pop     ecx
            pop     edx
        }
    }
    __except(EXCEPTION_EXECUTE_HANDLER)
    {
        flag = false;
    }

    return flag;
}

Virtual PC

Guests can use a non-existing instruction 0f3f070b to communicate with host, what you can do is then emit such instruction, VM will correctly interpret it but physical CPUs will throw an exception (which you can catch and jump over offending instruction). In this example we set EBX to a known value in the exception handler and then we can detect this scenario.

DWORD __forceinline VpcExceptionFilter(LPEXCEPTION_POINTERS ep)
{
    ep->ContextRecord->ctx->Ebx = -1;
    ep->ContextRecord->ctx->Eip += 4;

    return EXCEPTION_CONTINUE_EXECUTION;
}

bool IsRunningInsideVpc()
{
    bool flag = false;

    __try
    {
        _asm
        {
            push    ebx

            mov     eax, 1
            mov     ebx, 0 

            __emit  0Fh
            __emit  3Fh
            __emit  07h
            __emit  0Bh

            test    ebx, ebx
            setz    [flag]

            pop     ebx
        }
    }
    __except(VpcExceptionFilter(GetExceptionInformation()))
    {
    }

    return flag;
}

VirtualBox

To detect VirtualBox is extremely simple, you just need to check if a pseudo-device \.VBoxMiniRdrDN exists:

bool IsRunningInsideVirtualBox()
{
    HANDLE handle = CreateFile("\\.\VBoxMiniRdrDN", GENERIC_READ, FILE_SHARE_READ, 
        NULL, OPEN_EXISTING, FILE_ATTRIBUTE_NORMAL, NULL);

    if (handle != INVALID_HANDLE_VALUE)
    {
        CloseHandle(handle);
        return true;
    }

    return false;
}

Something little bit more generic can be done (assumption: you’re running on Windows) using WMI and the following queries:

• In Win32_BaseBoard matchName against (?i)(Hyper-V|Virtual Machine|Microsoft|VMware|VirtualBox|Parallels Virtual).
• In Win32_ComputerSystem match Model and Manufacturer against (?i)(Hyper-V|Virtual Machine|VMware|VirtualBox).
• In Win32_VideoController match Name against (?i)Hyper-V.

CPUID instructions can also help you (when those values are supported).

With EAX set to 0 (Get vendor ID) you get in EBX, EDX and ECX an ASCII string with CPU vendor name (see Wikipedia for list). Of course a VM can return a false name or it may be an unknown VM.

With EAX set to 1 (Processor Info and Feature Bits) bit 31 of ECX (hypervisor) is set to 1 if you’re running under a VM. Again a VM may return a false result (and some VMs don’t honor this bit).

When I had to play with this issue I tried also to check for hardware tricks/features which are not supported in a VM (for example to USB Legacy support) but I found it’s not reliable enough to be used in production.

In comment you said you’re running on Android. That’s a completely different story but common techniques are similar to what I said about WMI (or a combination of the above). A common way is to check the device name string for well-known emulators, from Android 7 there is a specific flag ro.kernel.qemu.

Can you fake those values? Yes, see for example Is there a way to set ro.kernel.qemu to 0 in a emulator?. Note that any decent application which cares to stop you to use it under emulation will also use multiple detection techniques (see also Android: Get Hardware Information Programmatically).

Unfortunately there is not an unique answer. Each virtual machine has a sort of bridge you can use but you have to write specific checks for each VM you want to detect (examples are VC++ specific but you can easily adapt them to your compiler). Note that in theory you should not be able to determine if you’re running under a VM or not.

VMWare

VMWare uses IN instruction to handle guest to host communication. Normally this instruction is not available in user-mode and it throws an exception but VM handles it. If we catch the exception then we know we are not running under VMWare (or we are privileges to execute IN instruction). Second test to determine if we have privileges or we are running under WMWare is almost useless but that’s standard detect code and I write it here for completeness (we just check for an expected string VMXh in EBX register, note we had to initialize some registers with required values.)

bool IsRunningInsideVmWare()
{
    bool flag = true;

    __try
    {
        __asm
        {
            push    edx
            push    ecx
            push    ebx

            mov     eax, 'VMXh'
            mov     ebx, 0
            mov     ecx, 10
            mov     edx, 'VX'

            in      eax, dx
            cmp     ebx, 'VMXh'
            setz    [flag]

            pop     ebx
            pop     ecx
            pop     edx
        }
    }
    __except(EXCEPTION_EXECUTE_HANDLER)
    {
        flag = false;
    }

    return flag;
}

Virtual PC

Guests can use a non-existing instruction 0f3f070b to communicate with host, what you can do is then emit such instruction, VM will correctly interpret it but physical CPUs will throw an exception (which you can catch and jump over offending instruction). In this example we set EBX to a known value in the exception handler and then we can detect this scenario.

DWORD __forceinline VpcExceptionFilter(LPEXCEPTION_POINTERS ep)
{
    ep->ContextRecord->ctx->Ebx = -1;
    ep->ContextRecord->ctx->Eip += 4;

    return EXCEPTION_CONTINUE_EXECUTION;
}

bool IsRunningInsideVpc()
{
    bool flag = false;

    __try
    {
        _asm
        {
            push    ebx

            mov     eax, 1
            mov     ebx, 0 

            __emit  0Fh
            __emit  3Fh
            __emit  07h
            __emit  0Bh

            test    ebx, ebx
            setz    [flag]

            pop     ebx
        }
    }
    __except(VpcExceptionFilter(GetExceptionInformation()))
    {
    }

    return flag;
}

VirtualBox

To detect VirtualBox is extremely simple, you just need to check if a pseudo-device \.VBoxMiniRdrDN exists:

bool IsRunningInsideVirtualBox()
{
    HANDLE handle = CreateFile("\\.\VBoxMiniRdrDN", GENERIC_READ, FILE_SHARE_READ, 
        NULL, OPEN_EXISTING, FILE_ATTRIBUTE_NORMAL, NULL);

    if (handle != INVALID_HANDLE_VALUE)
    {
        CloseHandle(handle);
        return true;
    }

    return false;
}

Something little bit more generic can be done (assumption: you’re running on Windows) using WMI and the following queries:

• In Win32_BaseBoard matchName against (?i)(Hyper-V|Virtual Machine|Microsoft|VMware|VirtualBox|Parallels Virtual).
• In Win32_ComputerSystem match Model and Manufacturer against (?i)(Hyper-V|Virtual Machine|VMware|VirtualBox).
• In Win32_VideoController match Name against (?i)Hyper-V.

CPUID instructions can also help you (when those values are supported).

With EAX set to 0 (Get vendor ID) you get in EBX, EDX and ECX an ASCII string with CPU vendor name (see Wikipedia for list). Of course a VM can return a false name or it may be an unknown VM.

With EAX set to 1 (Processor Info and Feature Bits) bit 31 of ECX (hypervisor) is set to 1 if you’re running under a VM. Again a VM may return a false result (and some VMs don’t honor this bit).

When I had to play with this issue I tried also to check for hardware tricks/features which are not supported in a VM (for example to USB Legacy support) but I found it’s not reliable enough to be used in production.

In comment you said you’re running on Android. That’s a completely different story but common techniques are similar to what I said about WMI (or a combination of the above). A common way is to check the device name string for well-known emulators, from Android 7 there is a specific flag ro.kernel.qemu.

Can you fake those values? Yes, see for example Is there a way to set ro.kernel.qemu to 0 in a emulator?. Note that any decent application which cares to stop you to use it under emulation will also use multiple detection techniques (see also Android: Get Hardware Information Programmatically).