Comments 12
Мне кажется, что speculate надо перевести более точно.
www.multitran.ru/c/m.exe?CL=1&s=speculate&l1=1
www.multitran.ru/c/m.exe?CL=1&s=speculate&l1=1
Может, кто-то знает, на что рассчитывают механизмы коррекции rdtsc виртуалок.
Время ведь на виртуалке выдаётся настоящее (API GetSystemTime, time_t time()). Часы не запаздывают оттого, что время потрачено в VMM.
То есть, таймер rdtsc корректируется, а обычный time() выдаётся без коррекции (если на виртуалке есть интернет, можно и с NTP-сервера запросить).
На расхождениях этих таймеров можно детектировать VM, не залезая в такие дебри, как спекулятивное выполнение?
Время ведь на виртуалке выдаётся настоящее (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 раз, только один замер может увеличить время из-за переключения контекста.
Если RDTSC включают после CPUID, возвращаемся обратно к вопросу, почему накапливается существенное расхождение часов и RDTSC.
Возможно система дает вашему процессу очень мало вычислительной мощности, почти не переключает на него исполнение.
Система без виртуализации переключает процессы по прерываниям таймера. То есть, она не может дать квант времени меньше 20мс (но может давать эти кванты реже). Значит, если выполнить RDTSC+CPUID подряд 10 раз, только один замер может увеличить время из-за переключения контекста.
обнаружение превращается в гонку гипервизора против детектораДа вроде, никто и не скрывает VM? Не знаю, есть ли специализирующиеся на скрытности VMM, но обычные Hyper-V, VMWare палятся на совсем простых вещах, типа наличия в диспетчере устройств «виртуализированных», наличия в Program Files «support drivers», зарардкоженных серийных номерах и моделях HDD, ставят свой копирайты в производителя BIOS и материнсткой платы (доступно через WMI)
Это теперь любой «средненький» вирус сможет детектить песочницу или виртуалку?
Sign up to leave a comment.
Новая техника атак на основе Meltdown. Использование спекулятивных инструкций для детектирования виртуализации