Простенький пакер-протектор, вопрос на мильон

Пишу простенький пакер-протектор, сейчас есть две идеи, между которыми я мечусь и не могу выбрать одну

1) PE разбирается на секции, каждая шифруется отдельно, но остается на своем месте, секция с кодом (уже шифровання) переносится в новую секцию, которая добавляется в PE, на место секции кода помещается загрузчик в виде базонезависимого шеллкода
в новую добавленную секцию, куда был перенесен код, вначале вставляется структура внутреннего формата, в которой указано понятным для лоадера образом где какие секции (импорт\экспорт\tls) и что с ними делать
ну и дальше отрабатывает загрузчик, он сам себя сначала перемещает в динамично выделенную память, что бы освободить место в секции кода и расшифровывает туда оригинальный код
смысл в том, что размеры секций, их порядок и расположение сохраняется и загрузчик винды делает большинство работы по размещению образа в памяти, моему загрузчику остается только расшифровать все секции, вернуть на место секцию кода и загрузить импорт

2) PE точно так же разбирается на секции, но все тело пакуется целиком в одну секцию и PE полностью пересобирается, лоадер кладется опять же в первую секцию, дальше все почти так же как в первом варианте, за исключением того,
что после выгрузки шелла в динамик память он копирует шифрованный образ в кучу например, затем делает NtUnmapViewOfSection и далее самостоятельно грузит секции в нужные места попутно расшифровывая их + так же загрузка импорта и обработка всего необходимого

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

 

Что означает "выглядит лучше"? Оба варианта выглядят рабочими, какой критерий выбора? "Пакер" это упаковщик если че, он не шифровать должен, а сжимать. А "криптор" это способ прятать скомпрометированный код от антивирусов. Там процедурой расшифровки не отделаешься, и вообще в целом нежелательно какие-то непонятные данные с высокой энтропией в файле держать.

 

ТС мне кажется нужно ставить вопрос по другому: Какой способ будет мение палевный АВ. Или все таки речь идет о стабильности и универсальности?

 

Я понимаю чем различается протектор\криптор\упаковщик
Но в целом если глобально посмотреть, то алгоритм везде плюс-минус одинаковый, то есть присутствует лоадер в том или ином виде, который занимается подготовкой и приведением в рабочий вид того, что должно будет потом исполниться, а различные свистоперделки типа защиты импорта\памяти\кода\виртуализация\шифрование\сжатие это уже доп. опции, если можно так выразиться, тут уже как раз и начинаются различия
Но в целом криптор и протектор из перечисленного выше наиболее схожи по причине того, что цель первого - спрятать некоторые действия\код от АВ, а второго - спрятать и защитить код от крекера, в обоих случаях защита будет от реверса, в первом случае только это автоматический анализ, если не учитывать, что образец будет весьма интересен, что бы его сели раздолбать ручками, а второй вариант 100% ручное ковыряние.

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

--- Сообщение объединено, 4 авг 2022 ---

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

 

Нет! Если ты пишешь "пакер" то схема работы UPX самая стабильная. Но у пакеров есть сигнатура. По ней АВ видит и распаковывавет упаковщик. Если распаковать не вышло - детект! Понимаешь? У криптора задача иная. Максимально имитировать легальный файл как внешни так и в работе. Там уже если прицепишь непонятную аверам секцию будет детектить больше половины АВ.

--- Сообщение объединено, 4 авг 2022 ---

это что то не то. Нужно в зашифрованный оригинал воды налить и все))
Имхо сейчас критпоры лучше писать на боле высокоуровневых языках. По крайней мере в дайджестах обзоры - АРТ юзают типа голанд, раст. Там даже просто достаточно пошифровать стринги и мусором разбавить код. + кросплатформенность.

 

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

 

Если ты не сделаешь "полноценный антидамп" (с), то семплы твоей поделки можно будет автоматикой решать, гоняя не визорах.

 

