Здравствуйте,

очень недавно начал осваивать эту интересную тему реверсинга, и вот
на данный момент не могу понять некоторую, так сказать, теоретическую
вещь:

1. вот у нас есть некоторый исполняемый файл, накрытый неким протектором
2. мы его запускаем, системный загрузчик создает новый процесс и т.п.
3. на опр. место в адресном пространстве процесса отображается этот
исполняемый файл
4. так же в адресное пространство загружаются иные необходимые библиотеки
5. выполнение программы начинается с EP, и первым делом запускается код протектора
6. он выполняет распаковку программы, после чего начинает выполняться сама
распакованная программа

Собственно вопрос: если у нас в адресное пространство изначально загружен запако-
ванный образ программы, куда протектор помещает распакованный код программы?
По идее, в адресном пространстве в результате распаковки должны быть в итоге 2 образа:
один еще запакованный, а другой распакованный где-то в изначально свободном месте
адресного пространства, так ли это?

Заранее, спасибо!

| Сообщение посчитали полезным:

daloki пишет:
6. он выполняет распаковку программы, после чего начинает выполняться сама
распакованная программа
не факт

| Сообщение посчитали полезным:

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

-----
Everything is relative...

| Сообщение посчитали полезным:

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

| Сообщение посчитали полезным:

daloki
Протектор может выделять память и распаковывать туда код кусками, выполнять его и приниматься за следующий кусок. В самом файле может быть предусмотрена допсекция с физразмером 0 и нужным виртразмером. Можно и на стеке код исполнить при желании.

-----
старый пень

| Сообщение посчитали полезным:

Есть такое понятие как анти-дамп. В общем случае это методика разрушения привычной PE-структуры образа в памяти. Если мы захотим сделать дамп, мы считываем начиная с базового адреса заголовок, секции (обрезая нули, чтобы физический размер был экономнее) и все это пихается в файл, внося, если требуется, необходимые изменения в PE заголовок (ELF, MACHO - подчеркнуть нужное). Секции обязаны располагаться одна за другой. Там где заканчивается одна секция, начинается другая, после последней секции память не доступна (хотя при желании можно там прилепить еще один кусок виртуальной памяти).

Ну так вот, чтобы этого было нельзя сделать, протекторы стремятся разрушить подобную схему размещения кода и данных в памяти. На это у них есть много уже отработанных методов:

1. Шифрование ресурсов. Протектор может перехватить функции чтения ресурсов, а сами ресурсы убрать куда подальше и зашифровать чтобы жизнь медом не казалась. Обычно протекторы этого не делают (ибо хук не стабильная практика) и в памяти все ресурсы находятся в нормальном виде, и лишь в самом файле программы сжаты.
2. Защита импорта:
2.1 Склеивание адресов разных библиотек в одну кучу. Компиляторы делают таблицу импорта такой, что после перечисления адресов одной библиотеки идет нулевой адрес, затем следующий. Некоторые упаковщики ставят туда 0xFFFFFFFF.
2.2 Перенос всей секции импорта в выделенную память.
2.3 Эмуляция или обфускация вызовов API.
3. Защита исполняемого кода.
3.1. Сплайсинг. Из программы удаляются куски кода, как правило, обфускируются, а затем размещаются в выделенной памяти.
3.2 Виртуальные машины. Разновидность сплайсинга. Обфускация через виртуальную машину.
3.3 Наномиты. Эмуляция переходов или других не сложных инструкций. Псевдо виртуальная машина, реализованная через обработку исключений. На место вырезанной инструкции вставляется инструкция вызвающая исключение. Исключение обрабатывается защитными механизмами и правится контекст.
3.4 Шифрование по ключу. В этом случае на месте оригинального кода стоит вызов процедуры расшифровки, а ключи могут быть где-то в памяти, или привязаны к переменным (например, ID процесса или потока). Делаем дамп - получаем не рабочие процедуры. Secured Sections армадилы я сюда не отношу, т.к. в случае дампа зарегистрированная программа содержит нормальный расшифрованный код на своем месте. Т.е. это нельзя считать анти-дампом. А вот CopyMEM ||, про который мне напомнил r_e, это оно и есть. Но там шифруются не процедуры, а страницы памяти целиком. Чтобы не допустить чего плохого, зашифрованные страницы имеют атрибуты не позволяющие читать/писать/исполнять код на этих страницах. При обработке исключений, нужные страницы расшифровываются не надолго.
3.4 Защита кода через проверки переменных окружения. Сюда можно отнести вызовы CPUID, проверка Process ID, Thread ID (то о чем я упомянул в предыдущем пункте). В случае дампа в лучшем случае программа сможет работать только на этой машине, в худшем - не сможет работать вообще.
4. Защита данных. Слабо знаком с этой темой. Но смысл в том, что защита берет на себя API для доступа к данным. Это может быть целая виртуальная файловая система. Защита держит некий архив данных для программы и отдает их по приказу через API вызовы защиты. Убираем защиту - теряем данные.

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

Добавлено спустя 6 минут
Vamit пишет:
любой протектор вешается на уже собранный рабочий код
Есть протекторы, которые вставляют свой код ДО компиляции.

| Сообщение посчитали полезным: daloki, sendersu, Abraham, sivorog

Спасибо, весьма обстоятельно ответили, это наводит некоторый порядок в голове, и как оказалось не все так просто

| Сообщение посчитали полезным:

Если б все было просто - чем бы мы тут занимались?

-----
старый пень

| Сообщение посчитали полезным: Abraham