Известно что для исследования зловреда нужна песочница. В бюджетном варианте какая-нибудь виртуалка с Windows 7 на борту. 10-ку для этого не советуют ибо там кода который следит за вами, и за самим собой немеряно. Но хакеры ребята умные, и потому не леняться писать детекторы виртуального окружения в свой зловред тоже. Честно говоря, я был удивлен когда мне предложили спрятать виртуалку простой правкой реестра, как на рисунке.
Мне уже кажется что это вообще невозможно по ряду причин. Стоит отметить, что алгоритмы обнаружения виртуальных машин, используемые для защиты коммерческого приложения, являются коммерческой тайной компаний производителей программного обеспечения, в связи с чем не публикуются.
Как распознать виртуальную машину?
Во-первых, любая виртуальная машина несет на своем борту какое-нибудь специфическое оборудование. Это касается видеоадаптера, жесткого диска, идентификатора процессора, версии BIOS, MAC-адреса сетевой карты.
Во-вторых, виртуальные машины оставляют следы в системе в виде запущенных вспомогательных процессов, драйверов и других специфических объектов.
В-третьих, если как следует покопаться в реестре виртуальной машины, там можно найти много всяких интересных ключей, характерных только для виртуальных машин.
Ну и в-четвертых, некоторые производители специально оставляют возможности, позволяющие обнаружить их продукты.
Что же касается общих признаков наличия виртуальной машины, предложенных в свое время госпожой Рутковской (характерное расположение таблиц IDT, GDT и LDT, а также время выполнения операций процессором), то в настоящий момент все эти признаки трудно поддаются анализу и приведению к какому-нибудь общему знаменателю, главным образом из-за многоядерности и многоликости современных процессоров.
Анализ вспомогательных процессов коммерческим приложением обходится путём переименования исполняемых файлов или переименованием указанных процессов (таблица 1) в таблице процессов.
Помимо вспомогательных процессов можно анализировать и объекты, порождаемые этими процессами в ОЗУ компьютера. Идентификация виртуальной машины в этом методе основана на попытке создания объекта с именем, приведенным в таблице 2. Данная операция осуществляется при помощи функции WinAPI CreateFile. Ошибка создания объекта является признаком существования объекта.
Обойти подобную проверку возможно перехватом вызова функции CreateFile или непосредственной модификацией системной динамической библиотеки Microsoft Windows - kernel32.dll. Обход анализа открытых окон приложений (таблица 3) осуществляется при помощи перехвата WinAPI функций или переименованием окон, используя методы WinAPI до запуска исследуемого приложения.
Анализ первых трёх байт MAC-адреса виртуального сетевого адаптера (таблица 4), обеспечивающего соединение гостевой виртуальной машиной с хостовой системой, также не обеспечивает необходимой защиты - параметры сетевого интерфейса легко изменить. Анализ времени выполнения инструкций является более надёжным подходом, хотя он уже и не работает на VMware Workstation 12-ой версии.
Или такой вот нестандартный подход одного студента из Томского политеха - оказывается используя Windows XP, VMware Workstation можно идентифицировать по следующему алгоритму:
1. Записать в регистр EAX -> 564d5868h;
2. Записать в регистр ECX -> 0Ah;
3. Прочитать данные из порта 5658h;
4. Выполнение вернёт текущую версию виртуальной машины, в данном случае 12.
Последовательный вызов опкодов 0Fh, 3Fh, 07h и 0Bh на реальном процессоре приводит к возникновению ошибки времени выполнения, но на эмулированном процессоре VirtualPC выполняется без ошибок, что позволяет явно идентифицировать эту виртуальную машину.
Более подробно можно прочитать про методы детектирования VM в журнале "Хакер" №8 за 2021-й год.
Такие дела.
No comments:
Post a Comment
А что вы думаете по этому поводу?