Ниже в качестве примера приведен фрагмент вируса I-Worm.Kiliez.e, на малоизвестность которого жаловаться не приходится (Вах! Как трудно взглянуть на дамп того, что вы запускаете!) (листинг 1.1). Текстовые строки, содержащиеся в теле I-Worm.Kiliez.e, выдают агрессивные намерения последнего с головой!

Листинг 1.1. Фрагмент вируса I-Worm.Kilez.e

Идентификация упаковщика и автоматическая распаковка

Упаковка исполняемых файлов «навесными» упаковщиками была широко распространена еще во времена господства MS-DOS и преследовала собой следующие цели:

– уменьшение размеров программы на диске;

– сокрытие текстовых строк от посторонних глаз;

– затруднение анализа программы;

– «ослепление» сигнатурного поиска.

Два последних пункта стоит отметить особо. Напрямую дизассемблировать упакованную программу нельзя. Прежде исследователю предстоит разобраться с упаковщиком, зачастую основанным на весьма нетривиальном алгоритме и содержащим большое количество разнообразных приемов против отладчиков и/или дизассемблеров. Также существуют и полиморфные упаковщики (например, tElock), генерирующие машинный род распаковщика на «лету» и делающие зашифрованные экземпляры одной и той же программы не похожими друг на друга.

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

С переходом на Windows многое изменилось. Количество упаковщиков резко возросло, но ни одного универсального распаковщика до сих пор так и не появилось, а потому анализ упакованных файлов представляет собой одну из актуальнейших проблем современной антивирусной индустрии.

ПРИМЕЧАНИЕ

Если при дизассемблировании исследуемого файла большую часть исполняемого кода дизассемблер представил в виде дампа или выдал на выходе бессмысленный мусор (неверные опокоды команд, обращения к портам ввода/вывода, привилегированные команды, несуществующие смещения и т. д.), то файл, скорее всего, упакован и/или зашифрован.

Зачастую расшифровщик крайне примитивен и состоит из десятка-другого машинных команд, смысл которых понятен с первого взгляда. В таком случае распаковать файл можно и самостоятельно. Для этого вам даже не придется выходить из дизассемблера – всю работу можно выполнить и на встроенном языке (если, конечно, ваш дизассемблер поддерживает такой язык). Для расшифровки простейших «ксорок» хорошо подходит HIEW, а задачи посложнее решаются с помощью IDA (листинг 1.2). Подробное изложение методики расшифровки исполняемых файлов вы найдете в книге Криса Касперски «Образ мышления – дизассемблер IDA».

Листинг 1.2. Пример типичного «ксорного» расшифровщика с комментариями

Если же код расшифровщика по своей дремучести напоминает непроходимый таежный лес, у исследователя есть все основания считать, что подопытная программа упакована одним из навесных упаковщиков, к которым, в частности, принадлежат ASPack, UPX, NeoLite и другие. Отождествить конкретный упаковщик при наличии достаточного опыта можно и самостоятельно (даже полиморфные упаковщики легко распознаются визуально, стоит только столкнуться с ними три-пять раз кряду), а во всех остальных случаях вам помогут специальные сканеры, самым известным (и мощным!) из которых является бесплатно распространяемый PE-SCAN (http://k-line.cjb.net/tools/pe-scan.zip). Давайте возьмем файл с вирусом Worm.Win32.Lovesan(также известный под именем MSblast) и «натравим» на него РЕ-SCAN (рис. 1.2). Сканер тут же сообщит, что вирус упакован упаковщиком UPX, который можно скачать с сервера upx.sourceforge.net, а при нажатии на кнопку ОЕР определит и адрес оригинальной точки входа в файл (в данном случае она равна HCBh). Ну, коль скоро мы знаем имя упаковщика, найти готовый распаковщик не составит больших проблем («UPX» + «unpack» в любом поисковике)[1]. Вместе с тем, знание оригинальной точки входа в файл позволяет установить на этот адрес точку останова, и тогда в момент передачи управления только что распакованному файлу отладчик немедленно отреагирует.

ВНИМАНИЕ

Установка программной точки останова с кодом CCh в подавляющем большинстве случаев приведет к краху распаковщика, для предотвращения которого следует воспользоваться аппаратными точками останова; за подробностями обращайтесь к руководству пользователя вашего отладчика, в частности, в soft-ice установка аппаратной точки останова осуществляется командой ВРМ адрес X.

Рис. 1.2. РЕ-SCAN в действии

А как быть, если РЕ-SCAN не сможет определить оригинальную точку входа или ни один из найденных вами распаковщиков не справляется с данным файлом? Если исследуемый файл хотя бы однократно запускался (то есть ваша машина уже потенциально заражена), можно взять procdump и, запустив распаковываемый файл еще раз, снять с него полный дамп памяти (task>имя процесса>dump fill). Конечно, чтобы полученный дамп превратился в полноценный РЕ-файл, над ним придется как следует поработать, но для дизассемблирования сойдет и так. Шансы распаковать файл без его запуска средствами procdump относительно невелики, да и качество распаковки оставляет желать лучшего. Зачастую распакованный файл не пригоден даже для дизассемблирования, не то что запуска!

На худой конец, можно попробовать перехватить передачу управления распакованному коду, просто поставив на соответствующие API-функции точки останова. При определенных навыках работы с двоичным кодом мы имеем все шансы осуществить такой перехват еще до того, как вирус успеет внедриться в систему или что-то испортить в ней. Однако никаких гарантий на этот счет у нас нет, и вирус в любой момент может вырваться из-под контроля, поэтому исследования такого рода лучше всего проводить на отдельной машине или под любым симпатичным вам эмулятором PC.