Вычисление VirtualAddress секции после упаковки EXE файла UPX`ом.

Привет кодерам! У меня такая проблема, имеется EXE файл, в котором я создаю еще одну секцию. В эту секцию записываются данные, которые используются программой. Поскольку создаваемая секция пятая по счету, я вычисляю указатель на нее по такому алгоритму:

Код (Text):

1.  
2. lpImageDosHeader=GetModuleHandle("")
3. lpImageNtHeaders = lpImageDosHeader + @lpImageDosHeader.e_lfanew
4. lpImageSectionHeader = lpImageNtHeaders + Размер(IMAGE_NT_HEADERS)
5.  
6. OffSetCode=lpImageDosHeader+@lpImageSectionHeader[5].VirtualAddress  
7.  
8.  

В OffSetCode у меня лежит указатель на мою секцию, однако если теперь упаковать EXE файл UPX`ом, у меня получиться только две секции: UPX0 и UPX1, а значит lpImageSectionHeader[5].VirtualAddress будет указывать пальцем в небо.



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



_1887029448__section.zip

 

В fasm и msvc можно задать переменную, значение которой будет приравнян к адресу начала секции непосредственно в compile-time. Поскольку используется другой компилятор, то можно поправить сорцы UPX или воспользолваться другим пакером.

 

S_T_A_S_

>В fasm и msvc можно задать переменную ...

А как эту переменную задать в msvc ?

 

А как-нибудь попроще можно? Без правки исходников UPX.

И чтобы можно было на Си реализовать.

 

#pragma section

__declspec(allocate("segname"))

 

А если не секрет, для каких целей нужен адрес начала секции? Если туда пихается что-то вроде PE файла, то его мало смысла использовать отдельную секцию, проще так:

Код (Text):

1. unsigned char  data [] =
2. {
3.     0x4D, 0x5A, 0x90, 0x00, 0x03, 0x00, 0x00, 0x00,
4. /////
5. }

Сконверитить бинарник в C source поможет простейший скрипт

2136074850__bin2cpp.pl

 

А если не секрет, для каких целей нужен адрес начала секции?



Для самодельного компилятора, имеется болванка EXE файла

(stub) в которой создается секция и туда помещается скомпилированный байт-код. Этот stub имеет фиксированный размер и количество секций, и заранее известно, что следующая секция будет иметь VirtualOffset скажем 6000h. А значит stub может получить указатель на байт-код, как сумму хендла приложения и VirtualOffset добавленной секции:



OffSetCode=GetModuleHandle("")+6000h



Но если добавить еще несколько секций с данными, то их VirtualOffset предсказать невозможно,и надо использовать предыдуший алгоритм, который не работает в случае упаковки экзешника UPX`ом.

 

IMHO самое простое решение в этом случае - выделить в болванке место, куда записать все нужные оффсеты при добавлении секций и потом их оттуда считавать (что-то типа дублирования нужной части PE заголовка). Более красивое - компилировать болванку с фиктивными значениями оффсетов на секции, а потом пропадчить нужные места в коде при добавлении секций. Или использовать другой пакер, который сохраняет секции, а не пихает всё в 2, как UPX.



ЗЫ: GetModuleHandle("") - зачем? у экзешников фиксированный адрес загрузки.