Сейчас дописываю стэковый полиморфный движок.

Работает он так:

1) Преобразует весь код к виду
push xxxx
push xxxx
.........
jmp reg32

2) После этого каждая инструкци по многу раз (рандомер)
пермутирует например:

было: push 12345678

стало: mov eax,123000
add eax,678
push eax
xchg eax,edx
push edx
pop eax

Это так самы простенький вариант. На самом деле всё будет хитрее и сложнее.

А теперь вопрос - какие варианты его детектирование без
эмуляции кода ??? Да ну и там всё будет обильно реалистичным мусором посыпано.

Ну да там очепятка вкралась
mov eax,1230000
add eax,45678

sl0n
Твой полиморфизм только в момент выполнения?

Нет конечно, на**й он нужен если только в момент выполнения ???

Непонятен первый пункт. К какому виду преобразуется код? Покажи как к такому виду будет преобразован код из второго пункта (для следующего поколения вируса). Если движок будет увеличивать размер кода в ограниченное снизу количество раз, то это будет означать экспоненциальный рост его объёма и вследствие этого серьёзное ограничение на количество поколений...

sl0n
А теперь вопрос - какие варианты его детектирование без эмуляции кода
его можно будет засечь например статистическим анализом - в файле будет куча опкодов 0x68 (push imm32), да может и других (0xFF etc.)
после этого подключается эмуляция, и медленно медлеенннооо... :)

Ну раз непонятен 1) объясняю:
делается следующее весь код вируса представляется в виде
068 + 4 байта вируса ... а в конце делается переход на стэк. Таким образом у нас получается простейший стэковый движок. Далее после первого прохода пермутациии он мутирует к примеру так :
Из инструкции: push 12345678
Получаем : mov eax,12345678
push eax
Далее идёт следующий проход и пермутируют уже две инструкции и т.д. Да размер вируса будет расти сильно но это есть гуд, т.к. зесь как я думаю все инструкции нужно будет
эмулировать, а ещё есть такая вещь как глубина эмуляции...

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

Вот ... жду ещё отзывов Ж)

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

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

з.ы. Доктор скорее всего тебе ничего не скажет - наверняка это страшная кибальчишечья тайна всем известной конторы :)

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

Dr.Golova
ну а чиста теоретически?
допустим, статистический анализ не помогает (а его всегда можно "подогнать")
че авп будет делать дальше?
если конечно это не военная тайна...

added: кстати, трагедия про авп :))))

Кажеться в Itanium и AMD64 реализовали защиту от исполнения кода где попало и XP SP2 уже юзает эту фичу .
Наверное благодаря вирусописателям :)

Допишу и запостю ...