Вопрос по морфингу кода.

[nikoniko]

Всем привет, тему это особо никто не разбирал тут да и по моим наблюдениям большинство людей остановились на выборе OLLVM который по факту является обфускатором нежели морфером кода.

На данный момент я разрабатываю свой стиллер (Бетта тест в профиле бесплатный) и пришел к выводу что по факту весь проект готов, осталось лишь одно - создать морфер который будет хотя бы частично помогать убирать детекты, за пару недель сделал мини проект который морфит код (Хочу уточнить разницу между морфингом кода и обычными джанк генераторами, я создавал морфер так что бы код вплетался в исполяемую часть и генерировал стандартные блоки по типу if else swith case goto try catch и так далее, создавал фейковые винапи колы ну и генерировал строки). Сам по себе морфер писался так что бы генерированный код не обрезался оптимизатором, никакие блоки не сокращались и никак не заменялись в процессе работы компилятора


По итогу получилось как то так:
ДО

После

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

По итогу хочется узнать мнение, что требуется добавить в морфер а так же что изменить в старой версии.

 

[Alzheimer]

(Хочу уточнить разницу между морфингом кода и обычными джанк генераторами

Морфер - это когда сам код меняется, но результат его выполнения прежний
Джанк генерации - вставка мусорных инструкций в код который могут запутать реверсера

По итогу хочется узнать мнение, что требуется добавить в морфер

Если ключевая цель морфера - чистить детекты, в таком случае совершенствуй эту технологию. Не пихай много лишнего. Просто выбери цель которую должен обеспечивать морфер и доведи ее до ума.

 

[Stupor]

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

 

[nikoniko]

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

Я понимаю, однако тут речь идет не про морф стаба криптора на 150 строк, а про морф огромного проекта на 30к строк исходного читаемого кода. Тут цель не скрыть статику а делать так что бы софт от морфа к морфу вел себя по разному, тот же OLLVM работает вообще по другому. Так же как минимум многое кол-во авров сейчас умеют понимать что бинарь как либо обфусцирован и необзодимо делать такой морфер, код которого будет вплетаться в саму логику а не просто как в OLLVM строиться джанк кодом вокруг нее (пусть уже на уровне пре компиляции а не исходного кода)

 

[Stupor]

В таком запущенном случае нужно не OLLVM, а LLM к проекту подключать через API, он легко логику пределает.