Записки исследователя компьютерных вирусов
Шрифт:
Здесь же мы не можем позволить себе подробно останавливаться на этом обширном вопросе и просто сравним стартовый код нормальной программы с кодом вируса Win2K.Inta.1676 (листинги 1.4 и 1.5).
Листинг 1.4. Так выглядит нормальный start-up от Microsoft Visual C++ 6.0…
Листинг 1.5. Атак выглядят окрестности точки входа вируса Win2K.Inta.1676
Смотрите, в то время как «хорошая» программа лениво опрашивает текущую версию операционной системы и иже с ней, зловредный вирус сломя голову несется в объятья драйвера inf.sys. Правильные программы так не поступают, и коварность вирусных планов разоблачается с первого взгляда!
ПРИМЕЧАНИЕ
Разумеется, отсутствие стартового кода еще не есть свидетельство вируса! Быть может, исследуемый файл был упакован или разработчик применил нестандартный компилятор/набор библиотек. Ну, с упаковкой мы уже разобрались, а с идентификацией компилятора поможет справиться IDA и ваш личный опыт.
ПРИМЕЧАНИЕ
Текущие версии IDA PRO определяют версию компилятора непосредственно по стартовому коду и если он отсутствует или был изменен, механизм распознавания дезактивируется и поиском подходящей библиотеки сигнатур нам приходится заниматься вручную, через меню File Load file FLIRT signature file. И если обнаружится, что нормальный start-up y файла все-таки есть, но выполнение программы начинается не с него, – шансы на присутствие вируса существенно возрастают!
Троянские программы, в большинстве своем написанные на языках высокого уровня, имеют вполне стандартный start-up и потому на такую наживку обнаруживаться не хотят. Взять, например, того же Kilez'a (листинг 1.6).
Листинг 1.6. Стандартный стартовый код червя I-Worm.Kilez.h
Даже «невооруженным» глазом видно, что стартовый код червя идентичен стартовому коду Microsoft Visual C++ 6.0, что совсем не удивительно, поскольку именно на нем червь и написан.
Точка входа
При внедрении вируса в файл точка входа в него неизбежно изменяется. Лишь немногие из вирусов ухитряются заразить файл, не прикасаясь к последней. Вирус может вписать по адресу оригинальной точки входа jump на свое тело, слегка подправить таблицу перемещаемых элементов, вклиниться в массив RVA-адресов таблицы импорта, внедриться в незанятые области кодовой секции файла и т. д., однако ареал обитания таких особей ограничен преимущественно застенками лабораторий, и в дикой природе они практически не встречаются. Не тот уровень подготовки у вирусописателей, не тот…
«Нормальные» точки входа практически всегда находятся в кодовой секции исполняемого файла (.text), точнее – в гуще библиотечных функций (Навигатор IDA PRO по умолчанию выделяет их голубым цветом), непосредственно предшествуя секции данных (рис. 1.3 и 1.4). Точки входа зараженного файла, напротив, чаще всего располагаются между секцией инициализированных и неинициализированных данных, практически у самого конца исполняемого файла.
Рис. 1.3. Так выглядит дизассемблерный листинг нормального файла. Точка входа расположена внутри секции. text в гуще библиотечных функций, приходясь приблизительно на середину файла
Так происходит потому, что при дозаписи своего тела в конец файла «вирусная» секция оказывается самой последней секцией инициализированных ячеек памяти, за которой простирается обширный регион неинициализированных данных, без которого не обходится практически ни одна программа. Это-то вирус и демаскирует! Ни один из известных автору упаковщиков исполняемых файлов так себя не ведет, и потому ненормальное расположение точки входа с высокой степенью вероятности свидетельствует о заражении файла вирусом!
Может ли вирус внедриться в середину файла? Да, может, но для этого ему придется разорвать себе задницу. Точнее – скорректировать все относительные ссылки между концом и началом файла, что очень и очень непросто. Правда, учитывая тот факт, что всякая секция, независимо от ее физического смещения в файле, может быть спроецирована по произвольному виртуальному адресу, вирус может обосноваться в кусочке незанятой памяти, оставшейся от выравнивания стартовых адресов секций по кратным адресам. (Обычно секции дискового образа выравниваются по адресам кратным 200h байт, а секции страничного имиджа на lOOOh байт. Поскольку различные секции могут иметь различные атрибуты доступа к памяти, а всякий атрибут распространяется на всю страницу целиком, «делить» одну физическую страницу могут лишь секции с идентичными атрибутами.)
Рис. 1.4. Так выглядит дизассемблерный листинг файла, зараженного вирусом WinNT.Infis.4608: точка входа расположена в секции. reloc, помещенной непосредственно за концом инициализированных данных у самой «кромки» исполняемого файла
Рассмотрим, например, как устроен стандартный «блокнот». Пропустив notepad.exe через утилиту efd.exe от Ильфака Гуильфанова, мы обнаружим разрыв в 6BCh байт, разделяющий секции. data и. rsrc. Причем непосредственно в самом исполняемом файле этот разрыв отсутствует (секции примыкают друг к другу вплотную, без зазора), и он образуется уже после проецирования секций в память (листинг 1.7).
Листинг 1.7. Расположение секций РЕ-файла до их проекции в память и после
Поэтому внедрение вируса в середину файла с последующей раздвижкой секций .data и. rsrc не искажает RVA-адреса остальных частей файла. Тем же самым способом вирус может внедриться и в конец секции .text, что сделает факт заражения менее заметным (хотя, учитывая, что в конце секции.command, «Блокнот» содержит свыше 1Кб неиспользуемого пространства, легко узнаваемого по цеопчке нулей, драть задницу с перемещением секций незачем).
Некоторые антивирусы (и DrWeb в частности), обнаружив, что точка входа указывает на секцию с атрибутом writable, сообщают, что файл, возможно, заражен. Однако это очень ненадежный признак, уверенно распознающий вторжение вируса в последнюю секцию файла, но пропускающий остальные типы внедрений. К тому же в атрибуте writable нуждаются многие вполне законопослушные упаковщики и навесные защиты, вызывающие ложное срабатывание эвристического анализатора (впрочем, про то, что антивирусам доверять не стоит, мы уже говорили).