Зачем нужны протекторы ?

Прнивет всем. Прочитал тут одну тему и подумал. Большая часть софта накрыта протекторами и все стремяться их снять, распаковав модуль(дамп, восстановление импорта и пр.), так вот зачем это вобще нужно ??
Цепляем к модулю свой загрузчик, в редких случаях даже ядерный, как только поток начнёт выполнять модуль этот загрузчик получит управление, выполнит сокрытие себя, необходимые перехваты для последующего контроля кода и пр., после чего передаст управление на оеп для запуска анпакера в этом модуле, который всё нужную работу выполнит сам. Например можно весь анпакер протрассировать. Реализуется всё это предельно просто. Так для чего нужна распаковка, если учесть что анпакер это часть защищенного модуля ?

 

Clerk
+1 или вовсе навесная долепка.

 

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

 

TSS
Какой есчо граф. Если должна быть выполнена загрузка модуля, то LdrLoadDll() будет полюбому вызван. Мутируйте/виртуализируйте как угодно - всёравно тред будет с ядром и системными модулями общаться, ядерные входы и калбэки не проэмулируешь.

 

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

 

Clerk
А как ты будешь контролировать зашифрованную прогу(патчить?). К тому же ещё нужно понять что патчить.

Да просто, если знаешь все антиотладочные трюки.

 

Виртуализация редко применяется, обычно запустил и распаковывается.
Booster

Я к примеру сказал, трассировате его незачем. А антиотладка - я знаю все существующие приёмы, все альтернативные сам предложил.

 

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

 

все операции записи на исполняемую страницу

 

Clerk
Мы же контролируем не сферического коня в вакууме. Прежде чем что-то прицепить, нужно понять для чего. Против тебя действительно любые антиотладочные приёмы бесполезны, но думаю защита не конкретно AntiClerk.

 

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

 

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

и какова скорость трассировки?
есть подозрение что это займет нереальное количество времени, при том что прога под протом доходит до OEP за единицы секунд

 

Хватит бурлить =) доктор таки распакует ... а для эмулей упаковщики и нужны
вот ответ !

 

GoldFinch

Если трассируется юзермодный код и если трассировщик ядерный выполнен надлежащим образом, то трассировка абсолютно никак не скажется на быстродействии - поверено. Причина этого - код выполняющийся на PASSIVE_LEVEL на довольно длительные промежутки времени замораживается, принудительно отдовая свои кванты другим потокам. Изза этого трассировка незаметна. Существует множество других препятствий, изза которых полноценная трассировка на ядре NT невозможна.

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

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

 

Вопрос приводит к разделению - всякая защита, которая после отработки восстанавливает в памяти образ не может называться защитой. Наверное o14189 прав. Единственное чего не пойму - для чего абсолютно все имеют целью распаковку модуля, что давно перенесено в приват, если задача имеет простое решение - загрузчик прикреплённый к целевому модулю.

 

Clerk
Виртуальная машина это цельная распаковка?

 

Booster
Да. Но это довольно редко применяется, практически весь софт накрыт самораспаковывающимися протекторами.

 

Clerk

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

 

Stiver

Минус производительность. Виртуальная машина здесь предпочтительнее.

 

Stiver
Это только теория, ни легальный софт ни малвара по большей части это не использяет, довольно редко.