привет всем. пишу программку, которая должна определять, что она запущена из-под виртуальной машины. 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.
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 Вставлю проверку на количество процов. Или даже для одноядреного может не сработать?
не в курсе про архитектуру 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 для гостевой ОС у гипервизора не получится точнее защититься от такого способа детекта можно, но крайне сложно
хотя можно проверить VMX-бит в ECX через CPUID.EAX = 1 если ОС виртуалиируется, то гипервизор сбросит VMX-бит при эмуляции CPUID но в этом случае надо точно знать, поддерживает ли процессор VMX из CPUID можно определить полную информацию о семействе, типе процессора и т. д далее искать по заранее подготовленной базе процессоров, поддерживающих VMX
Очередная гонка, только декорации сменились.. HuXTUS Погугли по теме, материала валом по распространённым VM, даже по детектам хардварной виртуализации.
примено так: если hooked тогда варя стоит. Code (Text): start: push offset sehhandle push dword ptr fs:[0] mov dword ptr fs:[0], esp pushf or dword ptr[esp], 100h popf rdtsc __safenop: nop pop dword ptr fs:[0] add esp, 4 call ExitProcess, 0 sehhandle: mov eax, [esp+0ch] cmp [eax.context_eip], offset __safenop jne __badbad call MessageBoxA, 0, o nothooked, 0, 0 call ExitProcess, 0 __badbad: call MessageBoxA, 0, o hooked, 0,0 call ExitProcess, 0
вообще, определить факт наличия эмуля как такового можно, пожалуй, одним способом: запросить тип проца и считать тики, но опять же инфу отдаёт сам эмуль, и стало быть и время потраченное на цикл он может выдавать адаптированно). таким образом остаётся искать ошибки логики работы эмуля или переполнения.
http://www.google.com/search?q=Attacks+on+more+virtual+machine+emulators Посмотри вот эту доку. Их 3 части.
