Как исследовать алгоритм работы вируса
Ситуация, когда компьютер оказался заражен неизвестным вирусом,
встречается не очень часто, но полностью сбрасывать со счетов такую
возможность нельзя. Выше рассматривались способы обнаружения ви-
руса и выделения его в чистом виде. Сейчас переходим к исследованию
алгоритма работы файловых вирусов для успешной борьбы с ними.
1. Прежде чем перейти к рассмотрению этого вопроса, вспомним неко-
торые принципы функционирования MS DOS.
Структура СОМ- и ЕХЕ-программ. Вообще говоря, следует отли-
чать СОМ- и ЕХЕ-программы от СОМ- и ЕХЕ-файлов. Дело в том,
что в настоящее время расширение СОМ или ЕХЕ является просто
признаком (кстати, необязательным) запускаемой программы. Спо-
соб загрузки программы в память и ее запуска определяется опера-
ционной системой по внутреннему формату программы. Этот факт
часто не учитывали авторы первых вирусов, что приводило к унич-
тожению некоторых программ вместо их заражения.
СОМ-программа представляет собой часть кода и данных, которая
начинается с исполняемой команды и занимает не более 64Кбайт.
Например, такую структуру имеет командный процессор
COMMAND.СОМ операционной системы MSDOS до версии 6.22
включительно.
Структура ЕХЕ-программы гораздо сложнее. В начале файла
ЕХЕ-программы располагается заголовок (см. приложение). Поля
ReloCS и ExelP определяют расположение точки входа в программу,
поля ExeSP и ReloSS - расположение стека, поля PartPag
и PageCnt - размер корневого сегмента программы. Размер некоторых
6-1436
программ, вычисленный по полям PartPag и PageCnt, может не со-
впадать с реальным размером файла. Такие программы называются
"сегментированными" или "содержащими внутренние оверлеи".
Опытные авторы вирусов избегают заражать такие программы. Пос-
ле заголовка может размещаться специальная таблица, точное место
расположения которой определяется полем TablOff, а размер - по-
лем ReloCnt. В этой таблице хранятся адреса тех слов в коде про-
граммы, которые модифицируются операционной системой во время
загрузки программы. Например, просматривая файл программы при
помощи утилиты HackerView, можно видеть команду call
0000:1234h. В процессе загрузки программы MS-DOS подставит вме-
сто нулей нужный сегментный адрес, и все будет работать коррект-
но. Кстати, если в поле TablOff указано число 40h или больше,
то, скорее всего, это программа в формате Windows. Подобный
формат имеет, например, командный процессор Windows 95
COMMAND.COM. Несмотря на свое расширение, он имеет в нача-
ле знаменитые символы "MZ" и длину 95Кбайт.
2. Приступаем к исследованию конкретного файлового вируса и разра-
ботке алгоритма его лечения. В качестве жертвы "показательного
вскрытия" возьмем широко известный в начале 90-х годов вирус
SVC-1740. Выбор определился следующими обстоятельствами:
- это очень простой вирус с четкой структурой;
- он не содержит деструктивных функций;
- не содержит грубых ошибок в алгоритме;
- он стандартно заражает СОМ- и ЕХЕ-программы.
Запустив SVC вирус на своей машине, можно наблюдать следую-
щие его проявления.
а) В MS-DOS успели заразиться файлы ARCVIEW.EXE,
HIEW.EXE и LEX.EXE. В результате HackerView, проверяющий
целостность своего кода, отказался работать, сообщив: "HIEW
bad, work is aborted".
6) Windows 3.11 и Windows 95 сначала запустились корректно, но
затем продемонстрировали разноцветные горизонтальные полосы
в видеорежиме 800х600х256 (вирус не заражал какие-либо драй-
вера, просто в момент старта Windows в памяти находился ви-
русный обработчик прерывания INT 21h).
Излечение пришло после использования антивирусов:
DrWeb с: /сир /а1
и
AidsTest с: /f /g /q
3. При помощи ранее описанных методов заразим две приманки:
TEST.COM и TEST.EXE. Увеличение их длины на 1740 байт мож-
но увидеть только на "чистой" машине (Stealth-эффект). Несколь-
ко слов об инструментарии. Вообще говоря, выбор дизассемблеров
весьма широк. В свое время была широко известна программа
DisDoc. По признанию Е. Касперского, он активно пользуется инте-
рактивным дизассемблером IDA. Быстро просмотреть код програм-
мы позволяет утилита HackerView. Также возможно использование
любого отладчика. В данном случае для изучения кода зараженных
приманок использовался дизассемблер Sourcer v5.04. Несмотря на
отсутствие некоторых полезных опций и ошибки при дизассембли-
ровании (достаточно редкие), пользоваться программой удобно -
упакованная PkLite, она занимает на дискете всего 48Кбайт.
Итак, запускаем дизассемблер командой sr test-сом. На экране появи-
лась темно-синяя лицевая страница. Нажав клавишу "а", можно пе-
рейти на страницу опций. Рекомендуется установить опцию "а" -
обязательно дизассемблировать фрагмент программы, располагаю-
щийся после команд jmp/ret/iret - это позволяет получить ассемб-
лерный код тех фрагментов программ, в которые нет явного перехо-
да (процедуры обработки прерываний, скрытые подпрограммы и так
далее). Нажав Enter, вернемся на первую страницу. Запустим процесс
дизассемблирования нажатием клавиши "g". В зависимости от про-
изводительности компьютера, процесс дизассемблирования длится от
нескольких секунд до нескольких минут. Для грубой оценки размера
листинга можно принять, что один килобайт кода соответствует деся-
ти-пятнадцати килобайтам текста. 6740 байт зараженной приманки
дают 96Кбайт текста+файл test.sdf. Этот очень интересный файл хра-
нит в текстовом виде как опции, использованные при дизассемблиро-
вании, так и параметры полученного текста (размещение фрагментов
кода и данных, место расположения символических имен и прочее).
Если изменить эти параметры, переименовать файл в test.def и пере-
дать его Sourcer в командной строке в качестве параметра, то дизас-
семблер будет работать в соответствии с новыми инструкциями. Ана-
логичную операцию проделаем для файла testexe.
б*
4. Займемся анализом полученного листинга. Поверхностно изучая за-
раженные приманки, видим:
- файлы увеличили свою длину на 1740 байт;
- в их конце явно видны посторонние коды;
- изменилось время создания файлов, точнее, изменилось количе-
ство секунд - оно стало равным 60;
- в начале файла test.coM появилась команда jmp;
- в заголовке файла test.exe изменились значения полей ReloCS,
ExelP, ExeSP, ReloSS, PartPag и PageCnt.
Итак.
а) В начале вирусного кода содержится последовательность команд
вида:
call sub_1
sub_1: pop si
sub si,3
Подобная последовательность символов характерна для очень мно-
гих вирусов. Команда call помещает в стек смещение следующей за
ней команды. Это значение извлекается вирусом при помощи ко-
манды pop si (в то время как обычно это делается командой ret)
и помещается в регистр si. Скорректировав эту величину на длину
команды call (3 байта), вирус получает возможность корректного
обращения к ячейкам памяти относительно кодового сегмента:
mov cs:Data[si], xxxx.
Не случайно DrWeb всегда реагирует на подобные команды в на-
чале программ, выдавая предупреждающее сообщение. Впрочем,
это не является обязательным признаком присутствия вируса. На-
пример, устаревшая пристыковочная защита от несанкционирован-
ного копирования (НСК) "Nota" также пользуется этим приемом.
б) Важным элементом алгоритма вируса является определение на-
личия собственного резидента в ОЗУ. Вызывая прерывание DOS
с "секретной" функцией 83h, вирус ждет реакции системы. "Здо-
ровая" система не среагирует на провокацию, а "больная" поме-
стит в регистр dx число 1990h (год создания вируса?), чем и из-
вестит о наличии вируса в памяти. Вот соответствующий
фрагмент вирусного обработчика прерывания INT 21h:
cmp ah,83h
je loc_9
loc_9:
mov dx,1990h
iret
Наличие такой проверки использует антивирус-фаг во время детекти-
рования вирусного кода в оперативной памяти. Также антивирус-бло-
кировщик может имитировать присутствие вируса в памяти, предот-
вращая его внедрение в программное обеспечение компьютера.
в) В случае отсутствия вирусного обработчика INT 21h в памяти,
вирус пытается установить его и остаться в памяти резидентно.
Алгоритм резидентной записи кода вируса в память основан
на прямой модификации заголовка блока памяти (МСВ). Под-
робное описание этого алгоритма и методов борьбы с вирусами,
использующими подобный метод инсталляции, можно найти
в одном из номеров журнала "Монитор" за 1993 г.
г) Установив свою резидентную копию в ОЗУ (или обнаружив на-
личие такой копии), вирус передает управление оригинальной
программе. Изучение этого момента чрезвычайно важно для ана-
лиза. В процессе заражения (данный фрагмент из листинга уда-
лен) вирус считывает (в data_15) 24 байта начала программы
и анализирует первые два байта из них. В зависимости от содер-
жимого первого слова ("MZ" или нет), вирус выполняет зараже-
ние жертвы либо по СОМ-, либо по ЕХЕ-алгоритму, дописывая
фрагмент памяти со своим кодом к ее концу. Естественно, счи-
танные 24 байта также дописываются в файл-жертву. Поэтому
для определения способа передачи управления оригинальному
коду программы вполне достаточно повторно сравнить сохранен-
ный фрагмент начала с признаком "MZ":
cmp cs:data_15[si],5A4Dh
je lt_Was_EXE
В случае если программа была заражена по СОМ-алгоритму, вирус
просто извлекает первые 3 байта из ячейки памяти по адресу
data_15, копирует их в старое начало оригинального кода (по адре-
су cs:100h) и передает туда управление. Адресу data_15 соответ-
ствует 80-ый (если считать от конца) байт зараженной программы.
В случае если программа была заражена по ЕХЕ-алгоритму, вирус
вычисляет старую точку входа по сохраненным в data_20 и data_21
значениям полей ReloCS и ExelP, восстанавливает расположение
стека по сохраненным в data_18 и data_19 значениям полей ReloSS
и ExeSP и передает управление на ReloCS+ES+10h:ExeIP (ES -
сегмент PSP; ES+lOh - сегмент начала программы; ES+ReloCS+
10h - полный сегмент точки входа). Расположение этих адресов
в зараженном файле (от конца файла):
data_20 - 60
data_21 - 58
data_18 - 66
data_19 - 64
Еще могут пригодиться сохраненные значения полей PartPag
и PageCnt (от конца файла):
data_16+1 - 78
data_16+3 - 76
Для излечения зараженного файла достаточно восстановить изме-
ненные значения ячеек, адреса которых только что вычислили,
и отсечь 1740 вирусных байт от конца файла.
5. Еще несколько особенностей, с которыми иногда можно встретить-
ся при дизассемблировании кода вируса и изучении листинга. Код
вируса может быть зашифрован. В этом случае в начале вирусного
кода должен располагаться расшифровщик. Вообще говоря, рас-
шифровщиков может быть много, но первый всегда существует.
Если расшифровщик меняется от одного зараженного файла к дру-
гому, значит имеем дело с полиморфным вирусом. Вырожденный
случай - зашифровываются только сохраненные в теле вируса бай-
ты. Для СОМ-файла вполне достаточно пошагово пройти расшиф-
ровщик в отладчике, дождаться его завершения и сохранить на вин-
честер расшифрованный код вируса. Полученный файл можно
дизассемблировать. Для ЕХЕ-файла такое не подходит, так как в
памяти после загрузки отсутствует заголовок, и полученный файл
не может быть дизассемблирован именно как ЕХЕ. Вероятно, при-
дется писать специальную программу расшифровки на основе изу-
ченного по листингу алгоритма расшифровщика.
Расшифровщик может быть совмещен с алгоритмами, противодей-
ствующими трассировке кода вируса с использованием отладчиков.
Ознакомиться с ними можно в специальной литературе, посвящен-
ной борьбе с НСК. Авторы вирусов, как правило, редко изобретают
что-то новое и используют широко известные методы.