да даже сделав полноЦЕННЫЙ антидамп, не стоит надеяться на то, что его оЦЕНИТ Никто^^

 

Что-то подобное я реализовывал тут. Там тоже шелл копируется в верхнюю область, анмапится оригинальный exe и вручную разбирается PE файл. Но там совсем простой проект, нет TLS, не обновляется 64-битный PEB и т.п

 

Я достаточно сильно обобщил, сказав, что везде есть лоадер, понятное дело, что сама реализация загрузки отличается везде, но сам факт - основа - лоадер.
По поводу невозможности распаковать и сразу детект - это не так, я писал где-то год назад простейшее подобие UPX, и не было там никаких детектов, ВТ 1\60, и то там какой-то ноунейм орал на отсутствие подписи цифровой

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

Я же выше написал что задача у меня стоит полуразвлекательного характера, мне нечего делать в данный момент времени, ну так получилось, появилось свободное время, и я решил поразмять мозги, написать несколько прототипов разных вариантов загрузки. Без всяких наворотов типа украденных байт, виртуализации, морфинга, защиты памяти, мостов на импорт и так далее. Сейчас не стоит задача переплюнуть VMP или Themida, хотя с моим текущим уровнем знаний это вряд ли получится сделать, но смысл думаю понятен

Запахло индийскими специями )))
Мне кажется антидамп это очень относительная штука, в которой защита никогда не будет 100%
Придумал ты как защитить память (допустим это что-то невообразимо сложное), но процессор то в конечном итоге исполняет и код и доступ имеет к данным, что бы приложение работало как полагается, а значит доступ ко всему этому то есть, просто вопрос времени, как долго это будет ломаться, но отломить можно все

 

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

Тем не менее, в 2022 писать пакер даже для развлечения... вы б ещё вирусами под дос развлекались.

 

Нигде защита не будет 100 процентная, даже аппаратный Intel SGX имел какие-то уязвимости. Вопрос в том, что сейчас смотреть в сторону таких обычных алгоритмов протектора, наверное, мало смысла имеет. Можно подумать над "софтварным анклавом" (с) и нормальной его реализации. Либо над виртуализацией кода.

 

Не верю. Покажи мне ехе с аномальной структурой и проверим. Под аномальной подразумевается секция(и) с необычными характеристиками.

Пакер, протектор. криптор - три разные вещи. У них разные задачи. О протекторе вообще разговора небыло.

 

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

Ну и дальше не верь, секция максимально необычная, энтропия зашкаливает из-за сильного сжатия, в импорте ничего нет, PE максимально не похож на стандартное приложение, и тем не менее как я писал выше было 1\60
То, что пакер протектор и криптор три разные вещи я думаю и младенцу понятно будет, как минимум потому что им дали разные названия, как максимум потому что у них цели разные, но при этом никто не отменял того факта, что их действие глобально схоже, а так же они могут быть скомбинированы, например протектор и пакер, защищает приложение и хорошенько его сжимает, это вообще классика, все современные протекторы кроме защиты еще и пакуют твое детище, что бы оно ужалось в размерах. Крипторы я видел так же со сжатием, когда на выходе получаем файл меньше, чем был с учетом стаба.

--- Сообщение объединено, 7 авг 2022 ---

Разве не было ?

 

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

 

Это тоже ясно, но мои строки наверное снова никому не интересно было прочитать ? Или тут все через строчку читают ?

 

не только лишь через строчку, бро - между строк в основном. иначе - не видать никакого дзена^^

 

Ой, да делай, что хочешь, какие проблемы? Я не против.
На вот, почитай на досуге, гуан, конечно, но может интересно будет:
https://xss.is/threads/64259/
https://xss.is/threads/64508/

 

Rel, ну вот, опять старая, как мир история:

--- Сообщение объединено, 7 авг 2022 ---

почему просто нельзя взять и поставить везде пароли из восьми звёздочек?

 

Там через недельку конкурс должен закончиться, может опять откроют форум для чтения без регистрации.