Метаморфический генератор
Я пытаюсь найти ссылки на различные конструкции метаморфических генераторов, если кто-то укажет мне правильное направление. Я просмотрел некоторые документы в ACM, но не смог найти то, что искал.
2 ответа
Если вы ссылаетесь на метаморфические движки, я, к сожалению, не знаю ни о каких хороших ссылках. Я думаю, что это связано с тем, что тема все еще находится под запретом из-за того, как она обычно используется вирусописателями. Я думаю, что это неоправданно, поскольку техника интересна сама по себе. Я всегда был очарован самоизменяющимися и самовосстанавливающимися системами. И можно также сказать, что это немного связано с искусственным интеллектом.
Для неинформированного метаморфический движок - это исполняемый файл, который меняет каждый байт и инструкцию сам по себе, так что, хотя новое содержимое файла является уникальным по сравнению с предыдущим поколением, общий алгоритм остается тем же. Поставщики антивирусного программного обеспечения столкнулись с большими трудностями при идентификации вирусов, когда метод впервые использовался вирусами, поскольку простая идентификация вирусов по сигнатуре была неэффективной, когда каждое поколение было различным. Введение полиморфных и метаморфических вирусов ознаменовало эпоху, когда антивирусное программное обеспечение перешло от идентификации по сигнатурам к эвристике. То есть вместо того, чтобы смотреть на точный код или поток байтов, вы скорее пытаетесь определить, что делает код.
При реализации такого подхода возникает несколько проблем, которые зависят от используемого исполняемого формата и архитектуры процессора:
Некоторые архитектуры RISC не могут содержать полные 32-битные непосредственные объекты, поэтому сегмент кода неизбежно будет содержать пулы данных для непосредственных объектов, которые выбираются с помощью двойного поиска. Это серьезный ограничитель показа, потому что вам нужен способ однозначно отделить код от данных. То есть некоторые значения данных могут быть юридически представлены как код, и наоборот. Если ваша программа ссылается на динамические библиотеки, такие как, скажем, среда выполнения C, вам также нужно пересчитать информацию, используемую при перемещении, что нетривиально.
И самая большая проблема заключается в том, что такие программы имеют тенденцию экспоненциально увеличиваться в размерах для каждого нового поколения. Если исходный "упрощающий" алгоритм (описанный ниже) плохо работает, добавляется все больше и больше мусорного кода. А "плохая работа" означает, что ей не удается безупречно упростить код до исходного. Любое дополнительное "раздувание" от предыдущего поколения накапливается.
Общая техника работает следующим образом: приложение должно считывать себя и анализировать исполняемый формат (ELF, COFF, a.out, PE). Затем для каждой группы из N инструкций он пытается упростить алгоритм. Например, добавление значения X с последующим вычитанием по значению X фактически является noop и может быть проигнорировано. a*b+a*c можно упростить до a*(b+c), сохраняя одну инструкцию. Таким образом, этот упрощитель находит голый скелет всего алгоритма, поскольку ранее он подвергался метаморфизму.
После этого вы снова запутываете код, делая обратное. Возьмите N инструкций и замените их чем-то еще, что делает то же самое. Другие этапы включают в себя разделение данных сразу на несколько частей, запутывание строк и разбиение кода на несколько новых функций, а также перемещение кода. Все это делается при отслеживании кода и ссылок на данные. Затем, наконец, код собирается и возвращается обратно в форму в виде исполняемого файла.
Это ошеломительно сложно. Только для настоящих хардкорных сборщиков. Вы были предупреждены.
Ищите движки, написанные авторами virii:
1) z0mbie
2) mental driller (metaph0r)
3) vecna
также поиск в Google для "Project Bukowski"