Pull to refresh

Comments 12

В каком предложении и что вам кажется более подходящим?
забавно, что наказав меня минусом, у меня кончилась карма голосовать и я не смог поставить вам плюс :)

Может, кто-то знает, на что рассчитывают механизмы коррекции rdtsc виртуалок.

Время ведь на виртуалке выдаётся настоящее (API GetSystemTime, time_t time()). Часы не запаздывают оттого, что время потрачено в VMM.

То есть, таймер rdtsc корректируется, а обычный time() выдаётся без коррекции (если на виртуалке есть интернет, можно и с NTP-сервера запросить).

На расхождениях этих таймеров можно детектировать VM, не залезая в такие дебри, как спекулятивное выполнение?
Есть механизм Blue Chicken. Описан у Рутковской. Если слишком много вызовов rdtsc, то его перестают перехватывать. Как один из вариантов. И циклы на разной аппаратуре занимают разное время. Так что не всё так просто
Если слишком много вызовов rdtsc, то его перестают перехватывать
Ну отлично. Вызываем 100500 раз RDTSC, его перестают перехватывать и корректировать, а на 100501-й раз RDTSC меряет что-то полезное, например, время выполнения гарантированно перехватываемой инструкции, типа CPUID.

И циклы на разной аппаратуре занимают разное время
Да, но не в тысячи раз разница.
Ну там и не будет такая большая разница, а после cpuid можно включать. Не очень получается так обнаружить, иначе бы все малварщики его использовали, чтобы уйти от песочниц. Ещё особенность, что из 3 уровня привилегий нельзя точно узнать, какая должна быть разница у rdtsc. Возможно система дает вашему процессу очень мало вычислительной мощности, почти не переключает на него исоплнение. В итоге обнаружение превращается в гонку гипервизора против детектора.
CPUID тут просто для примера. Можно взять любую другую инструкцию, либо просто доступ к памяти, требующий нетривиальной трансляции, чтобы точно вылететь в гипервизор.

Если RDTSC включают после CPUID, возвращаемся обратно к вопросу, почему накапливается существенное расхождение часов и RDTSC.

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

Система без виртуализации переключает процессы по прерываниям таймера. То есть, она не может дать квант времени меньше 20мс (но может давать эти кванты реже). Значит, если выполнить RDTSC+CPUID подряд 10 раз, только один замер может увеличить время из-за переключения контекста.
обнаружение превращается в гонку гипервизора против детектора
Да вроде, никто и не скрывает VM? Не знаю, есть ли специализирующиеся на скрытности VMM, но обычные Hyper-V, VMWare палятся на совсем простых вещах, типа наличия в диспетчере устройств «виртуализированных», наличия в Program Files «support drivers», зарардкоженных серийных номерах и моделях HDD, ставят свой копирайты в производителя BIOS и материнсткой платы (доступно через WMI)
Да, стандартные пользовательские гипервизоры себя не скрывают. Но их переделывают специально, чтобы избежать детекта. И в них надо детектировать свойства ОС, оборудования, иногда специальные MSR. А метод в статье почти не привязан к ПО
Это теперь любой «средненький» вирус сможет детектить песочницу или виртуалку?
Если не поставлен патч от Intel, то да
Sign up to leave a comment.