Идите вы на хуй, короче, ёбаные суки козлы, идите вы на хуй в пизду!

Уж нету терпения гадское блядское это всё видеть курлы блядь мурлы

Идите вы на хуй, спиною вперёд блядь и кланяясь: "Слушаюсь, сэр, и иду",

Идите вы на хуй, и быстро при этом, и хуй вам на рыло, козлы!

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

Рассмотрим реализацию, основанную на технологии конечных автоматов (еще говорят switch-технология). Введем внутренние состояния автомата.

• 0 - до первого (до '-') числа

• 1 - внутри первого числа

• 2 - до второго (после '-') числа

• 3 - внутри второго числа

• 4 - конец строки (после последнего символа)

• 5 - ошибка синтаксиса

Тогда программа представляется в таком виде:

Тогда таблица действий при переходах между состояниями выглядит так:

Простой исходник на си будет выглядеть так:

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

Полученный код, будучи скомпилированным с оптимизацией, крайне труден для дизассемблирования, и вот по какой причине: при попытке его восстановления в классические си-конструкции, типа for, while, if-else, останутся "лишние" goto, и если их будет много, то понять смысл будет исключительно сложно.

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

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

Теперь рассмотрим более сложный исходник:

Как видим, последний пример написан без команд сравнения и условных переходов.

В таком виде программа представляет собой цикл из трех частей: в первой части анализируются внешние данные (здесь это строка символов), и преобразуются в некоторые внутренние переменные (здесь это показано неявно через массив T[]), затем вычисляются переходы по таблицам между состояниями (здесь это первый switch), и одновременно на каждом таком переходе выбирается из таблиц номер действия (здесь это опять же первый switch и переменная A), и в третьей части цикла выполняется некоторое реальное действие (здесь это второй switch).

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

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

Подобные таблицы могут быть преобразованы в функцию.

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

Таким образом работа программы будет заключаться в итерации такого цикла:

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

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

Рассмотрим следующий вариант.

Состояниями являются значения регистров EAX..EDI, а номером действия является численное значение байтов, определяющих некую инструкцию, дополненную либо NOP'ами либо командой RETN.

Тогда ВСЯ наша программа будет являться... функцией.

Изначально, на вход этой функции подается, к примеру, EAX = 2, ECX = 3, остальные = 0, команда NOP. Тогда число будет, например, таким:

На выходе функция дает результат:

что соответствует команде inc ecx, и тем же самым состояниям-значениям регистров.

Тогда мы выполняем полученную команду, и меняется состояние ecx, и мы подаем в функцию такое число:

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

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

Возникает вопрос: как построить такую функцию.

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

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

Поэтому рассмотрим упрощенный вариант.

Аргументом функции будет номер состояния. Результатом будет число размером в WORD. Старшим байтом результата будет первый байт опкода. Младшим байтом будет номер состояния, а его младшим битом -- значение флага ZF. Поэтому появится возможность убрать из программы команды вида JZ/JNZ, и закодировать их посредством переходов между состояниями. Сама программа будет криптовать текстовую строчку.

Исходный код программы:

Функция, заданная таблицей:

Теперь сгенерируем функцию. Пусть это будет полином. Хоть и тривиально, но интересно.

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

Нахуячим простенькую програмку по подсчету коэффициентов полинома: см. (1)

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

Или же, в более приятном виде:

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

Вот программа, полученная в результате всех этих извращений:

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

После этого, если программа не была спроектирована как конечный автомат, так, как это показано в начале статьи, то можно будет реверсировать ее в классические си-конструкции типа if, for, while.

Теория

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

Предположим, что в качестве переменной части состояния автомата был бы использован не флаг ZF, а, скажем, значение регистра AL. Тогда для получения всей информации, закодированной в функции, на каждом шаге пришлось бы анализировать 256 вариантов. А если бы это был регистр AX, то при проверке первых двух байт файла на MZ, из текущего состояния было бы 65534 перехода на одну ветвь исполнения, и 2 перехода на другую ветвь.

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

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

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

---

Приложение (1): программа для подсчета коэффициентов полинома

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

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

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

Код, который (и только который) я рассматриваю -- это 32-битный x86-код. Однако, приведенный в этой статье дизассемблер может быть элементарно преобразован для работы с 16-битным кодом.

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

Когда-то давным давно (в 1997 году) я еще не знал, до какой степени универсальный дизассемблер -- полезная штука; поэтому в движке ZCME было написано так:

Как видно, это дизассемблер, заточенный под конкретный набор инструкций; каковые и были использованы в ZCME-based вирусе.

Позже, в следующем таком вирусе, дизассемблер пришлось дополнить. И в следующем через один вирусе, его тоже пришлось изменить. И так прошло три года... ;-)

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

Как видно из примера выше, мне были нужны одни только длины инструкций; все остальное же заключалось в проверке опкода на EB, E8, E9, 7x, 0F 8x, и т.п.

Но есть случаи, когда кроме длины хочется знать о инструкции еще что-то; и тогда дизассемблер становится чуть сложнее.

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

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

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

В конце текста приведен фрагмент кода на C++, позволяющий разобрать заданную инструкцию на составляющие. Вызывается оно так:

В результате чего из процедуры возвращается 1 если все ок, и 0, если наступил локальный пиздец -- попалась неизвестная инструкция.

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

Переменные

Сборка инструкции из всего вышеприведенного отстоя, выглядит так:

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

В качестве бонуса, для тех кто не знает C, разъясню, что такое *xz++. Это, во первых, чтение/запись из адреса памяти, коий хранится в переменной по имени xz, а, во-вторых, инкремент этой переменной. Другими словами, это LODSB при чтении и STOSB при записи.

Собственно, это все.

DISASM.CPP

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

Надо сказать, что подобное желание возникло уже после того, как я прочувствовал все плюсы использования готовых компонент для создания вирусов. Были созданы движки LDE32, KME32, ETG, CMIX, DSCRIPT, EXPO, RPME, CODEGEN, PRCG, MACHO и MISTFALL, обладающие почти всеми свойствами, описанными в этом тексте. Однако даже и тех небольших преимуществ от попытки эти движки стандартизировать было достаточно чтобы понять всю важность приведения движков к некоторому "стандартному" виду. Следует сразу заметить: подобная "стандартизация" влияет скорее на алгоритм и внешний вид, чем на код, и ни коим образом не может послужить упрощению работы антивирусов.

КОД

• Движок должен содержать только исполняемый код. Таким образом движок не должен содержать никаких данных в явном виде. (достигается генерацией данных кодом)

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

• Движок не должен непосредственно использовать никаких внешних данных и не должен непосредственно вызывать никаких внешних процедур. (достигается передачей движку указателей на данные/код)

• Движок не должен содержать никаких непосредственных системных вызовов. Хотите работать в движке с файлами? - пишите свои процедуры работы с файлами, так, как это удобнее в конкретном вирусе, передаете на них указатели и движок становится универсальным.

PUBLIC-функции

Параметры каждой функции должны передаваться только на стэке. Каждая функция должна сохранять и восстанавливать все регистры. При выходе из функции флаг DF должен быть сброшен в 0 (CLD). Результат (если он нужен) должен возвращаться в регистре EAX.

ИСХОДНИКИ

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

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

ДОКУМЕНТАЦИЯ

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

• описание движка;

• описание PUBLIC-процедур и их параметров;

• описание замеченных глюков (т.е. фич);

• где движок тестировался, то есть когда он точно работает, когда не работает, а когда хз;

ЖЕЛАТЕЛЬНО

Чтобы в движке существовала одна (и только одна) PUBLIC-функция, которая бы шла В НАЧАЛЕ исполняемого кода (хотите в середине - вставьте в начало JMP), и чтобы написана она была в стиле cdecl (RET с последующим ADD ESP, xx) или pascal-функции (выход по RET nnnn).

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

Чтобы движок был написан инструкциями real 386, то есть чтобы отсутствовали привилегированные инструкции/регистры и все 486+ инструкции вообще.

ЧТО В РЕЗУЛЬТАТЕ

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

Более того, решается просто глобальная задача связи asm- и cpp- кода, без использования obj-ей.

ПРИМЕР ОФОРМЛЕНИЯ ДВИЖКА

Движок: KILLER. Задача: произвести зависание с вероятностью 1/1000.

Исходник:

Полученный в результате инклюдник на ASM:

Тот же самый инклюдник на C/C++:

Инклюдник/хеадер на ASM:

Инклюдник/хеадер на C/C++:

Пример вызова движка на ASM:

Пример использования на C/C++:

Пример программки для компиляции исходника движка:

Пример программки для выдирания бинарной (DB,DB,...) версии движка из скомпиленного EXE-файла:

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

Заметим, что все это написано без использования оффсетов как таковых.

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

• данные содержатся отдельно от кода и шифруются переменным ключом

• данные генерируются кодом

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

Теперь представим себе, что мы пишем вирус в соответствии со следующим правилом: в вирусе может присутствовать только код. И нам нужно использовать данные вида "C:\WINDOWS\*.EXE",0.

Удобно генерировать такую строку двумя путями:

Здесь возникает две проблемы. Во-первых, части строки будут "видны" в коде вируса, что не есть хорошо. Во-вторых, при большом количестве данных набивать подобную хрень непросто.

Вывод: требуется макрос для преобразования данных в код. В конце текста как раз и представлены такие макросы. Вызываются они так:

Сгенеренный макросами код выглядит так:

Вот сами макросы:

_(x) 2000 Z0MBiE, http://z0mbie.host.sk_

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

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

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

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

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

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

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

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

Где будут хранится хеши? Хеши могут хранится в зашифрованном виде в самом вирусе; достаточно большая база хешей может хранится в распределенном виде, когда носителями являются интернетовские машины; и эти хеши, что более интересно, могут подключаться так же, как и обычные вирусные плугины. Но что значит - подключить десяток хешей к такому вирусу? А это значит, что у антивирусов появится потенциальная возможность пропустить уже хотя бы один зараженный файл -- из которого потом вновь разовьется эпидемия.

Как разбить вирус на элементы? Если вирус пишется на ассемблере, это придется делать руками. Если вирус пишется на hll, то это проще сделать автоматически: например компилять из c++ в ассемблер.

Какими должны быть элементы? Понятно, что они должны состоять из целых инструкций, поскольку множество комбинаций этих инструкций крайне велико: очень много программ, и как минимум половина их "объема" - это код. В принципе, длины элементов не ограничены ни чем. Однако, есть одна трудность. Для хорошей "морфности" такого вируса, в нем должно быть два типа вариантов элементов. Несколько вариантов -- те, которые встречаются очень часто; для того, чтобы у вируса была возможность постоянно изменяться; см.выше - номера 1,2,3. Оставшаяся же часть вариантов -- это те куски кода, которые встречаются достаточно редко. Для того, чтобы их было сложно найти, но вместе с тем и существовала вероятность того, что они будут найдены. Например - что-нибудь вроде варианта 4.

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

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

---

Исходя из этого, задача разбивается на 3 части, или же три глобальных вопроса: ЧТО?, КУДА? и КАК?.

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

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

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

Теория

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

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

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

Исходя из сказанного, необходимо разобрать весь файл в некоторую легко изменяемую сущность, изменить ее, и собрать файл заново.

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

Итак, нашу задачу можно разбить на 5 этапов:

1. Загружаем PE файл в память по виртуальным адресам; создаем таблицу флагов и выставляем в ней биты, указывающие, являются ли соответствующие дворды указателями/длинами, и какими. То есть проводим начальный анализ структуры файла.

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

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

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

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

Проблемы дизассемблирования

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

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

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

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

Можно было бы работать только с файлами определенного вида, а именно, такими, в которых в кодовой секции находится только код и ничего больше. Но это как раз то, чего не хотелось бы делать. Ведь нам надо, чтобы антивирусы проверяли КАЖДЫЙ файл по пол-часа. Да и мало таких файлов.

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

Практика

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

• проверяем PE файл на валидность (наличие таблицы фиксапов и т.п.)

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

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

1. досовскую часть и PE заголовок файла

2. секции файла

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

• разбираем импорты

• разбираем экспорты

• разбираем фиксапы

• разбираем ресурсы

• ищем в файле начала процедур по сигнатурам (типа push ebp/mov ebp,esp) и помечаем их для-последующего-анализа

• помечаем точку входа

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

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

• изменяем список; во время отладки я вставлял NOP'ы между всеми инструкциями файла

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

• пересчитываем таблицу фиксапов

• пересчитываем значения указателей (т.е. rva, фиксапов и относительных смещений условных переходов); если некоторые условные переходы пришлось увеличить, то повторяем все с пересчета виртуальных адресов

• ассемблируем список (собираем все данные в один массив)

• записываем файл на диск

• дописываем к концу файла оверлей, если он был

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

Что означают фразы типа "разбираем PE заголовок" / "разбираем импорты"? Это значит, что мы выделяем среди них метки, указатели и другие специальные объекты и выставляем для них во флагах соответствующие биты. Например, байт по адресу pe_header+28h (28h=EntryPointRva) поимеет флаги типа FLAG_DWORD и FLAG_RVA, а тот адрес, на который он показывает, будет обозначен как FLAG_LABEL и FLAG_CREF.

Какие специальные объекты будут присутствовать в списке?

1. Метки, то есть то, на что ссылаются RVA и FIXUP'ы.

2. RVA, то есть дворд, который указывает на метку.

3. FIXUP, то есть дворд, такой же как RVA, но + IMAGEBASE, притом адрес должен быть занесен в таблицу фиксапов.

4. так называемая DELTA, то есть разница между адресами двух меток.

5. инструкция

6. блок данных

