· Начало · Отвђтить · Статистика · Поиск · FAQ · Правила · Установки · Язык · Выход · WASM.RU · Noir.Ru ·

 WASM Phorum —› WASM.RESEARCH —› AsPack

. 1 . 2 . >>

Посл.отвђт Сообщенiе


Дата: Май 9, 2004 21:14:22

Решил поисследовать алгоритм работы аспака.
Взял файл, запаковал этим самым аспаком, помедитировал некоторое время под отладчиком,
Отследил процедуру распаковки, сдампил каждую распакованную секцию на диск.
Функция распаковки принимает на вход адрес памяти, куда будет распакована секция и её размер.

Затем я сверил полученные секции с исходными(которые в незапакованном файле), один к одному.
Все, кроме ресурсов. AsPack при паковке отбросил небольшую их часть.
Взяв PE Header от запакованного файла и секцию ресурсов, я соединил все это(.rsrc выдрал из
незапакованного) и начал колдовать в PE Editor'e:

Нужно было определить Virtual Offset, Raw Size, Raw Offset. Тут затруднений не возникло.

+-------+--------------+----------------+----------+------------+
|Name | Virtual Size | Virtual Offset | Raw Size | Raw Offset |
+-------+--------------+----------------+----------+------------+
|.text | ? | 1000 | 61000 | 1000 |
|.rdata | ? | 62000 | 17000 | 62000 |
|.data | ? | 79000 | 6000 | 79000 |
|SINGLE | ? | 83000 | 1000 | 7F000 |
|.rsrc | ? | 84000 | 23000 | 80000 |
+-------+--------------+----------------+----------+------------+

Raw Size - параметр функции unpack.
Raw Offset, Virtual Offset - вычисляются.

Осталось Virtual Size. Я поставил его равным Raw Size:

+-------+--------------+----------------+----------+------------+
|Name | Virtual Size | Virtual Offset | Raw Size | Raw Offset |
+-------+--------------+----------------+----------+------------+
|.text | 61000 | 1000 | 61000 | 1000 |
|.rdata | 17000 | 62000 | 17000 | 62000 |
|.data | 6000 | 79000 | 6000 | 79000 |
|SINGLE | 1000 | 83000 | 1000 | 7F000 |
|.rsrc | 23000 | 84000 | 23000 | 80000 |
+-------+--------------+----------------+----------+------------+

Файл не запустился(другую инфу я брал из незапакованного файла).
Я заглянул в незапакованный файл.

В нем Virtual Size = 9F68
|.data | 9F68 | 79000 | 6000 | 79000 |

Опытным путем я обнаружил, что Virtual Size секции .data изменяется(можно поставить) в пределах:
9000 >= Virtual Size <= A000. Тут я застрял.

Можно ли вычислить Virtual Size секции .data ?
Или Aspack при сжатии файла все же сохраняет некоторую инфу из PE заголовка?
Такую например как: Size Image, RVA и Size Import Table и IAT.


Дата: Май 9, 2004 22:28:14

9000 инициализированных данныХ, плюс 1000 не-инициализированных
я бы просто огруглял VirtualSize до следущей секции (SINGLE), а если секции последния тогда до SizeOfImage


Дата: Май 9, 2004 22:43:12

ozzman

А ты хоть читал что-нибудь по теме, если задаешь такие вопросы?


Дата: Май 9, 2004 23:43:45

volodya
>А ты хоть читал что-нибудь по теме, если задаешь такие вопросы?

Ага.
Вобщем чтобы узнать VirtualSize секции мне нужен IMAGE_SECTION_HEADER.
А IMAGE_SECTION_HEADER находится в заголовке незапакованного файла.
Предположим он мне недоступен, следовательно надо ещё покопаться во внутренностях AsPack.

у-у-у-пс, пардон, вспомнил про первую часть статьи про упаковщики, ушел читать...


Дата: Май 10, 2004 00:05:53

Выдержка из статьи:

Тогда возникает вопрос - откуда брать VirualSize?
Рекомендуется использовать значение поля SizeOfRawData, выровненное по SectionAlignment.
Ниже указан макрос на C++ для выравнивания секции по SectionAlignment:

#define RALIGN(dwToAlign, dwAlignOn) ((dwToAlign % dwAlignOn == 0) ?
dwToAlign : dwToAlign - (dwToAlign % dwAlignOn) + dwAlignOn)

