Как работает VmWare?

Преамбула.
Наковырял на днях несколько интересных инструкций, вернее они документированные, просто юзаются немного нестандартно. Борщ на них обламывается, либо UD#, либо рез-т совсем левый. Проверил под варей, переваривает )) блин на ура, я даже озадачился поначалу, ну не могли тамошние девелоперы учесть все нюансы.
Собственно амбула.
Кто нибудь в курсе как варя эмулит поток команд? Ясно, что какую то часть кода она выполняет непосредственно на камне, иначе вышесказанное не объяснить. Как она решает,
что выполнять, а что эмулить? Напрашивается вывод, что как то парсит код. Проверил - любое сочетание и любое количество префиксов почти перед любыми инструкциями она разруливает на ура.Это получается парсинг на уровне ИИ , чисто программная эмуляция в этом случае будет немногим медленней, однако варя весьма шустро работает. Просветите кто реально в курсе. Гугль не сильно помог, какие то общие фразы.

 

А под VirtualBox ?

 

А что за инструкции и как выглядят? Насколько я себе представляю, VMWare дизассемблирует "влегкую", т.е. ее интересует инструкция в том случае, если произошло исключение (например, запись в crX, порты ввода/вывода и т.д.), а также для отлова инструкций типа sgdt/sidt, которые показывают значения различных системных регистров. Но если процессор поддерживает виртуализацию, это даже и не нужно.

 

medstrax1
Если курнуть доки Intel'а а потом хорошей травы - эмуляцию инструкций процессора сделать не так уж сложно.
Вся сложность в виртуальной аппаратуре.

 

BOCHS всё исполняет сам (эмулирует полностью) - потому там проблемы.
VmWare и VirtualBox эмулируют только привилегированные команды.
Т.е. код запускается на реальном процессоре: выполнился - хорошо, получили исключение - тогда дизаасемблирует и эмулирует команду.
Так что если твоя хитрозакрученная команда не привелигированная - её процессор исполняет как обычно, эмулятор её даже не анализирует.

 

Насчет борща беру свои слова обратно, просто я юзал какую-то древнюю версию. Эмулит просто изумительно, даже не вижу пока как задетектить, юзая только проц, не трогая ОС и железо. Я как то сваял небольшой детект для виртуалок, см. http://wasm.ru/forum/viewtopic.php?id=31540 , дык борщ щас эту фичу эмулит без проблем, в отличие от вари и виртуалбокса. Виртуалбокс, надо сказать, откровенный отстой, он банальное FF E8 эмулит неправильно, как и кучу других "кривых" инструкций.

А как быть с непривилегированными командами? Почему они тоже эмулируются правильно?
В любом случае перед тем как отпустить код на выполнение на реальном камне, он должен пропарсить его на предмет потенциально опасных команд, я не вижу другого решения. Но это нифига не быстро.

 

Они не эмулируются, они исполняются процессором.

В ring3 потенциально опасная команда не выполнится без исключения.

 

что есть борщ?

 

newbie
BOCHS
http://bochs.sourceforge.net/

 

Ага,как же, попробуй SIDT выполнить под варей, значение будет совсем другое нежели в хостовой JC.

Под потенциально опасными я имел ввиду непривилегированный команды, результат которых может повлиять на гостевую систему. К примеру, smsw команда непривилегированная, но она в случае выполнения на реальном камне дает доступ к cr0.pe. Если гостевая ось рассчитана на работу в реалмоде, ей нельзя давать видеть что проц уже в протмоде, поэтому варя фейкает smsw.

 

Нужно какимто хитрым способом стянуть у них отладочные символы к vmx86.sys, если попросить думаю не датут

 

Часть исходников вроде как открыта. Мы не смотрели правда что там и как, но полагаем, что найти релевантный код возможно.

 

medstrax1

Т.е. дизассемблировать таки надо, но все, что требуется, это только получить код операции инструкции для идентификации инструкции. Если с ней все в порядке -- пусть исполняется. Если нет -- надо виртуализировать. Я когда-то пробовал обмануть Virtual Box с помощью самомодифицирующегося кода, но без особого интереса и следовательно без успеха. Но где-то писали, что это возможно.

 

они уже убрали унылые ассерты а-ля "Error Function SuperPuperEmulation() failed. \super\puper\emulation.c:666" ?
помню неплохо так помогали править их баги )

 

Sol_Ksacap
Сурцы не нужны, нужны отладочные символы.
n0name
Оо точно, как я забыл )

 

VMWare и другие эмуляторы работают на принципе динамической рекомпиляции. Где-то была классная статья на эту тему.

Sol_Ksacap
Я ща просмотрел, на первый взгляд - не интересно. Там модули поддержки (типа vmware-user), исходников самого драйвера я не нашел.

 

Great

лучше посмотреть классные исходники. тем более, что их есть. хоть и не от вари. а сама идея проста как бублик
машкод1 до первого перехода --> представление удобное для автоанализа/модификации --> машкод2 + переход на новую рекомпиляцию в конце

машкод1 !== машкод2. они даже не обязательно должны у одному типу процев относиться.

на том же принципе работают и жит системы. единственно, в чем заковырка - комад много у х86. потому, лучше отталкиваться от готовых либ.

а главнвя проблема с эмулями - железо.

 

Хорошие новости для борцов с эмуляторами. Ни один из протестированных мной (bochs, vmware, virtualpc, virtualbox, qemu)не эмулирует корректно инструкцию fstenv. Подозреваю, что схожая ситуация и с немалым количеством других команд FPU. Уточню, проверял на проце без аппаратной виртуализации. Возможно с поддержкой VT-х рез-ты будут другими, но это малоактуально. Если в гостевой ОС иметь ринг0 привилегии, то задетектить аппаратный гипервизор очень легко.

 

Еще. Ни один эмулятор не рубит такую фишку.Ставим брекпойнт на чтение/запись дескриптора GDT, потом грузим селектор этого дескриптора в сегментный регистр.
На реальной машине имеем #DB, в виртуалке бряк игнорится