Теперь о том, как мы отличаем код от данных. Напомню, что мы рассматриваем адрес на который есть ссылки только через указатели (rva и fixup'ы), но нет ссылок через call/jmp. Итак, берем предполагаемую процедуру и разбираем ее по одной инструкции. Для каждой инструкции проверяем, не является ли она глючной, типа 00 00, FF FF, F4 (hlt), CD (int), и т.п., то есть таким опкодом, который в процедурах PE файлов не встречается.

Если какой-либо из байтов предполагаемой инструкции содержит флаги типа "метка" или "данные", то это не процедура. Если инструкция имеет относительный адрес (jmp, call, jxx, jecxz,...), то он должен показывать на что-нибудь приличное, то есть не в блок данных и не в середину другой инструкции. Повторяются же такие проверки до тех пор, пока не будет найден RET или JMP.

Однако, есть и такие ситуации, когда отличить код от данных достаточно сложно. Например, такой объект, как метка (label), вроде бы не может присутствовать в середине инструкции, сгенеренной hll компилятором. Но вот - нихрена подобного. Очень даже может. Рассмотрим типичный случай.

Как видно, адрес 100050F0 находится в середине инструкции (2), и в то же время используется в инструкции (1). Почему так происходит, догадаться несложно. В результате, о инструкции (2) нельзя с полной уверенностью сказать, является ли она кодом или данными. То есть, автоматически нельзя определить, было ли в исходнике написано 100050F4 - 4 или 100050EC + 4. Короче говоря, нет возможности пофиксить такой поинтер, и файл придется оставить в покое.

Или вот, замечательный пример от дяди Рошаля.

И, в дополнение ко всему прочему, бывает еще одна хуевая фишка. Это куски 16-битного кода в 32-битных приложениях, типа антивирусов и форматеров. Со всеми проистекающими отсюда глюками.

Движок

Несмотря на все глюки, движок почему-то работает. Называется движок МИСТФАЛЬ, есть такой рассказ у Джорджа Мартина, "Мистфаль приходит утром".

Движок написан на борман C++, правда без классов и прочих фич. Основная функция engine() с хуевой кучей параметров, идет, как и следует, самой первой, а после нее есть еще несколько внутренних подпрограммок. Все это дело называется kernel (не путать с маздайным) и находится в файлах engine.cpp & .hpp; соответственно код и константы.

Из кернела вызывается так называемый внешний юзерский мутатор (mutate.cpp), коий может и должен быть модифицирован пользователем. Мутатор, то есть, собственно инфектор, оперирует исключительно со списком из структур, которые будем называть хуйнями (hooy), ибо мозги уже отказывают. В хуйнях могут быть метки, опкоды, блоки данных, словом все то, о чем говорилось в начале. Да и вообще, вся технология описания движка точно такая же, как и в RPME, только RPME был заточен на вирусы, а мистфаль предназначен для работы с PE файлами.

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

1. Найти две любые подряд идущие инструкции; после первой инструкции вставить JMP на вторую, а после JMP'а - зашифрованое тело вируса.

2. Аналогично для декриптора.

3. Аналогично для команды вызова декриптора.

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

Применение в вирусах

Прежде всего, движок жрет не просто много, а очень много памяти. При этом, может получиться глюк на кривом файле; да и на нормальном тоже. Аллокация памяти, как и в RPME, предоставляется движку пользователем. Перед вызовом движка выделяйте дохуя памяти, мегабайта 32.

Стратегия аллокации весьма специфическая: движок будет только запрашивать память, и никогда -- отдавать. Однако для каждого файла используется одна и та же память, т.е. после возврата из движка все количество выделенной памяти нужно сбросить в 0. То есть произвести такой глобальный release. Реально движок использует (17*SizeOfImage) байт на временные линейные массивы, плюс байт по 40 на каждую инструкцию/запись списка.

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

Движок мог бы работать в ring-0. Но из-за большого количества требуемой памяти возможны всякие глюки.

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

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

Специальные фичи

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

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

Библиотека сигнатур

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

В задачи мэнеджера сигнатур входят 2 функции:

1. поиск в файле кусков кода и

2. добавление информации о новых кусках кода в библиотеку

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

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

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

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

Какие преимущества дает библиотека сигнатур? Вроде бы, надо для каждого байта файла делать CMPSB с тысячами сигнатур. Но ведь есть такой рулез, как бинарный поиск. Так что времени уходит мало.

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

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

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

Z0MBiE

Существуют ассемблерные команды DIV и IDIV, выполняющие деление -- беззнаковое и со знаком. На вход командам подается делимое, находящееся в регистрах AX либо DX:AX либо EDX:EAX, и делитель, находящийся в байте, ворде либо дворде соответственно. Частное и остаток от деления возвращаются в регистрах AL:AH, AX:DX либо EAX:EDX. Поскольку разрядность делимого в два раза больше возможной разрядности частного, то возникает ряд ситуаций, когда процессор вместо деления генерирует исключения по переполнению (EXCEPTION_INT_OVERFLOW) либо по делению на 0 (EXCEPTION_INT_DIVIDE_BY_ZERO).

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

Собственно об этих проверках в эмуляторах мы и будем говорить дальше.

Эмулятор от г-на Данилова: drweb32.dll web/div8 web/div16 web/div32 web/idiv8 web/idiv16 web/idiv32

---

Эмулятор от г-на (ага, то что вы подумали) Богданова: kernel.avc/emul.obj avp/div8 avp/div16 avp/div32 avp/idiv8 avp/idiv16 avp/idiv32

---

Комментарии

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

Из 12 процедур 100% алгоритмически грамотные проверки присутствуют только в 5-ти. Хотя, конечно, проверки на наябки есть везде, и ни одного ошибочного варианта пропущено не будет. Однако вместе с ошибочными вариантами в большинстве случаев отсекаются и нормальные комбинации чисел.

1. Подпрограммы div8 и div16

богданов: алгоритм правильный; код минимальный.

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

И, хотя и радует программистская смекалка: (вместо байтов поделил ворды, а вместо вордов - дворды), но зачем сделал проверки на переполнение? не будет его.

2. Подпрограмма div32

богданов: алгоритм правильный; код минимальный.

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

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

3. Подпрограмма idiv8

богданов: алгоритм неправильный. Делит только числа меньше 128 (а их 65536), нет проверки на переполнение.

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

Однако, при AX=C0FF и, скажем, CL=81, команда IDIV выполнится нормально, а веб перейдет к эмуляции INT0.

4. Подпрограмма idiv16

богданов: алгоритм неправильный. Делит только числа меньше 32768 (а их 2^32), нет проверки на переполнение.

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

Однако, при DX=C000, AX=FFFF, и, скажем, CX=8001, команда IDIV выполнится нормально, а веб перейдет к эмуляции INT0.

5. Подпрограмма idiv32

богданов: алгоритмически неправильно, так как делит только числа меньше 80000000h, а их 2^64, и нет проверки на переполнение.

данилов: процедура отсутствует напрочь.

---

Итоги программерского компетишена

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

Однако, данилов подает надежды, что не все потеряно: видны попытки написать правильный код, причем ясно, что изменения вносились несколько раз; есть даже такие умные вещи, как проверка на переполнение, попытка проверки на нулевое делимое, и нечто - уже совсем близкое - к корректной проверке перед IDIV-ом.

Касательно этой проверки перед IDIV-ом, надо сказать, что - весьма похоже - что это все откуда-то неправильно содрано. Но нам важно не это.

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

---

В итоге, выигрывает Данилов!

Эпизод 1

Богданов, согнувшись, придерживая руками шляпу, прыжками сбегает по лестнице, в надежде достичь выхода. Но не тут-то было. И вот его, пурпурно-красного, изрыгающего страшные проклятия, царапающего когтями пол, упирающегося, дрыгающегося и разбрызгивающего в разные стороны ядовитые сопли, за ноги подтаскивают к дверям (вниз - ступеньки), берут за руки/ноги, медленно раскачивают... нет, это уже было... ставят раком, и с разбегу дают ОХУИТЕЛЬНОГО пинка, от чего он, приобретя ускорение, грациозно пролетает несколько метров, и, наебнувшись на ступеньках, раскинув в стороны руки, падает в лужу. Раздается всплеск... По луже идут круги... Осень, вечер, дует холодный ветер и падает мокрый снег...

Эпизод 2

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

---

Зачем это было

Теперь резонно рассказать, нахрена я за это взялся. Все дело в том, что мне тоже понадобилось выяснить, можно ли выполнять команду IDIV (для двордов), в процессе переделывания движка KME.

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

А потом решил проэмулировать команду IDIV целиком. А хули?

---

Подпрограмма IDIV

Подпрограмма, эквивалентная команде IDIV, возвращает CF=1 вместо INT0.

Ну вот собственно и все... А вы чего ждали?

(x) 2000 Z0MBiE

<http://z0mbie.host.sk>

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

Итак, надо научиться генерить код:

• выполнящий определенные нужные нам действия

• полиморфный

• по возможности максимально похожий на код сгенеренный hll-компиляторами

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

Два сгенеренных таким образом вируса могут различаться:

• на уровне алгоритма

• на уровне команд

Уровень алгоритма здесь означает примерно следующее: вирус состоит из "блоков", на каждый из которых имеется несколько вариантов, отличающихся по своей сути. Например переход в ring-0 через IDT либо GDT либо INT 2E либо VMM/..., заражение файлов в хеадер либо в последнюю секцию, и т.п.

Уровень команд означает что каждая "строка" псевдо-языка, в котором представлены такие алгоритмические блоки может быть представлена различными ассемблерными инструкциями, такие строки могут также иметь несколько вариантов, могут быть изменены и перемешаны.

Вот как это выглядит:

задача: вычислить выражение f(x)=10*sin(2*x)

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

Итак, вот мы выбрали один из алоритмов. Вопросы тут такие:

• каким образом его реально закодировать и

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

Генерацию именно ассемблерного кода пока оставим, а все инструкции будем представлять в виде текста. Короче говоря, пишем вирусный конструктор. Чтобы потом из конструктора сделать компилятор, вместо writeln('nop') (для наглядности будем юзать паскаль) надо просто генерить сооветствующие опкоды.

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

• использовать фиксированный набор команд (как и поступают hll-компиляторы)

• [по желанию] использовать огромное количество мусора изменяющего регистры

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

Итак, на уровне переменных нам достаточно следующих основных команд-макросов:

Уровень переменных Уровень регистров

Используются предыдущими макросами.

Чтобы продемонстрировать уровни команд и регистров, напишем такую вот несложную программу-препроцессор: asmx.pas.

Вызывается программа так: asmx.exe 1.src 1.asm.

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

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

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

•

(x) 2000 Z0MBiE

<http://z0mbie.host.sk>

ASMX.PAS 1.SRC 1.ASM

• Введение

• Переход в RING-0

• Работа с памятью

• Работа с портами

• Процессы и нити

• Прочие функции

• Коментарии

Введение

Рассмотрим некую Win32-программу. Как известно, программа эта вызывает kernel, а kernel уже вызывает ring-0.

Под Win9X VMM/VWIN32 реализует специальные сервисы для kernelа. Вызываются они так:

где service-number -- номер сервиса, например 0x002A0010 для INT 21, 0x002A0029 для INT 31, и так далее. Надо сказать, что с номерами VxD-callов эти сервисы не имеют ничего общего. Найти полный список соответствий всяких номеров именам сервисов можно в питреке.

Под WinNT ноль вызывается из кернела посредством INT 2E.

Но, как выяснилось, в маздае в VMMе существует NTKERN.VXD, коий реализует NT-евые сервисы. Называются они типа ntoskrnl!DbkBreakPoint и вызываются так же -- через INT 2E. И, о чудо, у такого рулезного инта DPL=3, то есть его можно вызывать прямо из PE файла. Более того, в обработчике нет никаких хитрожопых проверок - типа откуда пришел вызов.

Дальше-интереснее. Оказывается, INT 2E активно используется при загрузке маздая. А во время работы маздай может пользовать функции типа ntoskrnl!NtPowerInformation.

Короче говоря, можно вызывать INT 2E из PE файлов одним из следующих способов:

Как видим, при вызове INT 2E в EAX должен быть номер сервиса, а в EDX указатель на кадр стэка. Перед тем как вызвать соответствующую функцию, обработчик инта копирует данные из *EDX в свой стэк.

Список всех номеров и имен функций лежит в ntoskrnl.inc.

Далее идут описания некоторых наиболее интересных функций INT 2E.

Переход в RING-0 PsCreateSystemThread

Тут все и так ясно. Создаем нить прямо в нуле. При выходе из нити (по RET) она автоматически убивается ф-цией PsTerminateSystemThread.

PoCallDriver

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

Кадр стэка выглядит так:

А реальный код, коий я по возможности соптимизировал, такой:

Работа с памятью

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

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

RtlCopyMemory, RtlMoveMemory

Отличаются эти две функции тем, что RtlCopyMemory просто берет и копирует буфера командой movs, а RtlMoveMemory сначала анализирует esi и edi, а потом копирует буфер по одному байту, причем начиная либо с начала либо с конца буфера. Таким образом RtlMoveMemory корректно обработает перекрывающиеся области esi...esi+ecx и edi...edi+ecx.

READ_REGISTER_BUFFER_UCHAR/ULONG/USHORT

Реализации команд REP MOVSB, REP MOVSD и REP MOVSW соответственно.

WRITE_REGISTER_BUFFER_UCHAR/ULONG/USHORT

Аналогично предыдущим: REP MOVSB, REP MOVSD и REP MOVSW, НО источник и приемник поменялись местами.

READ_REGISTER_UCHAR/ULONG/USHORT

Считать BYTE/DWORD/WORD. (MOV AL,[ESI], MOV EAX,[ESI] и MOV AX,[ESI])

Значение возвращается в EAX.

WRITE_REGISTER_UCHAR/ULONG/USHORT

Записать BYTE/DWORD/WORD. (MOV [EDI],AL, MOV [EDI],EAX и MOV [EDI],AX)

Работа с портами READ_PORT_BUFFER_UCHAR/ULONG/USHORT

Выполнить REP INSB, REP INSD и REP INSW соответственно.

WRITE_PORT_BUFFER_UCHAR/ULONG/USHORT

REP OUTSB, REP OUTSD и REP OUTSW.

READ_PORT_UCHAR/ULONG/USHORT

Выполнить IN AL,DX, IN EAX,DX и IN AX,DX соответственно.

WRITE_PORT_UCHAR/ULONG/USHORT

OUT DX,AL, OUT DX,EAX и OUT DX,AX.

Процессы и нити IoGetCurrentProcess, PsGetCurrentProcess

Обе функции указывают на один и тот же обработчик. Хендл текущего процесса возвращается в EAX.

Обработчик GetCurrentProcess'а изнутри реализует следующее:

KeGetCurrentThread, PsGetCurrentThread

Опять один и тот же обработчик. Хендл текущей нити возвращается в EAX.

Прочие функции KeQuerySystemTime Коментарии

Совершенно непонятно как обстоит дело с функциями для работы с файлами. (IoCreateFile, NtCreateFile, ZwCreateFile, ZwReadFile, ZwWriteFile, DeviceIoControlFile, etc.)

Я слышал, есть книжка про недокументированные возможности WinNT. Но те параметры, которые там описаны для соответствующих функций, передаются из программы в кернел, а ведь из кернела в ноль передаются уже совсем другие вещи, даже число параметров не совпадает. Ну а трассировать обработчик CreateFile выясняя все его 11 хитроизъебских параметров -- как-то лениво.

Существуют также функции для работы с registry. (RtlDeleteRegistryValue, RtlQueryRegistryValues, RtlWriteRegistryValue, IoOpenDeviceInterfaceRegistryKey, IoOpenDeviceRegistryKey, может быть -- ZwCreateKey, ZwDeleteKey, ZwEnumerateKey, ZwEnumerateValueKey, ZwOpenKey и т.п.)

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

Большинство функций, для которых не указано число параметров (в ntoskrnl.inc написан -), являются ВНУТРЕННИМИ, то есть параметры им передаются, но не на стэке а в регистрах, и вызвать их, минуя похеривание регистров в обработчике INT 2E нет никакой возможности.

Обычно эти функции написаны полностью маленькими буквами или начинаются с подчеркивания, типа memmove, memset, qsort, rand, sprintf, _except_handler2, _global_unwind2 и т.п.

•

См. также примеры в ntoskrnl.zip.

(c) 2000 Z0MBiE

<http://z0mbie.host.sk>

Это просто стандартные апи-функции третьего кольца.

Суть заключается в вызове всего одной функции: SetThreadContext. Эта функция устанавливает контекст, то есть все регистры для заданной нити.

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

Таким образом мы подлавливаем момент, когда в контексте текущей нити управление находится в нулевом кольце, а затем правим CS и EIP возврата на 28h и адрес-процедуры-нулевого-кольца.

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

Почему нельзя изменить один только CS на 28h? Потому, что тогда управление вернется в кернел, а кернеловский код в нулевом кольце сглючит, так как до начала работы надо переустановить сегментные регистры в 30h.

Вот собственно и все. Рабочий пример в CONTEXT.ASM.

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

P.S.

Улучшенный вариант перехода в 0 находится в CONTEXT2.ASM: здесь приходится организовывать свой стэк, зато можно вызывать VxDcall-ы.

Еще более простой вариант в CONTEXT3.ASM: здесь мы обходимся вообще без создания новой треады и прочей хуйни. Эта версия наиболее приближена к нормальному использованию в вирях.

(x) 2000 Z0MBiE, http://z0mbie.host.sk

Итак, нашей задачей (как обычно) является произвести НСД - а именно запись в защищенный для записи адрес X. (все это, ясное дело, из PE файла)

О том что в адрес X писать нельзя, можно узнать двояко - либо одной из функций IsBadXXXPtr, где XXX - Read, Write, Code и т.п., либо используя SEH. Вот оба варианта:

1. функция:

2. SEH:

Теперь переходим к вопросу: как пропатчить таблицу страниц. Для начала надо ее найти. В доке написано вот что: старшие 20 бит регистра CR3 суть физический адрес таблицы страниц, младшие 12 бит адреса равны 0 (выравнивание на страницу).

Если в PE файле написать так: mov eax, cr3 то в результате будет получен хуй. А все потому, что инструкция привилегированная, и может вызываться только из нулевого кольца. Правда, екскепшена при этом маздай не генерит, но и EAX не изменяет.

Что же делать? Можно прочитать доку по протмоде, и выяснить, что копия CR3 для текущего контекста (а надо сказать таблиц страниц может быть несколько для разных контекстов) лежит в TSS.

Где взять TSS? Селектор ейный получаем командой STR. (что-то вроде store task register) Далее все по плану:

Вот только что с ним делать, с физическим адресом из PE файла? В нулевом кольце его можно было бы транслировать в линейный, а в третьем - хуй. Поэтому такой метод не годится.

Кстати. Если вы в этом примере измените mov eax, [ecx+1Ch] на mov eax, [ecx+4], то вы поимеете ESP0, то бишь ESP того кода, который вызвал текущую задачу. Клево?

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

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

Но не все так плохо. Вышеупомянутая функция IsBadReadPtr говорит нам, можно ли читать конкретную страничку или нет. А это - уже целый бит. И точно такого же смысла бит (U/S) есть в дворде, описывающем эту же самую страничку в таблице страниц. И есть другой бит, R/W, определяющий врайтабельность страницы. Его можно получить функцией IsBadWritePtr.

Таким образом, вызывая IsBadRead/WritePtr для 1024 страниц мы генерим страницу двордов, в каждом из которых устанавливаем соответствующие биты. А затем в цикле сравниваем каждый из этих двордов с двордом текущей проверяемой странички, но сравниваем не весь дворд а только эти 2 бита.

Вот так это происходит:

Вот таким вот вышеприведенным куском кода и находится нужная нам страница из таблицы страниц, описывающая страницы в диапазоне BFC00000...C0000000.

Теперь надо изменить бит RW, скажем для адреса BFF70000. Делаем так:

Теперь у вас может (и должен) возникнуть такой вопрос: а откуда в двух примерах выше взялись числа BFC00000 и C0000000? А обо всем этом написано в приложении. Ну так вот, кратко. Все 4GB памяти делятся на 1024 куска по 4MB. Таблица страниц первого уровня описывает адреса 1024х таблиц второго уровня. А каждая из таблиц второго уровня описывает 1024 обычных страницы. Таким образом два вышеприведенных числа -- это BFF70000, округленное до 4MB в меньшую и большую сторону соответственно.

Работающий пример всего вышеописанного лежит в директории EXAMPLE1.

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

Как отсутствует? - спросите вы. Пример-то работает. А дело в том, что отсутствует она лишь до тех пор, пока не будет вызвано нечто навроде:

Примерно подобные действия наверное производит Soft-ICE, а также программа в директории EXAMPLE2. Суть вышеназванной функции заключается в вызывании VMM_PageReserve и VMM_LinPageLock, что говорит само за себя - прогружаем страничку в текущий контекст. А в голом без айса маздае не находится страничка из pagetable-а ну ни как.

Что ж делать-то, а? А вот посидел я тут ночку, и надумал такую феню. Если найти мы страничку из pagetable не можем по той причине, что ее в нашем контексте попросту нет (если мы не под айсом, конечно), то надо либо сменить контекст, либо все-таки имея CR3 научиться конвертировать физические адреса в линейные и прогружать их в память.

Второй вариант прокатил с полпинка. Как уже было сказано, EXAMPLE2 производит сие действо из нуля. А нижеследующий кусок кода делает это из третьего кольца.

Теперь, зная CR3 и умея легко коммитить физические адреса в линейные, мы имеем доступ ко всей pagetable, следующим образом:

Готово! А вызывается все это счастье таким раком:

Все это дело представлено в EXAMPLE3.

Знающие люди на этом месте скажут так: коль скоро ты умеешь вызывать INT 31, то нахуя надо вообще было все это писать? А я скажу так. Маза-то ведь была какая? Маза была не записаться в куда-то там, и не перейти в 0, а пропатчить pagetable. Так что все окей.

---

Приложение 5.3 Трансляция страниц

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

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

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

Мехпнизм подкачки страниц рассматривает 32-разрядный линейный адрес как состоящий из трех частей, а именно двух 10-разрядных индексов страничных таблиц и 12-заррядное смещение в таблице, адресуемой страничными таблицами. Поскольку как виртуальные страницы в линейном адресном пространстве, так и физические страницы памяти выравнены по 4Кбайтной границе страниц, модифицировать младшие 12 битов адреса нет необходимости. Эти 12 битов напрямую передаются аппаратному обеспечению, работающему с подкачкой страниц, независимо от того, разрешена ли подкачка в текущий момент, или запрещена. Отметим, что в этом состоит отличие от сегментации, поскольку сегменты могут начинаться с любого адреса байта.

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

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

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

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

И опять, выполняются проверки доступа, в результате которых возможна генерация исключений. Если же исключений не возникло, то старшие 20 битов элемента таблицы страниц второго уровня конкатенируются с младшими 12 битами линейного адреса, образуя физический адрес операнда (данных) в оперативной памяти.

Хотя такой процесс и может показаться сложным, затраты процессорного сремени на него невелики. Процессор имеет кеш элементов таблицы страниц, который называется ассоциативным буфером трансляции адреса (TBL). TBL удовлетворяет большинство запросов чтения страничных таблиц. дополнительные циклы шины затрачиваются только при доступе к новым страницам памяти. Размер страницы (4К) достаточно велик, поэтому по сравнению с числом циклов шины, затрачиваемых на выполнение команд и обращение к данным, число циклов для доступа к таблицам страниц относительно невелико. Одновременно с этим размер страницы достаточно мал, чтобы память использовалась наиболее эффективно. (Независимо от фактической величины структуры данных, она занимает не меньше одной страницы памяти).

5.3.3 Таблицы страниц

Таблица страниц представляет собой массив, состоящий из 32-разрядных элементов. Таблица страниц сама является страницей и содержит 4096 байтов памяти, или максимум 1Кб 32-разрядных элементов. Все страницы, включая каталоги страниц и таблицы страниц, выровнены по границе 4Кб.

Для адресации страницы памяти используется два уровня таблиц. Старший уровень называется каталогом страниц. Он адресует до 1К страничных таблиц второго уровня. Таблица страниц второго уровня адресует до 1К страниц в физической памяти. Таким образом, все таблицы, адресуемые одним каталогом страниц, могут адресовать до 1М или 220 страниц. Поскольку каждая страница содержит 4К, или 212 байтов, таблицы одного каталога страниц покрывают все линейное адресное пространство процессора i486 (220 x 212 = 2 **32).

Физический адрес текущего страничного каталога хранится в регистре CR3, который также называется базовым регистром каталога страниц (PDBR). Программное обеспечение организации памяти имеет опции использования одного каталога страниц для всех задач, одного каталога страниц для каждой задачи, либо некоторой комбинации этих двух опций. В Главе 10 приводится информация об инициализации регистра CR3. О том, как содержимое CR3 может изменяться для каждой задачи, см. в Главе 7.

5.3.4 Элементы таблицы страниц

Элементы страничных таблиц обоих уровней имеют одинаковый формат. Этот формат показан на Рисунке 5-14.

5.3.4.1 Адрес страничного блока

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

5.3.4.2 Бит присутствия

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

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

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

1. Операционная система копирует страницу с дисковой памяти в физическую память.

2. Операционная система загружает адрес страничного блока в элемент таблицы страниц и устанавливает бит Присутствия. Прочие биты, например, бит Чтения/Записи, также могут при этом быть установлены.

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

4. Выполняется рестарт программы, вызвавшей исключение.

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

5.3.4.3 Биты Доступа и "Грязная"

Эти биты содержат данные об использовании страницы на обоих уровнях страничных таблиц. Бит Доступа используется для сообщения о доступе на чтение или запись к странице или страничной таблице второго уровня. Бит "Грязная" сообщает о доступе к странице для записи.

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

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

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

О том, как процессор i486 обновляет биты Доступа и "Грязная" в многопроцессорных системах, написано в Главе 13.

5.3.4.4 Биты Чтения/Записи и Пользователя/Супервизора

Биты Чтения/Записи и Пользователя/Супервизора используются для защитных проверок страниц, выполняемых процессором одновременно с трансляцией адреса. Более подробную информацию о защите см. в Главе 6.

5.3.4.5 Биты управления кешем страничного уровня

Биты PCD и PWT используются для организации кеша страничного уровня. Программное обеспечение может при помощи этих битов управлять кешированием отдельных страниц или страничных таблиц второго уровня. Более подробную информацию о кешировании см. в Главе 12.

6.8 Защита на уровне страниц

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

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

1. Ограничения на адресуемый домен памяти.

2. Проверка типа.

Нарушение защиты приводит к генерации исключения. Механизм исключений описан в Главе 9. В данной главе описаны нарушения защиты, ведущие к исключениям.

6.8.1 Элементы страничных таблиц содержат параметры защиты

На Рисунке 6-10 показаны поля элемента страничной таблицы, которые управляют доступом к странице. Проверки защиты применяются к страничным таблицам как первого, так и второго уровня.

6.8.1.1 Ограничения адресуемого домена памяти

Для страниц и сегментов понятие привилегированности интерпретируется по-разному. Для сегментов существует четыре уровня привилегированности, лежащих в диапазоне от 0 (высший уровень привилегированности) до 3 (низший уровень привилегированности). для страниц существует два уровня привилегированности:

1. Уровень супервизора (U/S=0) - для операционной системы, прочего системного программного обеспечения (например, драйверов устройств), а также для защищаемых системных данных (например, страничных таблиц).

2. Уровень пользователя (U/S=1) - для прикладных кодов и данных.

Уровни привилегированности, используемые в сегментации, отображаются в уровнях привилегированности страниц. Если CPL равен 0, 1 или 2, то процессор работает на уровне супервизора. Если же CPL равен 3, то процессор работает на уровне пользователя. Когда процессор работает на уровне супервизора, все страницы являются доступными. Когда процессор работает на уровне пользователя, доступны только страницы, имеющие уровень пользователя.

6.8.1.2 Проверка типа

Механизмом защиты распознаются только два вида страниц:

1. Доступ Только для Чтения (R/W=0)

2. Доступ на Чтение/Запись (R/W=1).

Когда процессор работает на уровне супервизора при очищенном бите WP в регистре CR0 (в состоянии бита, соответствующем инициализации при сбросе системы), все страницы являются одновременно доступными для чтения и записи (признак защиты записи игнорируется). Когда процессор работает на уровне пользователя, то для записи доступны лишь страницы уровня пользователя, помеченные признаком Чтение/Запись. Страницы уровня пользователя, помеченные для Чтения/Записи или Только для Чтения, являются доступными для чтения. Страницы уровня супервизора с уровня пользователя недоступны ни для чтения, ни для записи. При попытке нарушения прав доступа к защищенным страницам генерируется исключение общей защиты.

В отличие от процессора 386 DX процессор i486 позволяет защищать страницы уровня пользователя от записи в режиме доступа супервизора. Установка бита WP в регистре CR0 включает чувствительность режима супервизора к защите страниц от записи в режиме пользователя. Это средство полезно для реализации стратегии "записи-на-копии", используемой некоторыми операционными системами, например UNIX, для создания задачи (это средство также называется порождением параллельных процессов или просто порождением).

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

---

(x) 2000 Z0MBiE, <http://z0mbie.host.sk>

Вот есть у нас заражение PE файлов.

1. Можно директом изменять адрес точки входа (EntryPointRVA). Это отлавливается эвристикой даже без эмуляции. (типа, точка входа показывает в конец файла? ну и пиздец ему)

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

3. Можно впатчивать JMP на себя в случайное место программы. Это кардинально лучше первых двух способов. Но тут нет гарантий, что вы попадете именно в код, а не в данные, да еще и непосредственно на начало инструкции. А если используете в качестве начала PUSH EBP/MOV EBP,ESP и им подобную хрень, то такую точку входа будет относительно просто найти. Да и вообще, сканирование файла и проверка всего, куда показывают JMPы/CALLы -- штука несложная. Но самый главный минус в том, что неизвестно, когда выполнятся ваши впатченные инструкции, и выполнятся ли вообще.

4. Анализ кода без его выполнения. Лучше всего такую фишку проводит IDA в комбинации с мозгами. Похожие, но сильно упрощенные алгоритмы я использовал в: ZCME/AZCME(dos) и RPME/CODEPERVERTOR(win32). Эти вещи работают относительно быстро, и неплохо выделяют код среди данных, хоть и не весь. Но и здесь есть качественный недостаток. В случае, если, например, какой-нибудь участок кода не выполняется никогда, а например условный переход (Jxx) на него существует, этот код будет проанализирован вместе с "нормальным".

5. Трассировка. А вот эта вещь позволяет не только пометить выполняемый (а не весь) код, но и узнать ПОРЯДОК выполнения инструкций и подпрограмм.

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

Итак, сам вирус, как пиздец зашифрованный, может лежать где угодно в файле. А передавать ему управление по-идее мог бы JMP, впатченый в некоторое, заведомо исполняемое место файла. Но JMP-это говно. Поэтому мы развратим его в несколько разных полиморфных инструкций, и при этом, впатчим их не одну за другой, а в РАЗНЫЕ места файла, но так, что выполнятся они в нужной нам последовательности.

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

Итак, что у нас есть.

Для еще не запущенных процессов отладка начинается с CreateProcessA, с флажками DEBUG_PROCESS+DEBUG_ONLY_THIS_PROCESS. Если же требуемый процесс открыт, то можно юзать DebugActiveProcess.

После того, как вызванная функция вернула success, можно крутить цикл. А в цикле происходит такое действо: вызывается WaitForDebugEvent и мы получаем так называемый debug event, то бишь структурку заполненную всяким отстоем.

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

Теперь о структурке. Идентификаторы каждого евента лежат в de_code. de_pid и de_tid - это id текущих отлаживаемых процесса и нити, для которых и сгенерился евент. Ибо мы можем отлаживать несколько процессов, и у каждого процесса могут быть свои нити.

Теперь о том, какие debug event'ы приходят в наш цикл.

• CREATE_PROCESS_DEBUG_EVENT -- самый первый event который мы получаем. В нем лежит такая хрень как хендлы файла, процесса и нити. Файл открыт на только-чтение или на чтение-запись. (наябывать тут нечего) Еще там начальный адрес, имя файла и прочий отстой.

• LOAD_DLL_DEBUG_EVENT -- эти события происходят когда загружается новая DLL-ка в контекст отлаживаемого процесса. Загрузчиком, либо LoadLibrary.

• EXIT_PROCESS_DEBUG_EVENT -- по этим событиям надо из цикла сваливать, ибо это конец отладки.

• RIP_EVENT -- ибо это конец отладки.

• CREATE_THREAD_DEBUG_EVENT -- здесь надо выставлять TF.

• EXIT_THREAD_DEBUG_EVENT, UNLOAD_DLL_DEBUG_EVENT, OUTPUT_DEBUG_STRING_EVENT -- прочие отстойные евенты, совершенно нам не интересны.

• EXCEPTION_DEBUG_EVENT -- а вот это самый интересный event. Он говорит что случился exception, в частности INT1 или INT3.

Фичи тут такие.

1. Перед тем как исполнять отлаживаемую программу, система вызывает кернеловскую функцию DebugBreak, в которой происходит INT3 (0xCC).

2. По умолчанию флаг TF (трассировка) не установлен, и мы (вроде бы) должны его устанавливать сами после КАЖДОЙ обработки событий типа INT1/INT3, ибо система так и норовит этот флажок сбросить.

Работа с памятью отлаживаемого процесса (ибо память эта находится в другом контексте и по-другому не доступна) производится посредством функций ReadProcessMemory и WriteProcessMemory.

Работа с регистрами отлаживаемой нити производится функциями GetThreadContext и SetThreadContext.

Итак, структура трассировщика примерно такая:

Подобный трассировщик будет обладать одним недостатком. Дело в том, что трассировать он будет не только текущий процесс, но и все загруженные в него DLL-ки. А у DLL-ек этих тоже есть свои точки входа, и вызываются они ДО точки входа основной программы. Кроме того, когда процесс сделает CALL в DLL-ку, трассировщик будет там долго и упорно охуевать, и вернется нескоро. И потом, здесь не поддерживаются нити.

Обходится это дело таким образом.

Чтобы поскипать DLLкин код в начале, надо

1. проебать кернеловский INT3 (который в DebugBreak), то есть попросту забить на него, и TF не устанавливать

2. написать простенький механизм впатчивания в прогу INT3 (0xCC) и восстановления оных (хранить оригинальные байты), аргумент -- адрес.

3. по получении евента CREATE_PROCESS_DEBUG_EVENT впатчить в начало программы (lpStartAddress) INT3.

Чтобы не выполнять трассировку в DLL-ках, проверяете текущий адрес, и если он вне программы, то

1. берете дворд со стэка (это будет адрес возврата) и впатчиваете по нему INT3

2. убираете TF к херам

Для поддержки разных нитей придется поебаться.

1. Надо будет впатчивать INT 3 в lpStartAddress при создании новой нити.

2. Хранить в себе список всех нитей, т.е. соответствие их ThreadId <--> ThreadHandle

3. При вызове екскепшенов int1/int3 конвертить TheadId (данный для текущего евента) в соответствующий ему ThreadHandle

4. Апдейтить эту инфу о нитях при создании процесса, создании нити и закрытии нити.

В дополнение. Флажок TF по-видимому, охуячивается при глюках, то есть сгенерив глюк и отловив его SEHом можно наебать отладчик.

Как разобраться с такой хуйней? Это дело непростое.

1. При получении екскепшена взять FS от отлаживаемой нити

2. Зная FS, и юзая GetThreadSelectorEntry получить VA от FS:[0]

3. Разобрать SEH'овую структуру и выявить адрес SEH'ового хандлера

4. Вхуячить в хандлер INT3

Вот собственно и все. Вышеописанное дело производит программа tracer32.

Теперь, как это реально использовать.

1. выбрать программу

2. протрассировать 2-3 секунды

3. полученный адрес использовать для впатчивания JMPа на вирус

В LDE32 всего две процедуры.

1. void pascal disasm_init(void* tableptr);

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

2. int pascal disasm_main(void* opcodeptr, void* tableptr);

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

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

Для подключения LDE32 добавьте следующую строку:

Пример

programmed in 1999 by Z0MBiE, <http://z0mbie.host.sk>

Русский | English

Содержание

• Структура декриптора

• Длина расшифровщика/Компрессия

• Возможности

• Как подключать

• Как вызывать

• Получение управления от декриптора

Структура декриптора

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

Легко заметить, что если обычный полиморфный движок производит данные длиной РАЗМЕР_ДЕКРИПТОРА + ДЛИНА_ИСХОДНЫХ_ДАННЫХ, то стэковый движок производит данные длиной ДЛИНА_ИСХОДНЫХ_ДАННЫХ * k, где k -- некоторый _коэффициент увеличения данных_, зависящий от многих параметров.

Длина расшифровщика/Компрессия

У KME при всех включенных фичах код увеличивается в 2-3 раза. Но тут возможен интересный эффект: при отсутствии "логики" (т.е. без шифровки регистров, см. FLAG_NOCMD) и одинаковых шифруемых данных (1 и тот же повторяющийся дворд/ворд/байт), декриптор получится меньше, то есть произойдет сжатие. Максимальное сжатие для одного полиморфного слоя -- в 4 раза, а при нескольких слоях возможно и еще больше.

Зависимость длины расшифровщика от количества полиморфных слоев

При получении данных зашифровывался 5-килобайтный буфер из NOPов, красным цветом -- шифровка регистров включена, синим -- выключена (FLAG_NOCMD). Как видим на третьем слое получено сжатие в 25 раз.

Возможности

Пользовать KME можно практически везде -- ring3 и ring0, NT и win9X как минимум, для остальных операционок х/з. Используется флэт-модель памяти, никаких сегментных регистров. Внутри движка нет никаких системных вызовов, одни регистры и память. Все параметры передаются на стэке. Внутренние переменные лежат там же. Код движка, как и код декриптора, не чувствителен к изменению оффсета.

У декриптора можно регулировать:

• используемые регистры (минимум 1, максимум 7),

• используемые команды (около десятка),

• наличие и параметры "пятен" (код разбросан по памяти и связан jmp-ми),

• а также некоторые другие детали.

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

Декриптор генерируется за 1 проход, и никакой дополнительной памяти по этому поводу не используется. В результате размер исходных данных и декриптора не ограничен. Таким образом реально создать расшифровщик в 100 мегабайт и оттуда запускать вирус при каждой загрузке. Возможно также несколькими вызовами KME создавать полиморфные "слои", то есть зашифровывать данные многократно. (см. примеры)

Как подключать

KME поставляется в трех формах.

1. В виде OBJ-файла

В виде OBJ-файла: KME32.OBJ и KME32.INT.

YOURMAKE.BAT:

YOURSRC.ASM:

2. В исходниках

В исходниках: KME32.INC и KME32.INT.

YOURSRC.ASM:

3. В "бинарном инклюднике"

В "бинарном инклюднике": KME32BIN.INC и KME32.INT.

YOURSRC.ASM:

Как вызывать

KME имеет всего одну PUBLIC near-процедуру, kme_main. Тип вызова паскалевский, то есть выход из процедуры по "RET xxxx". Все параметры типа DWORD, 13 штук.

Возвращаемое значение

Регистры без изменения, DF=0.

CF=0 если все в порядке.

CF=1 если ошибка (отсутствует свободное место в выходном буфере).

Комментарии

Значения констант описаны в KME32.INT. Все константы суть степени двойки. Можно их ORить либо складывать.

Flags (первый параметр) CommandMask (второй параметр)

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

Глобально все команды типа CMD_xxx могут быть отключены битом FLAG_NOLOGIC в параметре Flags, и тогда актуальны только CMD2_xxx.

В случае отсутствия сразу CMD2_ADD, CMD2_SUB и CMD2_XOR, будет использоваться CMD2_XOR.

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

• MOV для загрузки начальных значений регистров,

• PUSH и XOR для записи данных в стэк,

• ADD и JMPreg для выхода из декриптора.

RegMask (третий параметр)

Задает набор регистров, которые можно использовать в декрипторе. Всего 7 регистров (все РОНы кроме ESP).

Если не задано ни одного регистра, используется EAX.

Точки входа (InputEntry и OutputEntryPtr)

Все точки входа -- относительные смещения от начал своих буферов.

Получение управления от декриптора

После расшифровки исходных данных в стэк происходит JMP (ESP+InputEntry), то есть передача управления вирусу.

При этом разрушены все регистры из RegMask, а в стэке находится сам вирус а также N-1 декриптор в случае N слоев. Размер всей этой хрени в стэке вычисляется как сумма длин вируса и всех декрипторов кроме первого, причем каждая длина выровнена на границу 4-х байт ((InputSize+3) and (not 3)).

В начало | Содержание | English

Итак, raw-сокеты даны нам в виде набора апишек, импортируемых из WS2_32.DLL. Отнюдь не из WSOCK32.DLL. В чем же разница? Разница, как между хуем и пальцем. Если вы внимательно разберетесь в спуфинге на raw-сокетах, и увидите то, что отличает их от обычных, а затем посмотрите в win2k'шный WSOCK32.DLL::setsockopt() идой - то можно будет легко увидеть, в чем же фишка.

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

Затем, как вы знаете, надо инициализировать windows sockets api. Делается это WSAStartup'ом, коему впаривается версия именно 2.2 - в противном случае вас ожидает вселенский сакс.

Теперь можно сделать raw-сокет. Вот он.

Далее все зависит от цели - снифак мы пишем, спуфер, или даже все вместе.

СПУФЕР

Для тех кто не знает, спуфер (spoofer) - это такая хрень, которая позволяет вместо своего IP-шника подставить чужой. А в общем случае послать весь IP-пакет целиком. И это правильно.

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

А дальше можно работать как с обычным UDP-пакетом, посредством sendto(), только что в пакете будет еще и IP-заголовок.

Пусть готовый к отправке пакет, начинающийся с ip-header'а, находится в BYTE* buf, длиной int len.

(*) И тут есть одна тонкость. Винда пошлет пакет вовсе не на тот адрес, коий указан в поле dst ip-заголовка пакета. А пошлет винда пакет на тот адрес, который указан в структуре sockaddr, подаваемой в sendto(). В случае одной сетевухи это все одно и то же; в случае двух - может быть определенная разница.

СНИФФЕР

Для тех кто не знает, сниффер (sniffer) - это такая хрень, которая позволяет ловить все пакеты, хоторые проходят мимо машины.

Для того, чтобы ловить пакеты, надо "висеть на интерфейсе". Так говорят. Очень тяжело объяснить что это значит. На практике это выливается вот во что: надо выбрать один (а лучше все) из IP-адресов, присущих на данный момент машине, где работает сниффер, потом взять этот IP-адрес вместе с созданным raw-сокетом, и запидарасить все это в функцию bind().

Так что получим IP-адреса так, как это описано в [1]

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

Распечатаем все полученные IP-адреса.

Теперь делаем bind() -- ассоциируем сокет с первым полученным IP-шником.

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

После этого на сокет начинают приходить IP-пакеты со всей локалки. Получать их можно так же, как и обычные UDP-пакеты, командой recv(), с той лишь разницей, что что в них есть еще и IP-заголовок.

Далее идет разбор пакета, ну и все по плану.

ПРИМЕНЕНИЯ

Самое интересное заключается в том, что многие локальные файрволы при использовании raw-сокетов обламываются. По-видимому, их драйвера садятся на какой-то не тот источник данных - а значит, майкрософт их наебал. А может быть, в таких файрволах не предусмотрено то, что из машины выходит ip-пакет с совсем неродным src ip-шником. А может быть проблема в том, что файрволы портировали с NT 4, забыв о 2K-шных фичах. Хуй его знает, поди разберись во всем. Но факт тот, что глупые файрволы выпускают из машины любые raw-пакеты. В сочетании со сниффингом, это дает возможность ремотного управления затрояненой тачкой, в том случае, если на нее после установки трояна поставили файрвол. Естественно, TCP-соединение с такой машиной уже не установишь, и придется общаться по какому-нибудь левому протоколу, но это, я думаю, не проблема.

Ну и широко известные применения -- выгребание email'ов и аккаунтов/пассвордов посредством сниффинга, имперсонация других IP-шников в локалке, сканеры, флудеры, и все прочие счастья.

See also:

[1] 29a-6.004 -- Snorting coke (and packets) by GriYo / 29A

_(x) 2002_

http://z0mbie.host.sk

---

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

Вот как тогда будет выглядеть файл СPPFILE.CPP:

В свою очередь, ASMFILE.ASM будет выглядеть так:

Для успешной компиляции всего этого потребуется EXEFILE.DEF файл, в котором будут описаны соответствия внутренних и внешних имен функций проекта:

Теперь, чтобы все это скомпилировать, понадобится файл MAKE.BAT:

С другой стороны, можно было бы сделать ANYDLL.LIB, посредством

после чего вместо IMPORTS-части EXEFILE.DEF файла, использовать ANYDLL.LIB; при этом надо не забыть подать ANYDLL.LIB в командную строку bcc32.exe.

Вот часть TDUMP'а от полученного EXEFILE.EXE:

---

(x) 2002 z0mbie.host.sk

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

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

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

Например, если вирус перехватывает точку входа в файл, достаточно проверить наличие вируса только по этому адресу.

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

Примером этого пути развития является технология UEP (EPO).

Пусть

Тогда

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

Алгоритм проверки файла на вирус в этом случае такой:

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

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

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

Здесь

это так называемое число размещений из I по N.

Так, например, если число подозреваемых на вирусные блоков равно 4, а всего должно быть 2 последовательно выполненных блока, то будут проверены 12 вариантов:

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

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

Это достигается трассировкой программы. Трассировка же легко производится с использованием debug api.

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

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

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

Конечно, на небольшом локальном участке кода можно обойтись и без трассировки, одним лишь статическим анализом. Но когда речь заходит о большой мультитреадной программе, состоящей из нескольких файлов -- EXE'шника и всех его DLL'ек, а также о достаточно больших расстояниях между вирусными блоками, то дизассемблирования недостаточно, и трассировка становится необходимой.

Таким образом мы:

1. Выбираем программу.

2. Производим статический анализ. (парсинг на инструкции, см. движок Mistfall и вирус ZMist)

3. Производим динамический анализ (трассировку, см. Tracer32), с учетом данных парсинга. В частности, перед трассировкой в начало всех подпрограмм вставляются точки останова (brrakpoint, INT3), для того, чтобы не потерять управление на callback'ах, вызываемых из не трассируемых библиотек.

4. Снова производим статический анализ, уже более качественный, с учетом данных трассировки.

5. Для улучшения качества анализа возможно повторение начиная с шага 3.

6. Комбинируем полученные данные.

7. Выбираем последовательно выполняемые места программы, в которые следует поместить вирусные блоки.

8. Вносим в программу изменения.

9. Заново собираем исполняемые файлы.

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

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

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

---

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

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

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

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

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

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

Понятно, что тратить часть своих ресурсов на благо общества не всегда полезно самому человеку. Во все времена были люди, осознающие это. ЭГО - это личные установки, и когда они начинают доминировать над общественными установками (ИД), человек становится "эгоистом".

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

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

В контексте вышенаписанного, общество - это информационный объект, существующий в едином информационном пространстве. Но если есть один такой объект, то почему не существовать другому?

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

Теперь возникает законный вопрос: а где мое место в этом мире с его постоянной войной, которая идет не только в материальной, но и в идеальной, области мыслей? Ведь тихо стоять в стороне не получится. Это самообман. Всякий, кто обладает разумом, участвует в этой жизни. Возможны два варианта: либо подчиняться чужим мыслям на поле сражения, либо творить эти мысли, находясь над битвой. Либо играешь ты, либо играют тобой. Более правильно следует поставить вопрос так: какова должна быть моя мера управления этим миром, и какова должна быть мера моего подчинения этому миру?

Ответ на этот вопрос ясен любому здравомыслящему человеку. Цель жизни - добиться независимости от внешнего мира, и возможности максимально влиять на него, ибо лучшая защита - это нападение; добиться силы, власти, денег, влияния. Реализовать весь потенциал, заложенный в человека природой, а то, чего нет - взять силой. Ну и, конечно же, получить от этой жизни максимум удовольствия. Такова, в двух словах, самая общая цель.

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

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

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

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

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

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

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

То есть почти все современное знание человек хранит в компьютере, и процесс этот заходит все дальше и дальше, и назад уже не повернуть.

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

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

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

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

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

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

А что является следующей стадией развития вредоносной идеи, пусть даже и про покемонов? Идея эта обрастает атрибутами, и в ней формируется ядро, четко говорящее: 1. передай меня дальше, 2. заплати денег туда-то, 3. делай все, что говорит вася пупкин. Незакомплексованый читатель сразу узнает здесь программу какой-нибудь партии или что-нибудь из религий.

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

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

Если бы вы попали на 2-3 тысячи лет назад в прошлое, разве вы не воспользовались бы случаем, чтобы создать свою собственную религию? Но точно такая же ситуация есть и сегодня: в структуре киберпространства образовалась ниша, которая должна быть (и будет) заполнена самораспространяющимся распределенным информационным объектом высокой сложности.

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

Почему плугины?

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

На сегодня существует один реальный модульный вирус - это Hybris, и он показал себя отлично. Однако, моя субъективная оценка такова, что к хибрисовской системе плугинов трудно подключить что-нибудь свое, а построить на этой базе что-то действительно сложное, будет совсем не просто. Это не значит ничего плохого, хибрис по настоящему великолепен. Просто мне этого мало.

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

Основное отличие заключается вот в чем. У хибриса это действительно ПЛУГИНЫ, то есть просто дополнительные фичи, прикручиваемые к вирусу. В проекте PGN2, плюс к тому что есть у хибриса, абсолютно ВЕСЬ вирус состоит из МОДУЛЕЙ, каждый из которых может быть обновлен.

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

Далее вам представляется краткое описание системы PGN2.

2. Модульная структура в общем виде

Вирус в зараженном файле: (местоположение расшифровщика и зашифрованных данных зависит от метода заражения)

Физическая (начальная) структура вируса, находящегося в зашифрованном файле, после расшифровки, выглядит так:

3. Внешний контейнер

Внешний контейнер: (наличие контейнера опционально)

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

Таким образом, как только плугин принят из интернета и расшифрован, вызывается операция аттача плугина, и плугин:

1. добавляется во внешний контейнер (возможно, заменяя старую версию)

2. подключается к работающей копии вируса и исполняется.

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

Единственно, пока еще не реализована возможность шифровки внешнего контейнера.

4. Плугины - на диске и в памяти

Для удобства работы с плугинами они организованы в список. Структура вируса в памяти: (список плугинов в памяти)

Другими словами, на каждый плугин в памяти хранятся два образа: один - запакованный, то есть тот, который добавляется в каждый новый зараженный файл; а другой - распакованный в память PE EXE, который в настоящее время и исполняется.

5. Формат плугина

Поскольку плугины представлены в формате PE EXE, писать их можно практически на чем угодно, подходящих компиляторов также полно, хотя мне вполне хватило tasm'а и borland c++.

Единственно, откомпилированные PE-файлы должны удовлетворять следующим требованиям:

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

2. не содержать ресурсов (ресурсы будут поскипаны)

После компилирования, с PE файлом следует сделать следующее:

Тулза PE2PGN:

1. поскипать MZ-заголовок и DOS-овую часть

2. перерелоцировать на imagebase=0, physicaloffset=0

3. выкинуть ресурсы и фиксапы с типом 0

4. обнулить PE id, datetime, checksum, и прочие, в дальнейшем не используемые поля

Тулза PACKER:

5. сжать файл

Тулза HEADER:

6. добавить PGN2-заголовок (DWORD CRC32-id, DWORD version)

Таким образом, физически плугины в формате PGN 2, а виртуально (в памяти) - в формате PE EXE.

DWORD CRC32-id, который идет до запакованного тела плугина - это CRC32 от имени плугина маленькими буквами.

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

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

• imagebase больше не должен быть выровнен, нам это пофигу, так как:

• в ring3: выделение памяти через GlobalAlloc, align=DWORD

• в ring0: выделение памяти через PageAllocate, align=4K

• большинство записей в PE-заголовке нулевые, т.е. не используются

• аттрибуты и имена секций не имеют смысла (вся память r/w), нам нужны только оффсеты и длины

• при импорте функций из других плугинов - имена плугинов начинаются на @

• возможны любые импорты, экспорты и фиксапы, также возможны экспорты из системных DLL'ек по именам

• не поддерживаются ресурсы

• точка входа (если есть) вызывается первой

• затем вызывается начальное событие

• возможно наличие экспортируемой подпрограммы unload()

• подпрограммы интерплугинного взаимодействия: экспортируемая HandleEvent() и импортируемая Event() (опционально)

6. Загрузчик

LDRWIN32 - это специальный плугин, содержащий в себе блок кода LDRWIN32.bin, причем каждый из них называется загрузчиком. LDRWIN32.bin - это блок кода, который просто содержится внутри соответствующего плугина, и выполняет следующие функции: если к этому блоку кода приписать пачку плугинов (запакованных, в формате PGN2), и передать ему управление, то он построит в памяти список плугинов, распакует туда PE EXE-образы и запустит вирус.

Более точно, задача загрузчика такая:

• взять все имеющиеся плугины;

• загрузить дополнительные плугины из внешнего контейнера;

• выбрать новейшие;

• построить список плугинов;

• распаковать плугины;

• загрузить их в память как PE-файлы;

• настроить фиксапы, ипморты и экспорты;

• вызвать все точки входа (для каждого плугина);

• послать плугинам начальное событие;

• если событие не обработано, освободить память;

• вернуться в программу-носитель.

Также загрузчик содержит подпрограмму LDRWIN32.ldrwin32_copy(), которая вызывается для построения новой копии вируса (нового списка плугинов). Эта подпрограмма использует текущий список плугинов как родительский, и без чтения внешнего контейнера, просто выделяет память под копию списка и образы плугинов и копирует их туда, после чего генерит соответствующее событие. В настоящее время эта фича используется (под win9x) для построения второй активной копии вируса в ring-0.

Кроме того, плугин LDRWIN32 содержит следующие public-функции и переменные:

PluginList - указатель на первую запись списка плугинов. (см.PGN2.INC)

Чтобы получить значение импортируемого DWORD'а, надо сделать так:

Вместо этого можно ипортировать функцию LDRWIN32.GetPluginList(), которая вернет значение PluginList в EAX.

7. Взаимодействие плугинов

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

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

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

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

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

Общение между плугинами происходит так:

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

Для того, чтобы посылать события, плугин импортирует функцию Event() из загрузчика LDRWIN32.

У каждого события есть уникальный номер и один юзерский параметр.

Для вызова события, делаем так:

или, на C++:

Подпрограмма LDRWIN32.Event просто распределяет событие по тем плугинам, у которых есть public-подпрограмма HandleEvent.

Так что, для обработки событий, делаем так:

или, на C++:

Как видно, подпрограмма Event возвращает результат в EAX:

• 0 если событие не было обработано

• -1 если событие было обработано с результатом -1 (остановить распределение событий)

• N если N плугинов обработали событие с результатом 1

Очевидно, что после того, как некоторое событие обрабатывается (подпрограммой HandleEvent) с результатом -1, загрузчик просто останавливает распределение событий и возвращает -1 как результат. В остальных случаях LDRWIN32.Event просто суммирует результаты от HandleEvent()'ов (нули и единицы) и возвращает сумму.

9. Приоритет вызовов событий

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

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

Для этого у каждого плугина есть параметр PRIORITY, от 0 до 10 включительно, в соответствии с которым загрузчик решает, какой плугин вызовется раньше, а какой позже.

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

Если вы пишете плугин A, который должен (при одном и том же событии) быть вызван раньше плугина B, то поставьте для A значение PRIORITY на 1 меньше.

10. Взаимодействие плугинов через импорты/экспорты

В дополнение к функциям HandleEvent() и Event(), которые суть основной способ коммуникации между плугинами, плугины могут использовать импорты и экспорты друг между другом, и иморты из системных DLL'ек по именам.

Единственное отличие от импортов из системных DLL'ек в том, что имена импортируемых плугинов в import table должны начинаться на @.

Пример .DEF-файла, передаваемого TLINK32'у при линковке плугина:

11. Взаимодействие плугинов с загрузчиком (аттач/детач)

У плугинов может быть ненулевая точка входа (EntryPointRVA), которая вызывается сразу после того, как плугин будет загружен в память, но до посылки каких-либо событий. Во время этого вызова также возможно вызывать события. У процедуры EntryPoint() один DWORD-параметр, который обычно равен нулю. Но может также содержать и некоторое другое значение - код возврата из процедуры unload(). А эта процедура, если она в плугине есть, вызывается до того, как плугин будет выгружен из памяти, в случае апдейта плугина более новой версией, либо в случае просто выгрузки плугина из памяти. Если это выгрузка из памяти, то unload() должна освободить всю выделенную память и убить все созданные нити. Если это апдейт, то есть возможность передать некоторые данные из старой версии плугина в новую.

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

1. int __cdecl ldrwin32_attach(BYTE* buf, DWORD* bufsize)

Приаттачить пачку плугинов. Буфер - набор запакованных плугинов, желательно чтобы все заканчивалось на 'DD 0'. То есть формат буфера такой же, как и у внешнего контейнера. Длина буфера используется на случай, когда не найден завершающий 'DD 0'.

Если один из этих новопришедших плугинов у нас уже есть, то в загрузчике происходит следующее:

• проверить, если пришедший плугин новый; обновить внешний контейнер

• старые плугины: вызвать unload(UT_UPDATE), запомнить exitcode (exitcode может быть указателем на динамически-аллоцируемый блок)

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

• новые плугины: распаковать, загрузить в память, настроить импорты, экспорты, фиксапы

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

• новые плугины: вызвать точки входа, передавая exitcodе от соответствующих unload()'ов как параметр

После аттача, генерится евент EV_LDRWIN32_ATTACHED.

2. void __cdecl ldrwin32_detach_me()

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

Вызывающий плугин в таком случае будет ЗАМЕНЕН фэйковым (нулевым) плугином с версией на 1 больше, но с тем же ID, и с нулевыми compressed/decompressed size.

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

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

После детача генерится евент EV_LDRWIN32_DETACHED.

12. Оформление подпрограмм

Желательно, чтобы все public-подпрограммы были написаны согласно с cdecl конвенцией, то есть:

• порядок PUSHа параметров на стэк ОБРАТНЫЙ, т.е. после CALL'а, первый (последний запушеный) параметр находится по адресу [ESP+4], 2й по [ESP+8].

• выход из подпрограмм по RETN (0xC3)

• после CALL'а вызывающий делает <ADD ESP, 4 * число_параметров>

• подпрограммы могут изменять EAX,ECX,EDX

• подпрограммы не могут изменять EBX,ESI,EDI,EBP

• функции возвращают результат в EAX

13. Обработка ошибок (SEH)

1. SEH'ом ошибки обрабатываются только во время вызовов EVENT'ов. Когда вызывается EntryPoint или unload(), никакого SEH'а, кроме общего, нет.

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

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

2. Так как система PGN2 была разработана под win32/ring-3, т.е. win9x/ring0-код возможен, но не желателен, то логика работы не должна основываться на ring-0.

Весь ring0-код должен быть по возможности коротким и независимым, дабы не сглючило.

14. Выбор числовых констант

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

15. Фича: FUCKAPI

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

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

Итак, имена всех плугинов и public-процедур во всех плугинах, обрабатываются следующим образом:

1. первый символ @ пропускается (если он есть)

2. от имени считается crc32

3. этим crc32 инициализируется randseed, после чего генерируется строка из псевдослучайных символов (1..255), в ту же длину

Естественно, что это справедливо только для интерплугинных public-процедур, а при импорте из kernel'а имена останутся без изменений.

---

Как показала практика, если вирус достаточно изъебский, и проверка занимает дохрена времени, то аверы (в частности, НАВовцы) могут прицепиться к вирусной alredy-сигнатуре в заголовке файла, и только такие файлы на некий конкретный вирус и проверять.

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

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

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

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

Доказательство возможности автоматического реверсирования файлов таково: существует IDA, 100%-корректно дизассассемблирующая некоторые файлы, совершенно без посторонней помощи; существует TASM, который полученные IDой .asm-файлы успешно компилирует; а значит, этот процесс возможно автоматизировать. Более того, мы не дизассемблируем инструкции до уровня мнемоник, а только до уровня их длин; и при ассемблировании у нас также все намного проще.

Это и было сделано; и это работает; это вирус z10 и движок mistfall. И с детектилкой, судя по всему, большие проблемы. Но не об этом здесь речь.

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

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

Как вы будете чинить/апгрейтить незнакомый вам, скажем, телевизор? Вы его сначала осмотрите, и скажете: да, есть резон этим заниматься. Можно было бы, конечно, пару винтиков впихнуть в щель, скажем, между панелями, или насыпать железной стружки внутрь, но это не красиво. Работать это не будет.

Поэтому телевизор разбирается на части. При этом, мы знаем что это телевизор такой-то там марки/модели (PE EXE), то есть, именно по этому мы им и занимаемся. Но мы не знаем его устройства (нет исходников). Но вообще, что-то нам о деталях и связях между ними известно (PE формат и инструкции x86). Поэтому все вытащенные детальки откладываются в стороны, а в голове (или на бумажке, или в памяти компа) рисуются связи между ними, чтобы потом можно было собрать все обратно.

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

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

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

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

С программами, да еще в формате PE EXE все обстоит куда проще, потому как любую деталь можно произвести самому, тут же, и в любых количествах, да и все это делается автоматически. Ведь вы же не будете лично так извращаться с каждой программой? Вы напишете специальную программу для этого, т.е. движок. И он будет уже будет заниматься реверсингом. А вы только будете ему говорить: "так, типа, разобрал? вот те два проводка перекинь, вот этот кондер выпаяй, а вот эту коробочку вкрути вон туда; ну все, типа, можешь собирать обратно".

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

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

Таким образом, общая схема реверсирования такова:

1. получение полного доступа к объекту

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

3. разбор объекта на части, восполнение недостающей информации о связях

4. модификация частей/связей

5. сбор измененного объекта, с учетом всей имеющейся информации

Очевидно, что возможно проводить реверсирование не всего объекта, а только некоторой его части. Но объект, каким бы он ни был, всегда является частью еще более сложной системы, так же, как его части принадлежат ему самому; поэтому не имеет смысла говорить о частях объекта, единственная рекомендация -- это учитывать взаимодействие с системами более высокого уровня. Например PE EXE файл может вызывать функции системных DLL'ек по фиксированным адресам, без использования фиксапов. Так что можно его было бы рассматривать как часть всей операционки, но все таки мы говорим о файле.

Теперь рассмотрим вопрос о противодействии детектированию изменений. Прежде всего, как будут искать эти изменения?

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

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

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

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

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

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

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

Нет никаких сомнений, что это -- список элементов программы, также я буду говорить о списке инструкций, что то же самое. Движок RPME работает только с инструкциями, и ориентирован на пермутацию вирусного кода. А движок MISTFALL -- это то же самое, но для работы со всеми элементами PE файлов.

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

Кусок кода:

Часть списка:

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

На чем может быть написан реверсирующий движок? Все зависит от мастерства автора. Я считаю, что следует разумно сочетать C++ и ассемблер, т.е. разбить задачу на части и каждую часть писать на том, на чем это наиболее эффективно. В принципе, возможно написать реверсирующий движок исключительно на ассемблере.

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

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

Интеграция кода вируса с кодом программы -- это работа на уровне списка элементов файла; а именно -- вставка вирусного кода и/или декриптора в самые разные места кодовой секции; все это, естественно, на основе реверсирования файла.

Реверсинг и интеграция позволяют также использовать и старые добрые поли- и метаморфизм; полиморфным может быть вирусный декриптор, разбросанный по всему файлу, спрятанный в файле; а метаморфным/пермутирующим может быть сам вирусный код.

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

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

Почему так? Потому что есть такая вещь как UEP, то бишь Unknown Entry Point, которую проклятые антивирусники почему-то обозвали Entry Point Obscuring -- наверное, обскуринг ближе к их продажным сердцам. В кратце -- это не замена точки входа на вирусную, а вставка перехода на вирус в случайное место программы. В результате по точке входа зараженного файла находится то же, что было до заражения. А вирус срабатывает не сразу, а в середине работы программы. Но, поскольку, вирус-то должен быть куда-то записан, а место это зачастую алгоритмически фиксировано -- например это всегда последняя секция файла, то оттуда антивир и начинает эмуляцию, и незачем ему искать на это место переход.

Рассмотрим некий PE файл, лучше всего CALC.EXE.

1. Число секций

В PE хеадере хранится число секций в файле, это WORD, назовем его pe_numofobjects, оффсет в PE заголовке равен +06.

Примечание: обычно число секций не равно нулю, хотя маздаю (win9x) на это насрать, и даже если в файле нет ни одной секции, он все равно будет работать, особенно если после PE заголовка всунуть какой-нибудь код. Однако, если в файле совсем не будет импортов, то возникнут трудности с вызовом win32 api-шек. Но и это не проблема, если вместо апишек вызывать процедуру kernel@int21 по адресу BFF712B9.

Примечание: сразу после WORD pe_numofobjects идет DWORD pe_datetime (оффсет +08), то есть датавремя создания файла. Если работать с WORD'ом в падлу, то можно предварительно занулить pe_datetime и принять что pe_numofobjects это DWORD.

2. Таблица секций

Сразу после PE заголовка идет таблица секций (==таблица объектов, object table), элементы (записи, object entry) которой описывают секции файла. Сколько записей, столько и секций, всего pe_numofobjects штук. Длина PE заголовка в абсолютном большинстве случаев равна 0F8h байт. Но, поскольку всякое бывает, то берут WORD по +14h, прибавляют 18h, и получают точную длину PE заголовка.

Формат object entry (одной записи таблицы секций):

Теперь отметим САМЫЙ ВАЖНЫЙ МОМЕНТ: В таблице объектов хранятся _НЕ_ВЫРОВНЕННЫЕ_ значения физической и виртуальной длин секций. Что это значит? Это значит, что чтобы получить настоящие длины секций надо взять эти значения из соответствующих записей в таблице секций и ВЫРОВНЯТЬ: физическую длину на pe_filealign, а виртуальную длину на pe_objectalign.

Смещения же секций (физическое в файле и виртуальное (rva) в памяти) выровнены всегда.

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

Поля pe_filealign и pe_objectalign (DWORD'ы, смещения +3Ch и +39h) суть степени двойки, причем pe_filealign кратно 512 (сектор), а pe_objectalign кратно 4096 (страница в памяти).

Поэтому процесс выравнивания для одной секции выглядит так (на C):

Или на asm'е:

Кроме того, бывает, что виртуальная длина у всех секций == 0. Такую дрянь производит watcom. И при этом, оно работает. Откуда брать виртуальную длину в этом случае? Я брал вместо нее физическую длину и выравнивал ее на objectalign.

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

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

3. Секции

Для чего PE файл разбит на секции? Для того, чтобы в образе PE файла в памяти (который обычно не соответствует образу на диске) могли чередоваться инициализированные и неинициализированные данные. Кроме того, есть секции со специальным назначением, в них обычно хранятся таблицы импортов, экспортов, ресурсов, фиксапов, отладочной информации и некоторые другие.

Каждая секция файла имеет <физическую длину> и <виртуальную длину>. Физическая длина -- это то, сколько секция занимает на диске. А виртуальная длина -- это то, сколько секция занимает в памяти. Разница между этими длинами на ассемблере представляется как DB ?, то есть это и есть неинициализированные данные. Неинициализированные данные могут быть у любой секции. В результате получается такая ситуация:

Несмотря на кажущуюся простоту, возможны такие варианты:

• Физическая длина секции равна виртуальной. Идеальный вариант, мечта поэта. Обычно встречается когда filealign == objectalign.

• Физическая длина меньше виртуальной. Это значит, что у секции есть неинициализированные данные.

• Физическая длина больше виртуальной. Это значит что у секции есть оверлей или alignment. Помните, что если виртуальная длина меньше физической, то некоторая (скорее всего состоящая из нулей) часть образа секции с диска не загрузится -- это будет небольшой файловый алигнмент. Хотя никто не запрещает таким образом вставить не загружаемый в память "оверлей" не в конец файла, а между его секциями.

Alignment -- это разница между физической и виртуальной длинами. Можно понимать его по разному: для секции -- (A) если длины выровнены, и (B) если длины НЕ выровнены; и для файла, если это (C) заполненный нулями оверлей длиной меньше pe_objectalign. Причем в случаях (A) и (B) разница длин у одной и той же секции может иметь разный знак. Например, если невыровенная physsize=512, невыровненная virtsize=100, выровненная physsize=512, выровненная virtsize=4096, то в случае (A) alignment=3584, а в случае (B) alignment=412. Причем один из них -- в файле, а другой -- в памяти. Так что решите для себя, о каком из алигнментов вы думаете и/или говорите.

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

4. Лирическое отступление в область теории

ImageBase -- это адрес в памяти, куда должен быть загружен PE файл. По умолчанию большинство адресов в файле настроены на указанный в PE заголовке ImageBase (DWORD, смещение +34h). Обычно выровнен на 64k, и навряд ли линкер даст сделать меньше; однако маздайный загрузчик проглотит многие нестандартные значения с самым разным результатом.

Если файл -- это DLL, и загрузить его по указанному адресу нельзя, то происходит перенастройка на другой ImageBase, для этого используется таблица настроек (==фиксапов, релокаций). Если же в этом случае ее не окажется, то файл загружен не будет. Поните об этом, заражая PE DLL'ки, и при отдаче управления в файл вместо PUSH OFFSET/RETN делайте JMP.

ImageSize (DWORD, оффсет +50h) -- это виртуальная длина файла, то есть размер образа файла в памяти, вычисляется как виртуальный адрес (rva) последней секции + виртуальная длина последней секции. Обычно выровнен на pe_objectalign.

BaseOfCode -- это RVA первой кодовой секции, просто копируется сюда из object table при линковке.

BaseOfData -- та же фигня, для второй, обычно секции данных.

SizeOfCode -- длина кода, обычно выставлена корректно и равна вирт. длине первой секции.

SizeOfInitData & SizeOfUninitData -- полная херь, выставлено как попало и кое-где. Каким бы ни был метод заражения, менять их нет смысла.

pe_subsystem (WORD по смещению +5Ch) -- равно 2 для GUI приложений, и 3 для консольных аппликух. Иногда встречаются другие значения, и тогда файл заражать не следует.

5. Оверлеи

Оффсет оверлея вычисляется как физический оффсет последней секции плюс физическая длина последней секции.

Длина оверлея вычисляется как длина файла минус оффсет оверлея.

Оверлей в память вместе с PE файлом не грузится, но pe checksum по нему считается.

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

Если у оверлея первый DWORD=00000001h, а чуть дальше где-то идет .dbg, то это дебаговая инфа. Есть и другие ее виды.

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

Замечу, что в NT'ях и далее -- большинство файлов с оверлеями, в основном с дебаговой инфой в них.

6. Собственно, что нужно чтобы дописаться к последней секции

• проверить файл на валидность: alredy-infected, subsystem=2/3, ...

• выровнять длины последней секции

• передвинуть overlay если он есть или поскипать дебаговую инфу

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

• увеличить длины последней секции на соответственно выровненные длины вируса

• увеличить imagesize на выровненную-на-objectalign длину вируса

• проапдейтить заголовки

Пример добавления к последней секции: win9X.Examplo.

7. Некоторые другие методы заражения PE файлов

• запись в алигнмент:

• хеадера

• секции

• добавление новой секции

• добавление нескольких секций, возможно фэйковых

• запись на место секции .reloc (с убиванием фиксапов)

• запись в ресурсы

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

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

• нахождение в секции данных области нулей и запись в нее

• нахождение в кодовой секции неиспользуемых "пятен" и запись по кусочкам в них

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

•

При переходе к более сложным структурам происходит переопределение понятий.

Как показывает практика, технология UEP (unknown entry point), она же EPO, то бишь варианты вставки перехода на вирус в середину файла, не очень помогает в плане недетектируемости.

1. Что потребуется

2. Где получить информацию?

3. Отладка и тестирование

4. Отладчики

5. Организация памяти в win32 -- введение

6. PE-файлы

7. Вызов кернеловских функций

8. Работа с файлами

9. Заражение PE-файлов

10. Поиск файлов

11. Резидентность (ring-3)

1. Что потребуется

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

Это правильное решение, учитывая то, что не умея писать вирусы на ассемблере, совершенно нереально писать хорошие вирусы/черви на C/C++.

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

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

Итак, вы должны слегка знать 32-битный ассемблер -- тот, в котором EAX'ы вместо AX'ов. Перейти сразу с 16-битного асма на 32-битный -- HЕ ПОЛУЧИТСЯ, а тем более сделать это параллельно с изучением вирусов под win32.

На компьютере, где вы работаете с этим текстом, потребуется следующий софт:

• Windows 95/98/NT/2000 (рекомендую Win98)

• 32-битный ассемблер TASM 5.0; необходимы файлы: tasm32.exe, tlink32.exe, import32.lib, *.inc

• отладчик Soft-ICE под Windows (например Soft-Ice 4.00). сдесь следует проявить настойчивость, и, если айс глючит, то:

1. найти более новый/старый айс

2. попробовать другие винды

3. поменять железо

• удобная файловая оболочка и текстовый редактор. Необходимо добиться, чтобы компиляция файла достигалась нажатием не более одной-двух клавиш. Тут я рекомендую Dos Navigator, некоторые пользуют Far+MultiEdit.

• нужно, но не необходимо: HIEW, IDA Pro

• _HИКАКИХ_ (выкинуть в помойку): TurboDebugger, Norton/Volkov Commander, HyperTerminal, etc.

Кроме этого, потребуется такая документация, как:

• WIN32.HLP -- жизненно необходимо; занимает около 12 MB, я взял из Borland C++, есть также в бормановском билдере, наверное есть в SDK.

ФИШКА: параметры всех функций описанных для C-вызовов, на асме надо PUSH-ить в ОБРАТHОМ порядке.

ФИШКА 2: Данный файл аналогичного содержания можно также взять из Borland Delphi.

• DDPR.HLP -- необходимо для win9X ring-0/VxD; есть в DDK.

• лучше чтоб были SDK и DDK. это такие здоровые архивы с доками, инклюдниками и прочим стаффом, для написания простых аппликух и драйверов соответственно.

• Так же очень неплохая штука это "Описание формата PE" by Hardwisdom, тем более на русском языке.

2. Где получить информацию? Книги

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

• Мэтт Питрек "Секреты системного програмирования в Windows95"

• Эндрю Шульман "Hеофициальная Windows 95" (2-e издание)

Софт

<http://protools.cjb.net>

Интернет

Русскоязычные сайты:

• <http://z0mbie.host.sk> - Страничка Z0MBiE, передовые вирусные технологии

• <http://topd.tsx.org> - Он-лайн журнал Top Device, статьи, ссылки на сайты с документацией.

• <http://smf.chat.ru> - Сайт группы SMF

• <http://myallstar.cjb.net> - Сайт группы Misdirected Youth

• <http://vx.netlux.org> - Огромный архив журналов, исходников, ссылок.

Западные:

• <http://www.coderz.net> - Море вирмейкерских страничек

• <http://virus.cyberspace.sk> - Вирусный сайт Asterix'a.

IRC

Undernet:

• #virus - Англоязычный, но на нем можно встретить и русскоговорящих

• #smf - Русскоязычный

EFnet:

• #sgww - Русскоязычный

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

3. Отладка и тестирование

Поговорим от том, как наиболее эффективно производить отладку и тестирование вирусов, независимо от их написания.

Задача:

1. Взять какой-нибудь простой ЧУЖОЙ win32-вирус в исходниках рекомендую любой из in-the-wild вирусов (получивших распространение)

2. Откомпилировать, запустить и размножить

3. Пройтись по нему отладчиком

4. Вернуть машину в исходное состояние (убрать вирус)

5. Сделать это за минимальный срок

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

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

Всего есть четыре последовательных уровня отладки готового кода:

1. Тестирование свеженаписанного куска кода -- отдельно от вируса.

2. Отладка новой модификации вируса (после добавления свеженаписанного кода) -- на своей машине; в целях безопасности -- измените все используемые расширения с .EXE (и/или сигнатуры с PE00) на что-нибудь другое, как в вирусе так и у файлов-жертв.

3. Отладка полностью работающего вируса -- на своей машине.

Для этого требуется:

1. создать на винте отдельный раздел

2. сделать две версии таблицы разделов в MBR'е, таких, чтобы при основном MBR'е были видны все разделы, а при "вирусном" MBR'е работал только "вирусный" раздел

3. Написать пару программок прописывающих эти MBR'ы на винт

4. Загрузиться с "вирусного" раздела и установить на нем восстанавливалку оригинального MBR'а, винды, софт-айс, ну и что там еще понадобится

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

6. Написать .BAT-файл, форматирующий (стирающий) вирусный раздел и распаковывающий туда весь запакованный стафф (установленные винды, айс, и т.п.)

7. Сделать дискету, на нее записать программу, восстанавливающую оригинальный MBR

В результате для тестирования вируса потребуется:

1. запустить BAT файл и через 5 мин у вас будет готовый к тестированию раздел

2. записать на "вирусный" раздел подлежащий тестированию вирус

3. запустить программку, прописывающую "вирусный" MBR на винт

4. перезагрузиться

5. размножить/отладить вирус на "вирусном" разделе

6. прописать нормальный MBR обратно (другая програмка)

7. перезагрузиться в "нормальный" раздел

Все технические приготовления для одного такого тестирования должны занимать не более 5-10 минут; иначе это будет неэффективно. Конечно, можно тестировать вирус и на "своем" разделе, а потом либо написать свой собственный антивирус либо переставить винды; можно таким же образом восстанавливать "свои" винды.

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

4. Отладчики

Единственный отладчик, который потребуется -- это Soft-Ice.

При установке Soft-Ice обратите особое внимание на выбор видеоадаптера, не стоит отчаиваться если вы выбрали из списка предложенных именно ваш видеоадаптер, но ничего не заработало. В этом случае стоит попробывать выбрать другие видеоадптеры, возможно с каким-то все заработает. (Мой Trident 8900, упорно не хотел работать как Standart Trident SVGA, но отлично заработал как Trident 9440). Если вы перепробывали все видеоадаптеры, но ничего не заработало, практически в 100% помогает выбор VESA, правда в этом случае Soft-Ice будет работать в оконном режиме, а не в полноэкранном.

Как это не удивительно, но для меня составило большую трудность найти серийный номер для Soft-Ice в интернет. Серийный номер 5103-00009B-9B работает по крайней мере с Soft-Ice 4.03-4.05.

Главное надо помнить, что Soft-Ice в использовании не сложнее турбо дебагера, а по возможностям намного превосходит его.

Отлаживать вашу программу с помощью Soft-Ice тоже просто, для этого нужно вставить в начало вашей программы вызов 3-го прерывания, а в файле winice.dat после строки INIT= добавить i3here on; Теперь при запуске вашей программу после выполнения int 3 управление получит Soft-Ice, и вы сможете спокойно ее отлаживать.

Основные команды в нем почти те же самые, что и в досовском DEBUG.EXE, который обязан знать каждый. На любую комбинацию команд можно назначить хоткей.

Просмотреть в айсе команды можно написав в командной строке h (или help), можно также использовать ? в DEBUG.EXE -- это более понятно.

5. Организация памяти в win32 -- введение

Всего рассказать не смогу, ибо не знаю; поэтому для начала просмотрите все доки, которые у вас есть на эту тему. Рекомендую взять описание какого-нибудь процессора (386,486,586), там будут главы посвященные организации памяти. Лучше нет ничего.

Итак, win32 -- мультизадачная система, и в ней живут много процессов (программ). И каждый процесс находится в своем собственном 32-битном виртуальном_адресном_пространстве.

32-битное значит, что всего в этом пространстве 2^32 байт, или 4 гига. По сути виртуальное_адресное_пространство представляет из себя набор 4-килобайтных страниц обычной (физической) памяти, "отображенных" в самые разные "виртуальные" адреса (кратные 4-м килобайтам), от 0 до 0xFFFFF000. Те места, куда ничего "не отображено" -- "пустые" (их большинство), при чтении/записи возникает ошибка.

Все 4-килобайтные страницы в 4-гигабайтном пространстве могут быть ВЫДЕЛЕНЫ (allocate), и тогда соответствующим диапазонам виртуальных адресов будет соответствовать физическая память, на харде или в памяти. Страницы могут быть ОСВОБОЖДЕНЫ (free, deallocate), и тогда информация об отображении теряется, а физическая память "освобождается", то есть становится СВОБОДНОЙ для последующего использования. Выделенные страницы могут быть ПОДГРУЖЕНЫ (commit, lock), тогда они будут "зафиксированы", т.е. окажутся где-то в реальной физической памяти. Подгруженные страницы могут быть ВЫГРУЖЕНЫ (decommit, unlock), и тогда физическая память освободится, а данные из нее будут временно сброшены на диск в своп (swap-file).

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

То, что показано на рисунке (справа) -- это виртуальное_адресное_пространство одного процесса, а раз процессов таких много, то и виртуальных_адресных_пространств тоже много.

Информация об отображении реальной памяти в виртуальную (одного виртуального_адресного_пространства), вместе со всеми данными хранящимися в этой памяти называется КОНТЕКСТом. И говорят, что каждый процесс существует в определенном контексте. В контексте каждого процесса находятся код/данные самого процесса, стэки, хеап (heap), код/данные ядра системы, используемые процессом библиотеки (DLL) и прочяя хрень.

Представьте себе тетрадь в клетку, на каждом из листов что-то нарисовано. Клеточки -- это страницы памяти по 4k. Листы бумаги -- это контексты, или виртуальные_адресные_пространства.

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

Что где в памяти находится:

Самая главная фишка.

Заключается в том, что для каждой страницы существует так называемый уровень доступа. В win32 всего два уровня защиты: ring-3 (юзер) и ring-0 (ядро). Находясь в ring-0 свершенно наплевать какой уровень доступа у какой страницы -- все их (подгруженные) можно без проблем читать и писать. А вот для ring-3 есть несколько вариантов:

1. страницы для чтения и записи (read-write)

2. страницы только для чтения (read-only)

3. хуй (ни читать ни писать в такие страницы нельзя)

4. комбинации вышеперчисленных с испольнябельностью (executable), а также guard, writecopy и еще хер знает что -- скорее всего ничего их этого вам не встретится.

Быстро узнать текущий уровень доступа (0/3) можно взяв два младших бита CS.

Идея в том, что кодовые страницы в системе помечаются как read-only, и поэтому их можно исполнять и читать, а вот писать в них нельзя. Это в основном страницы кода в kernel'е и в ваших PE-файлах. Проблема с PE-файлами решается добавленим нужного бита в ObjectEntry соответствующей кодовой секции при заражении файла, либо в ран-тайме через VirtualProtect/WriteProcessMemory; проблема с kernel'ами и системными хернями решается (под маздаем) несколько более хитрыми приемами.

6. PE-файлы

PE (Portable Executable) -- это такой формат, в котором представлены практически все win32 EXE и DLL файлы. Поэтому с этим форматом мы и будем работать.

Прежде всего, рассчитаны PE EXE/DLL файлы на работу в третьем кольце, через KERNEL32.DLL и прочие библиотеки.

KERNEL32.DLL и другие библиотеки ЭКПОРТИРУЮТ (отдают) другим PE файлам кучу процедур, которые по существу и есть win32 api.

Обычные PE файлы ИМПОРТИРУЮТ (принимают) из KERNEL'а и других DLL-ек часть функций, и через них общаются с системой.

А сам KERNEL32.DLL и прочие работают уже с нулевым кольцом (больше 2-х гиг), где и происходит основная часть всех действий.

Происходит все это так: в каждом PE файле есть структуры импорта и/или экспорта (хотя их там может и не быть), в которых записаны примерно такие вещи:

В результате при запуске MAZAFUK.EXE загрузчик обязан загрузить в контекст этого процесса KERNEL32.DLL и все остальные требуемые DLL-ки, а адреса импортируемых из них функций положить в специально для этого отведенные в MAZAFUCK.EXE дворды. Так что после загрузки, мазафак будет просто делать CALL'ы по соответствующим двордам.

При написании обычных PE-EXE файлов, ни о каких импортах/экспортах думать не надо, эти занимается линкер (tlink32.exe). Просто указываются следующие вещи:

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

Рассмотрим PE-файл в памяти. (полное описание формата смотрите отдельно)

Файл этот состоит из следующих частей:

• MZ-заголовок

• PE-заголовок

• таблица секций (==таблица объектов)

• секции (несколько штук)

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

Нужно понять, что в отличие от, скажем, dos'овского COM файла, образ PE файлов в памяти не соответствует их образу на диске. Хотя, в отличие от dos'овских EXE-файлов, все их заголовки загружаются в память целиком. Идея в том, что разные секции загружаются в виртуальную память не так, как они хранятся на диске, то есть виртуальные_адреса_секций_относительно_начала_файла_в_памяти (RVA) не соответствуют физическим_адресам_секций_относительно_начала_файла_на_диске. Информация об этих несоответствиях и хранится в таблице секций.

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

В PE-заголовке есть поле ImageBase. Оно выровнено на 64k (что не есть факт), и указывает, начиная с какого виртуального адреса файл должен быть загружен в память. MZ-заголовок, PE-заголовок и таблица секций загружаются прямо по этому адресу, как они есть.

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

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

7. Вызов кернеловских функций

Это хитрая фишка, и ее надо отлаживать ОТДЕЛЬНО от всего прочего. Ваша задача: написать процедуру, которой на вход приходит имя (или хэш от имени) некоторой функции из KERNEL32.DLL, а на выходе мы получаем адрес этой функции.

Путь лежит через два шага:

1. научиться получать адрес KERNEL32.DLL, и

2. производить анализ кернеловских экспортов

Адрес kernel'а во всех маздаях (win9x) суть BFF70000. Под winNT этот адрес другой, и, вроде бы, может быть разным в разных версиях. Что касается адресов экспортируемых функций, то они разные в каждой версии и маздая и NT'ей.

При получении управления в PE файл прямо из загрузчика, на стэке лежит адрес возврата в загрузчик. В маздаях загрузчиком является KERNEL32.DLL, поэтому сняв со стэка адрес можно узнать адрес внутри kernel'а. С другой стороны, делать этого не нужно, так как в маздаях кернел фиксирован. Другое дело, winNT.

Там, сняв со стэка адрес возврата мы получаем адрес какой-то там левой DLL-ки, далее выравниваем его на 64k и сканируем вниз до MZ. Там смотрим в экспорт и проверяем, не kernel ли это. Если не кернел, то анализируем уже ИМПОРТЫ, и только оттуда узнаем адрес какой-нибудь кернеловской функции. (она там наверняка будет). Анализировать импорта - это значит разобрать секцию импорта жертвы и найти там функции вызываемые из kernel, и уже по адресам этих функций найти адрес кренеля в памяти.

Существует два простых способа анализа секции импорта:

1. Поиск GetModuleHandleA

Поиск в секции импорта адреса функции GetModuleHandleA, затем вызвав ее получить хендл(т.е. адрес) кернеля в памяти.

Тут надо сделать два замечания:

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

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

2. Адрес любой импортируемой функции

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

Как узнать адрес начала PE-файла зная ЛЮБОЙ виртуальный адрес внутри файла?

Поскольку:

1. адрес загрузки PE файла выровнен на 64k,

2. практически всю память от начала файла и до конца выделенной ему области можно читать

3. в самом начале файла лежит MZ-заголовок

то справедлив следующий алгоритм:

1. взять любой виртуальный адрес внутри файла

2. выровнять на 64k

3. если по адресу HЕ байты 'MZ', то вычесть из адреса 64k и повторить 3

Как анализировать kernel'овские экспорты?

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

Путь 1, наилучший: посмотреть формат PE файлов, ту его часть, где описаны экспорты, и, получив адрес kernel'а, самому разобрать его таблицу экспортов и найти адреса требуемых функций.

Путь 2, весьма отстойный: юзать директом следующий код:

Глюки тут бывают такие:

1. Если в программе вообще нет импортов, то -- вроде бы kernel подгружаться не должен -- но kernel это специальная dll'ка, кояя загружена всегда; взамен этого возникнут проблемы с вызовом кернеловских функций. Ситуация 'нет импортов' возникает, например, когда во всем сорце нет ни одной директивы EXTERN, а выход из файла происходит по RET'у. (такое возможно, например во всяких специальных DLL-ках)

2. Имена функций, иногда в зависимости от того, юзают ли они в качестве параметров символьные строки (а не только числа), могут кончаться на -A и на -W. Постфикс -A (ascii) значит, что строки в ASCII формате, то есть элементами строк являются БАЙТы, и кончаются они на 0. Постфикс -W (wide) значит, что элементами строк являются ВОРДы, это суть так называемые юникодные строки, а вообще это большая лажа, та как некоторые такие функции кернелом не поддерживаются. Функции эти (-A/-W) дублируются, то есть если есть одна, то скорее всего есть и другая; более того, у них одинаковые параметры вызовов, а все различия только в формате передаваемых им строк. Бывает, имена функций имеют в конце -Ex, то есть кончаются на Ex, ExA и ExW. Так вот, постфикс -Ex суть просто часть имени функции. Такие функции по сравнению со своими упрощенными (без Ex) вариантами, юзают большее (EXtended) число параметров, а могут упрощенных вариантов и не иметь. Как правило, внутри "упрощенных" функций управление передается на их -Ex - варианты.

Так вот, о чем там я. Говно заключается в том, что в большинстве документаций описаны функции типа CreateFile, а на самом деле такой функции в kernel'е HЕТУ. А есть в кернеле две функции: CreateFileA и CreateFileW. Просто доки расчитаны на C-шный компилятор, который сам разберется, какого типа строки передаются этой функции, и добавит A или W соответственно.

Поэтому, перед тем как передавать в свою процедуру_поиска_функций_в_кернеле имя какой-нибудь функции, убедитесь (гляньте в kernel32.dll) что такая функция там в точности существует.

8. Работа с файлами

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

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

Более подробно эти функции приведены на моей страничке в maplib4.zip.

И еще одно. Некоторые любят использовать для работы с файлами макросы. Макросы эти будут вставлять в вирус немерянные куски кода, PUSH-ащие кучи нулей, и каждый такой макрос будет занимать байт по 30. Так что для уменьшения длины вируса и упрощения его отладки лучше юзать процедуры. Кроме этого, есть замечательный "старые" (т.е. проверенные временем) процедуры типа lopen, lread и т.п.

Пример считывания файла в память:

9. Заражение PE-файлов

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

Наиболее простым и эффективным методом заражения PE файла является добавление к его последней секции. Для этого надо:

• проверить физическую и виртуальную длину последней секции: если физическая длина окажется больше виртуальной, не трогать такой файл; также не трогайте файл если какая-либо из длин нулевая

• старую точку входа сохранить внутрь вируса;

• вычислить виртуальный адрес вируса в файле; это будет физический_адрес_конца_последней_секции транслированный_в_виртуальный; добавив к нему VirusEntryPoint-VirusStart записать это дело в RVA точки входа (внутри PE-заголовка)

• по физическому_адресу_конца_последней_секции записать вирусный код

• физическую и виртуальную длины вируса округлить по FileAlignment и ObjectAlignment, взятым из PE-заголовка

• физическую длину последней секции -- увеличить на физическую длину вируса

• виртуальную длину последней секции -- увеличить на виртуальную длину вируса

• поле SizeOfImage внутри PE-заголовка -- установить равным виртуальному_адресу_начала_последней_секции + виртуальной_длине_последней_секции

В принципе все. Кроме всего описанного, надо еще проверять такие вещи, как не оверлей ли это, не DLL-ка ли это и не нулевая ли точка входа. Если в файле нет импортов -- не заражать. Если в файле есть фиксапы, а вирус привязывается к imagebase -- не заражать.

На практике такое заражение проявляется как:

1. считывание заголовков файла

2. их анализ

собственно заражение:

3. изменение заголовков и настройка вируса

4. дописывание вируса к концу файла

5. запись измененных заголовков назад в начало файла

Убивать фиксапы можно только если это не DLL-ка; привязываться к imagebase можно только если отсутствуют (убиты) фиксапы.

Переход на оригинальную точку входа рекомендуется делать командой JMP (опкод 0xE9). Это потому, что если делать PUSH <address>/RETN, потребуется фиксап, т.к. файл может быть загружен в другой imagebase.

Если точка входа нулевая, то это должна быть DLL'ка. В таком случае дефолтовый обработчик выглядел бы так:

но раз его в файле нет, то сделайте свой собственный, а перед mov eax,1 выполняйте вирусные действия.

10. Поиск файлов

Теперь осталось только научиться искать новые файлы. Опять же, это надо отлаживать отдельно. Поиск осуществляется фукциями FindFirstFileA / FindNextFileA / FindClose. Достаточно вставить нахождение пары файлов и их заражение в начало нашей программы, и простейший win32-вирус готов.

Вот как примерно выглядит рекурсивная процедура поиска файлов в каталоге:

11. Резидентность (ring-3)

Резидентность, такая как в DOS'овых TSR-программах, в win32 отсутствует. Это ясно из того, что система мультизадачная. Достаточно скрыть программу в памяти, и она будет молча, никому не мешая, работать, например искать и заражать новые файлы.

Наиболее простой и эффективный способ "резидентности": Скопировать текущий файл в виндовую диру (GetWindowsDirectoryA, CopyFileA) под именем DROPPER.EXE, и прописать в системых настройках этот дроппер как выполняемый при загрузке.

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

Как скрыть прогу от менюхи по ctrl-alt-del? Работает только в маздае; в winNT такой функции как RegisterServiceProcess нет, поэтому проверяйте, найдена ли она в экспортах.

Перечень запущенных процессов/модулей/нитей можно получить через Process32First/Next, Module32First/Next, Thread32First/Next. Поэтому на этих функциях можно делать стелс, впатчив кусок кода в кернел.

Да, как вы наверное уже знаете, запущенные программы в win32 нельзя стереть/открыть на запись, а значит, и заразить. Есть два способа обхода этого дела, для win9X и для winNT.

Под маздаем к %windir\wininit.ini дописываются 2 строчки:

И заражается не открытый файл, а его копия, которая затем при перезагрузке будет автоматом переименована в файл, а оригинальный файл стерт. Указанную херь к файлу удобно дописывать функцией WritePrivateProfileStringA. А в ring-0 можно заразить даже открытый файл.

Под winNT дважды используется ф-ция MoveFileExA с параметром DELAY_UNTIL_REBOOT, первый раз чтоб стереть старый файл и второй раз для переименования. Однако, как выяснилось, MoveFileExA суть наиглючнейшая штука, и у кого он там работает, я не знаю, и ни под winNT 4 ни под win2000 нихуя заменить explorer.exe им не получилось. Поэтому, в NT 3/4 просто переименовывайте старое имя файла в рандомное, даже если он сейчас исполняется; а под win2000 перед этим отключайте SFC. Ну и кроме этого есть SETUPAPI.DLL::SetupInstallFileA, что суть _работающий_ аналог movefileex'а.

Нити.

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

---

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

Алгоритм, в самых общих чертах

Алгоритм из тех, что с открытым и секретным ключом.

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

Подписать сообщение может только владелец секретного ключа, а проверить подпись - владелец открытого.

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

<<...С резким скачком производительности вычислительной техники сначала столкнулся алгоритм RSA, для вскрытия которого необходимо решать задачу факторизации. В марте 1994 была закончена длившаяся в течение 8 месяцев факторизация числа из 129 цифр (428 бит). Для этого было задействовано 600 добровольцев и 1600 машин, связанных посредством электронной почты. Затраченное машинное время было эквивалентно примерно 5000 MIPS-лет.

Прогресс в решении проблемы факторизации во многом связан не только с ростом вычислительных мощностей, но и с появлением в последнее время новых эффективных алгоритмов. (На факторизацию следующего числа из 130 цифр ушло всего 500 MIPS-лет). На сегодняшний день в принципе реально факторизовать 512-битные числа. Если вспомнить, что такие числа еще недавно использовались в программе PGP, то можно утверждать, что это самая быстро развивающаяся область криптографии и теории чисел...>>

Шифровка/расшифровка (теория)

Основная фича в том, что алгоритм оперирует "большими" числами, то есть числами, состоящими из сотен бит.

Открытый ключ (public key) -- это числа e и m. (e от слова encrypt, шифровка)

Секретный ключ (secret key, private key) -- числа d и m. (d от слова decrypt, расшифровка)

(иногда пишут {e,m} и {d,m} - на самом деле это ничего не значит)

Числа m и d - большие. Число e - маленькое, часто принимается равным 3, 9, 17, и т.п. Как видите, число m - одно и то же в обоих ключах (известно всем), а число e, зная m и d, обычно может быть легко найдено. Исходя из этого логично было бы считать m открытым ключом, а d секретным, но, так уж принято.

Согласно RSA, большое число x (причем x < m) зашифровывается в y так:

а расшифровывается обратно так:

Здесь ^ означает возведение в степень, а % -- остаток от деления, иначе называемый модуль. (не путайте этот модуль с абсолютным значением, оно здесь вообще нигде использоваться не будет) Часто модуль записывается так: a = b (mod m). Читается как "а равно b по модулю m". Значок % используется в Си, x mod y в Паскале, а x = y (mod m) во всякой литературе. Например: 10 mod 3 = 1.

Но вернемся к шифровке. Откуда берется x -- понятно и ежу, это же и есть ваше исходное сообщение, только представленное в виде большого числа. А нахождение чисел m,d и e называется "генерация ключей".

Генерация ключей (теория)

Для генерации ключей можно использовать старое доброе досовское PGP 2.6.x с параметрами -kg -d. Сгенеренные числа m/d/e будут выданы на экран. Если вы твердо решили написать свою реализацию RSA, то лучше, оставив генератор ключей на потом, сразу приступайте к шифровке/расшифровке (подпрограмма modexp).

Итак, генерации RSA-ключей (чисел m/d/e) заключается в следующем:

• Найти большие простые числа p и q, длина произведения (сумма длин) которых (в битах) равна длине искомого RSA-ключа. Простые -- значит не имеющие делителей кроме единицы, например 7, 11, 23. Обычно длины p и q принимаются одинаковыми - например по 128 бит для 256-битного ключа. Хотя есть и модификации алгоритма с существенно разными длинами p/q, для ускорения вычислений и, наверное, затруднения хака.

• Число m принимается равным m = p * q.

• Выбирается число e, взаимно простое с произведением (p-1)*(q-1). Взаимно простое -- значит не имеющее общих делителей, кроме единицы. Так как числа p и q - простые, а значит - нечетные (ибо не делятся на 2), то (p-1)*(q-1) -- число четное, и, соответственно, e будет нечетным. При этом e не может быть равно 1, ибо тогда шифровка не имеет смысла, так что минимально допустимое е равно 3.

Обычно выбирают некоторое начальное e, и пробуют e, e+2, e+4, e+6 и т.п., до тех пор, пока числа e и (p-1)*(q-1) не окажутся взаимно простыми. Записывается это условие так:

что равносильно:

Здесь GCD (Greatest Common Divisor) есть не что иное как НОД (Наибольший Общий Делитель).

Должно быть ясно, что если e = 3, то никакого GCD считать нихрена не нужно, а достаточно взять (p-1)*(q-1) и поделить на 3, и если не делится (остаток != 0), то все окей.

Кроме того, вместо (p-1)*(q-1) можно в разных источниках встретить что-то типа lambda(m) = lcm((p-1)*(q-1)), где LCM (Least Common Multiple) -- НОК (Наименьшее Общее Кратное). Так как множителя два, и друг на друга они, очевидно, не делятся (ибо длины p и q обычно принимаются равными), то никакого lcm считать не надо, достаточно просто умножить p-1 на q-1.

• Число d вычисляется такое, что (e * d) % ((p-1)*(q-1)) = 1.

Другими словами:

где modinv (modular inverse) -- специальная хитрая функция, кояя пользует так называемый алгоритм Евклида.

Возможных значений d, соответственно, бесконечно много:

Как видно, t=0 является наилучшим вариантом для достижения наибольшей скорости, однако, если задача, наоборот, максимально замедлить вычисления (бывает и такое, смотри DPGN), то можно выбрать t > 0.

Собственно на этом генерация ключей кончается.

Вникнув в алгоритм, можно видеть, что именно числа p и q и составляют самую секретную фишку. Вы скажете: но ведь m=p*q публикуется? Да. Именно в эффективном алгоритме разложения m на p и q и состоит хак.

Более быстрая расшифровка

Обычно расшифровку x = (y ^ d) % m заменяют чуть более сложным, но и более быстрым алгоритмом:

Почему алгоритм более быстрый? -- потому, что оперировать приходится более короткими числами, и в результате производится меньше операций. Хотя, признаюсь, используя этот метод у меня получилось увеличить скорость всего на 10% на C++.

Однако при использовании p и q разных длин, можно получить куда более существенный выигрыш в скорости. Недословно цитирую: "при замене 512-битных p и q на 256 и 768 бит получен выигрыш в скорости в 16 раз".

Шифровка/расшифровка

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

modexp()

Теперь рассмотрим вопрос о возведении большого числа в степень:

Такая процедура обычно называется modexp.

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

То есть будем рассматривать число e как степени двойки:

Кроме того, очевидно следующее:

Поэтому (x^(32+8+1)) % m может быть вычислено как:

Откуда брать x^i (i-ю степень x)? - в цикле умножать число x само на себя. В результате алгоритм нашей подпрограммы будет выглядеть так:

Как видно, все, что делает процедура modexp() -- это вызывает процедуру modmult() -- выполняющую c = (a * b) % m -- N раз, где N = e.общее_число_бит + e.число_единичных_бит - 1.

modmult() - вариант 1

Теперь рассмотрим процедуру modmult():

По аналогии с modexp()-ом, разложим b на степени двойки, т.е. воспользуемся формулой:

здесь << означает shl, двоичный сдвиг влево, т.е. x << y = x * (2^y).

Кроме того, ясно, что:

Таким образом для b=32+8+1, (a * b) % m будет вычислено как:

Текущее значение a<<i вычисляется в цикле, последовательным сдвигом на 1.

Вычисление модуля производится последовательным вычитанием m из c, каждый раз когда число с становится больше m. Это становится возможным из-за того, что длина числа c каждый раз увеличивается не больше чем на 1 бит (а значение - в 2 раза), и избавляет от необходимости выполнять нахождение остатка от деления после умножения.

modmult() - вариант 2

Здесь предлагается другой вариант, умножение столбиком. Такая процедура будет работать намного быстрее за счет встроенной в x86 32-битной команды MUL. Кроме того, что в отличие от предыдущей процедуры потребуется в 32 раза меньше операций (т.к. оперируем двордами, а не битами), насколько я слышал, в x86 процессор заложен еще и так называемый алгоритм быстрого окончания, то есть умножение старших нулевых битов множимого/множителя не происходит. Практика показала, что этот вариант modmultа быстрее в 2 раза.

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

1. Собственно умножение "столбиком": t = a * b. Очевидно, что разрядность числа t (число бит) будет равно сумме бит чисел a и b, то есть при одинаковой длине последних, длина t будет вдвое больше.

2. вычисление остатка от деления

Это, конечно, плохо, но придется. Итак, сейчас мы имеем t = a * b, и надо посчитать c = t % m.

Вот алгоритм:

Идея алгоритма в том, что мы последовательно вычитаем из c m<<maxbit(t), ..., m<<i, ..., m<<2, m<<1, m.

Сложение, вычитание, сравнение

Эти операции над большими числами релизуются достаточно просто:

Генерация ключей: нахождение больших простых чисел p и q

Заполняем число случайными значениями, и проверяем, является ли оно простым. Если не является, то увеличиваем число и проверяем еще раз. И так до тех пор, пока не задымит процессор.

Используется здесь такая оптимизация: начальное число выбирается нечетным, и затем увеличивается не на 1, а на 2. Это делается для того, чтобы заранее выбросить все четные (и соответственно, составные) числа.

Как узнать, является ли текущее число простым?

Есть два способа: быстрый, но ненадежный и медленный, но надежный. Используются оба.

Способ первый. "решето" (sieve). Используется, чтобы отсеять большинство составных чисел (т.е. не являющихся простыми).

Идея в следующем: делим тестируемое число p на сотню первых простых чисел. Если делится (остаток от деления равен нулю) - число составное.

На самом деле, конечно, никто не будет постоянно делить большое число на сотню простых, это очень долго. Поэтому производится следующая оптимизация: составляется таблица остатков remainder[] от деления начального значения тестируемого числа p на нашу сотню простых чисел prime[]. Затем, при поиске простого числа, вместе с самим числом p увеличивается некоторое дельта-значение pdelta. И при поиске остатка от деления p на i-е простое число prime[i] вместо p в качестве делимого берется сумма pdelta+remainder[i].

То есть, используется равенство:

Следует это из уже рассмотренного выше правила:

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

Способ второй. Сюда подаются на проверку только числа, прошедшие предыдущую проверку. Используется так называемая теорема Ферма: для любого a, если (a ^ (p-1)) % p != 1, то x - число составное. В качестве a обычно пробуют числа 2,3,5,7. Как видим, здесь просто вызывается описанная раньше процедура modexp().

Вычисление GCD

Итак, вот мы сгенерили простые числа p и q.

Теперь перебираем e = 3,5,7,9,... пока GCD(e, (p-1)*(q-1)) не окажется равным единице. (можно начинать с любого другого значения числа e, обычно тройка используется из соображений максимальной скорости)

Как посчитать GCD(x,y)? - используя так называемый алгоритм Евклида.

Поскольку число x - большое, а y - обычный дворд, оптимизируем алгоритм так: первый раз считаем остаток от деления большого числа на дворд, а затем уже оперируем только двордами. Вычисление остатка от деления приведено в описании процедуры modmult() - 2.

Вычисление modinv() (modular inverse)

Процедура modinv(a,m) возвращает такое i (0<i<m), что (i*a) mod m = 1. Число a должно быть 0<a<m.

Вот ее алгоритм из исходников PGP 2.6.x: (genprime.c)

А вот алгоритм из каких-то других исходников:

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

Что все это значит, я пока не представляю. Какая-то хуйня. Хотя на ассемблер в конце концов переписалось и заработало ;-)

Деление больших чисел

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

Еще что-нибудь про ассемблер

Удобно оперировать битами в больших числах командами BT/BTS/BTR/BTC. Выглядит это так:

То же самое, но из обычных команд:

Сдвиг большого числа влево (x shl 1, x * 2) Как происходит реальная шифровка

В случае, когда длина сообщения подлежащего шифровке больше длины RSA-ключа (длины числа m, в битах), сообщение разбивается на соответствующие блоки: для каждого блока (числа x) должно соблюдаться условие x < m. Можно например посчитать длину числа m в байтах и длину блоков принимать на байт меньше, и т.п.

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

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

Перед шифровкой алгоритмом RSA данные рекомендуется зашифровывать с использованием случайного элемента, по причине low-exponent attack.

low-exponent attack

Пусть некоторое сообщение x посылается e получателям, так, что открытые ключи каждого из них {e,n1}, {e,n2}, {e,n3}, ...

Хак заключается в восстановлении исходного сообщения, зная e открытых ключей и e зашифрованных сообщений.

Пусть e = 3, x -- исходное сообщение, y1,y2,y3 -- зашифрованные сообщения, n1,n2,n3 -- модули открытых ключей. Тогда x^3 может быть найдено следующим образом:

Вычисление кубического корня из большого числа осуществляется простейшим бинарным поиском:

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

Еще один способ хакнуть RSA

Вот некий способ похакать RSA, предложен толи каким-то Pinoy'ем, то-ли неким Leo de Velez'ом. Способ насколько теоретически прост, настолько же практически не реализуем.

Есть формула: 2^X = 1 (mod m), где m - модуль, присутствующий в обоих ключах, а X необходимо найти. Ясно, что X = e * d - 1, откуда, найдя X и зная открытое e, можно вычислить секретное d по формуле d = (X + 1) / e.

Идея тут в том, чтобы умножить m на некое Y, так, чтобы произведение m * Y состояло из одних двоичных единиц, то бишь и было равно 2^X-1. Отсюда несложно найти X, равное длине полученного произведения в битах.

Однако, способ нахождения Y, коий предложил de Velez, неверен. То есть эффективного способа попросту нет.

А даже если бы он был, то все равно вычислить ни m * Y, ни Y, ни X (для реальных ключей) было бы невозможно, так как \_длина\_ в битах числа X того же порядка, что и \_значение\_ e*d, а поскольку число d - большое, то длина X была бы например 2^1024, а значение 2^(2^1024), что есть полнейший бред.

В помощь изучающим исходники на английском

Рекомендуются исходники от PGP 2.6.3ia -- там все понятно и с комментариями.

---

Второй вирус (win32.zperm.b == z0mbie7) это почти то же самое, но вместо RPME там Ply-подобная мутация, то есть каждая команда дополнена до 16 байт NOPами, "плавает" в них, и кроме этого каждый 16-байтный блок может перемещаться в случайную область буфера, и все, опять же, связывается JMP-ами.

Следует сказать, что каспер весьма порадовал тем, что продетектил оба вируса одним и тем же кодом. А особенно мне понравилось название вирусов.

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

В общем, детектирование проводится так:

1. Брать команды по одной, удалять среди них JMPы и NOPы, полиморфные команды приводить к одному виду, переменные аргументы заменять на 0, копировать все это в буфер.

2. Просчитать по буферу контрольную сумму.

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

Короче говоря, алгоритм писался на конкретный вирус явно без учета всех возможностей пермутирующего движка. Например "обменяные" местами ветви алгоритма (при замене jz <--> jnz) и перемешанные инструкции не обрабатываются никак. Наверное это потому, что такие конструкции не встречаются в самом начале вируса, а именно по его началу и проводится проверка контрольной суммы. Это, в свою очередь, является продолжением старой традиции антивирусников детектировать вирус по длине контрольной суммы не составляющей и десяти процентов от общей длины вируса.

Ниже приведен детектирующий антивирусный код.

Интуитивно ясно, что внесение избыточности в информацию позволяет находить и восстанавливать помехи. Пример тому - избыточность естественных языков. Сколько избыточности вносить и как ее считать, можно прочитать у Шеннона.

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

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

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

Вот и все. Максимальное количество восстанавливаемых подряд байт равно числу столбцов. Количество строк и столбцов выбирается как вам удобнее.

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

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

Пример.

Есть данные, и есть контрольные суммы по строкам и по столбцам, посчитанные XORом. Пусть байт 74 (jz) изменили на EB (jmp).

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

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

Как вычислить старое значение байта?

• проXORить старую контрольную сумму на новую и на новое значение байта.

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

Пример на C++

Примечание (для тех кто не знает C):

Результат работы программы

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

В основном такими:

То есть такая схема подсчета контрольных сумм хорошо работает только если изменения произошли в пределах одной строки/столбца. Поэтому строки эффективно делать длиннее столбцов.

Если вас заинтересовало помехозащищенное кодирование - ищите линейный блоковый код, коды M из N, коды Хэмминга и тому подобную хрень.

---

_(x) 2000 Z0MBiE, http://z0mbie.host.sk_

Здесь и проявляются охуительно быстро распространяющиеся макро-черви. Такой червь может в считанные дни "разнести" некоторый дополнительный блок данных по большому числу компьютеров, хотя будет почти так же быстро вылечен. В противоположность им идут файловые вирусы, распространяющиеся с намного меньшей скоростью, но зато и время "излечения" от оных во много раз больше, чем от макро-червей. Сравните по продолжительности эпидемии onehalf-а и cih-а с одной стороны и meliss-ы и iloveyou с другой стороны.

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

Дела обстоят так: под Win9X существуют открытые на запись таблицы IDT, GDT & LDT. Непосредственную работу с ними мы далее и проведем. Во всех примерах полагаем, что соответствующая таблица находится в памяти, открытой для записи. Также должно быть ясно, что нижеприведенный код работоспособен под ring3/ring0, а не под V86.

ПЕРЕХОД В RING-0 используя IDT

Итак, IDT (Interrupt Descriptor Table, таблица дескрипторов прерываний) описывает прерывания, существующие в протмоде. То есть, грубо говоря, это селекторы и смещения на каждое прерывание.

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

Здесь есть два пути. Можно вызывать исключеня (exception), а можно вызывать прерывания. В чем разница? Прерывание вызывается командой INT, опкод CD ;-). А исключение -- созданной нами тяжелой ситуацией. (А кому щас легко?) Например если попытаться скормить процу опкоды FF FF то он вызовет исключение 06. Делим на 0 -- 00. Трассируем -- 01. Не подгружена страница памяти -- 0E. Глюкавая программа -- 0D.

