Предположим PE файл имеет экспорт. Необходимо ли наличие неупакованной информации об экспорте в файле на диске, либо ничего не мешает, например, DLL-ке распаковать эти данные уже после загрузки в память? Если это не необходимо, то зачем UPX так делает?

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

Promix_17 пишет:
распаковать эти данные уже после загрузки в память
и что тогда, по вашему, будет с файлами, у которых эта DLL находится в импорте?
конечно же -- "Не найдена точка входа в процедуру 'xxxx' в модуле 'yyyy'"

/ADD
просмотрел справку по юпиксу. нашел это


причины, по которым он не трогает DLL, не объясняются, но указана причина, по которой была введена эта опция - совместимость с Wine. Может, в этом дело?

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

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

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

Да это ж проверяется экспериметом за 5 минут. Берём пару ехе + dll, такую, чтоб была статическая линковка, в длл трём таблицу экспорта, а на DllMain лепим вызов мессаджбокса. Запускаем ехе - видим мессадж?

-----
Stuck to the plan, always think that we would stand up, never ran.

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

ARCHANGEL
Отрицательный результат получим - будем знать всё. Если месседжбокс будет, еще неизвестно, смапится ли функция на динамический экспорт. (Типа, если винда делает LoadLibrary->GetProcAddress, то LoadLibrary даст месседжбокс, а вот GetProcAddress может обломаться).

Вообще, вопрос интересный. В 5 утра не осилю написать тест, но если завтра никто не сделает, напишу тест ближе к ночи.

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

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

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

По поводу ручной загрузки: если файл упакован, а точка входа вызываться не будет при загрузке, то толку от экспорта мало - код экспортируемых функций тоже будет упакован и вызывать их просто нельзя. Максимум, что можно извлечь из экспорта без вызова точки входа в упакованном файле - просто получить адреса функций. Но толку от них? Т.е. это очень очень специфическая ситуация, когда экспорт в упакованной длл лучше оставлять.

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

А кто сказал, что они обязательно будут вызываться. Вызов сразу экспорта без вызова точки входа несколько нелогичен. А посмотреть на присутствие функций в экспорте могут вполне. Типа перечислить файлы в директории и поглядеть, какие из них экспортируют плагинные функции, скажем, чтобы составить список плагинов для юзера. А полноценно уже грузить, когда юзер ткнёт на конкретном плагине.
Да, возможно, вариант не часто используется. Но могут быть и другие аналогичные варианты. Чтобы не удивлялись, когда длл отвалится после упаковки.

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

tomac пишет:
Типа, если винда делает LoadLibrary->GetProcAddress, то LoadLibrary даст месседжбокс, а вот GetProcAddress может обломаться

Само по себе - да, но расчёт на то, что внутри DllMain делается реконструкция экспортов.

Archer пишет:
И в любом случае это не спасёт от ситуаций, если кто-то мапит руками или через апи без вызова точки входа и потом ожидает нормальный экспорт.

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

-----
Stuck to the plan, always think that we would stand up, never ran.

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

Некоторый резон не паковать экспорты таки есть. Я сталкивался с косяками. Какая-то из старых виндов (до XP) сначала чекала экспорт, а потом уже тягала DllMain. Скорее всего это было Win2k - оно вообще адово придиралось к исполнимым файлам. Причем в позу вставало вроде не всегда, а только в некоторых случаях (типа это COM dll и регается через RegSvr). Проще оказалось не паковать экспорт, чем разобраться с этим днищем. Продробностей не помню, извиняйте, это было 12 лет назад, когда я делал свой первый пакер.
С другой стороны сейчас это скорее всего уже не актуально, и всё взлетит и с пожатым экспортом. В то время всё через задницу работало, даже .NET с диска себя тупо перечитывал - патчи в памяти сколько хочешь, но исполняться будет то, что на диске

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