╔════════╤════════════════════════════════════════════════════╤══════════╤═══╗
║Okt 1999│NF представляет электронный журнал MooN BuG issue 11│ RedArc │003║
╟────────┴────────────────────────────────────────────────────┴──────────┴───╢
║ Концепция недетектируемого вируса (FullMorph) ║
╚════════════════════════════════════════════════════════════════════════════╝
К данной статье меня подтолкнул разгоревшийся в PVT.VIRII флейм о том,
что FullMorph невозможен, потому что этого не может быть никогда. Народ не
смущает ни теоретическое обоснование сего чуда Imagineer'ом, Reminder'ом и
мной, скромным. Не смущает и наличие первых разработок по этой теме: PLY, VCG,
ACG. Посему постараюсь в этой статье сделать что-то вроде FAQ по
недетектируемым вирусам.
И так, что же смущает прогрессивное человечество, то бишь вирмейкеров, в
концепции недетектируемости? Попробую задать эти вопросы себе и сам же на них
попытаюсь ответить.
Утверждение первое
==================
Если вирус может детектировать себя в инфицированных программах,
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
то и антивирус сможет его детектировать
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Необходимо рассмотреть отображение множества всех объектов, которые можно
заразить на множество уже зараженных объектов. Если для антивируса это
отображение ОБЯЗАНО быть изоморфным, (т.е. грубо говоря давать возможность
однозначно определять зараженность файла при наличии у него данного
признака), то для вируса это не нужно и даже ВРЕДНО! Если часть нашего
отображения будет покрывать незараженные файлы, то это несколько снизит
вирулентность, но значительно затруднит детектирование вируса данным способом.
Из классики (вирлист к DrWeb и AVPE) мы знаем, что существуют вирусы,
детектирующие свое наличие в файлах по следующим признакам:
- по первому байту программы (для COM-программ). Это может быть первый
байт команды перехода на вирус (0e9h или 0e8h) или некая любая другая команда
(nop; cli; sti; cld; xchg Reg,Reg; push Reg / pop Reg; cli / sti; pusha; int
3h; dec cx; ...);
- по некоторому байту / слову, находящемуся по фиксированному адресу в
начале программы (обычно после команды перехода) или по фиксированному адресу
в теле самого вируса;
- по последнему байту / слову инфицированной программы;
- по слову в поле CheckSum в заголовке EXE-программы;
- по установленному атрибуту ReadOnly;
- по специфическим данным в поле дата / время последней модификации
файла;
- по данным в полях EXE-заголовка для HLL-вирусов;
- по наличию файлов с одинаковым именем, но с различными расширениями
(справедливо для компаньон- и BAT-вирусов);
- ...
Для резидентных вирусов, которые инфицируют кроме файлов еще и память,
существуют следующие признаки:
- по специфическим функциям в "горячих" прерываниях для резидентных
вирусов (типа "ты здесь?" - "я здесь");
- по байту / слову по фиксированному адресу в памяти;
- ...
Уже из приведенного списка признаков мы видим, что нельзя однозначно
сказать о наличии вируса в файле, если файл начинается с команды PUSHA или
имеет атрибут ReadOnly. Некоторые (в основном устаревшие) вакцины специально
добавляли в файлы известные признаки вирусов (строка "MsDos" - как вакцина от
вирусов Jerusalem в конце файлов) что вносит еще больше сомнения в
целесообразности реагирования антивирусов на вирусные метки. Кто мешает
FullMorph-вирусу тоже ставить в конец инфицированных файлов строку-признак
"MsDos"? Некоторые вирусные метки совпадают для абсолютно разных вирусов
(значение 60 в поле секунд времени последней модификации файла) и сказать о
том, какой именно вирус (и есть ли вирус вообще) по таким признакам абсолютно
невозможно. Во время локальных эпидемий очень часто делаются самопальные
резидентные вакцины (вообще то такие вакцины делал даже Д.Н.Лозинский от того
же Phantom), которые откликаются на вирусные запросы "ты здесь?" или даже
содержат куски вирусного кода при необходимости (вирусы семейства Kela в
качестве ответа на вопрос "ты здесь?" возвращают адрес вируса в памяти, а
пытающийся проинсталлироваться вирус сравнивает начало своего кода с началом
кода резидентной копии). Так что лечение памяти по одним лишь вирусным меткам
занятие весьма сомнительное, которое чаще будет приводить к краху системы, чем
к положительным результатам. Более того, некоторые антивирусы хранят маски
вирусов (сигнатуры) в открытом виде и эти сигнатуры совпадают с сигнатурами в
других антивирусах. Так когда то антивирус Scan находил в антивирусе AIDSTEST
маску загрузочного вируса Disk Killer о чем радостно и сообщалось счастливым
обладателям обоих антивирусов.
Не сложно сделать вывод, что уважающий себя антивирус и тем более
коммерческий антивирус либо вообще никак не будет реагировать на метки,
которыми пользуются вирусы, либо сочтет их недостаточными и будет искать
дополнительные признаки присутствия вируса (кусок кода в виде сигнатуры, CRC
постоянной части кода вируса, ...). При отсутствии таких дополнительных
признаков антивирус может выдать одно из следующих сообщений:
- возможно инфицирован модификацией вируса (самые дерьмовые);
- возможно инфицирован вирусом типа COM.EXE.TSR.... (параноидальные);
- странная(ое) дата(время) создания файла (нормальные);
Таким образом, если антивирус будет пугать пользователя своими
сообщениями только потому, что в программе UUE.EXE по адресу 0:0419h найдена
команда CLI, пользователь просто откажется от использования этого антивируса.
Для коммерческих антивирусов (DrWeb, AVP, ...) такая бдительность может
оказаться пировой победой - фирма-разработчик обанкротится нафиг.
Кроме всего прочего существует ряд признаков, которые абсолютно не
пригодны для антивирусов и вполне приемлемы для вирусов. К таким признакам
следует отнести:
- проверка кратности длины файла некоторому значению, например 7;
- проверка бита ReadOnly в байте атрибутов;
- ...
Вирус может подсчитать контрольную сумму первого килобайта инфицируемой
программы и записать ее в виде двойного слова в конец файла. При тестировании
файла вирус снова подсчитывает контрольную сумму и сравнивает ее с числом из
конца найденного файла. Совпадает - вирус инфицировать файл не будет, не
совпадает - будет. При этом метка вируса тоже становится полиморфной, а
совпадение контрольной суммы n-байт файла с числом из последних байт - событие
совершенно случайное. Да и алгоритмов подсчета CRC существует великое
множество, что делает такую метку не опознаваемой без знания алгоритма
подсчета контрольной суммы. И даже если в антивирус будет вставлен именно этот
алгоритм подсчета CRC, то кто же даст гарантию, что абсолютно другой вирус или
программа с самоконтролем изменений не используют точно такой же алгоритм? Вот
вариации таких вирусных признаков:
- значение n для подсчета контрольной суммы зависит от длины файла и
каждый раз является случайным (например, если длина кратна 5, то n=5*5*5, а
если кратна 7, то n=7*6*5, ...);
- вместо контрольной суммы в конец файла записываются первые два байта
инфицируемой программы (кто сказал, что в неинфицированных файлах первые n
байт не могут совпадать с последними n байтами?);
- то же самое, что и в предыдущем пункте, но значение n зависит от длины
файла (чему оно кратно, столько байт и дописывается);
- то же самое, но смещение байт, копируемых в конец файла, зависит от
даты или времени создания файла;
- вирус генерирует n мусорных байт, сумма которых равна некоторой
константе или кратна некоторой константе и этот мусор дописывается в конец
файла;
- то же самое, но значение n зависит от значения секунды+минуты времени
создания файла, а константа, которой кратна сумма мусорных байт, это кратность
длины файла простому множителю (2,3,5,7,9);
- ...
Если немного пофантазировать, то вычислить метку вируса будет весьма
проблематично, так как при инфицировании одного и того же файла она будет
уникальна в каждом случае заражения. Еще большую полиморфность в признак
присутствия вируса будет вносить использование вирусом более одного метода
генерации своей метки (кратность длины файла некоторому значению; кратность n
байт в конце файла значению m, где n зависит от даты создания файла, а m от
времени создания файла; ...) и не инфицирование файлов при наличии у них хотя
бы одного признака. Выбор метода генерации метки при инфицировании так же
может быть случайным событием. Здесь главное выбрать такие признаки, которые
хоть иногда позволяли бы вирусу находить себе жертв ;)
Надеюсь, что после моих рассуждений даже самые закоренелые пессимисты
согласятся, что концепция FullMorph никак не страдает от того, что вирус может
и должен оставлять свои метки в инфицированных файлах чтобы избежать
повторного заражения.
Утверждение второе
==================
Данные вируса будут демаскировать вирус и будут прекрасной
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
сигнатурой, что сведет все усилия вирмейкера на нет
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Ну давайте для начала разберемся, какие данные нужны вирусу и без чего
можно обойтись. Для обычного Search вируса без полиморфной ангины кроме маски
файла и сохраненных байт программы и хранить, собственно, ничего не нужно. Все
остальное можно с успехом взять из DTA. Сохраненные байты программы можно
вставить непосредственно в код, например:
обычно восстановление начальных байт делается вот так:
mov si,offset OldBytes
mov di,100h
mov cx,3
rep movsb
...
OldBytes:
db 090h, 090h, 090h
при переносе в код мы избавляемся от необходимости хранения данных
mov di,100h
mov ax,09090h
stosw
mov al,090h
stosb
а вот теперь посмотрите на такой фрагмент:
mov ax,0c9h
push ax
pop si
add si,037h
push bx
add bx,0a2c4h
xchg bx,ax
pop bx
sub ax,bx
sub ax,1234h
mov word ptr ds:[si],ax
xchg si,di
mov al,6dh
add ax,23h
stosb
Все три фрагмента делают одно и то же, однако в последнем случае
антивирус без эмулятора уже не сможет найти место, где восстанавливаются байты
жертвы да и сами байты программы уже растворились в коде. FullMorph вирус
должен генерировать такие фрагменты случайным образом для новой копии и
разбавлять эти фрагменты мусорными командами. Все, нет ни данных ни сигнатуры.
А эмулятор никоим образом на данном фрагменте не сможет однозначно
идентифицировать вирус, да и мусорные команды могут быть не просто пустышками,
а анти отладочным, анти эвристическим или анти эмуляционным кодом (у каждого
эмулятора есть свои ограничения). Позволю себе одну ремарочку: не стоит
увлекаться созданием мусора с оригинальными анти антивирусными приемами,
поскольку именно эти приемы и будут прекрасным идентификатором вируса для
вирусолога. Да, никто не заставляет восстанавливать исходные байты программы в
самом начале вируса. Это можно сделать абсолютно в любом месте вирусного кода.
Перемещение блока восстановления жертвы по коду внесет дополнительную
полиморфность и эти данные будут спрятаны от любознательных глаз как за
крышкой гроба. И совсем не обязательно перемещая этот блок хранить в начале
кода вируса JMP на него. Можно просто "врезать" этот блок в любой другой,
случайно выбираемый при генерации новой копии вируса.
Так, у нас осталась маска файлов для поиска. С ней можно обойтись
примерно таким же способом. Вот три фрагмента:
стандартный способ
mov ah,4eh
mov cx,0feh
mov dx,offset FileMask
int 21h
...
FileMask db '*.com',0h
переносим данные в код
mov ah,4eh
mov cx,0feh
xor bx,bx
mov si,sp
push bx
mov bx,'mo'
push bx
mov bx,'c.'
push bx
mov bh,'*'
push bx
mov dx,sp
inc dx
mov sp,si
int 21h
а вот теперь посмотрите на такой фрагмент:
mov bh,14h
mov di,sp
xchg bx,ax
xor bx,bx
add ah,3ah
push bx
inc bh
dec bx
xchg cx,bx
dec cx
mov bx,06d6fh xor 1234h
xor bx,1234h
push bx
mov bx,(0632eh + 1234h)
sub bx,1234h
push bx
mov bx,1100h
add bx,1900h
push bx
mov bx,sp
inc bx
xchg bx,dx
xchg bx,di
xchg bx,sp
int 21h
Всё. Данные растворились в коде, а код полиморфичен. Сигнатура исчезла и
нет необходимости хранить смещение данных. Правда за такие финты ушами
приходится жертвовать минимизацией размера вируса, но... красота требует
жертв.
Теперь посмотрим, что же нам готовит полиморфность. А готовит она нам
следующее: если вирус модифицирует свое тело, то придется хранить таблицы для
дизассемблирования и варианты для замены команд / блоков. Если вирус
генерирует новую копию, то придется хранить данные для генератора. Эти данные
так просто в код не засунешь. Конечно можно выделять блок памяти под таблицы и
пихать в него таблицы прямо из кода таким же макаром, как в предыдущем примере
в стек пихалась маска для поиска файлов. Но это приведет к офигенному
увеличению кода, хотя цель уже будет достигнута. Но есть еще два пути:
традиционный и нетрадиционный. Традиционный заключается в том, что в теле
вируса данные шифруются полиморфик-циклом, а полиморфный декриптор
модифицируется тем же способом, что и остальной код. И совсем не обязательно
расшифровывать данные вируса в самом начале. Можно сначала произвести поиск
подходящих файлов для инфицирования, создать список их имен в памяти или на
диске, а уж потом (или в процессе поиска подходящих файлов в случайном месте)
расшифровать данные. Нетрадиционный заключается в том, что вирус при создании
n-ой копии будет сам себя "кастрировать" (как это сделано в VCG). Кастрация
заключается в том, что создавая n-ую копию вирус не включает в нее ни данные
ни полиморфную ангину (или полиморфный генератор). С одной стороны это
приведет к тому, что вирус, начиная с n+1 копии, уже не будет меняться. С
другой стороны можно вообще забить на данные и оставить их как есть, все равно
в одно прекрасное мгновение они не будут записаны в очередную жертву и
привязываться к ним антивирус не сможет (иначе он не сможет ловить n+1 копии
вируса). При этом совершенно не известно как будет выглядеть n-ая копия вируса
и сколько она создаст n+1 копий, практически не похожих друг на друга.
Особенно интересно совместить кастрацию с внутренним полиморфик-циклом.
Тогда во время периода жизни вируса с 1 по n-ую копию данные будут
зашифрованы, а начиная с n+1 копии их вообще не будет. При кастрации будет
высвобождаться туева хуча места, которое можно использовать для увеличения
проходов FullMorph-ангины с целью усиленного изменения n+1 копии вируса.
Надеюсь, что я развеял ваши сомнения по поводу того, что данные и
FullMorph не совместимы. Я привел только два подхода к данным, а их, как мне
кажется, столько же, сколько волосиков на среднестатистической пи$де.
Утверждение третье
==================
Вирус, тем более такой, будет содержать команды переходов. Эти
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
команды станут непреодолимой трудностью для мутаций
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Ну во первых вирус может вообще не содержать команд переходов в чем можно
убедиться, если повнимательнее почитать предыдущие номера MooNBuG'а. Во
вторых, большинство команд условных и безусловных переходов будут находиться в
ангине, а ее можно либо полиморфно зашифровать, либо однажды кастрировать,
либо и то и другое вместе (смотри предыдущие рассуждения). Если допустить, что
сама ангина мутировать не будет, то не придется ломать голову над пересчетом
адресов переходов. Да и генерация этих адресов не такая уж и сложная задача.
Вот как я решил ее в VCG:
;--- Калькуляция перехода
;Input: si - адрес метки для перехода
; di - адрес команды перехода
; bx - адрес начала буфера
;Output: none
CalcJump:
push ax cx dx
mov ax,di
mov dx,si
sub ax,bx
sub dx,bx
cmp ax,dx
jl JumpDown
JumpUp:
mov cx,0ffffh
sub ax,dx
sub cx,ax
sub cx,2
xchg dx,cx
jmp FormJump
JumpDown:
add ax,3
sub dx,ax
FormJump:
mov word ptr ds:[di+1],dx
pop dx cx ax
ret
Так же рекомендую заглянуть в исходники вирусов PolyLabel и BlackLabel
(названные вирусологами GU.xxxx), которые были опубликованы в предыдущих
номерах журнала. Так что вариантов выкрутиться из этой проблемы много.
Надеюсь, вас не испугают такие "трудности" тем более, что десяток решений
этой проблемы уже предложено в нашем журнале. А дальше - это ваша фантазия.
Утверждение четвертое
=====================
С каждой копией вирус будет увеличиваться в размерах, что его
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
будет демаскировать и в конце концов приведет к гибели жертву
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
А кто сказал, что большая длина вируса - это плохо ? Это было бы плохо
еще пару лет назад, но сейчас память дешевеет... Кроме того, чем больше длина,
тем сложнее ее анализировать. Также не надо забывать, что у антивирусного
эмулятора есть такое понятие, как "глубина эмулирования", т.е. грубо говоря
через сколько команд/секунд/условных единиц (нужное подчеркунть) прекратить
эмулирование выполнения команд данного файла и перейти к проверке
следующего. Я не призываю к написанию HLLP, HLLC, но большая длина
потенциально может быть полезной.
Все зависит от того, как подойти к FullMorph. Если подойти с позиций,
которые описывал Reminder в PVT.VIRII, то безусловно вы столкнетесь с этой
проблемой. Однако сам же Reminder и предложил несколько решений этой проблемы.
За более конкретными советами прошу обращаться непосредственно к нему. Если
посмотреть с позиций вирусов PLY, то вполне можно плавать в некоторых разумных
рамках с увеличением / уменьшением кода. Если глянуть выше, где я говорил о
данных, то становятся видны два решения:
- вирус может не модифицировать свой код, а постоянно его регенерировать,
что приведет к некоторым разумным рамкам по варьированию длины новой копии;
- вирус будет однажды кастрирован и больше мутировать не будет и при этом
к моменту кастрации у него все еще сохранится приемлемая длина кода.
А то, что длина демаскирует вирус - это и слону понятно. Только при этом
не следует забывать, что FullMorph-вирус может быть резидентным стелс-вирусом.
Да и при отсутствии ревизора / инспектора и сложной реализации зверька не
доступной для анализа вирусологам (чего, собственно, мы и добиваемся) это
приращение длины будет антивирусу как мертвому припарка. Главное - сделать
разумные ограничения в ангине, чтобы с первых же копий не нагенерировать код,
который забьет 6 гигабайтный диск командой перехода на тело зверька ;)
В общем я не вижу здесь никаких не решаемых проблем. Надеюсь, что и вы
тоже их не видите.
Утверждение пятое
=================
Вирус должен восстанавливать жертву перед возвратом управления
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
и именно в этот момент его можно будет отследить и вылечить
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Во первых антивирусу еще нужно найти место, которое вирус будет
восстанавливать. Ну посмотрите хотя бы уже старенький прием с плавающей точкой
передачи управления вирусу, который приведен в вирусах V++. Пусть антивирус
нашел таки это место и поставил туда хардверный бряк, ну и что? К этому
моменту вирус уже успеет перетрахать весь винчестер, отработает возможная
троянская компонента и вместо передачи управления вирус вызовет перезагрузку
компа (возможно последнюю в его жизни). Допустим, что ожидание процесса
передачи управления жертве будет происходить в некотором виртуальном мирке,
созданном эмулятором антивируса. А кто это вирусологу сказал, что после
восстановления байт в точке перехода вирус таки отпустил жертву? Есть такие
красивые вещи, как симбиоз и принципы "неизлечимости". Ну с симбиозом понятно.
Этому вопросу мы уже уделяли внимание в ранних выпусках MooNBuG'а. О
неизлечимости вам поведает S.S.R. Я хочу только привести простейший пример,
где этот финт ушами у антивируса не пройдет.
Вирус может просканировать (сканировать, трассировать, эмулировать) тело
жертвы в поисках "горячих" команд, как то вызов прерываний, команд безусловных
переходов и пересылки данных и организовать их выполнение из своего кода.
например, в теле жертвы найден такой фрагмент кода:
...
je @1
jmp @2
@1:
...
@2:
...
что вирусу мешает изменить этот кусок на следующий:
je @1
jmp @3
@1:
...
@2:
...
[тело вируса]
@3:
jmp @2
...
[тело вируса]
В данном случае вирусу нет никакой необходимости восстанавливать тело
жертвы в первоначальный вид, а лечение жертвы без восстановления всех таких
фрагментов будет губительно в первую очередь для самой жертвы. И таких вот
изюминок может быть случайное количество со всевозможными вариантами.
K FullMorph это, честно говоря, имеет весьма косвенное отношение, но
проблемой для вирмейкера точно не является. Передача управления жертве
является больным местом для любого файлового вируса, а полная полиморфность
служит совершенно для других целей: не нашел - не полечил. Не будет же DrWeb
или AVP запускать все подряд файлы на вашем компе! Да и на эмуляцию каждой
программы уйдет туева хуча времени, а при стремительном увеличении размеров
винта и геометрической прогрессии наполнения их всевозможным хламом такой
антивирусный подход не приведет ни к чему. Так что в свете рассматриваемого
утверждения FullMorph стоит того, чтобы вы его сделали.
Надеюсь, что и это опасение снято с ваших перепуганных в доску душ ;)
Утверждение шестое
==================
Механизм мутаций будет настолько сложным, что его нельзя будет
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
хорошо замаскировать и именно в нем антивирусы найдут сигнатуру
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Собственно отвечая на четвертое утверждение я ответил и на это
предубеждение. Однако повторюсь. Все зависит от того, с какой стороны вы
подойдете к вопросу создания полномутирующего вируса. Подходов на сегодняшний
момент уже известно около десятка. Каждый имеет свои преимущества и свои
недостатки. Я надеюсь, что вы найдете ту золотую середину между жертвой
размера и сложностью конечной копии, которая доставит не мало головной боли
вирусологам.
Постарайтесь минимизировать свою ангину и при этом сохранить максимум
функциональности. Однако это именно ваша проблема - выбрать и
усовершенствовать что-то готовое или создать что-то свое. Главное - начать.
Утверждение седьмое
===================
Этого не может быть, потому что не может быть никогда
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Ну если вас не убедили мои рассуждения по шести приведенным выше
утверждениям, то вы либо счастливый человек - вам это не нужно, либо полный
кретин, которому говорить - что об стенку горох ;)
В предыдущем номере журнала я опубликовал кодогенератор VCG, который
является моей, пусть несколько глюкавой, версией FullMorph. Уже после того,
как журнал был обнародован и Belka и Strelka попали в силки вирусологов (там
столько было глюков и недоделок, что это и не удивительно), в очередном
апдейте к AVP появилось сообщение о более мощной ангине ACG для резидентных
FullMorph-вирусов. Почему AVP стал детектировать ACG? Не знаю - я так и не
нашел эту ангину. Возможно в ней тоже что-то не предусмотрели или внесли
какие-то баги. Надеюсь, что вашу ангину уж точно никто задетектить не сможет.
Так что это не просто может быть, это уже есть!
Самое интересно, что идею FullMorph можно реализовать не только в
ассемблере, но и в языках высокого уровня. Примером могут служить вирусы HLLW.
Fomin и HLLW.FMRA, опубликованные в предыдущих номерах журнала. Доведенная до
ума эта идея представлена в журналах DVL. Вот разве что еще никто не сделал
хотя бы первую реализацию FullMorph на пакетных файлах, скриптах и макросах.
Все еще впереди... А может быть это сделаете вы?
Да, если у вас есть еще какие то утверждения о том, что этого не может
быть или что невозможно создать не детектируемые вирусы - не стесняйтесь,
высылайте мне свои вопросы, сомнения и утверждения. Я постараюсь разобраться
сам и ответить на них всем. Как всегда, мой адрес: [email protected]
Особая благодарность за помощь при подготовке этой статьи выражается:
"Dmitry Kulshitsky"<[email protected]>