SizeOfRawData секции дата: 6000, выравнивание: 1000, макрос вернет 6000.
До 9000 как-то недотягивает :(


Дата: Май 10, 2004 00:37:23

Отследил процедуру распаковки, сдампил каждую распакованную секцию на диск.

Начнем с того, что с тобой общаться я начну только тогда, когда вторую часть прочитаешь и сдампишь именно так, как показано там :) Вот если и тогда не получится, тогда бум подумать :)


Дата: Май 10, 2004 16:02:34

Вобщем-то, я изучил работу аспака.
Я принципиально не хотел смотреть 2-ю часть статьи про упаковщики, пока не пойму все сам,
но все же пришлось: из-за дампа. Автоматические дамперы непонятным образом высчитывают VA секций.
А мне хочется все ручками - дампить посекционно.

Появились несколько вопросов:

1) В аспаке распакованный код каждой секции копируется затем по адресу(VA) секции.
Я много слышал про stolen bytes в аспре, но сам аспр не распаковывал, и меня вопрос, даже
не вопрос, а предположение: если в аспре распакованный код каждой секции копируется
по VA секции, но не весь, некоторые байты искажены, и лишь затем, ниже в коде недостающие байты
докопируются на свои места. Снятый дамп соответственно не работает.
Данные спертые байты и называются stolen bytes. Я прав?

2) Все ли пакеры оставляют секцию импорта не тронутой, как в аспаке?


Дата: Май 10, 2004 18:07:37

Касательно 1 - теперь уже не все так однозначно. Вырипываются байты и из API-вызовов, и из OEP и т.п. Тут прогресс далеко ушел вперед, а за аспротектом я не слежу совсем. Отправляю тебя на xtin.org/woodman.com - там ты найдешь ответы на любые возможные вопросы по аспротекту.
Касательно 2 - разумеется, нет. Все ее корежат.


Дата: Май 10, 2004 21:09:04

Кстати, как там поживает третья часть статьи?


Дата: Май 10, 2004 21:14:51

Устал я. :(
А что, народ еще хочет?


Дата: Май 10, 2004 23:35:16

Не могу отвечать за всех, но мое мнение - первые две статьи - это наилучшая, наиподробнейшая и наинтереснейшая инфа в рунете про упаковщики, PE и т.д. А третья статья, должна быть вообще "хитом", про протекторы.
А ты говоришь устал. Если нужно, могу помочь с описанием аспротекта. Правда его копать только сегодня начал: с древней версии 1.1b. Под описанием понимаю полный разбор алгоритма работы. После того, как разберусь с 1.1 версией, начну копать более свежие.


Дата: Май 11, 2004 00:36:43

Хех. Я учту. Спасибо за предложение. Я подумаю.


Дата: Май 14, 2004 15:24:41

volodya
Блин !!!! Ждем тут паждём понимаешь !!! Надеемся, понимаешь, надеемся .


Дата: Май 14, 2004 21:51:55 · Поправил: Godness

To CARDINAL & ozzman

volodya конечно молоток!, но и самим бы надо разбираться ;). А то все где статья... где статья

... без обид


Дата: Май 23, 2004 03:00:54

округленный virtual size всегда равен разнице va следующей и текущей секций. неокругленный может быть меньше на Section Alignment - 1, если v_sz будет уменьшен на больную величину (т.е. nextSection.va - mySection.va >= v_sz + Section Alignment) файл не загрузиться, т.к. в нем будет дыра, а дыра - это кролик ;)
последний virtual size вычисляется либо на основе image size (если он известен), либо берется от балды, но с запасом...
вообще же говоря, для восстанавления файла заголовк на хрен не нужнен! просто читаем паямть пока дают читать, средствами оси определяем атрибуты страниц (хотя можно и не определять, а присвоить все, что есть), затем самостоятельно бьем на секции и кидаем в дамп.
если обнаружим длинную последовательность нулей, то размещаем секции так, чтобы она попала на конец секции, и урезаем raw size, чтобы файл был более компактен.
правда, придется еще вручную воостанавливать импорт, это можно сделать либо так: смотрим какие dll'и загрузил процесс, определяем адреса экспорируемых ими функций, затем пытаемся найти их в файле. если много-много адресов будут сосредоточены в одном месте - то это 100% IAT.
остальное - дело техники.

. 1 . 2 . >>


Powered by miniBB 1.6 © 2001-2002
Время загрузки страницы (сек.): 0.057