обнаружение виртуальной машины

привет всем.
пишу программку, которая должна определять, что она запущена из-под виртуальной машины. ring-3. Нужно использовать как универсальные методы обнаружения VM, так и специфичные для отдельных прог(VMware, Parallels, Microsoft V-PC, innotec VirtualBox итд). Пока использую следующие способы обнаружения:
1) RDTSC - если разница между двумя RDTSC слишком большая, то VM
2) проверяю бэкдор VMware, взял из статьи Криса Касперски
3) ищу установленные VMware Tools в списке запущенных процессов

Этого мало))) Буду очень благодарен за любые советы, методики и куски кода.

PS: гуглил.

 

Попробуй поработать с SetSystemTime. У меня на варе она не изменяла дату. Если это был не глюк, а закономерность, то можно ее прикрутить к определению.

P.S.: есть еще способ определения по специфическому оборудованию

 

На http://chitchat.at.infoseek.co.jp/vmware/index.html например - http://chitchat.at.infoseek.co.jp/vmware/backdoor.html#top. Не знаю совпадает это с тем что у тебя есть или нет.

 

баян, прикрывается спец. патчем, + этот же патч меняет имена устройств.
есть неплохой способ с проверкой хука rtdsc. варя ставит этот хук, который можно обнаружить и в r3.

 

Майкрософт Оффис ищи =)))
На 95% машин с Виндовс стоит офис
И на 95% варей - он не стоит ))

 

адрес IDT считай

 

ECk
не очень тоже способ. Особенно на 2х-4х ядерных машинах.

 

MSoft
SetSystemTime, к сожалению, работает. И на VMware и на VirtualBox'е. А жаль, было бы здорово.

Насчет специфичного оборудования: у меня нет виртуалки Parallels и Microsoft Virtual PC. Если у кого-нибуть они установлены, может подскажите за какие железки цепляться?

В VMware обычно рекомендуют определять по mac адресу, хотя я думаю искать еще и по имени мышки, она у них своя, фирменная.

EvilPhreak
Да, у меня именно этот код, но, опять же, работает только с VMware, а виртуальных машин немало.

Magnum
Просто супер! обязательно сделаю такую проверку.

ECk
командой sidt, я так понимаю.
Вот мои результаты:
нормальный комп: ff 07 00 f4 03 80
Virtual Box: ff 07 90 f0 00 ea
VMware: ff 07 00 80 c1 ff

А что с ним делать?

n0name
Вставлю проверку на количество процов. Или даже для одноядреного может не сработать?

 

смотри на последний байт. должен быть 80.

для одного проца сработает.

 

HuXTUS
Чем SVM детектить будешь?

 

n0name

Подробнее пожалуйста. Как устанавливается и как снимается.

 

не в курсе про архитектуру SVM, но VMX, если повезет, можно задетектить через всю ту же SIDT
для этого временно переключаемся в реальный режим и выполняем последовательно
LIDT (загружаем 0 в IDTR) и SIDT
если гипервизор реализован не совсем хорошо, то в после SIDT мы не получим 0
однако в случае переотображения гипервизором IDT на адрес, заданный операндом LIDT, задетектить VMX таким способом невозможно
можно попытаться все в том же реальном режиме выполнить последовательность инструкций
RDTSC, RDMSR, RDTSC, найти разность значений между двумя RDTSC и с определенной вероятностью исходя из величины разности задетектить VMX
фишка здесь в том, что:
1. в большинстве случаев для эмуляции реального режима гипервизор использует виртуальный режим
2. выполнение привилегированной (в виртуальном режиме) инструкции RDTSC приводит к #GP, но #GP не приведет к VM-Exit (потому как в данном случае #GP имеет приоритет над VM-Exit), а значит своевременно подкорректировать значение TSC для гостевой ОС у гипервизора не получится
точнее защититься от такого способа детекта можно, но крайне сложно

 

rei3er

У ТС в постановке ring 3 only..

 

тогда скорее всего никак
по крайней мере сходу ничего в голову не лезет

 

хотя можно проверить VMX-бит в ECX через CPUID.EAX = 1
если ОС виртуалиируется, то гипервизор сбросит VMX-бит при эмуляции CPUID
но в этом случае надо точно знать, поддерживает ли процессор VMX
из CPUID можно определить полную информацию о семействе, типе процессора и т. д
далее искать по заранее подготовленной базе процессоров, поддерживающих VMX

 

Очередная гонка, только декорации сменились..

HuXTUS
Погугли по теме, материала валом по распространённым VM, даже по детектам хардварной виртуализации.

 

примено так:
если hooked тогда варя стоит.

Код (Text):

1. start:                  push    offset sehhandle
2.                         push    dword ptr fs:[0]
3.                         mov     dword ptr fs:[0], esp
4.  
5.                         pushf
6.                         or      dword ptr[esp], 100h
7.                         popf
8.                         rdtsc
9. __safenop:              nop
10.                         pop     dword ptr fs:[0]
11.                         add     esp, 4
12.                         call    ExitProcess, 0
13.                        
14. sehhandle:              mov     eax, [esp+0ch]
15.                         cmp     [eax.context_eip], offset __safenop
16.                         jne     __badbad
17.                         call    MessageBoxA, 0, o nothooked, 0, 0
18.                         call    ExitProcess, 0
19. __badbad:          call    MessageBoxA, 0, o hooked, 0,0
20.                         call    ExitProcess, 0

 

вообще, определить факт наличия эмуля как такового можно, пожалуй, одним способом: запросить тип проца и считать тики, но опять же инфу отдаёт сам эмуль, и стало быть и время потраченное на цикл он может выдавать адаптированно). таким образом остаётся искать ошибки логики работы эмуля или переполнения.

 

http://www.google.com/search?q=Attacks+on+more+virtual+machine+emulators

Посмотри вот эту доку. Их 3 части.

 

HuXTUS
http://handlers.sans.org/tliston/ThwartingVMDetection_Liston_Skoudis.pdf