Идентификация упаковщика и автоматическая распаковка
Упаковка исполняемых файлов "навесными" упаковщиками была широко распространена еще во времена господства MS-DOS и преследовала собой следующие цели: а) уменьшение размеров программы на диске; б) сокрытие текстовых строк от посторонних глаз; в) затруднение анализа программы; г) "ослепление" сигнатурного поиска.
Два последних пункта стоит отметить особо. Напрямую дизассемблировать упакованную программу нельзя. Прежде исследователю предстоит разобраться с упаковщиком, зачастую построенном по весьма нетривиальным алгоритмам, а также содержащим большое количество разнообразных приемов против отладчиков и дизассемблеров. Также существуют и полиморфные упаковщики, генерирующие машинный род распаковщика на "лету" и делающие зашифрованные экземпляры одной и той же программы непохожими друг на друга.
Для борьбы с упаковщиками было создано большое количество автоматических распаковщиков, работающих по принципу трассировки исполняемого кода и отслеживания момента передачи управления на оригинальный код. Для борьбы с антиотладочными приемами использовалась технология эмуляции процессора, обхитрить которую было не так-то просто, хотя и возможно, но на этот случай в некоторых из распаковщиков был предусмотрен режим ручной распаковки, в котором распаковывалось все, что только было можно распаковать.
С переходом на Windows многое изменилось. Количество упаковщиков резко возросло, но ни одного универсального распаковщика до сих пор так и не появилось, а потому анализ упакованных файлов представляет собой одну из актуальнейших проблем современной антивирусной индустрии.
Если при дизассемблировании исследуемого файла большую часть исполняемого кода дизассемблер представил в виде дампа или выдал на выходе бессмысленный мусор (неверные опкоды команд, обращения к портам ввода/вывода, привилегированные команды, несуществующие смещения и т .д.), то файл скорее всего упакован и/или зашифрован. Зачастую расшифровщик крайне примитивен и состоит из десятка-другого машинных команд, смысл которых понятен с первого взгляда.
В таком случае распаковать файл можно и самостоятельно. Вам даже не придется выходить из дизассемблера, – всю работу можно выполнить и на встроенном языке (если, конечно, ваш дизассемблер поддерживает такой язык). Для расшифровки простейших "ксорок" хорошо подходит HIEW, а задачи посложнее решаются с помощью IDA. Подробное изложение методики расшифровки исполняемых файлов вы найдете в книге "Образ мышления – дизассемблер IDA" Криса Касперски.
.text:004010DA loc_4010DA: ; CODE XREF: sub_401090+58vj .text:004010DA mov dl, [esp+ecx+0Ch] ; загрузить в DL след. байт
.text:004010DE xor dl, 66h ; расшифровать по XOR 66h
.text:004010E1 mov [esp+ecx+0Ch], dl ; положить на место
.text:004010E5 inc ecx ; увеличить счетчик на единицу
.text:004010E6 cmp ecx, eax ; еще есть что расшифровывать?
.text:004010E8 jl short loc_4010DA ; …если да, то мотаем цикл
.text:004010EA loc_4010EA: ; CODE XREF: sub_401090+48^j
Листинг 1 Пример типичного "ксорного" расшифровщика с комментариями
Если же код расшифровщика по своей дремучести напоминает непроходимый таежный лес, у исследования есть все основания считать, что исследуемая программа упакована одним из навесных упаковщиком, к которым, в частности, принадлежат ASPack, UPX, NeoLite и другие. Отождествить конкретный упаковщик при наличии достаточно опыта можно и самостоятельно (даже полиморфные упаковщики легко распознаются визуально, стоит только столкнуться с ними три-пять раз кряду), а во всех остальных случаях вам помогут специальные сканеры, самым известным (и мощным!) из которых является бесплатно распространяемый PE-SCAN (http://k-line.cjb.net/tools/pe-scan.zip). Давайте возьмем файл с вирусом Worm.Win32.Lovesan (также известный под именем MSblast) и натравим на него PE-SCAN. Сканер тут же сообщит, что вирус упакован упаковщиком UPX, который можно скачать с сервера upx.sourceforge.net, а при нажатии на кнопку "OEP" определит и адрес оригинальной точки в файл (в данном случае она равна 0x00011CB).
Ну, коль скоро мы знаем имя упаковщика, найти готовый распаковщик не составит больших проблем ("UPX" + "unpack" в любом поисковике)[1]. С другой стороны, знание оригинальной точки входа в файл позволяет установить на этот адрес точку останова, и тогда в момент передачи управления только что распакованному файлу, отладчик немедленно всплывет (внимание! установка программной точки останова с кодом CCh в подавляющем большинстве случаев приводит к краху распаковщика, для предотвращения которого следует воспользоваться аппаратными точками останова; за подробностями обращайтесь к руководству пользователя вашего отладчика, в частности, в soft-ice установка аппаратной точки останова осуществляется командой BPM адрес X).
Рисунок 4 PE-SCAN в действии
А как быть, если PE-SCAN не сможет определить оригинальную точку входа или ни один из найденных вами распаковщиков не справляется с данным файлом? Если исследуемый файл хотя бы однократно запускался (то есть ваша машина уже
потенциальна заражена) можно взять ProcDump(http://ProcDump32.cjb.net)и, запустив распаковываемый файл еще раз, снять с него полный дамп памяти (Task -> имя процесса -> Dump Fill). Конечно, чтобы полученный дамп превратился в полноценный PE-файл, над ним придется как следует поработать "руками", но для дизассемблирования сойдет и так. Шансы распаковать файл без его запуска средствами ProcDump относительно невелики, да и качество распаковки оставляет желать лучшего. Зачастую распакованный файл не пригоден даже для дизассемблирования, не то что запуска!
На худой конец, можно попробовать перехватить передачу управления распакованному коду, просто поставив на соответствующие API-функции точки останова. При определенных навыках работы с двоичным кодом мы имеем все шансы осуществить такой перехват еще до того, как вирус успеет внедриться в систему или что-то испортить в ней, однако никаких гарантий на этот счет у нас нет, и вирус в любой момент может вырваться из-под контроля, поэтому исследования такого рода лучше всего проводить на отдельной машине.
Итак, вызываем soft-ice и устанавливаем точки останова на все потенциально опасные функции, а также на все те функции, которые обычно присутствуют в стартовом коде (см. "стартовый код"). Если вирус написан на языке высокого уровня, мы захватим выполнение еще до начала выполнения функции main. В противном случае, отладчик всплывет при первой попытке выполнения потенциально опасной функции.
Отладчики, устанавливающие глобальные точки останова (и soft-ice в их числе), всплывают независимо от того, какое приложение их вызывает, поэтому всегда обращайте внимание на правый нижний угол экрана, в котором soft-ice выводит имя процесса, "потревожившего" отладчик и, если это не исследуемый вами процесс, а что-то еще, вы можете смело покинуть отладчик, дожидаясь его очередного всплытия.
| основные функции стартового кода | основные потенциально опасные функции |
| GetVersion | CreateFileA, |
| GetVersionExA | RegOpenKeyA |
| GetCommandLineA | RegOpenKeyExA |
| GetModuleHandleA | LoadLibraryA |
| GetStartupInfoA | FindFirstFileA |
| SetUnhandledExceptionFilter | FindFirstFileExA |
Давайте продемонстрируем технику ручной распаковки на примере анализа вируса I-Worm.Sobig.f. PE-SCAN показывает, что он упакован полиморфным упаковщиком TeLock 0.98 (http://egoiste.cjb.net/), однако найти готовый распаковщик в Интернете для этой версии не удается (те, что есть, не распаковывают файл совсем или распаковывают его неправильно). Пошаговая трассировка распаковщика (равно как и попытки анализа алгоритма распаковки) заводят нас в никуда, ибо код оказывается слишком сложен для начинающих (а вот опытные программисты получают от его реконструкции настоящее удовольствие, ибо упаковщик весьма неплох). Просмотр дампа в HEX-редакторе также не показывает ничего подозрительного. Тупик…
А теперь на сцену выходит наш прием с контрольными точками: и исследуемая программа тотчас ловится на GetModuleHandleA и CreateFileA.
На момент вызова последний весь код и все данные зараженного файла уже полностью распакованы, поэтому просмотр содержимого сегмента данных немедленно разоблачает вирус по агрессивным текстовым строкам:
| 001B:00419561 | 62 | 6C | 65 | 00 | 00 | 00 | 00 | 62-61 | 73 | 65 | 36 | 34 | 00 | 00 | 53 | ble....base64..S |
| 001B:00419571 | 4D | 54 | 50 | 00 | 00 | 00 | 00 | 74-63 | 70 | 00 | 74 | 65 | 78 | 74 | 2F | MTP....tcp.text/ |
| 001B:00419581 | 70 | 6C | 61 | 69 | 6E | 00 | 00 | 69-73 | 6F | 2D | 38 | 38 | 35 | 39 | 2D | plain..iso-8859- |
| 001B:00419591 | 31 | 00 | 00 | 51 | 55 | 49 | 54 | 0D-0A | 00 | 00 | 45 | 48 | 4C | 4F | 20 | 1..QUIT....EHLO |
| 001B:004195A1 | 25 | 73 | 0D | 0A | 00 | 00 | 00 | 50-61 | 73 | 73 | 77 | 6F | 72 | 64 | 3A | %s.....Password: |
| 001B:004195B1 | 00 | 00 | 00 | 55 | 73 | 65 | 72 | 6E-61 | 6D | 65 | 3A | 00 | 00 | 00 | 41 | ...Username:...A |
| 001B:004195C1 | 55 | 54 | 48 | 20 | 4C | 4F | 47 | 49-4E | 0D | 0A | 00 | 00 | 00 | 00 | 4D | UTH LOGIN......M |
| 001B:004195D1 | 41 | 49 | 4C | 20 | 46 | 52 | 4F | 4D-3A | 20 | 3C | 25 | 73 | 3E | 0D | 0A | AIL FROM: <%s>.. |
| 001B:004195E1 | 00 | 00 | 00 | 52 | 43 | 50 | 54 | 20-54 | 4F | 3A | 20 | 3C | 25 | 73 | 3E | ...RCPT TO: <%s> |
| 001B:00419BD1 | 00 | 00 | 00 | 24 | 5C | 00 | 00 | 53-4F | 46 | 54 | 57 | 41 | 52 | 45 | 5C | ...$\..SOFTWARE\ |
| 001B:00419BE1 | 4D | 69 | 63 | 72 | 6F | 73 | 6F | 66-74 | 5C | 57 | 69 | 6E | 64 | 6F | 77 | Microsoft\Window |
| 001B:00419BF1 | 73 | 5C | 43 | 75 | 72 | 72 | 65 | 6E-74 | 56 | 65 | 72 | 73 | 69 | 6F | 6E | s\CurrentVersion |
| 001B:00419C01 | 5C | 52 | 75 | 6E | 00 | 00 | 00 | 20-2F | 73 | 69 | 6E | 63 | 00 | 00 | 64 | \Run... /sinc..d |
| 001B:00419C11 | 62 | 78 | 00 | 68 | 6C | 70 | 00 | 6D-68 | 74 | 00 | 77 | 61 | 62 | 00 | 68 | bx.hlp.mht.wab.h |
