detect.txt

                      О ДЕТЕКТИРОВАНИИ СЛОЖНЫХ ВИРУСОВ

     Каким образом происходит детектирование современного вируса?

     Во-первых,  из  всего набора проверяемых файлов выбираются те, которые
 могут  быть инфицированы конкретным вирусом. То есть, например, все PE-EXE
 файлы от 16k и больше.

     Затем происходит более тщательное отфильтровывание тех файлов, которые
 этим  вирусом инфицированы быть не могут: с учетом внутренних особенностей
 файла.  Например,  если  PE-хеадер  меньше килобайта, нет смысла проводить
 проверку на CIH.

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

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

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



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

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

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

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

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


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


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

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


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


     Как же достигнуть такой фичи?


     Есть несколько путей.

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

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

     3.  Перемешивание  между собой кусков вируса (или декриптора) и кусков
 программы, с сохранением работоспособности программы. Этот вариант основан
 на реверсинге и интеграции.

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


     Хотя,  наиболее простым и эффективным вариантом будет генерация вируса
 из  hll-подобных  кусков,  то  есть  таких кусков кода, которые производят
 существующие  c++  -  компиляторы.  Вероятность того, что такие куски кода
 есть в некой программе -- велика; и вместе с тем не придется анализировать
 саму  программу.  Возможно,  это  и  есть  решение. Нечто в этом роде было
 показано  в  одном из rvm'ов; там написаный на ассемблере код генерил себе
 декриптор  в  виде  якобы  откомпилированного паскалем exe'шника; exe'шник
 этот   ничем   не   отличался  от  настоящих,  за  исключением  собственно
 зашифрованного ассемблерного кода внутри.
     Здесь  же  я  предлагаю  не  генерить такой exe'шник, а модифицировать
 существующий, с сохранением работоспособности.


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