>>909820 (OP)
profit?

>>909820 (OP)
Нет.
Любой такой рандом разрушает программу, значит рандом должен быть не рандомным: любое искажение не должно нарушать программу, на любую мутацию придется адаптировать программу так, чтобы мутация ее не затронула.
Т.е. мутации могут быть рандомными, но каждая мутация рандомной быть не может: на каждую мутацию кто-то должен генерировать комплиментарную мутации иммунную часть.
И кому бы это делать?
Конпелятору для конпеляции это не нужно. Так что занимаются этим как правило специализированные программы - крипторы/обфускаторы.
В самом простом случае они перемешивают код и досыпают между инструкциями программы безопасные ничего не делающие инструкции.
В самом сложном - виртуализируют программу на динамически изменяемой обфусцированной виртуалке, так что шансов все это просто распаковать почти нет. К счастью продуктов такого уровня на рынке пока просто нет. Но когда-нибудь будут.
Также популярный вариант - обфускация препроцессором. Программист пишет свой модуль к препроцессору, который меняет сам исходник, затрудняя реверс. Но это больше для языков, где в коде остается много полезной для реверса инфы.

>>909878
>Любой такой рандом разрушает программу
Почему? Смотри, как было бы хорошо не морфить стаб криптора отдельно, а создать свой метаязык, на котором написать стаб, который при каждом билде будет уникальным.

>>909820 (OP)
> Неужели ни один человек на земле до такого не додумался?
Палю фишку:
tcl, иди рандомь себе на здоровье как в твою голову стукнет
hint: желательно писать на тикле в жопу бухим, увеличивает скорость разработки.

какие use case для той фишки что предлагаешь?

>>909820 (OP)
>Неужели ни один человек на земле до такого не додумался?
Это говно нужно только мамкиным кацкерам перед одноклассниками выебываться. Среди конпиляторописак этого генетического мусора нет.

>>909883
Берешь виртуалку, для каждого билда рандомно меняешь ей опкоды, добавляешь мусорные опкоды, ведущие на другие, либо ничего не делающие, либо динамически меняющие другие опкоды. Плюс еще можно поиграться со стеками и контролем исполнения - там много мест, где код можно безопасно изменить, в т.ч. его работу, что обламывает поведенческие анализаторы.
Оп, и у тебя разная программа каждый билд, или даже каждый запуск, если нужно, или даже меняющаяся динамически во время исполнения.
При этом основная программа не разрушена, логика исполнения не нарушена, она даже не знает что снаружи выглядит как постоянно меняющийся кусок говна.
Фишка в том, что снаружи внутрь виртуалки, в настоящую программу, не заглянуть без полного разбора виртуалки, а это сделать практически нереально - она каждый раз разная. Но теоретически возможно.
И это самое простое, что можно придумать.

>>909939
Нет, это нужно и для серьезных систем. В частности полиморфный код клиента может служить частью абсолютной защиты сети, отрезая взломанных клиентов от сети, прерывая эпидемию на корню: каждый клиент имеет уникальный код, нельзя запилить патч более чем для одного, или еще каким-либо образом скомпрометировать более чем одного за раз.
При этом каждый взлом придется начинать с нуля, с анализа.
Приправив это парой-тройкой архитектурных фишек можно создать абсолютно защищенную сеть, которой не страшны никакие внешние атаки, контроль которой перехватить нельзя. Т.е. один человек может единолично рулить огромной сетью, не боясь потери контроля, имея гарантию, что сеть не скомпрометирована, имея гарантию что рабочий код клиента соответствует тому, который допущен для работы в сети.
Клиент в свою очередь получает надежный канал обновлений, и гарантию, что взлом может произойти только локально, через доступ к его компу, но не из сети.

>>909957
>Т.е. один человек может единолично рулить огромной сетью, не боясь потери контроля
Мы же понимаем, о чем это? Представляете, как можно майнить?

>>909959
От патча легко избавиться на уровне архитектуры.
Произвольный код - там виртуалка, и бинарник каждый раз разный. Никаких стойких сигнатур просто нет, относительные смещения тоже непостоянные. Строго индивидуальный взлом каждого клиента. Это не упаковка, это почти полноценная перекомпиляция.
Перехват контроля сети теоретически невозможен - это не сложно сделать, опять же на уровне архитектуры.

>>909989
И вообще, самая смехота такого подхода: можно смело публиковать исходники, зная что контроль отобрать не смогут, если ты сам добровольно его не отдашь.
Полиморф там не для того, чтобы не добрались до рабочего кода, а как механизм защиты сети на уровне архитектуры. Т.е. сеть ожидает общения именно с конкретным полиморфом.

>>909957
Что за маняфантазии я только что прочел? Иди уже нахуй, школьник и делай свою абсолютную защиту, а не пизди на сосаче.

>>909820 (OP)
> полиморфизма/метаморфизма
> не отличает полиморф от метаморфа
Нажал кнопку вызова бхц и спокойно поскроллировал двач дальше.

Доставьте журнальчеки бхц

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

>>909950
>у тебя разная программа каждый билд, или даже каждый запуск, если нужно, или даже меняющаяся динамически во время исполнения.
>При этом основная программа не разрушена, логика исполнения не нарушена, она даже не знает что снаружи выглядит как постоянно меняющийся кусок говна


Как эта годнота реализуется?
Я сейчас пишу генератор мусора для полиморфного генератора, там попросту сишные функции-примитивы типа PUSH_R, которые добавляют опкод в шеллкод, и функция, которая случайным образом добавляет определенные опкоды в программу.

А как делается полноценная виртуалка? Как ее сделать полиморфной?