Разработчики вирусного ПО и просто разработчики, не желающие, чтобы их программу пытались реверсить, на этапе запуска или установки проводят проверки на виртуальную машину, и в случае её обнаружения отказываются работать, а то и вовсе самоликвидируются. Под катом описан способ, как можно попробовать решить эту проблему.
Я использовал VMWare Fusion для Mac, однако с тем же успехом способ работает и в Workstation для Win.
1) Для работы необходима заново установленная система, как внести изменения в уже существующую — не нашёл.
Готовите виртуальный диск, указываете систему, как это обычно делаете, и в настройках к устанавливаемой машине, у меня этот пункт назван Isolation, выключаете любой обмен данными с хостовой ОС.
2) Далее надо найти конфигурационный VMX файл, создаваемый на этапе создания машины в VMWare, и в конец добавить строки:
isolation.tools.getPtrLocation.disable = «TRUE»
isolation.tools.setPtrLocation.disable = «TRUE»
isolation.tools.setVersion.disable = «TRUE»
Как полностью удалить VMware Workstation
isolation.tools.getVersion.disable = «TRUE»
monitor_control.disable_directexec = «TRUE»
monitor_control.disable_chksimd = «TRUE»
monitor_control.disable_ntreloc = «TRUE»
monitor_control.disable_selfmod = «TRUE»
monitor_control.disable_reloc = «TRUE»
monitor_control.disable_btinout = «TRUE»
monitor_control.disable_btmemspace = «TRUE»
monitor_control.disable_btpriv = «TRUE»
monitor_control.disable_btseg = «TRUE»
Эти опции предотвращают детектирование программами виртуального окружения через такие сложные проверки, как отслеживание адресного пространства памяти, счётчиков.
Важно! Если на этапе настройки установки будет опция вроде «Express install», «Быстрая установка» — выключайте их. Также не стоит устанавливать VMWare Tools в установленную систему, т.к. некоторое ПО в проверку включает и наличие этого пакета.
3) Сохраняем файл, указываем для загрузки ISO с установщиком системы, устанавливаем ОС как обычно.
4) Несмотря на то, что подавляющее большинство программ, не любящих виртуальной среды, не заходят дальше проверок, которые мы отсекли на 2 шаге, некоторые особо упорные всё же идут дальше и пытаются искать, к примеру, всё, что похоже на название контроллеров виртуальных дисков.
Чтобы победить и их в Windows, идём в редактор реестра в ветку HKLMSYSTEMCurrentControlSetServicesDiskEnum. Как видите, там есть вполне явная отсылка к тому, что диск — виртуальный.
Нам нужно изменить его, убрав из параметра VMware, Virtual, Ven, итп, и сохранить её так.
Также имеет смысл заменить в реестре поиском по VMware/Virtual на какой-нибудь Intel или IBM всё, что меняется, а не только дисковые переменные.
После пробуйте запускать ваш упрямый объект экспериментов — в процентах 70 случаев описанные шаги помогут пройти проверки на виртуальное окружение.
Как ускорить работу виртуальной машины Vmware, Oracle VirtualBox и Microsoft Hyper-V
Важно! Значение в HKLMSYSTEMCurrentControlSetServicesDiskEnum перезаписывается после каждой перезагрузки, так что его нужно менять после каждого нового запуска системы.
Denisoid написал(а):
Естественно, это не исчерпывающее руководство, некоторое ПО также может пытаться определять виртуальную систему следующими методами:
1) Проверками диапазона MAC адресов (просто подменяется в настройках виртуального сетевого адаптера до запускa виртуальной машины)
2) Через WinAPI опросом конфигурации ОС и прочей системной информации (FirmwareTable)
3) Низкоуровневыми трюками.
Проверить, насколько вы обезопасили себя от обнаружения, а также ознакомиться с другими популярными у разработчиков средствами обнаружения песочниц и виртуалок можно средством Pafish.
Несмотря на то, что остались места, где можно себя выдать, предложенный метод заставляет обхитрить большинство ПО, которое не желает работать в виртуальной среде, в данном случае, в VMWare.
Как видно, улучшить скрытность можно также выделив виртульной машине больше системных ресурсов. Что касается памяти, выбирать стоит значения, кратные 1024.
Спасибо всем, кто осилил статью и помог в дополнении её толковыми комментариями!
Источник: www.safezone.cc
» Проблемы с VMware Workstation (часть 4)
Метоп описаный в шапке решает проблему с определением USB-устройств в хост-системе, но не позволяет испольвовать в этой системе саму программу VMware Workstation.
Т.е. бесполезен для этой конкретной ветки как решение проблем с работой VMware Workstation.
Тогды немлохо бы шапку поправить, а то путает народ
[more] Добрый день,
Просьба помочь разобраться в следующих ситуациях.
Есть Windows 7, и при установки(удалении) независимо какой версии vmware workstation(и 7ая и 9ая), wmware player 3.01 (удаление). Появляется только пустое серое окно.
Очень не хочется систему преустанавливать.
Заранее очень благодарен.
Есть внутренний хард диск для ноутбука Dell 630 с установленной системой Windows XP и некоторым программным обеспечением ( для спец оборудование).
Задача.
Из этого внутреннего хард диска, сделать виртуальную машину готовую к работе.
Примечание.
По ситуации 2, я хотел сделать образ хард диска ноутбука (Acronis True Image), и потом акронисом же восстановить его на виртуальную машину.
Но при восстановлении, на мометне выбора жесткого диска для восстановления, виртуальный жесткий диск почему то невозможно выбрать.
Если идея бестолковая не судити строго, я лишь пользователь.
[more] Возникла проблема:
1 Хостовая ОС Вин 8 перезагрузилась. После чего все виртуалки которые были запущены думают что их уже используют и соответственно запустить их нет никакой возможности. поискал по форуму, но ничего не нашел. Пользуюсь виртуалками не так давно, поэтому с какого боку начать копать проблему вообще ума не приложу.
2 сообщение которое выдается:»Эта виртуальная машина возможно в использовании.
Если виртуальная машина не используется, нажмите кнопку «Сменить владельца», чтобы получить доступ к ней. В противном случае, нажмите кнопку «Отмена», чтобы не повредить ее.
Файл конфигурации: E:_VirtualsWin 7_Win7 avrWindows 7 Avr.vmx.»
3 если жму «сменить владельца» получаю: «Не удалось открыть виртуальную машину: E:_VirtualsWin 7_Win7 avrWindows 7 Avr.vmx
Сменить владельца этой виртуальнйо машины не удалось.
Виртуальная машина используется приложением на компьютере узла.
Файл конфигурации: E:_VirtualsWin 7_Win7 avrWindows 7 Avr.vmx.»
Подскажите кто что может [/more]
Источник: ru-board.club
Детектим виртуалки
Не каждому хочется, чтобы его, кхм, новый текстовый редактор какие-нибудь неприятные дядьки исследовали под виртуальной машиной. Детект виртуалок — обязательный функционал определенного рода софта, и поэтому наша рубрика ну совершенно никак не может обойтись без обзора соответствующих способов!
Как распознать виртуальную машину?
Во-первых, любая виртуальная машина несет на своем борту какое-нибудь специфическое оборудование. Это касается видеоадаптера, жесткого диска, идентификатора процессора, версии BIOS, MAC-адреса сетевой карты.
Во-вторых, виртуальные машины оставляют следы в системе в виде запущенных вспомогательных процессов, драйверов и других специфических объектов.
В-третьих, если как следует покопаться в реестре виртуальной машины, там можно найти много всяких интересных ключей, характерных только для виртуальных машин.
Ну и в-четвертых, некоторые производители специально оставляют возможности, позволяющие обнаружить их продукты.
Что же касается общих признаков наличия виртуальной машины, предложенных в свое время госпожой Рутковской (характерное расположение таблиц IDT, GDT и LDT, а также время выполнения операций процессором), то в настоящий момент все эти признаки трудно поддаются анализу и приведению к какому-нибудь общему знаменателю, главным образом из-за многоядерности и многоликости современных процессоров.
Анализируем оборудование
Начнем, пожалуй, с жесткого диска. Если посмотреть идентификатор жесткого диска в диспетчере устройств на виртуальной машине, то в его составе можно увидеть интересные строчки:
DiskVirtual для VirtualPC DiskVBOX_HARDDISK для Virtual Box Prod_VMware_Virtual для VMware Workstation
Самый простой способ узнать наименование жесткого диска — прочитать значение ключа с именем «0» в ветке реестра HKLMHARDWARESYSTEMCurrentControlSetServicesDiskEnum.
В этом месте перечисляются все дисковые накопители в системе, и первым, как раз в ключе с именем «0», будет тот диск, с которого произошла загрузка системы.
Другие статьи в выпуске:
Хакер #174. Собираем квадрокоптер
- Содержание выпуска
- Подписка на «Хакер» -60%
Как читать реестр, я думаю, ты знаешь. Используем сначала API RegOpenKeyEx для открытия нужного ключа, далее с помощью RegQueryValueEx читаем значение. Выглядеть это должно примерно вот так:
. // Открывем нужный ключ реестра RegOpenKeyExA(HKEY_LOCAL_MACHINE, «HARDWARESYSTEM CurrentControlSet ServicesDiskEnum», 0, KEY_QUERY_VALUE, // Читаем значение RegQueryValueExA(rKey, «0», NULL, RegPath); // Закрываем все, что открыли ранее RegCloseKey(rKey); .
Далее все просто — используем strstr для поиска нужных нам строк в считанном значении и, в зависимости от результата сравнения, делаем вывод. Версия BIOS содержится в ключе «SystemProductName» в ветке HKLMHARDWAREDESCRIPTIONSystemBIOS. К примеру, для VMware там будет лежать строка «VMware Virtual Platform», а для VirtualBox — «VBOX –1».
Прочитать это все можно с помощью все тех же API — RegOpenKeyEx и RegQueryValueEx.
Данные о видеоадаптере можно подглядеть в HKLMSystemCarrentControlSetEnumPCI. В этой ветке перечислено все, что подключено к шине PCI, в том числе и видеокарта. Для VirtualPC это строчка вида VEN_5333SUBSYS_00000000DEV_BEEFREV_00, что расшифровывается как «VirtualBox Display», а у Parallels Workstation — строка VEN_1AB8SUBSYS_04001AB8DEV_CAFEREV_00, определяющую некий «VirtualBox Device», а у Parallels Workstation строки VEN_1AB8SUBSYS_04001AB8DEV_4006REV_00, определяющие «Parallels Tools Device» и «Parallels Memory Controller» соответственно.
Алгоритм действий следующий: пытаемся открыть нужный нам ключ, и если он открывается успешно, то оборудование, описанное этим ключом, в наличии и можно делать вывод о присутствии какой-либо виртуальной машины:
. if (RegOpenKeyEx(HKEY_LOCAL_MACHINE, L»SYSTEMCurrentControlSet EnumPCIVEN_5333 SUBSYS_00000000, 0, KEY_QUERY_VALUE, RegCloseKey(rKey); // Мы под VirtualPC return true; >.
Идентификатор процессора определяется с помощью команды cpuid. Благодаря ей можно получить много всякой полезной информации об установленном процессоре. Вид выдаваемой этой командой информации зависит от содержимого регистра EAX.
Результат работы команды записывается в регистры EBX, ECX и EDX. Подробно про эту команду можно почитать в любой книге по программированию на ассемблере. Для наших целей мы будем использовать эту инструкцию, предварительно положив в регистр EAX значение 0x40000000:
. _asm < mov eax, 0x40000000 cpuid mov ID_1, ebx mov ID_2, ecx mov ID_3, edx >.
После выполнения этого кода на VMware Workstation в переменных ID_1, ID_2 и ID_3 будут записаны значения 0x61774d56, 0x4d566572 и 0x65726177 соответственно (в символьном представлении это не что иное, как «VMwareVMware»), на VirtualBox в ID_1 и в ID_2 будет лежать значение 0x00000340, а на Parallels Workstation в ID_1 0x70726c20, в ID_2 — 0x68797065 и в ID_3 — 0x72762020 (что соответствует строке «prl hyperv»).
Использование MAC-адреса для идентификации производителя сетевой карты, конечно, не самый надежный способ (ибо MAC-адрес довольно-таки просто поменять), но тем не менее его вполне можно применить для детекта виртуальных машин в качестве дополнительной проверки.
Ты наверняка знаешь, что первые три байта MAC-адреса сетевой карты определяют ее производителя. Производители виртуальных машин в этом плане не исключение:
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
Вытащить эти первые три байта из MAC-адреса нам поможет API-функция GetAdaptersInfo:
// Подключаем либу, в которой // содержится нужная нам функция #include #pragma comment(lib, «IPHLPAPI.lib») . // Определяем размер буфера под данные, // возвращаемые функцией GetAdaptersInfo(AdapterInfo, // Выделяем память под данные об адаптере AdapterInfo = (PIP_ADAPTER_INFO) new(char[OutBufLen]); // Получаем информацию об адаптере GetAdaptersInfo(AdapterInfo, // Сравниваем первые три байта MAC-адреса // с 00:1c:42 (Parallels Workstation) if (((BYTE)AdapterInfo->Address[0] == 0x00) ((BYTE)AdapterInfo->Address[1] == 0x1c) ((BYTE)AdapterInfo->Address[2] == 0x42)) < delete(AdapterInfo); // Мы под Parallels Workstation return true; >else < delete(AdapterInfo); return false; >.
Вспомогательные процессы, окна и другие «подозрительные» объекты
Для нормальной работы практически все виртуальные машины требуют установки дополнений к гостевой операционной системе, например VBoxGuestAddition для VirtualBox или Parallels Tools для Parallels Workstation. Без этих дополнений работа с виртуальной машиной несколько затруднительна (ни тебе нормального разрешения экрана и полноэкранного режима, ни взаимодействия с USB-девайсами, ни нормальной настройки сетевых подключений). В общем, все производители виртуалок не рекомендуют использовать их без этих дополнений. А эти самые дополнения оставляют очень заметный след в виде запущенных процессов:
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
Для поиска процесса по имени мы воспользуемся функциями CreateToolhelp32Snapshot, Process32First и Process32Next:
#include . . // К примеру, ищем процесс vmtoolsd.exe wchar_t VMwareProcessName[] = ; PROCESSENTRY32 pe; HANDLE hSnapShot; hSnapShot = CreateToolhelp32Snapshot (TH32CS_SNAPPROCESS, 0); ZeroMemory ( pe.dwSize = sizeof(PROCESSENTRY32W); Process32First(hSnapShot, do < if (memcmp(pe.szExeFile, VMwareProcessName, 24) == 0) // Мы под VMware return true; >while (Process32Next(hSnapShot, .
Помимо непосредственно самих процессов, демаскирующим признаком могут стать окна, открытые этими процессами. Окон в каждой из рассматриваемых виртуальных машин может быть довольно много, и все их мы перечислять не будем, а ограничимся одним или двумя. Итак:
VirtualBox VBoxTrayToolWndClass Parallels Workstation CPInterceptor DesktopUtilites Virtual PC VMware Workstation VMSwitchUserControlClass
Найти окно по имени класса очень просто — для этого есть функция FindWindow:
. // К примеру, ищем окно для VMware HWND VMwareWindow = FindWindowA(«VMSwitchUserControlClass», NULL); if(VMwareWindow != NULL) // Мы под VMware Workstation return true; .
Помимо процессов и окон, указывающих на наличие ВМ, можно найти и другие «подозрительные» объекты — например, если покопаться в гостевой ОС виртуальной машины утилитой WinObj или какой-нибудь аналогичной, то можно найти вот такие объекты:
VirtualBox DeviceVBoxMiniRdrDN DeviceVBoxGuest Parallels Workstation Deviceprl_pv Deviceprl_tg Deviceprl_time DevicePrlMemDev DevicePrlMemDevPci DevicePrlMemDev Virtual PC DeviceVirtualMachineServices
Проверить наличие «подозрительного» объекта очень просто, достаточно попытаться открыть его с помощью CreateFile:
. // К примеру, проверяем 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)) // Мы под VirtualBox return true; .
Что еще «подозрительного» можно найти в реестре?
Помимо признаков наличия специфического оборудования, в реестре можно увидеть и другие следы, оставляемые виртуальными машинами. Некоторые из них базируются в ветке HKLMHARDWAREACPIDSDT. Достаточно в этом месте проверить наличие таких вот ключей:
VirtualBox VBOX__ Parallels Workstation PRLS__ Virtual PC AMIBI VMware Workstation PTLTD__
Проверку реализуем так же, как мы проверяли наличие определенного оборудования. Просто делаем попытку открыть нужный нам ключ и, в случае успеха, делаем вывод о наличии ВМ.
Возможности, заложенные производителем
Некоторые производители (в частности, VMware и Microsoft) специально реализуют возможности управления своими продуктами, которые можно использовать для наших целей.
В Virtual PC используются инвалидные (не «инвалидные», а «альтернативно одаренные». И вообще-то они «недействительные». — Прим. ред.) команды процессора с опкодами 0x0F, 0x3F, 0x07 и 0x0B, попытка выполнения которых на реальном процессоре вызовет исключение, в то время как на Virtual PC все пройдет нормально. С помощью этих команд можно достаточно просто задетектить виртуалку от Microsoft:
. __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; .
В VMware Workstation для взаимодействия гостевой и основной ОС реализован небольшой бэкдор в виде порта с номером 0x5658. Для его использования необходимо в EAX положить «магическое» число 0x564d5868 (в символьном представлении — «VMXh»), а в ECX записать одну из команд взаимодействия гостевой и основной ОС (например, команда 0x0A возвращает версию установленной VMware Workstation). Короче, выглядит все это приблизительно так:
. __try < __asm < mov eax, 0x564d5868 mov ecx, 0x0A mov edx, 0x5658 in eax, dx >// Мы под VMware return true; > __except(EXCEPTION_EXECUTE_HANDLER) return false; .
Заключение
Как видишь, признаков, характерных для виртуальных машин, предостаточно, и для того, чтобы их увидеть, сильно глубоко копать совсем не нужно.
Источник: xakep.ru