Pull to refresh

Tribute to HIEW

Reading time 5 min
Views 48K
Навеяно древними воспоминаниями… Проходят года и десятилетия, сменяют друг друга названия операционных систем, но кое-что всё же остаётся неизменным. Среди всего многообразия околохакерского ПО меня всегда удивлял HIEW; непостижимым образом этой консольной программе удаётся бороться со временем и быть популярной даже сегодня. HIEW занял свою нишу и стал основным инструментом промышленного вирусного аналитика. Вам может показаться это странным и неудобным, но использовать HIEW для вирусного анализа — очень эффективно.

Итак, начнём-с, пожалуй.

Задача: выделить и классифицировать вредоносное ПО среди горы исполняемых файлов.

Решение: использовать динамический анализ неудобно, IDA долго (и дорого), вывод — используем HIEW.

Опишем примерный алгоритм экспресс анализа исполняемого файла на вредоносность. Первое, что необходимо сделать — выявить возможное заражение анализируемого объекта файловым вирусом.

Загрузим исполняемый файл в HIEW и посмотрим, в какую секцию указывает точка входа (Enter, F8, F6). Здесь возможно несколько случаев.

Вариант первый. Точка входа указывает куда-то в область заголовка PE-файла. Вариант тривиален и обнаруживается визуальным просмотром файла в текстовом режиме.

Вариант второй. Точка входа указывает на последнюю секцию исполняемого файла. Это тоже очень подозрительно и, скорее всего, свидетельствует о заражении файла. Рассмотрим несколько примеров.

Точка входа имеет следующий вид:

image

Натренированный глаз режет применение инструкции call +5, что очень не характерно для обычного компилятора. Так же интересна строка 0x0048с030, где, вероятно, происходит ручная работа с заголовком PE-файла. Посмотрим на атрибуты секции:

image

Напрашивается очевидный вывод: анализируемый объект заражён файловым вирусом. В данном случае это разновидность вируса Virut.

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

Иногда можно встретить следующую картину:

image

Вердикт очевиден – файл заражён. После байт, оставленных в конце файла для выравнивания компилятором, следует не только осмысленный код, но и сама точка входа.

Сделаем небольшое лирическое отступление от экспресс-анализа. Напрашивается вопрос: можно ли с HIEW исследовать динамически-расшифровывающиеся объекты? На удивление, это часто удаётся сделать. Рассмотрим предыдущий пример с вирусом Virut. Код вируса невелик, местами зашифрован и расположен в конце файла. Немножко полистав дизассемблерный листинг, натыкаемся на это:

image

Здесь нетрудно увидеть простейший цикл расшифровки. Однако в случае статического анализа мы не можем определить, что и с каким ключём тут расшифровывается. Но! Вспомним, что HIEW поддерживает поиск перекрёстних ссылок, наведём курсор на начало цикла расшифровки, нажмём F6 и поищем вызовы интересующего нас участка кода:

image

Очень вероятно, что это и есть код, вызывающий процедуру расшифровки. В этом случае зашифрованный участок находиться по адресу 0x0048c155 ([EAX]), а одно-байтовый ключ находиться по адресу 0x0048c154 ([EAX-1]). Размер блока — 0x12b2 байт.

Чтобы произвести расшифровку, пользователи IDA побежали бы писать скрипт на idc или питоне. В отладчике, вообще, ничего делать не пришлось бы. Пользователи же HIEW используют встроенные средства обработки блоков данных. Опишем требуемый алгоритм шифрования, выделим границы блока в режиме 16-ричного редактора и запустим скрипт.

image

Встроенное средство обработки блоков имеет Intel-подобный синтаксис и позволяет производить несложные преобразования по 8, 16, 32 и 64 бита. В результате расшифровки получим вполне пригодные для анализа данные:

image

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

image

В глаза бросаются инструкции call +5; pop reg. Данный приём очень характерен при написании базо-независимого кода. Следует отметить, что вместо прямого перехода на тело вируса часто используются инструкции типа push reg; retn либо mov reg, addr; call reg и другие вариации на эту тему. Нормальные же компиляторы обычно так не поступают, по крайней мере, уж не на точке входа, а в каком-нибудь виртуальном классе. Из всего этого можно сделать вывод, что данный экземпляр так же заражён файловым вирусом. В данном случае это — небезызвестный Sality.

Двигаемся дальше. Допустим мы встретили следующий код:

image

Несмотря на то, что точа входа сразу указывает на call и jmp, файл не заражён, и это стандартное начало программы С/C++, скомпилированной Microsoft Visual Studio 2010. Данный пример скорее исключение. Обычно при заражении кодовой секции вредоносный код дописывается либо в её конец (при наличии достаточного количества места), либо делается jmp на вредоносный код прямо с точки входа. Компиляторы же обычно начинают выполнение программы с вызова стандартной функции, имеющей стандартный пролог:

image

Здесь мы видим начало программы, скомпилированной с помощью компилятора Visual Studio C++ 6.0. Точка входа указывает на стандартный пролог, далее следует установка собственного обработчика исключений.

Рассмотрим следующий код:

image

Здесь точка входа указывает на уже известную нам последовательность push addr; retn. Перед нами — Rustock.

После анализа точки входа неплохо произвести просто просмотр секций и оверлеев файла. Иногда встречаются следующие экземпляры:

image

В данном примере, в оверелее, вероятно, записано зашифрованное тело оригинальной программы. Суть механизма «заражения» можно понять из следующего кода:

image

По сути, «вирус» заражает файлы следующим образом: полностью зашифровывает оригинальный исполняемый файл, перемещает данные себе в оверлей и перезаписывает получившимся файлом оригинальную программу. При запуске программа расшифровывает оригинальный файл, записывает его на диск во временную директорию и запускает с оригинальными параметрами командной строки.

На этом вирусный анализ как таковой заканчивается. Обнаружить более сложные заражения за короткое время в режиме промышленного аналитика затруднительно (личное мнение). Далее идёт работа по определению вредоносного функционала самого анализируемого файла.

Различные вымогатели, фейковые антивирусы и т.п. обнаруживаются просто при беглом просмотре файла в текстовом режиме:

image

Поскольку ни для кого не секрет, что в России производиться достаточное количество вредоносного ПО, то возможнось работы HIEW с русскими кодировками из коробки сильно облегчает жизнь вирусному аналитику.

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

image

… можно сделать вывод, что эти данные зашифрованы. Можно ли их статически расшифровать? В данном случае нам повезло, и мы снова ограничимся одним HIEW. Перейдём на начало зашифрованных данных и поищем перекрёстные ссылки:

image

Сразу же находим требуемый цикл расшифровки. Всё, дело почти сделано. Выделяем зашифрованный блок, пишем скрипт:

image

И расшифровываем вредоносниый код:

image

В случае невозможности быстрой расшифровки, файл направляется на более глубокий анализ, но это уже другая история.

Далее по плану идёт определение стандартных троянских программ типа Zeus, SpyEye, Carberp и других. По словам, опытный вирусный аналитик идентифицирует их с первого взгляда (автор же проверить данное заявление не имеет возможности).

В итоге мы можем анализировать и классифицировать экземпляры с практически нереальной скоростью: 1 объект менее чем за 10 минут. Видимо это и стало залогом успеха такой легендарной программы как HIEW.

P.S. Подробное описание HIEW unicornix.spb.ru/docs/prog/heap/hiew.htm
Tags:
Hubs:
+83
Comments 25
Comments Comments 25

Articles