Записки исследователя компьютерных вирусов

Конечно, все это еще не свидетельствует о наличии вируса (троянской программы), а отсутствие компрометирующих программу текстовых строк не гарантирует ее лояльности, но… просто поразительно, какое количество современных вирусов ловится таким элементарным способом. Не иначе как снижение культуры программирования дает о себе знать! Действительно, подавляющее большинство современных программ (и вирусов в том числе) разрабатывается на языках высокого уровня, и программисты не дают себе никакого труда хоть как-то скрыть «уши», торчащие из секции данных (не знают, как это сделать?). Откомпилированная программа просто шифруется статическими упаковщиками, которые легко поддаются автоматической/полуавтоматической распаковке, выдавая исследователю исходный дамп со всеми текстовыми строками на поверхности (см. раздел «Идентификация упаковщика и автоматическая распаковка»).

Ниже в качестве примера приведен фрагмент вируса 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.

Вызываем soft-ice и устанавливаем точки останова на все потенциально опасные функции, а также все те функции, которые обычно присутствуют в стартовом коде (см. далее раздел «Стартовый код»). Если вирус написан на языке высокого уровня, мы перехватим управление еще до начала выполнения функции main. В противном случае отладчик всплывет при первой попытке выполнения потенциально опасной функции.

Отладчики, устанавливающие глобальные точки останова (и soft-ice в их числе), всплывают независимо от того, какое приложение их вызывает. Поэтому всегда обращайте внимание на правый нижний угол экрана, в котором soft-ice выводит имя процесса, «потревожившего» отладчик, и, если это не исследуемый вами процесс, а что-то еще, вы можете смело покинуть отладчик, дожидаясь его очередного всплытия (табл. 1.1).

Таблица 1.1. Функции, помогающие перехватить управление у распакованного вирусного кода

Давайте продемонстрируем технику ручной распаковки на примере анализа вируса I-Worm.Sobig.f.РЕ-SCAN показывает, что он упакован полиморфным упаковщиком TeLock 0.98 . Однако найти готовый распаковщик в Интернете для этой версии упаковщика не удается (те, что есть, или не распаковывают файл совсем, или распаковывают его неправильно, хотя к моменту выхода книги в свет ситуация может и исправиться). Пошаговая трассировка распаковщика (равно как и попытки анализа алгоритма распаковки) заводят нас в никуда, ибо код оказывается слишком сложен для начинающих (а вот опытные программисты получают от его реконструкции настоящее удовольствие, ибо упаковщик весьма неплох, только при испльзовании айса имейте в виду, что, во-первых, вам потребуется падч IceExt, меняющий DLP INT'a 1 с 3 на 0, а во-вторых, ставить точки останова надо с большой осторожностью, так как tElock активно использует отладочные регистры для своих целей, модифицируя их через контекст исключения). Просмотр дампа в НЕХ-редакторе также не показывает ничего подозрительного. Тупик…