Записки исследователя компьютерных вирусов
Шрифт:
Зачастую расшифровщик крайне примитивен и состоит из десятка-другого машинных команд, смысл которых понятен с первого взгляда. В таком случае распаковать файл можно и самостоятельно. Для этого вам даже не придется выходить из дизассемблера – всю работу можно выполнить и на встроенном языке (если, конечно, ваш дизассемблер поддерживает такой язык). Для расшифровки простейших «ксорок» хорошо подходит HIEW, а задачи посложнее решаются с помощью IDA (листинг 1.2). Подробное изложение методики расшифровки исполняемых файлов вы найдете в книге Криса Касперски «Образ мышления – дизассемблер IDA».
Листинг 1.2. Пример типичного «ксорного» расшифровщика с комментариями
Если же код расшифровщика по своей дремучести напоминает непроходимый таежный лес, у исследователя
ВНИМАНИЕ
Установка программной точки останова с кодом 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 активно использует отладочные регистры для своих целей, модифицируя их через контекст исключения). Просмотр дампа в НЕХ-редакторе также не показывает ничего подозрительного. Тупик…
А теперь на сцену выходит наш прием с контрольными точками – и исследуемая программа тотчас ловится на GetModuleHandleA и CreateFileA. На момент вызова последней весь код и все данные зараженного файла уже полностью распакованы и просмотр содержимого сегмента данных немедленно разоблачает вирус по агрессивным текстовым строкам (листинг 1.3).
Листинг 1.3. Распакованный вручную I-Worm.Sobig.f сразу же выдает агрессивность своих намерений характерными текстовыми строками
Стартовый код
В девяностых годах двадцатого века, когда вирусы создавались преимущественно на ассемблере и писались преимущественно профессионалами, а коммерческие программисты в своем подавляющем большинстве полностью отказались от ассемблера и перешли на языки высокого уровня, для разработчиков антивирусов наступили золотые дни, ибо распознать зараженный файл обычно удавалось с первого взгляда. Действительно, любая нормально откомпилированная программа начинается с так называемого стартового кода (Start-Up code), который легко распознать визуально (стартовый код, как правило, начинается с вызова функций GetVersion, GetModuleHandleA и т. д.). Дизассемблер IDA автоматически идентифицирует стартовый код по обширной библиотеке сигнатур, выдавая тип и версию компилятора.
ПРИМЕЧАНИЕ
Ассемблерные программы стартового кода лишены и потому, когда ассемблерный вирус внедряется в программу, написанную на языке высокого уровня, стартовый код отодвигается как бы «вглубь» файла, демаскируя тем самым факт своего заражения. Сегодня, когда ассемблерные вирусы становятся музейной редкостью, такой способ распознавания мало-помалу перестает работать, однако до полного списывания в утиль дело еще далеко.
Вообще-то никаких формальных признаков «нормального» start-up'a не существует и всяк разработчик волен реализовывать его по-своему. Однако свой собственный start-up цепляет к программе только извращенец. Обычные программисты для этих целей используют библиотечный стартовый код, поставляемый вместе с компилятором, зачастую даже и не подозревая о его существовании. Несмотря на то что даже в рамках одного-единственного компилятора существует множество разновидностей стартового кода, все они легко узнаваемы и факт отсутствия стартового кода надежно обнаруживается даже самыми начинающими из исследователей!
Приблизительная структура типичного стартового кода такова: сначала идет пролог, затем настройка обработчика структурных исключений (для C++ программ), обнаруживающая себя по обращению к сегментному регистру FS. Затем следует вызов функций GetVersion (GetVersionEx), GetModuleHandleA и GetStartupInfoA. Подробнее об идентификации стартового кода можно прочитать в книге Криса Касперски «Фундаментальные основы хакерства» или в «Hacker Disassembling Uncovered» его же, которую, кстати говоря, можно стащить отсюда: http://www.web-hack.ru/books/books.php?go=48