Короче говоря, разница тут между прерываниями и исключениями в том, что если дескриптор описывает исключение (например инт с номерком из вышеперечисленных) то в типе дескриптора у него похеру какой DPL, а если это обычное прерывание, то DPL надо поставить 3 (смотри сюда), иначе вызовется не требуемый инт, а INT 0D (нарушение защиты). Другое дело, если перехватывать сразу 0D.

Пример перехода в ring-0 с использованием IDT, INT 00h. Вызов исключения.

Пример перехода в ring-0 с использованием IDT, INT 01h. Вызов исключения.

Пример перехода в ring-0 с использованием IDT, INT xxh. Вызов прерывания.

ПЕРЕХОД В RING-0 используя LDT (GDT)

Таблицы GDT и LDT (Global- и Local Descriptor Table, таблицы глобальных/локальных дескрипторов) суть описывают селекторы, что в протмоде являются заменой старых добрых сегментов. Иногда, правда, кроме селекторов они описывают и более сложные объекты защищенного режима, что нам и потребуется.

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

Инфу о таблице GDT можно поиметь при помощи команды SGDT m.

Как видим можно поиметь gdt_limit -- размер таблицы уменьшенный на 1, и gdt_base -- базовый адрес таблицы.

Инфу о таблице LDT поиметь более сложно, ибо команда LGDT r/m16 возвращает селектор LDT, а дескриптор этого селектора находится в GDT.

Теперь чтобы из этого селектора (который в AX) поиметь базу/размер LDT, надо сделать так:

В чем же отличие GDT от LDT -- для нас? Если взглянуть на вышеприведенный код, то становится понятно, что работать с GDT несомненно проще, чем с LDT, и это так. Но дело тут вот в чем. Существующие антивирусы в состоянии активно противодействовать нашему переходу в ring-0. То есть они уже могут защищать от записи (записи из ring3) страницы памяти в которых находятся GDT и IDT. В частности SPIDER.VXD уже умеет защищать от записи GDT и IDT, и все вирусы читающие/пишушие в эти таблицы (то есть CIH и прочие, с похожим на него переходом в 0 через IDT) -- все они сосут.

А вот с LDT сложнее -- запись в нее использует сам находящийся в ring3 16-битный кернел от маздая, KRNL386.EXE. В этом то и заключается вся хуйня... ;-)

Итак, как же мы собираемся переходить в 0 через LDT/GDT. Как уже было сказано выше, в этих таблицах хранятся не только дескрипторы сегментов. Там еще бывают такие вещи как сегменты состояния задачи, шлюзы перехода (callgate) и еще хрен знает чего. Собственно на последних -- шлюзах -- мы и остановимся.

Шлюз перехода -- это такая хрень, которая позволяет перейти из одного кольца защиты в другое. Конкретно -- из ring3 в ring0. Что собой представляет шлюз перехода? А представляет он собой всего-навсего дескриптор в таблице GDT или LDT, а адреса их мы получать уже умеем. От обычного же дескриптора селектора дескриптор шлюза отличается некоторыми битами.

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

Итак, вот переход в ring-0 через GDT:

А вот переход в ring-0 через LDT:

Как видно, в приведенных примерах используется SEH (Self Exception Handling). Вкратце -- это дело обеспечивает переход на метку __exit при возникновении некоторых глюков.

Итак, используя почти последнее что у нас осталось -- LDT, мы перешли в ring-0. Я полагаю, что вам уже известно, что обычно делают дальше. ;-) Иначе читать этот текст бесполезно. А дальше обычно выделяют память, копируют туда вирус, перехватывают обращения к файлам, портят флэш и все такое.

Проблема заключается в уже инсталлированом простеньком драйверке -- называется он SPIDER.VXD. Конечно, проблема не только в этом конкретном антивирусе, а в возможности существования таких мониторов и в возможности всяких плохих действий с их стороны. Короче, допустим, что сей файлик, подстерегая нас на доступе к IDT и GDT, таки пропустил в ring-0. И вот, ничего не подозревающий вирус делает свой первый VxDcall. И сосет. Ибо VxDcall сделан -- откуда?, и функция GetVxdName() на вопрос антивируса "а из какого вэыксдя пришел вот ентот вот вэыксдекольчик?" честно отвечает ему "а хуй его знает". И тогда антивирус орет "батя, хуйня!", тем стремая юзера, и тот, как показано на картинке, бежит к лозинскому. Помните об этом.

Собственно о том, как всего этого избежать, и написан сей текст.

Признаюсь вам честно, я преувеличил. Пока еще не на все VxDcall-ы орет sipder, и тем пользуется библиотечка KILLAVXD. Суть ее заключается в следующем: просканировать список VxDей, найти спидера(веба)/авп, и пропатчить их так, чтобы не могли открывать никакие файлы. Пока помогает.

Но дело в том, что список VxDей мы получаем VxDcall-ом, что само по себе плохо. Дальше можно долго спорить о том, что делать и кто виноват. Можно впатчить VxDcall в VMM (0xC0001000 и дальше) и вызывать системные функции оттуда. Но на это найдутся всякие Get_Cur_VM_Handle, ProcessId и прочие, и кроме того -- на каждый такой VxDcall нас могут найти поиском в памяти, и т.п. Короче говоря, так жить нельзя.

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

Как убить -- да все так же. Найти VxD, пропатчить. Дальше -- по желанию. Отгрузить, стереть на диске, etc. Но отгружать и стирать на диске плохо -- юзер явно увидит. Тогда уж эффективнее грохнуть флэш и винт.

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

Рассмотрим вопрос подробно. Как происходит VxDcall? А вот как. Сначала (все нуле) встречается CD 20 xx xx yy yy. Вызывается INT 20h. Обработчик берет yy yy. Это номер VxD. Сканируется список VxDей. Берется из таблички адрес сервиса xx xx, и CD 20 xx xx yy yy меняется на FF 15 [address]. И вот на этот CALL (FF 15) и передается управление.

Рассмотрим теперь VMMcall Hook_Device_Service. Что оно делает? А вот что. Берется список VxDей, сканируется до нужного нам. Все это посредством VMMcall Get_DDB. А дальше берется табличка оффсетов и в ней меняется оффсет хандлера.

Таким образом вместо

можно делать так:

, где DDB_Service_Table_Ptr -- это поинтер на таблицу оффсетов хандлеров сервисов, по одному на каждый сервис соответствующего VxD.

Но ведь и Get_DDB суть тоже отстой, ибо может быть перехвачено.

Поэтому наша задача -- находить структуры DDB самим. Вот ну ОЧЕНЬ глюкавый пример того, как это не нужно делать.

Проблема приведенного примера вот в чем. Мы НЕ проверяем присутствие страниц сканируемой памяти. И это нам чревато боком ;-). Выходов тут целых два, а может и больше. Во-первых, можно хватать экскепшн через IDT, и это правильно. А во-вторых (для особо умных) можно сканировать таблицу страниц.

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

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

ПРИЛОЖЕНИЕ

---

_(c) 1999 Z0MBiE, http://z0mbie.host.sk_

• непосредственная загрузка VxD-драйвера либо изменение какого-нибудь из существущих загружаемых VxD-файлов;

• модификация дескриптора прерывания в IDT;

• создание callgate-а в GDT или в LDT, включая сюда поиск LDT в памяти без доступа к GDT;

• переход посредством вызовов KERNEL-овских функций (всякие там пэйджеры);

• переход сплайсингом в одну из VMM-овских процедур (например C0001000) либо изменение каких-либо уазателей в VMM-овских данных;

• переход модификацией контекста (SetThreadContext, ставим CS=28h, EIP=r0proc);

• переход через INT 2E/PsCreateSystemThread, PoCallDriver, RtlCopyMemory и т.п.;

• используя INT 31, коий можно вызывать через kernel32 (push 002A0029/call ord0);

• переход в нулевое кольцо посредством медитации (спросить хрюкера) ;-)

При этом мы знаем, что можно писать в защищенную память из третьего кольца, например модифицируя таблицу страниц или через INT 2E/RtlCopyMemory.

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

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

Как убить VxD-драйвер?

Для этого надо ответить на 2 вопроса. Во-первых, что это за драйвер, и, во-вторых, где он находится. Btw, скажу сразу, здесь я рассматриваю только 3 драйвера, а именно SPIDER.VXD, AVP95.VXD и AVPG.VXD (AvpGuard).

Как найти загруженный VxD? Можно получить поинтер на первый DDB и дальше идти по цепочке, проверяя имя драйвера. Но это есть хуйня, ибо VxDcall VXDLDR_GetDeviceList может легко отлавливаться так же как и любой другой вызов. Поэтому предлагается сканировать всю память в поисках DDB-блоков. Таким образом мы и найдем интересующие нас VxD-драйвера.

Поиск DDB в памяти:

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

Где нибудь с control_proc_0 сканируем и патчим память на предмет следующих значений: для спидера и авп95 находим все последовательности

и меняем на

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

и меняем на

В результате антивирус вирусные события-то отлавливает, но вот передать их в PE-файл посредством VWIN32_SetWin32Event не может, и поэтому сам пробует вызвать VWIN32_SysErrorBox. А это такая фишка, которая спрашивает да/нет. Вот тут он и имеет EAX=1, что означает Yes.

Теперь подходим к такому вопросу: а что если CD 20 nnnnnnnn уже успело измениться на CALL? Тогда надо вычислить два следующих значения:

и так же как и в случае CD 20 nnnnnnnn, заменить все

на

Только вместо VMMcall Get_DDB желательно найти VMM-овский DDB так, как это было описано в самом начале текста, хотя если работает только один avpg.vxd это не обязательно.

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

Вот кусок из библиотечки KILLAVXD, слегка модифицированный в соответствии с вышесказанным:

•

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

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

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

1. На уровне байт, составляющих тело вируса.

2. На уровне команд(опкодов), составляющих тело вируса.

3. На уровне функциональных вызовов(действий) вируса.

4. На уровне алгоритма вируса.

Уровень 1

Наиболее простой уровень полиморфизма, существует в двух проявлениях:

1. крипт-вирусы -- тело вируса зашифровано, расшифровщик как правило один и постоянный, после расшифровки управление передается на один и тот же (байт-в-байт) код

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

Детектирование таких вирусов может достигаться:

• анализом самого расшифровщика (статистическим либо по плавающей сигнатуре)

• трассировкой расшифровщика до нахождения постоянной сигнатуры

• сравнением сигнатуры "насквозь" (в случае слабой шифровки тела вируса)

• по функциональной сигнатуре

Уровень 2

"Пермутирующие", они же "метаморфные" вирусы.

Идея заключается в том, чтобы изменять команды/группы команд на функционально им эквивалентные(замена), и/или менять команды/группы команд местами(перестановка).

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

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

О реализации.

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

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

2. новый код создается каждый раз из некоего специфически закодированного "прообраза", который хранится в зашифрованном виде.

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

Уровень 3

Назовем их функционально мутирующие вирусы.

Такой уровень на практике пока еще не был реализован.

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

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

функциональна сигнатура: 21 4E 21 3D 21 40

Очевидно, что прерывания/процедуры api, которые вызываются вирусом, представляют неплохую информацию для его детектирования.

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

Уровень 4

Пожалуй самый сложный уровень, единственный за который не следует браться ;-)

Назовем их алгоритмически мутирующие вирусы.

Алгоритм работы программы (вместе с результатом ее работы), есть, наверное, самый высокий уровень информации о программе.

И как бы мы ни извращались на уровнях команд и функциональных вызовов, все равно файл с расширением .EXE и внутренним форматом PE будет найден, открыт, и в него произойдет запись. Либо нечто в этом роде.

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

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

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

Общие рекомендации

В глобальном смысле, я сегодня вижу такую ситуацию:

Вылечить можно отнюдь не все вирусы, достигается это технологиями Seek&Destroy(вставка ошибок в случайные места программы и обработка их вирусом), UEP (Unknown Entry Point) и прочими гадостями.

В частности, есть вот такая интересная техника заражения:

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

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

В случае хорошего вируса, это случайно выбранная точка программы. (UEP)

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

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

А вот детектировать можно любой (или почти любой ;-) вирус, вопрос только КОГДА.

Здесь есть несколько параллельных временных стадий.

1. Фаза распространения (вирус идет от пользователя к пользователю, и через некоторое время попадает в антивирусную контору)

2. Фаза создания антивируса (контора пишет антивирус)

3. Фаза лечения (антивирус идет из конторы к пользователю, и, в последный момент, вирус просекает что больше не судьба и накернивает "...ЭВМ, систему ЭВМ или их сеть...")

Длительность всех трех стадий некоторым образом связана с такими "качествами" вируса, как:

1. маскировка (позднее поймают)

2. сложность (дольше будут писать антивирус)

3. защита (сводит антивирус на нет)

Здесь следует сказать пару слов о деструкции. Так вот деструкция, несомненно, нужна. ;-) Но в меру. Например всякая рандомная деструкция снижает маскировку, зато "умная" деструкция (типа пришел новый антивирус или юзер пишет письмо к аверам) усиляет защиту и усложняет лечение.

Также можно хранить вирус в нескольких файлах, но это может сильно затруднить распространение.

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

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

Можно при ситуации "антивир хочет нас вылечить" совершать убийство (ритуальное) пользователя вместе с компьютером.

В заключение...

...не надо ;-)

_(c) 1999 Z0MBiE, z0mbie.host.sk_

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

• определение длины инструкции;

• определение регистров, используемых в инструкции;

• определение, например арифметической операции, которую выполняет инструкция и т.п.

МЕТОДЫ ДИСАССЕМБЛИРОВАНИЯ

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

Возможно несколько способов побайтового разбора инструкций.

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

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

1.2. Организация массива данных

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

Примечание

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

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

Недостатки

1. Одной килобайтной таблицей указателей/флагов дисассемблирование отнюдь не исчерпывается.

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

3. Не всегда удобно хранить в программе данные. (например в случае пермутирующих вирусов)

2. Дисассемблирование без использования данных

Здесь обсуждается по-сути, преобразование вышеперечисленных таблиц в код.

Но вы ошибаетесь, если думаете, что я предложу сделать так:

2.1. Преобразование таблицы переходов в код с использованием "дерева"

Здесь идея заключается в том, чтобы таблицу переходов преобразовать в код процессора следующим образом:

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

Например для сегментных префиксов 26, 2E, 36, 3E и соответствующей им битовой маски 001xx110 будут выполнены примерно следующие инструкции:

2.2. Сравнение с использованием битовых масок

В этом методе последовательно выполняются проверки битовых масок.

Итак, пусть нам нужно выявить все сегментные префиксы, как то - ES,CS,SS,DS,FS и GS.

Очевидно, что опкоды их кодируются так:

и тогда мы имеем две битовых маски: 001xx110 и 0110010x.

Возникает вопрос, как вместо 6-ти сравнений и переходов сделать что-то более правильное.

Эта проблема решается достаточно просто. Например вот так:

БИТОВЫЕ МАСКИ

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

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

Используется макрос так: в AX загружается значение опкода и следующего за ним байта (на случай двухбайтовых проверок), в BX загружается not AX. Первым параметром макросу подается битовая маска, вторым - имя метки, на которую передавать управление.

Вот собственно и все. Возможности макроса понятны из комментариев к нему.

Этот текст призван стать кратким обзором нескольких алгоритмов сортировки.

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

Итак, каждый алгоритм сортировки состоит из трех основных частей:

• Функция сравнения пары элементов сортируемого массива.

• Процедура перестановки, меняющая местами пару элементов.

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

Пузырьковая сортировка

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

Алгоритм прост и крайне неэффективен.

Сортировка выбором

Во время i-го прохода по массиву выявляется наименьший элемент, который затем меняется местами с i-м.

Все остальное аналогично пузырьковой сортировке.

Сортировка Шелла

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

Интервал между сравниваемыми элементами постепенно уменьшается до единицы. Это означает, что на поздних стадиях сортировка сводится просто к перестановкам соседних элементов.

Сортировка Хоора

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

Для массива из 10 чисел установим два индекса: на первый (i) и на последний (j) элементы.

На каждом шаге будем изменять значение индекса j на значение step (вначале оно равно -1, индекс уменьшается), т.е. двигать j влево. Мы будем делать так в том случае, если j-й элемент больше, чем i-й элемент. Если это условие не выполнено - поменяем местами i-й и j-й элементы массива и сами индексы i и j, а также изменим знак у значения step -- оно станет равным +1:

Продолжим процесс: теперь j движется вправо, и изменится условие - сейчас для продолжения процесса необходимо, чтобы j-й элемент был меньше i-го.

Будем продолжать вышеописанный процесс до тех пор, пока индексы i и j не станут одинаковыми.

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

Таким образом, мы описали процедуру нахождения расположения одного элемента. Иными словами, мы "отсортировали" один элемент множества. Такая же процедура применима к элементам "левого" и "правого" подмножеств, которые на данный момент еще не отсортированы.

Условие завершения нашей рекурсивной процедуры - совпадение границ, которое эквивалентно тому, что в множестве остался один элемент.

QuickSort

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

Основное отличие - за делящий элемент всегда выбирается середина массива.

Сортировка с помощью двоичного дерева

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

Если мы составим такое дерево из букв слова "СОРТИР", сравнивая ASCII коды букв, то получим следующую структуру:

Как видно, узел "С" имеет два преемника: левый "О" и правый "Т". Если составить бинарное дерево из элементов неупорядоченного массива, то в общем случае дерево получится достаточно хорошо заполненным (а если массив уже был рассортирован, то дерево выродится в линейный список).

Если мы будем обходить дерево по правилу "ЛЕВЫЙ преемник - КОРЕНЬ - ПРАВЫЙ преемник", то, записывая все встречающиеся элементы в массив, мы получим упорядоченное в порядке возрастания множество. На этом и основана идея сортировки деревом.

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

Недостаток метода - требуется много памяти. В приведеном примере - дополнительный мегабайт данных на каждые 256k элементов.

Сортировка с помощью массива индексов

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

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

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

Доступ к массиву данных ведется не как a[i], а как a[index[i]], и функция сравнения теперь выглядит иначе:

В результате фактически сортируется массив с индексами, а не с данными.

А теперь сравните по скорости тысячу операций swap(x,y), где в первом случае x и y - это большие структуры данных, а во втором - числа по 2-4 байта.

Какую сортировку выбрать

Ниже приведена зависимость скорости сортировки от числа элементов массива. Эксперимент проводился на весьма торозном компьютере, так что верна лишь пропорциональность скоростей. Массив заполнялся случайными числами от 0 до N, где N - число элементов массива.

sort.gif

Как видно, QuickSort показывает лучший результат по времени, да и по реализации процедура сортировки весьма проста.

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

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

И еще: в случае, если функция сравнения less(XPEH a,XPEH b) занимает много времени, можно заранее просчитать "веса" элементов и функцию сравнения определить уже для них.

(c) 1999 Z0MBiE

<http://z0mbie.host.sk>

• Немного арифметики

• Условное выполнение без передачи управления

• BCD-операции

• Команды MUL и DIV

• Сравнение ASCIIZ-строк с использованием хэш-функций

• Вывод десятичных чисел на экран (itoa)

Немного арифметики CDQ

CDQ (convert double-word to quad-word) -- преобразование двойного слова (в EAX) в учетверенное слово (в EDX:EAX).

Более понятный эквивалент:

NOT

Инверсия всех битов операнда.

NEG

Изменение знака операнда.

TEST

То же что и AND, но без изменения содержимого операндов. Изменяются только флаги.

CMP

Понятно, все слышали про CMP. ;-) Вот альтернативная точка зрения.

То же, что и SUB, но без изменения содержимого операндов. Изменяются только флаги.

SBB

SBB (subtract with borrow) -- вычитание с заемом. Кроме второго операнда, из первого вычитается еще и CF (Carry Flag, флаг переноса).

Наиболее интересна форма команды с одинаковыми операндами. В этом случае в каждый бит регистра загружается значение CF, то есть регистр=0 если CF=0 и регистр=0xFFFFFFFF если CF=1.

Условное выполнение без передачи управления

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

Пример 1 Пример 2: нахождение абсолютного значения

Если eax >= 0:

Если eax < 0:

Пример 3: нахождение минимального значения

Если ebx >= eax:

Если ebx < eax:

Пример 4

Если eax = 0:

Если eax != 0:

BCD-операции

Замечено, что многие программисты боятся таких команд, как AAA, AAS, ASS ;-) и некоторых других. Причина этого (по Фрэйду) кроется глубоко в детстве и связана с сексуальными переживаниями, не поддающимися психоанализу. ;-))

Пара слов о BCD

BCD -- (binary coded decimal) -- двоично-десятичные числа. Выдумавшие их разработчики были лентяи и мазерфакеры, поэтому BCD-числа числа бывают двух видов -- упакованые и неупакованные.

• Packed BCD -- это байты, каждая тетрада (4 бита) которых изменяется от 0 до 9, то есть 00h,01h,...,09h,10h,11h,...,99h.

• Unpacked BCD -- это просто байты, изменяющиеся от 0 до 9, а старшая их тетрада равна 0.

Понятно, что нормальные арифметические (ADD/SUB/MUL/DIV) операции с такими числами невозможны, поэтому вместо того чтобы их выкинуть на помойку люди занимаются с ними мазохизмом в виде команд AAA, AAS, AAM, AAD, DAA и DAS.

Команды DAA и DAS предназначены для работы с Packed BCD. Команды AAA, AAS, AAM и AAD предназначены для Unpacked BCD. Команда AAD -- это коррекция ПЕРЕД делением, все остальные -- коррекции ПОСЛЕ соответствующих операций.

Действие BCD-команд AAA

Ascii Adjust after Addition -- ASCII-коррекция после сложения.

AAS

Ascii Adjust after Substraction -- ASCII-коррекция после вычитания.

AAM / AAD

Операнд по умолчанию = 10.

DAA / DAS

Decimal Adjust after Addition и Decimal Adjust after Substraction.

О применимости BCD-чисел

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

Например самый типичный вирмэйкерский объект -- таймер компьютера, то бишь время и дата, хранящиеся в CMOS, находятся в Packed BCD формате.

Флаг AF (Auxilary Flag) -- флаг вспомогательного переноса -- существует как раз для BCD арифметики. Работает так же, как и CF, но для бита 3 а не 7.

И даже в наборе команд сопроцессора присутствуют команды для работы с BCD: FBLD -- загрузить и FBSTP -- сохранить число в BCD формате.

Перевод чисел в BCD и обратно

BCD --> Binary:

Binary --> BCD:

Пример использования BCD-арифметики

Когда-то один знакомый (написавший как-то весьма крутой вирус) задал мне интересную задачку -- написать подпрограмму выдачи шестнадцатиричного числа на экран (DOS, число в AX) -- наименьшей возможной длины.

Вот несколько вариантов решения:

20 байт:

21 байт:

21 байт:

21 байт:

Команды MUL и DIV Умножение на константу

При умножении чисел на постоянный множитель (для увеличения скорости) вместо MUL можно использовать серии из SHL и ADD(OR).

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

Использование MUL вместо DIV

Рассмотрим интересный случай. Генератор случайных чисел, алгоритм - почти как у ТурбоПаскаля 7.0, период 2^32.

Обратим внимание на строчку с (*), то бишь на MUL. Неочевидно, но факт - здесь его действие почти такое же как и у DIV. Более того - в этой ситуации MUL работает примерно в 1.5 раза быстрее, а в случае нулевого параметра -- rnd(0) -- в результате возвращается 0, тогда как при DIV произошла бы ошибка деления.

Несложно догадаться, что возникает такая ситуация только в конкретном случае, когда операнд для DIV(MUL) -- случайное 16- или 32-битное число.

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

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

При известном наборе строчек и/или ограничениях на них, ошибки исключены. Преимущество такого сравнения в случаях:

• в случае большого количества строк и заранее подсчитанных контрольных сумм -- увеличивается скорость работы программы

• в случае вирусов -- уменьшается размер кода/данных и затрудняется изучение (дисассемблирование)

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

Вывод десятичных чисел на экран (itoa)

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

(c) 1999 Z0MBiE

<http://z0mbie.host.sk>

Все вы слышали про ОБРАТНОЕ ПРОЕКТИРОВАНИЕ (reverse engineering), то бишь про дисасемблирование программы, изменение логики и последующую компиляцию. И все слышали про некое жалкое подобие реверсирования, выполняющееся автоматически, а именно -- про ПЕРМУТАЦИЮ, то есть перестройку вирусного кода на уровне ассемблерных инструкций, с целью затруднить его анализ и детектирование. Очевидно, что явным эффектом от пермутации будет постоянное изменение некоторой контрольной суммы вируса, и, как следствие -- усложнение алгоритма и увеличение времени детектирования.

При заражении PE файлов иногда возникает необходимость выровнять какие-нибудь из вышеприведенных элементов структуры ObjectEntry в соответствии с полями PE Header'а FileAlign и/или ObjectAlign.

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

И так далее... Ну, кто узнал свое? ;-)

Теперь рассмотрим ситуацию, когда в делитель пришел 0. Ответ ясен: ваш вирус СГЛЮЧИТ, и маздай выдаст поинтер на с таким трудом написанный код. А может быть, это антивирусная эвристика спецом подсунула такой хуевый файл и только и ждет DIV 0, а?

ДА, можно вставить проверку на 0. Но не красивее ли ВООБЩЕ не использовать DIV, прочитав наконец доку, и поняв, что делитель, он же File/ObjectAlignment суть степень ДВОЙКИ?

А DIVы, процедуры с PUSHем EDXа и условными JMPами пусть сосут.

---

Но мало кто знает, что кроме [rename] есть еще более убойная вещь, называемая [CombineVxDs]. Найдено оно было случайно при инсталляции win95, и, хотя тестировать такое мне попросту лениво, но это стопроцентно как-то работает. Итак, вот что я нашел:

И действительно, взглянув в WININIT.EXE, я увидел не только rename и CombineVxDs, но и какое-то SetupOptions.

Короче говоря, флаг вам в руки...

ПРИМЕЧАНИЯ

1. Обычный VMM32.VXD представляет из себя следующее:

2. Распакованный VMM32.VXD представляет из себя вот что:

3. Работа с VMM32.VXD осуществляется утилитой DEVLIB.EXE из DDK\BIN.

4. Пример добавления секции [rename] в WININIT.INI:

---

(x) 2000 Z0MBiE, z0mbie.host.sk

Как найти TCB? Четвертым двордом TCB имеет удобную сигнатуру: 'THCB'. Но искать всякий отстой в памяти уже, честно говоря, надоело, поэтому под win98 можно сделать так:

Далее скажем, что пропатчить CS:EIP у текущей нити из нее же -- дело непростое, так что создадим для этого новую нить.

Далее, приостановим текущую нить, чтобы выполнилась нить созданная:

И вот, мы уже побывали в нуле. Что же происходило в новой нити?

Как видим, простая замена CS:EIP на свои собственные. А вот так выглядит процедура, на которую попадает управление в нуле:

Ну, собственно, это все. А вы чего ждали?

• Вступление

• Термины (пермутация, метаморфизм)

• Плюсы и минусы пермутации

• Ограничения на исходный код

• Хранение данных внутри кода

• Внешние вызовы

• Дизассемблирование инструкций

• Список инструкций

• Формат записи списка

• Этапы пермутации

• Дизассемблирование

• Подготовка списка к мутации

• Ассемблирование списка

• Линковка

• Дополнение алгоритма (plugin-ы) и внешняя мутация

• Изменение списка (мутация)

• Замена

• Перестановка

• Мусор

• О результатах

Вступление

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

Нас, вирмэйкеров, объединяет процесс. Цель у каждого своя. Кто-то получает удовольствие, кто-то знания, кто-то -- и то и другое. Удовольствия я оставлю себе, а знания предлагаю вам.

Термины Пермутация

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

Метаморфизм (генерация кода)

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

Плюсы и минусы пермутации

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

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

Ограничения на исходный код

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

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

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

Хранение данных внутри кода

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

В таком случае возможны два варианта:

• данные содержатся отдельно от кода и шифруются переменным ключом

• данные генерируются кодом

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

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

Сгенеренный этими макросами код может выглядеть, например, так:

Внешние вызовы

На вход пермутирующему движку подается исходный буфер с кодом. Метки, на которые из этого буфера идет передача управления командами типа JMP/CALL/JCC (с относительным к EIP аргументом), могут быть как внутри так и вне буфера. Последние мы будем называть внешними метками. От пермутирующего движка будет требоваться сохранить работоспособными все внешние вызовы.

Дизассемблирование инструкций

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

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

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

Список инструкций

Для работы с инструкциями существует несколько препятствий. Например то, что инструкции переменной длины -- это заставляет встраивать в пермутирующий движок дизассемблер длин. (в вирусах Ply этот вопрос решен тем, что все команды дополнены до одинаковой длины NOP-ами). Также нам мешает то, что инструкции могут быть связаны командами типа JMP и CALL -- это не позволяет просто так убрать какую-нибудь инструкцию из программы или вставить в программу лишнюю инструкцию. Значит требуется преобразование ассемблерного кода в некоторую промежуточную сущность, кояя позволит легко оперировать инструкциями. Таким объектом является список инструкций. Можно обойтись и без списка инструкций. Так я поступил в ZCME. Движок работал за один проход, в котором одновременно происходило дизассемблирование старого кода и ассемблирование нового. В результате в один момент времени я мог рассматривать только одну ассемблерную команду, но не несколько. Список же позволяет не только единовременно оперировать несколькими инструкциями, но и производить над ними такие действия, которые без него весьма трудоемки.

Формат записи списка

Рассмотрим одну запись списка, соответствующую одной ассемблерной команде.

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

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

Теперь информация о команде.

1. собственно опкод (или поинтер на него)

2. длина опкода

3. указатель на запись следующей команды (но не обязательно на следующую запись в списке). =NULL, если текущая команда типа RET или JMP.

4. указатель на запись условно-следующей команды, то есть той команды, на которую указывают call-ы, jcc и т.п., либо jmp-ы, либо же указатель на метку, внешнюю по отношению к исходному блоку кода. =NULL, если текущая команда не является одной из jmp/call/...

5. флаги.

Во флагах указывается такая информация, как:

• является ли команда меткой (XREF),

• является ли указатель на условно-следующую команду указателем на внешний адрес или на запись списка

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

Этапы пермутации

Итак, с учетом списка инструкций имеем три основных этапа:

1. a) дизассемблирование кода (создание списка инструкций); b) обработка списка (*)

2. изменение списка инструкций (собственно мутация)

3. a) ассемблирование нового кода; b) линковка (**)

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

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

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

Дизассемблирование

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

Ниже приведен кусок из движка RPME, дизассемблирующая часть:

Подготовка списка к мутации

Собственно этот пункт не обязателен, он нужен для упрощения задачи. Здесь мы проводим две операции:

• замену всех коротких условных переходов (jcc short), а также команд типа LOOP/Z/NZ и JECXZ их near-эквивалентами. Это нужно для того, чтобы во-первых впоследствии определять условные jmp-ы только по одному опкоду, а также чтобы при линковке работать только с 4х-байтными относительными смещениями

• удаляем из списка все JMPы (заменяя у предыдущих JMPам команд указатели на следующую команду)

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

Ассемблирование списка

На этом шаге у нас есть список уже измененных инструкций из которого нужно сделать ассемблерный код. Ассемблирование списка происходит по следующему алгоритму:

Вот как это выглядит на C++:

Линковка

Линковка здесь требуется не для абсолютных смещений, которые мы вовсе не рассматриваем, а для относительных к EIP 4х-байтных смещений, коии присутствуют после опкодов jmp,call,jcc. Относительный адрес перехода можно пофиксить зная, на которую запись списка указывает относительное смещение и зная оффсеты текущей команды и команды-метки (эти оффсеты становтся известны при ассемблировании).

Дополнение алгоритма (plugin-ы) и внешняя мутация

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

Изменение списка (мутация)

Очевидны три основных действия, применяемых к инструкциям: замена, перестановка и мусор (т.е. добавление мусора). Действие может быть ОБРАТИМЫМ и НЕОБРАТИМЫМ, в зависимости от того, возможно ли после него вернуться к исходному состоянию или нет. Необратимые действия как правило приводят к увеличению кода. Замена и перестановка являются операциями обратимыми. Добавление мусора может быть операцией как обратимой, так и необратимой, в зависимости от того, насколько наши возможности совпадают со сложностью алгоритма удаления мусора из кода. Комбинация замены и мусора увеличивает вероятность необратимых изменений в коде.

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

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

2. В случае только обратимых изменений, объем кода будет изменяться только в некоторых пределах.

Замена

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

Рассмотрим например такую команду, как условный переход (Jcc). Находим Jcc, меняем на JNcc (инвертируем условие, попросту - XORим опкод на 1). Меняем местами указатели на следующую и условно-следующую записи списка. Готово. Теперь при ассемблировании две ветви алгоритма (после Jcc) поменяются местами.

Пример:

Еще пара вариантов замены: XOR r, r <--> SUB r, r, TEST r, r <--> OR r,r и т.п.

Перестановка

Учитывая одно из наложенных на код ограничений -- условные jmp-ы идут только сразу за командами, устанавливающими соответствующие флаги, рассмотрим 2 команды, следующая за которыми - не jcc.

Обязательным условием будет также отсутствие флага XREF на каждой из команд, то есть они не должны быть метками. Кроме того, из двух команд только одна может использовать стэк. А если какая-либо из команд использует ESP, то обе не должны использовать стэк.

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

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

Мусор

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

О результатах

О результатах расскажем и даже покажем кодом.

Итак, в середине пермутации движок вызывает процедуру обработки списка инструкций. (callback)

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

Для того, чтобы во всем вирусе изменить все, например, NOPы на XCHG EBX,EBX в обработку инструкции достаточно добавить такой код:

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

или так:

В первом случае могут остаться ссылки на эту запись (то есть она реально не удалится) (проверить сие можно так: test [ebx].h_flags, CM_XREF)

Для того, чтобы инвертировать все jcc на jncc с сохранением работоспособности кода, делаем так:

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

---

Напротив, их главными побочными эффектами всегда являются обман, ограничение и подчинение.

Хакера эмулировать еще проще. Домашней странички не нужно, достаточно поставить где-нибудь nmap, пару скриптов на перле, и юникодом дефейсить найденные ишаки с подстановкой соответствующего рандомного никнейма.

Через пол года эта "вирусная группа" сменяет половину своих членов на других членов, понемногу все они (с трудом) запоминают свое название и ники, а так же название журнала, и можно сказать что дело сделано. Можно даже начинать собирать материал.

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

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

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

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

Понятно, что именно так получается не всегда - иногда чуть получше, а иногда даже и хуже, но сути дела это не меняет.

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

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

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

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

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

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

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

Кто-то спросит: а как же быть, если я хочу, а не получается? Решений тьма: жениться, стать нарком, покончить с собой.

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

Теперь о качестве статей и вирусов. Есть новый и интересный материал, который раньше нигде не публиковался, который вы придумали сами. А есть вирусы/статьи типа "я тут новичок вася вот написал вирус правда такой уже есть опубликуйте, а?", а также стандартный материал, но написанный каждым по-своему: типа com, exe, tsr, win32, polymorphic, boot, их комбинации, и прочее говно, которое уже сто раз везде было и всех заебало.

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

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

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

Если вы пользуетесь pgp, а ваш друг - нет, то во-первых, вы не пользуетесь pgp, а во-вторых, он вам не друг.

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

Вопрос "для чего все это делается" не обсуждается. Те, кому это интересно, просто делают, а все прочие молча идут нахуй.

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

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

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

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

Когда вы садитесь за компьютер в первый раз в жизни - вы рождаетесь в киберпространстве.

Когда вы отходите от компьютера попить кофе - вы засыпаете в киберпространстве.

Когда вы возвращаетесь за компьютер, сегодня или через неделю - вы просыпаетесь.

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

Вы никогда не замечали, что работа за компьютером надоедает? Не в смысле "устали глаза" или "болит голова", а именно "надоело", просто не хочется ничего делать.

Это значит, что ресурсы вашей внутренней энергии заканчиваются.

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

Компьютерный вирус - это неизменный атрибут киберпространства.

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

Но отнюдь не этой целью руководствуются авторы компьютерных вирусов.

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

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

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

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

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

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

Ну и соответственно вирусописатели - это люди, наиболее противоположных с вами взглядов, люди, до которых вам далеко, по велению киберпространства "подбрасывающие" в разговор неприятные вам темы.

Ну а раз взгляды противоположные, несомненно формируется некоторая антипатия, неприязнь к вирусописателям.

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

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

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

Никакой интеллектуальности. Найти и убить свой бывший вирус.

Получить деньги за работу.

Другой тип антивирусников - бывшие фидошники.

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

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

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

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

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

Но киберпространство не принимает их, забирая внутреннюю энергию с огромными темпами.

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

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

ЧТО ЖЕ ТАКОЕ КОМПЬЮТЕРНЫЙ ВИРУС

Опять же, несмотря на потуги (понятно кого) определить вирус как опасную програму, это не так.

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

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

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

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

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

Некоторые "программисты" в душе боятся вирусов. Такие заверяют что запросто могут их писать. Как правило это "программисты" на бэйсике/паскале и т.п.

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

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

Вот что сказал один вирусописатель о компьютерных вирусах

вирус - это символ моей жизни.

компьютеры помогают жить этому миру.

вирус - помогает жить мне.

человеческая жизнь - это шаг нашего мира на пути к неизвестному.

написанный вирус - это шаг на пути к покорению океана знаний.

виртуальный мир - это мир знаний.

познавая, я совершенствую свой внутренний мир.

в виртуальном мире намного меньше грязи чем в мире реальном.

ибо зло, царящее в реальном мире еще не пришло сюда.

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

и мне это нравится.

я никогда не изменю своих взглядов, а если изменю - это буду уже не я, не тот, кто пишет эти строки.

когда я пишу программу - я счастлив, это и есть моя жизнь.

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

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

я здесь навсегда.

ПОЧЕМУ СТОИТ ПИСАТЬ КОМПЬЮТЕРНЫЕ ВИРУСЫ

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

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

Если вас интересуют деньги - вы их получите. Многие вирусописатели неплохо зарабатывают своими способностями.

Если вас интересует слава - она будет ваша. Автор вируса, разошедшегося по всему миру, может гордиться своим именем.

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

А если вы уже программист, причем не на бэйсике - вам просто небходимо попробовать написать вирус. Что вы потеряете? Лишь немного времени.

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

Ура компьютерным вирусам!!!

Для тех, кто не видит разницы, это звучит так:

---

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

Мотивируют они это тем, что попадет этот исходник/журнал куда не следует, в частности, к антивирусникам, коим от этого, якобы, станет легче жить.

Темная сцена, почти ничего не видно. Посредине - неподвижное пятно света от прожектора. На сцену махая руками выбегает Касперский - бородатый толстый мужик лет под 50, в рваном халате и тапочках, с деревянным посохом, лысый, но с длинной рыжей бородой, в зубах погасшая беломорина - бегает кругами, высоко задирая колени, выкрикивает что-то невнятное, изредка попадает на свет - в такие моменты он вертит головой в разные стороны, посматривает вверх, и опять начинает бегать.

Но вы то понимаете, что не в вирусах и не в спаме дело.

Как вам наверное известно, каспер, сначала обещавший сменить формат баз, из-за лености своей просто навесил на них контрольную сумму.

Пытаясь в очередной раз сделать вам всем подарок - еще одно троянское дополнение, я выяснил следующее:

1. от файла считается 20-байтовый хэш

2. от хэша считается некоторая функция, которая затем оверлеем записывается в задницу файлу. Типа 13,10,'; 0XLSznpdI71fB300e7Uwj1DPr8uAEV6YKjE8+IKy4VCYDt3lzRTLi27dWP',0ADh,0ADh

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

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

Хэш (NIST Secure Hash Algorithm, SHA) каспером попросту украден.

В одном из оригинальных исходников хэша (pgpsha.h) записано так:

Оригинальные исходники лежат здесь: shaorig.zip, а дисассемблированные куски кода из авп здесь: shadiza.zip.

Сравнивайте, изучайте, рассказываете об этом всем, кого знаете.

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

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

Трепещите, ламеры, ибо скоро настанет вам пиздец!

Перепечатка этого материала возможна только полностью и с указанием источника:

(c) 06 June 1999, Z0MBiE, http://z0mbie.host.sk

На протяжении всех 80-ти килобайт книжки меня преследовало "третье лицо", от имени которого обещался говорить автор. Правда, обошлось без эксцессов.

Казалось бы, ну и что с того? Ан, не тут-то было. Из времен и дат создания лечащих вирусы obj'ей, можно извлечь весьмааа интересную информацию, например о том, как работает любимая нами контора.

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

• Распаковать все имеющиеся в наличии (на январь 2001-го года) .avc-файлы.

• Разбить все имеющиеся в .avc'шках 32-битные obj'и по некоторым критериям (см. ниже).

• Написать програмку, дампящую дату/время создания этих obj'ей.

• Написать програмку, считающую статистику по полученным дампам и генерящую графики.

Теперь о критериях.

1. Все имеющиеся obj'и (2590 штук). На графиках обозначены красным цветом.

2. obj'и от сентября 2000-го года и старше. На графиках обозначены желтым цветом.

3. obj'и, исходником которых является файл с расширением .asm (имена исходников прописываются во всех без исключения obj'ах). Замечу, что, согласно имеющейся информации, большинство таких файлов написано бездарным богдановым. На графиках обозначены зеленым цветом.

4. obj'и для win32- и win9X-вирусов. На графиках обозначены синим цветом.

Зависимость количества выпущенных OBJ'ей от времени суток

Как видно, основная часть конторы начинает работать в 10 утра, а расходится в 8-9 вечера. Два пика наблюдаются где-то к 2-м часам дня и в 6 часов вечера. Можно предположить, что после двух у них обед. Конечно, эта инфа не такая уж и секретная... Просто радует сам факт ее обнаружения посредством анализа общедоступных баз.

Зависимость количества выпущенных OBJ'ей от дня недели

Интуиция мне подсказывает, что, судя по графику, контора находится на второй стадии болезни Паркинсона. Иначе чем объяснишь такое рвение в понедельник, к пятнице сходящее на нет?

Не могу удержаться, процитирую:

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

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

Вторая стадия болезни наступает тогда, когда носитель заразы хотя бы в какой-то степени прорывается к власти. Нередко все начинается прямо с этой стадии, так как носитель сразу занимает руководящий пост. Опознать его легко по упорству, с которым он выживает тех, кто способнее его, и не дает продвинуться тем, кто может оказаться способней в будущем. Не решаясь сказать: "Этот Шрифт чересчур умен", он говорит: "Умен-то он умен, да вот благоразумен ли? Мне больше нравится Шифр". Не решаясь опять-таки сказать: "Этот Шрифт меня забивает", он говорит: "По-моему, у Шифра больше здравого смысла". Здравый смысл - понятие любопытное, в данном случае противоположное уму, и означает оно преданность рутине. Шифр идет вверх, Шрифт - еще куда-нибудь, и штаты постепенно заполняются людьми, которые глупее начальника, директора или председателя. Если он второго сорта, они будут третьего и позаботятся о том, чтобы их подчиненные были четвертого. Вскоре все станут соревноваться в глупости и притворяться еще глупее, чем они есть.

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

"Законы Паркинсона" (c) Сирил Паркинсон

Зависимость количества выпущенных OBJ'ей от года

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

Теперь вот о чем вспомним. Как-то каспер вякал, будто они свои новые базы тестируют чуть ли не по месяцу. Так вот, это - наглая ложь. Вот файлик, ircwormd.c, был скомпилен, когда? - 'Fri Jan 05 00:25:10 2001', то бишь ночью. А апдейт, в коий он был включен, вышел в этот же день.

Подведем итоги. К чему все это было надо? Во-первых, плюнули в рожу касперу. Во-вторых, показали, как можно круто облажаться используя отстойный майкрософтовский софт (я думаю, что 32-битные obj'и они masm'ом компиляют). В третьих, выяснили, что контора, в общем-то, работает весьма регулярно и с высокой вероятностью в конторе постоянно находится хоть кто-то способный писать нечто на C и компилять obj'и. Причем, иногда народ там засиживается допоздна. В четвертых, выяснили время, когда контора на 99% неактивна -- с часа ночи до 8-ми утра. В пятых, мы знаем, что в субботу/воскресенье контора генерит obj'и лишь на треть своей мощности. Далее, мы теперь знаем, что на 400-500 трепаков под винду, obj'и приходится писать примерно на каждые 100, то есть на четверть.

И в заключение (критика должна быть конструктивной!) процитирую еще немного из Паркинсона:

<<...на третьей стадии сделать нельзя ничего. Учреждение практически скончалось. Оно может обновиться, лишь переехав на новое место, сменив название и всех сотрудников. Конечно, людям экономным захочется перевезти часть старых сотрудников, хотя бы для передачи опыта. Но именно этого делать нельзя. Это верная гибель - ведь заражено все. Нельзя брать с собой ни людей, ни вещей, ни порядков. Необходим строгий карантин и полная дезинфекция. Зараженных сотрудников надо снабдить хорошими рекомендациями и направить в наиболее ненавистные вам учреждения, вещи и дела немедленно уничтожить, а здание застраховать и поджечь. Лишь когда все выгорит дотла, можете считать, что зараза убита...>>

Просматривая эту "новинку", кто-то заметил:

\- Ндаа, этим ребятам явно не судьба.

\- Что не судьба? - спросил я.

\- Всё.

Но для начала о том, почему я все таки решил написать этот обзор. Все очень просто -- авторы (или автор?) вышеупомянутого журнала имели наглость в непотребных целях использовать архивы с моими исходниками. А именно, как они выразились, "перегоняли"

<< все заархивированные исходники из ZIP-а в RAR со словарем 256 kb. >>

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

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

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

Затем сделаем то, что забыли сделать авторы - а именно, содержание журнала. Для достижения этой цели воспользуемся командой DIR. К полученным строчкам припишем (справа) названия статей, и, убрав все лишнее, отсортируем все это в порядке возрастания даты файлов.

Итак, журнал писался 3-4 месяца, ну пусть будет 100 дней. Суммарный объем журнала составляет 48,277 байт, таким образом получаем 482 байта в день, делим на двоих, и получаем 241 байт на рыло. При средней длине строки текстового файла 70 символов получается три с половиной текстовых строчки в день.

Но это еще что! Один хакер умудрялся писать всего по одной строчке в день, да и то не каждый, а только по выходным. Но что самое интересное, прогресс не стоял на месте, а двигался вместе с ним, и он был тверд в своем намерении, и в конце концов результат был достигнут. Так что три с половиной строчки кристально чистой вирмэйкерской мысли, этого исключительного, абсолютного зла, генерируемого каждый день объединенными силами двух могучих вирмэйкерских разумов - это вам, отцы, не в тапки срать, и результат перед нами - 48,277 байт взрывоопасной смеси из исходников мощнейшего вирусного движка, народного творчества, и прочего всякого подобного.

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

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

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

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

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

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

Замечу, что сделать ascii-ключ из бинарного можно:

1. добавив ключ в pgp keyrings, посредством pgp.exe keyfile.pgp, и

2. эстрактировав оттуда ключ в ascii-форме, посредством pgp.exe -kxa.

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

Больше всего меня обрадовало то, как авторы рассказывают друг про друга. Статья занимает 5730 байт и называется "Состав", и начинается она так:

Пока что нас только двое. Тут есть кое-какая инфа, возможно полезная для людей, увлекающихся психологией.

Затем идут четыре описания: описание первого автора вторым, первого первым, второго вторым и второго первым. Отбросив качественную сторону вопроса, перейдем непосредственно к количественным характеристикам. Средняя длина одного описания составляет 5730/4 = 1432 байта. Обратим внимание на фразу "Пока что нас только двое. ". Из этого следует, что размер статьи с названием "Состав" в последующих релизах журнала, если они будут, будет считаться по формуле:

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

Если же их в группе окажется 16 (реальное число) членов, то (страшно подумать) все их описания друг друга займут

что составит 366592 / 48277 = 7.59 -- аж семь их первых журналов!

Но не будем о грустном, и оставив такую литературную часть в стороне, перейдем непосредственно к исходникам.

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

"модуль для поиска jmp/call'ов",

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

ЗАКЛЮЧИТЕЛЬНАЯ ЧАСТЬ

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

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

После прочтения журнала Spawn#1 я почувствовал себя именно так, и, простите, выблевал вот этот текст.

Уже хороший вопрос. Грамотный... Тут все перепалки между черными и белыми шляпами как детектив читать можно, а вот хэккеры - они все уже объединились и скоро всех похакают.

Hу в общем прихожу. Открывает мне - сам Основатель Школы Хэкеров - Арви Хакер. [А надо сказать, что когда мне за неделю до того Арви сказал про UGF, я подумал что там ГУРУ собираются. Очевидно, isnt it? Вот потому я и приехал. Утром! Специально к 9.00 приехал.]

Срыг проходил в "киевском" (какой то там молодежный центр), в небольшом зале, присутствующих было человек 50-60. Ходили журналюги с камерами, задавали вопросы про хэккеров. Был там и майор мвд чепчугов, о нем мы еще будем рассказывать дальше. Ну и, конечно же, нельзя было не заметить легендарного старпера из гУру Форсез (UGF), позже, в перерыве, он собирал с желающих деньги.

Эта книга написана по той причине, что за небольшим исключением все трактаты и книги, все "тайные" мемуары, все великие труды и факи по вопросу хэккинга являются не более чем ханженским мошенничеством, греховодным бормотанием и эзотерической тарабарщиной хроникеров магических знаний, не способных или не желающих предоставить объективную точку зрения на этот вопрос. Хэккер за хэккером, пытаясь означить принципы "черного и белого хэккерства", преуспели лишь в таком затуманивании объекта рассмотрения, что человек, самостоятельно изучающий хэккинг, проводит свой занятия за глупым стоянием в пентаграмме в ожидании появления хексов в голове, тасованием байт для предсказания будущего, теряющего в байтах всякий смысл, или даже присутствием на Гуру Форсез, гарантирующих лишь расплющивание его эго (а заодно и бумажника); и, в итоге, выставляет себя круглым идиотом в глазах тех, кто познал истину!

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

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

Пламя Ада горит ярче благодаря топливу, доставленному этими томами седой дезинформации и лжепророчества.

Здесь же вы найдете правду и фантазию. Каждая необходима для существования другой, но должна приниматься за то чем она является на самом деле. То, что вы увидите, не всегда может прийтись вам по нраву, но -- вы увидите!

Здесь -- хэккерская мысль с истинно хэккерской точки зрения.

Хэккерский ритуал Что необходимо принять во внимание перед выполнением ритуала

1. Лицо, выполняющее ритуал, сидит (или лежит) лицом к алтарю (компьютеру) в течении всего ритуала, исключая специально оговоренные конкретные случаи.

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

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

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

5. Разговоры (кроме тех, что ведутся к контексте церемонии) и курение запрещены после удара колокола в начале и до его удара в конце.

6. Книга Интлист содержит принципы сатанинского хэккерства и его ритуалов. ПЕРЕД ТЕМ как начать совершать ритуалы из Книги Питрека строго необходимо прочесть И ПОНЯТЬ ПОЛНОСТЬЮ Книгу Интлист. До этого же, никакого намека на успех не должно ожидаться от нижеприведенных тринадцати шагов.

Тринадцать шагов

_См. "Предметы, используемые в хэккерском ритуале" для более детальных инструкций._

1. Оденьтесь для ритуала.

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

3. Если в качестве хэккера используется женщина, она занимает свое положение.

4. Очищение воздуха происходит при звуке колокола.

5. "Заклинание к Хэккеру" и следующие за ним "Адские Имена" (см. Книгу Питрека) прочитываются священником вслух. Участники повторяют каждое Адское Имя за священником.

6. Испейте из кубка (стакана).

7. Поворачиваясь против часовой стрелки, священник указывает курсором на главные стороны света и вызывает соответствующих Принцев Ада: Хэккера -- с Юга, Крякера -- с Востока, Вирмэйкера -- с Севера и Ламера -- с Запада.

8. Благословите фаллос (если он используется в ритуале).

9. Священник читает вслух соответствующее заклинание для исполняемой церемонии: Дисассемблирования, Форматирования или Уничтожения (см. Книгу Питрека).

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

(А) Для склонения кого-либо на выдачу пароля или создания взломо-благоприятной ситуации

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

Вот, что может быть задействовано (как по отдельности, так и в любой комбинации):

а) визуальные образы, такие, как рисунки, картины и т.д.;

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

в) представление желаний в виде живых картин или сценок, как с собой в качестве главного персонажа, так и в роли объекта вашей страсти (прием перенесения), используя все, что может усилить эти образы;

г) любые запахи, соответствующие объекту вашей страсти или желаемой ситуации;

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

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

(Б) Обеспечение помощи и успеха человеку, к которому вы испытываете симпатию или сочувствие

_(включая самого себя, кретина)_

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

(В) Вызывание уничтожения врага

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

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

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

в) созданием ярких литературных описаний конца вашей жертвы; (конец - не менее 20 см)

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

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

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

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

11.б) Если просьбы излагаются устно, участники (по одному) излагают их священнику. Он затем повторяет их просьбы своими словами (которые эмоционально стимулируют его в большей степени). "Хэккеранасрыг!" и "Да здравствует Хэккер!" произносятся после каждой просьбы.

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

12. Подходящий PGP-Ключ затем зачитывается священником (в двоичной форме) как доказательство верности участников Силам Тьмы.

13. Удар колокола возвещает об осквернении (т.е. об окончании периода очищения, возвещанного ударом колокола в начале - прим. перев.) и слова "ИТАК, СВЕРШЕНО" произносятся священником.

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

Участники мужского пола облачены в черные трусы. Трусы могут быть как с капюшонами, так и с колпаками; дабы, если появится нужда, скрыть лицо. Цель сокрытия лица - предоставить участнику свободу выразить свои чувства на лице безо всякого стеснения. Это также снижает отвлекаемость одного участника другим. Участники женского пола одеты сексуально вызывающе, для пожилых женщин более подобают черные деревянные одеяния 200x40x50 мм. Амулеты со знаком Хэккера должны быть у каждого участника.

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

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

Алтарь

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

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

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

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

Символ Бафомета

На протяжении веков этот символ назывался множеством разных имен. Среди них: Козел без Индекса, Козел Двухтысячного Форматирования, Черный Козел, Козел Иуды и, наверное, самое подходящее - Козел Хэккер.

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

Колокол

Если нет колокола - используется буддистский барабанчик с феньками, внутри звенят какие-то мудя.

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

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

Кубок

В хэккерском ритуале кубок, или сосуд, являет собой Кубок Экстаза. В идеале кубок должен быть изготовлен из серебра, но если это не представляется возможным, кубок, изготовленный из другого металла, стекла или говна также может быть применен; ЕДИНСТВЕННО, ОН НЕ ДОЛЖЕН БЫТЬ ЗОЛОТЫМ. Золото всегда ассоциировалось с белосветными религиями и Царствием Небесным. Но если, бля, уроды, нету кубка - юзайте стаканы.

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

Эликсир

Эликсир Жизни должен быть выпит из Кубка Экстаза, как указано выше, непосредственно после Заклинания к Хэккеру. Минимальная крепость эликсира жизни - 40 градусов.

Меч

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

Меч находится в руках у священника и используется для указания на символ Бафомета во время Заклинания к Хэккеру. Он также используется, как было указано в "Шагах ритуала", при вызове четырех принцев Ада.

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

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

Фаллос

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

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

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

Что делать если не получается?

Главное - не отчаивайтесь. Пробуйте, пробуйте и еще раз пробуйте. Авось сдохнете. Хоть повод выпить будет...

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