Создаем вирус и антивирус - Игорь Гульев

test.com

cseg segment

assume cs:cseg, ds:cseg, ss:cseg

org 100h

Start:

db 1249 dup (0FAh,90h,0FBh,0F8h)

mov ah,4Ch

int 21h

cseg ends

End Start

test.exe

cseg segment

assume cs:cseg, ds:cseg

Start:

db 1000 dup (0FAh,90h,0FBh,0F8h)

mov ah,4Ch

int 21h

cseg ends

sseg segment stack

assume ss:sseg

db 118 dup (0FAh,90h,0FBh,0F8h)

sseg ends

End Start

Скопируем приманки на зараженную машину. Выполним над ними как можно больше операций: запустим, скопируем в другое место винчестера и на дискету, переместим, просмотрим их в NC и DOS (командой dir). При этом желательно несколько раз поменять системное время и дату, потому что вирусы нередко активны не каждый день и не круглые сутки. Чтобы исключить Stealth-эффект, загрузимся с чистой дискеты и рассмотрим внимательно эти файлы. Как правило, достаточно бывает проконтролировать размер файлов и просмотреть их код при помощи F3 – наличие вируса определить несложно. в) Выделение нерезидентного файла. Самый неприятный случай. Помимо того, что вирус нередко привередничает, распознавая приманку, и по-прежнему отказывается работать «без выходных и отпусков», так еще и заражаемость программ сильно зависит от их расположения на винчестере. Одни нерезидентные вирусы заражают только в текущем каталоге, другие – только в подкаталогах 1-го уровня, третьи – в каталогах, указанных в строке path системной среды (Vienna), четвертые – вообще во всех каталогах винчестера. Поэтому воспользуемся программой типа rt, чтобы скопировать приманки во все каталоги диска (запускаем из корневого каталога):

rt copy a:test.* .

Точка «.» в конце – символ текущего каталога. Потом их можно будет удалить:

rt del test.*

Теперь выбираем заведомо зараженную программу и запускаем ее N раз, постоянно изменяя время и дату. Проконтролировать изменение длины поможет та же программа rt:

rt dir test.* >test.txt

Получаем файл test.txt, содержащий список файлов test.* с указанием их длины. Выбираем тот файл приманки, который изменил длину. Вот вирус и пойман.

Как исследовать алгоритм работы вируса

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

1. Прежде чем перейти к рассмотрению этого вопроса, вспомним некоторые принципы функционирования MS DOS.

Структура COM– и EXE-программ. Вообще говоря, следует отличать СОМ– и ЕХЕ-программы от СОМ– и ЕХЕ-файлов. Дело в том, что в настоящее время расширение СОМ или ЕХЕ является просто признаком (кстати, необязательным) запускаемой программы. Способ загрузки программы в память и ее запуска определяется операционной системой по внутреннему формату программы. Этот факт часто не учитывали авторы первых вирусов, что приводило к уничтожению некоторых программ вместо их заражения.

СОМ-программа представляет собой часть кода и данных, которая начинается с исполняемой команды и занимает не более 64Кбайт. Например, такую структуру имеет командный процессор СОМ– МАND.СОМ операционной системы MSDOS до версии 6.22 включительно.

Структура ЕХЕ-программы гораздо сложнее. В начале файла ЕХЕ-программы располагается заголовок (см. приложение). Поля ReloCS и ExeIP определяют расположение точки входа в программу, поля ExeSP и ReloSS – расположение стека, поля PartPag и PageCnt – размер корневого сегмента программы. Размер некоторых программ, вычисленный по полям 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».

б) Windows 3.11 и Windows 95 сначала запустились корректно, но затем продемонстрировали разноцветные горизонтальные полосы в видеорежиме 800x600x256 (вирус не заражал какие-либо драйвера, просто в момент старта Windows в памяти находился вирусный обработчик прерывания INT 21h).

Излечение пришло после использования антивирусов:

DrWeb c: /cup /al

и

AidsTest c: /f /g /q

3. При помощи ранее описанных методов заразим две приманки: TEST. COM и TEST.EXE. Увеличение их длины на 1740 байт можно увидеть только на «чистой» машине (Stealth-эффект). Несколько слов об инструментарии. Вообще говоря, выбор дизассемблеров весьма широк. В свое время была широко известна программа DisDoc. По признанию Е. Касперского, он активно пользуется интерактивным дизассемблером IDA. Быстро просмотреть код программы позволяет утилита HackerView. Также возможно использование любого отладчика. В данном случае для изучения кода зараженных приманок использовался дизассемблер Sourcer v5.04. Несмотря на отсутствие некоторых полезных опций и ошибки при дизассемблировании (достаточно редкие), пользоваться программой удобно – упакованная PkLite, она занимает на дискете всего 48Кбайт.

Итак, запускаем дизассемблер командой sr test.сом. На экране появилась темно-синяя лицевая страница. Нажав клавишу «a», можно перейти на страницу опций. Рекомендуется установить опцию «a» – обязательно дизассемблировать фрагмент программы, располагающийся после команд jmp/ret/iret – это позволяет получить ассемблерный код тех фрагментов программ, в которые нет явного перехода (процедуры обработки прерываний, скрытые подпрограммы и так далее). Нажав Enter, вернемся на первую страницу. Запустим процесс дизассемблирования нажатием клавиши «g». В зависимости от производительности компьютера, процесс дизассемблирования длится от нескольких секунд до нескольких минут. Для грубой оценки размера листинга можно принять, что один килобайт кода соответствует десяти-пятнадцати килобайтам текста. 6740 байт зараженной приманки дают 96Кбайт текста+файл test.sdf. Этот очень интересный файл хранит в текстовом виде как опции, использованные при дизассемблировании, так и параметры полученного текста (размещение фрагментов кода и данных, место расположения символических имен и прочее). Если изменить эти параметры, переименовать файл в test.def и передать его Sourcer в командной строке в качестве параметра, то дизассемблер будет работать в соответствии с новыми инструкциями. Аналогичную операцию проделаем для файла test.ехе.

4. Займемся анализом полученного листинга. Поверхностно изучая зараженные приманки, видим:

– файлы увеличили свою длину на 1740 байт;

– в их конце явно видны посторонние коды;

– изменилось время создания файлов, точнее, изменилось количество секунд – оно стало равным 60;

– в начале файла test.сом появилась команда jmp;

– в заголовке файла test.ехе изменились значения полей ReloCS, ExeIP, 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: