VirusCodeGenerator
by Redarc
"Пишем вирус и антивирус"
Хижняк.J
Программа VCG_TEST.COM является демонстрацией возможностей
вирусного кодогенератора. При ее старте создается (модифицируется) файл
test1.com. Файл test1.com так же является программой. При ее старте
выводится сообщение:
VirusCodeGenerator by RedArc
Смысл демонстрации в том, что программа вывода вышеприведенного
сообщения формируется по полиморфному закону. При этом в качестве
полиморфного энджина используется кодогенератор.
Буду очень благодарен тем, кто вышлет мне программу, детектирующую
все создаваемые демонстрашкой файлы test1.com как, например, DEMO_VCG.
Да, при этом не стоит подсчитывать количество команд STOSW в файле ;)
Это заюзано только для демки. В вирусе их может вообще не быть.
PS: Никаких "сюрпризов" в программах нет: вирусов, троянов или еще
чего. Можете не бояться ;)
=======================================================================
****> Клич RedArc был услышан, и уже через день DrMad запулил в
comp.virus программулину, которая успешно детектировала данные вирусы.
Ее саму и исходник на ASM вы можете найти в каталоге VCG. Ниже приведен
ответ RedArc на эту программу.
=======================================================================
От: redarc@oitsp.tsu.tula.ru <redarc@oitsp.tsu.tula.ru>
Тема: Re: Re: VCG
Дата: 2 апреля 1999 г. 23:26
Привет!
Вобщем то да... опаньки. Но я немного не это имел ввиду. Сам
виноват, что не написал. Трассировка штука хорошая, но... Во первых ее
можно обламать, а во вторых, можно уйти из под детектора и вирус будет
активирован самим детектором. Да и отлов конкретно этой штуки можно
было еще проще сделать.
1. Проверить косвенные признаки (хотя бы то, что в конце всегда
стоит набор команд: 0cdh 021h 0c3h)
2. Поставить бряк на 0c3h и посмотреть сигу по адресу 100h.
Это безопаснее и проще, но только в данном случае.
Я то имел ввиду детектор программ, генерируемых VCG. Ну типа, как
это делает тот же AVP для VCL. То есть, отлавливать все генерируемые
файлы как VCG-based.
> В качестве сиги полиморфиков можно брать не последовательности
> байтов, но _состояния_, т.е. определенные значения SP, других
> регистров и указуемых полей памяти. А вобщем случае в качестве сиги
> надо брать _действия_, т.е.
То есть, нужен эмулятор? Я правильно понял?
> включать динамику процесса. Это сложней, но Каспер, ДанилОфф и особенно
> Валик это умеют.
Фигвам. Они отвалятся на самых безобидных приемах - юзанье портов. Пример.
|Начало программы|
|Переход на EntryPoint вируса|
|Программа|
|Первые блоки вируса|
|EntryPoint вируса|
|Вызов VCG|
|Остальные блоки вируса|
|VCG|
Ну как понятно из вышеприведенной схемы, вирус может внедрять
переход на свою стартовую точку в пределах первых n-байт жертвы
(случайное место на протяжении блока, где отсутствуют call, jmp, ret,
etc). Размер внедрения (перехода на вирус) - величина не постоянная,
код внедрения генерируется самим VCG.
Точка входа в вирусный код содержит (или не содержит, в зависимости
от того, что было сгенерировано) всякую лабуду по антиотладке,
антитрассировке и антиэвристике. Так сказать, первый эшелон защиты
вируса. Здесь же, в промежутках между защитным кодом, производится
стартовая настройка некоторых регистров. Затем вызывается VCG, который
в буфере генерирует новую копию вируса. Здесь опять же интересный факт
- блоки вируса не имеют постоянной длины, это вы уже успели заметить.
Они же перемешиваются в случайном порядке. Точки входа в блоки
запоминаются опять же в буфере и после окончания генерации всех блоков,
заносятся как адреса перехода. Ну типа:
- первый проход:
@@Block1: ;<- адрес сохраняем в буфере
.........
@@JumpNext1: ;<- в этой метке адрес перехода на
;следующий блок. Сохраняем в буфере
jmp 01234h ;начальное значение
;---
@@Block2: ;<-адрес сохраняем в буфере
......... ;ну и так далее
- второй проход
@@Block1:
.........
@@JumpNext1:
jmp [@@Block2]
;---
@@Block2:
.........
Запоминаем теперь только адрес EntryPoint только что сгенеренного
вируса и возвращаем управление старому вирусу (из которого получили
управление). Теперь вирус производит поиск жертв и их инфицирование.
Код, как сами понимаете, был сгенерирован ранее VCG и представляет из
себя блоки команд, раскиданных в хаотичном порядке по всему телу и
имеющие фиг знает какие размеры. В промежутках между "полезными"
блоками, управление получают "мусорные" блоки, которые мешают
трассировке и эмуляции зверька. При обнаружении еще не инфицированной
жертвы, вирус дописывает в ее конец сгенерированную VCG свою копию из
буфера и дописывает VCG. Затем корректирует адрес EntryPoint, находит
блок, куда в жертве можно воткнуть переход на вирус, сносит этот блок в
конец файла жертвы, а VCG генерирует блок перехода меньшей или равной
длины от найденного блока. Ну для красоты, VCG при записи шифруется с
неким ключем по одному из нескольких алгоритмов. Декриптор с нужным
алгоритмом генерируется самим же VCG и записывается в точку входа VCG.
Сигнатур в явном виде нет. Дальше, вирус ведет счетчик пораженных копий
и при достижении им некоего предельного значения, происходит вот что:
при инфицировании последующих жертв, в файлы записывается только тушка
сгенерированного вируса и устанавливается переход на начало кода
вируса. Сам же VCG не дописывается, собственно как и переход на VCG и
декриптор VCG. То есть, как будто их и небыло никогда. То есть сам VCG
сигнатурой являться уже не может, так как не все генерируемые им вирусы
будут его носить с собой.
Еще о прелестях жизни. Блоки вируса будут не постоянной структуры,
то есть, VCG будет носить с собой несколько "формул" одного и того же
вируса и выбирать блоки из разных "формул" по случайному закону.
Конечно, зверек будет довольно не хилых размеров, но он же
создается исключительно в научных целях и предназначен только для
журнала, так что прокатит. Да, выше я имел ввиду только Search и только
для COM-файлов.
Можно сделать как и в Pkunk: несколько "формул" с разной стратегией
поражения: в начало файлов, в конец файлов, заражение EXE и COM файлов,
резидентность и нерезидентность, ... дальше по вкусу. Но мне это уже не
интересно.
Дык собственно отсюда и была моя просьба в описании общего подхода
для детектирования кода, сгенерированного VCG.
1. Поиск в вирусе постоянной сигнатуры даже путем эмуляции ни к чему не
приведет. Это потому, что кроме самого VCG там нет ничего боле менее
постоянного, а VCG будет в какой то момент похерен.
2. Трассировка исключается, так как я уж постараюсь ее не допустить ;)
3. Эмуляция опять ни к чему не приведет, так как в "последнем поколении"
вируса, это когда VCG не будет дописан в новую жертву, ничего
зашифрованного в вирусе не будет.
Следовательно, нужны более иные подходы для детектирования такого класса
вирусов. Вот я уже слышал про какие то хитрые методы, типа слежения за
динамикой процесса... Посему и просил показать методы детектирования ни
того, что в конце-концов выводит на экран программа, а того, что они
сгенерированы одним и тем же генератором. А Костин прием здесь не катит.
Увы... Даже если откинуть метод, принятый Костей, то суть его заключается
в поиске _статического_ текста, генерируемого файлом. Вирусы же ничего
такого генерировать не должны. Так что вот так...
RedArc
==========================================================================
***> Ну что ? Всем все ясно ? Конкурс обьявляю открытым ! Детекторы можно
слать лично RedArc. Сам VCG находится в одноименном каталоге.
|
