Declare и FreeLibrary, или еще раз о вызовах DLL

[0xy]

Предполагается проделать следующее:
1) сохранить dll в TEMP;
2) вызвать ейную функцию через Declare;
3) при закрытии проги, убить DLL в TEMP.

Для обеспечения п.3, DLL необходимо выгрузить из памяти.
Вопросы:
1. Если DLL задекларирована в модуле формы:
a) выгрузит ли ее VB (VBA) при закрытии этой формы?
б) если да, то существует ли событие для формы, возникающее уже после выгрузки DLL?

2. Насколько корректно такое "ручное решение"

Declare sub UserSub Lib "UserDLL"()
'-----------------------------------------
Dim hDLL&
hDLL=LodrLibrary "UserDLL"
Call UserSub
While FreeLibrary(hDLL)
Wend
При обращении к выгруженой DLL, VB тупо падает (что вполне естественно).
Но можно ли быть увереным в отсутствии других проблем?

[Хакер]

. Если DLL задекларирована в модуле формы:
a) выгрузит ли ее VB (VBA) при закрытии этой формы?
б) если да, то существует ли событие для формы, возникающее уже после выгрузки DLL?

Нет, не выгрузит.

2. Насколько корректно такое "ручное решение"

Declare sub UserSub Lib "UserDLL"()
'-----------------------------------------
Dim hDLL&
hDLL=LodrLibrary "UserDLL"
Call UserSub
While FreeLibrary(hDLL)
Wend
При обращении к выгруженой DLL, VB тупо падает (что вполне естественно).
Но можно ли быть увереным в отсутствии других проблем?

Некорректно. Работает, но очень грубый метод.

Можно воспользоваться той информацией, которую я писал, сделать Free для хендла из таблицы, занулить указатель на функцию, попробовать удалить библиотеку. Если получится — хорошо, если не получится (где-то ещё остался «незакрытый» хендл), делаем заявку на отложенное удаление.

Вообще, зачем надо удалять библиотеку?

[Денис]

Вообще, зачем надо удалять библиотеку?

Ну как же. Это вновь псевдо-одиночные программы, дискеточно-флешечные.

[Antonariy]

Вообще нужно предусматривать функционал, который позволяет однозначно управлять поведением и определять состояние библиотеки. Я так делал при разработке модульной com-архитектуры.
1) LoadLibrary
2) CreateObject
3) …
n-2) Обнуление всех ссылок
n-1) FreeLibrary
n) Разрегистрация и удаление при необходимости.

Все работало.

[Twister]

1) LoadLibrary

Но правильнее было бы GetModuleHandle -> LoadLibrary

[jangle]

Предполагается проделать следующее:
1) сохранить dll в TEMP;

Уже на этом этапе твоя программа развалится, когда запустят 2 экземпляра приложения. Второй экземпляр попытается сохранить DLL которую использует первый экземпляр и обломается. Или первый экземпляр вызовет функцию из DLL думая, что она сохранена в TEMP а ее данный момент ее перезаписывает второй экземпляр... Короче куча подводных камней.
Я в таких случаях прошиваю DLL внутрь экзешника и вызываю ее из памяти, без сохранения на диск. Т.е. делаю динамическую библиотку - статической. Но такие трюки тебе еще не по-плечу.

[0xy]

jangle

Предполагается проделать следующее:
1) сохранить dll в TEMP;

Уже на этом этапе твоя программа развалится, когда запустят 2 экземпляра приложения. Второй экземпляр попытается сохранить DLL которую использует первый экземпляр и обломается. Или первый экземпляр вызовет функцию из DLL думая, что она сохранена в TEMP а ее данный момент ее перезаписывает второй экземпляр...

Все верно, но не актуально (либа сохраняется не тупо в темп, а в TEMP\RND, да и запускать второй экземпляр не предвидится.)

Я в таких случаях прошиваю DLL внутрь экзешника и вызываю ее из памяти, без сохранения на диск. Т.е. делаю динамическую библиотку - статической. Но такие трюки тебе еще не по-плечу.

Пожалуй, это было бы оптимальным решением (сам об этом думал).
Касательно реализации--вижу одну сложность--с заполнением импорта dll. Любопытно, как ты решил этот вопрос? Да и все остальное (релокацию dll и прикручивание ее к exe) ты делаешь вручную, или процесс автоматизирован?

PS
Походу вопрос: можно ли через Declare вызвать функцию из своего собственного экпорта (exe)?

[Antonariy]

Похоже по плечу

[jangle]

Уже на этом этапе твоя программа развалится, когда запустят 2 экземпляра приложения. Второй экземпляр попытается сохранить DLL которую использует первый экземпляр и обломается. Или первый экземпляр вызовет функцию из DLL думая, что она сохранена в TEMP а ее данный момент ее перезаписывает второй экземпляр...Все верно, но не актуально (либа сохраняется не тупо в темп, а в TEMP\RND, да и запускать второй экземпляр не предвидится.)

В таком случае, непонятно почему нельзя положить DLL просто рядом с EXE?

Касательно реализации--вижу одну сложность--с заполнением импорта dll. Любопытно, как ты решил этот вопрос? Да и все остальное (релокацию dll и прикручивание ее к exe) ты делаешь вручную, или процесс автоматизирован?

Почему только импорта? Тебе еще секцию экспорта обработать прийдется. Получить адреса экспортируемых функций, и заменить их своими врапперами (если хочешь сделать красиво) вызывая функции из DLL по указателю. Импорт обрабатываешь стандартно через LoadLibrary/GetProcAddress , а если DLL неявно слинкована с другой, то можно и эту вторую DLL тоже прошить внутрь EXE, настраивая импорт "первой" через врапперы My_LoadLibary/My_GetProcAddress, ну это уже высший пилотаж. К сожалению, я все это делал на PB а не на VB, но нет никаких принципиальных ограничений против Visual Basic. За исключением самого процесса "зашивания" DLL, отсуствие встроенного ассемблера не позволяет перегнать DLL в набор ассемблерных инструкций:

Код: Выделить всё

! db &HE2,&HF5,&H3F,&HAF,&HAC,&HAF,&HAF,&HAF,&HAB,&HAF,&HAF,&HAF,&H50,&H50

Прийдется "прошивать" DLL или в ресурсы, или создавать новую секцию в скомпилированном VB-экзешнике и в нее записывать DLL.
Что довольно неудобно...

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

А что касается автоматизации, то есть платная утилита MoleBox которая делает все выше описанное автоматически. Склеивает экзешник с DLL`ками, а потом прозрачно вызывает их из памяти, без сохранения во временную папку.

PS
Походу вопрос: можно ли через Declare вызвать функцию из своего собственного экпорта (exe)?

На VB нельзя. Поскольку этот компилятор не умеет создавать секцию экспорта и импорта в генерируемом PE файле. За исключением разумеется стандартного экспорта COM DLL, и стандартного импорта MSVBVM60.DLL

[Хакер]

jangle, хватит говорить глупости.

[jangle]

jangle, хватит говорить глупости.

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

[0xy]

jangle

непонятно почему нельзя положить DLL просто рядом с EXE?

Можно, но не удобно.

А что за это бредовый код:

Код: Выделить всё

00410E76    ^\E2 F5       LOOPD SHORT 00410E6D
00410E78      3F            AAS
00410E79      AF            SCAS DWORD PTR ES:[EDI]
00410E7A      AC            LODS BYTE PTR DS:[ESI]
00410E7B      AF            SCAS DWORD PTR ES:[EDI]
00410E7C      AF            SCAS DWORD PTR ES:[EDI]
00410E7D      AF            SCAS DWORD PTR ES:[EDI]
00410E7E      AB            STOS DWORD PTR ES:[EDI]
00410E7F      AF            SCAS DWORD PTR ES:[EDI]
00410E80      AF            SCAS DWORD PTR ES:[EDI]
00410E81      AF            SCAS DWORD PTR ES:[EDI]
00410E82      50            PUSH EAX
00410E83      50            PUSH EAX


MoleBox, к сожалению, глючит по-черному! Полные версии под 98-й вообще не запускаются, а Lite(или как его там...) пакует вроде нормально, но потом пакованый VB-шный EXE-шник либо не видит вшитой dll, либо падает при ее вызове (через Declare)--зависит от номера версии.
Если есть нормальный MoleBox--поделись

Впрочем, возможно мы друг друга не поняли
Я представляю себе это так:
1) делаем релокацию DLL под нужный нам ImageBase (к примеру, 600000), удаляем релоки и получаем "статическую либу";
2) записываем все секции dll в хвост exe (после его секций) и отражаем этот факт в PE-заголовке;
3) директорию экспорта (EXE) настраиваем на экспорт dll (Хакер, подскажи, так можно ли декларить самого себя?);
4) обеспечиваем выполнение кода EP dll перед EP exe;
5) импорт либы, наверное, заполняем вручную (объединять его с импортом exe, ИХМО, намного геморнее);
6) имеем серьезный геморой с ресурсами либы (если таковые присутствуют) , а также с tls и прочими "наворотами" (хотя "прочие" встречаются редко) как быть с этим?

[jangle]

jangle
Можно, но не удобно.

Неудобно только в одном случае, если собираешься использовать чужую DLL без согласия ее автора.
Однако, прошивка ее внутрь EXE не спасет отца демократии от разоблачения. Рано или поздно кто-нибудь
заглянет внутрь экзешника и обман будет раскрыт

А что за это бредовый код:

Код: Выделить всё

00410E76    ^\E2 F5       LOOPD SHORT 00410E6D
00410E78      3F            AAS
00410E79      AF            SCAS DWORD PTR ES:[EDI]
00410E7A      AC            LODS BYTE PTR DS:[ESI]
00410E7B      AF            SCAS DWORD PTR ES:[EDI]
00410E7C      AF            SCAS DWORD PTR ES:[EDI]
00410E7D      AF            SCAS DWORD PTR ES:[EDI]
00410E7E      AB            STOS DWORD PTR ES:[EDI]
00410E7F      AF            SCAS DWORD PTR ES:[EDI]
00410E80      AF            SCAS DWORD PTR ES:[EDI]
00410E81      AF            SCAS DWORD PTR ES:[EDI]
00410E82      50            PUSH EAX
00410E83      50            PUSH EAX


?

Код: Выделить всё

MoleBox, к сожалению, глючит по-черному! Полные версии под 98-й вообще не запускаются, а Lite(или как его там...) пакует вроде нормально, но потом пакованый VB-шный EXE-шник либо не видит вшитой dll, либо падает при ее вызове (через Declare)--зависит от номера версии.
Если есть нормальный MoleBox--поделись ;) 

Про последние версии не скажу, но в первой, вместе в VB экзешником и DLL в коробку надо было класть msvbvm.
Зачем тебе Win98? Ты же не пишешь софт для отсталых пользователей, даже M$ прекратила ее поддержку.

Впрочем, возможно мы друг друга не поняли

Статью по ссылке конечно не читал...

Я представляю себе это так:
1) делаем релокацию DLL под нужный нам ImageBase (к примеру, 600000), удаляем релоки и получаем "статическую либу";

Нет настраивать релоки будешь исходя из полученного указателя на PE заголовок DLL, удалять их не надо.

2) записываем все секции dll в хвост exe (после его секций) и отражаем этот факт в PE-заголовке;

Наверное можно сделать и так,я не пробовал. Но проще создать дополнительную секцию в PE файле и записать DLL в нее.
А при старте экзешника вычислять ее смещение, и получать указать на PE Header DLL`ки. Или сохранить DLL в ресурсы,
загружать ее в строковую переменную, и получать указатель на нее StrPtr(VarDll).

3) директорию экспорта (EXE) настраиваем на экспорт dll (Хакер, подскажи, так можно ли декларить самого себя?);

Ничего не надо настраивать в экспорте EXE

4) обеспечиваем выполнение кода EP dll перед EP exe;

Не обязательно, просто перед первым использование функций из прошитой DLL тебе надо
вызвать ее DllMain, примерно так Call EntryPoint (lpImageDosHeader, %DLL_PROCESS_ATTACH, 0) чтобы Dll знала, что она загружена в память, это если ей нужно выполнить инициализацию каких-то своих внутренних переменных.

5) импорт либы, наверное, заполняем вручную (объединять его с импортом exe, ИХМО, намного геморнее);

Не нужно ничего объеденять. Пробегаемся по секции импорта dll, получая имя DLL, функции. Подгружаем их через LoadLibary и заполняем таблицу
адресов функций.
Примерно так:

Код: Выделить всё

While  lpImageImportDescriptor.OriginalFirstThunk <> 0
....
   lpDllName = lpImageImportDescriptor.pName + lpImageDosHeader
     szDllName = lpDllName
     hDll = GetModuleHandle(szDllName)
       'подгружаем DLL прописанную в таблице импорта 
        If hDll = 0 Then hDll = LoadLibrary(szDllName)
...
          lpFuncNameRef = lpImageImportDescriptor.OriginalFirstThunk + lpImageDosHeader
           '--------------------------------
           'настройка адресов функций
           lpFuncAddr = lpImageImportDescriptor.FirstThunk + lpImageDosHeader       
....

      If (lpFuncNameRef And IMAGE_ORDINAL_FLAG) Then
             lpFuncAddr = GetProcAddress(hDll, ByVal lpFuncNameRef And &HFFFF)
        Else
          lpFuncAddr = GetProcAddress(hDll, lpImageImportByName.ImpName)
  .........     
                 lpFuncAddr=lpFuncAddr+1
                 lpFuncNameRef=lpFuncNameRef+1
           Wend                       


6) имеем серьезный геморой с ресурсами либы (если таковые присутствуют) , а также с tls и прочими "наворотами" (хотя "прочие" встречаются редко) как быть с этим?

С ресурсами DLL никаких проблем не будет. Она их найдет.

P.S. Готовый пример на С++ посмотри по этой ссылке: http://www.rsdn.ru/forum/src/501167.flat.aspx

[0xy]

Неудобно только в одном случае, если собираешься использовать чужую DLL без согласия ее автора.
Однако, прошивка ее внутрь EXE не спасет отца демократии от разоблачения. Рано или поздно кто-нибудь
заглянет внутрь экзешника и обман будет раскрыт

Да, но ЗАКОННО заглянуть внутрь exe-шника непросто
Хотя моя цель пока совершенно мирная...

MoleBox, к сожалению, глючит по-черному! Полные версии под 98-й вообще не запускаются, а Lite(или как его там...) пакует вроде нормально, но потом пакованый VB-шный EXE-шник либо не видит вшитой dll, либо падает при ее вызове (через Declare)--зависит от номера версии.
Если есть нормальный MoleBox--поделись

Про последние версии не скажу, но в первой, вместе в VB экзешником и DLL в коробку надо было класть msvbvm.

ЖЕСТЬ! Может ему еще и kernel положить

Зачем тебе Win98? Ты же не пишешь софт для отсталых пользователей, даже M$ прекратила ее поддержку.

Совместимость--правило хорошего тона. Даже 1% клиентов не бывает лишьним

Впрочем, возможно мы друг друга не поняли

Статью по ссылке конечно не читал...

Да, статью прочел позже.
Хотя мой метод существенно отличается от описаного в статье: он намного менее универсален (по сути, заточен на вшивание единственной dll), но в некоторых случаях (если у dll нет ресурсов "и пр. наворотов") реализуется намного проще.
Т.е. в моем случае, секции dll грузит в память загрузчик exe. Правда, он почти ни чего не знает о PE-заголовке dll, со всеми вытекающими...
И ресурсы dll, по-моему, таки не найдет (ибо не сможет узнать свой хендл).
В статье, как я понял, эта проблема решается методом интеграции с конкретным языком, что для меня мутновато (кстати, почему у них не работает GetProcAddress--я так и не понял). Я же попробую просто перехватить GetModuleHandle.

А С++ для меня, к сожалению, язык иностранный.

[jangle]

Выложи свою dll на форум попробую ее прошить в экзешник (pb кодом), если все получится тебе останется только перевести исходник на VB

[0xy]

jangle
Спасибо, в этом пока нет необходимости.
А вот от готовой процедуры заполнения импорта я бы не отказался (хоть на каком-нибудь бейсике)

PS
А на счет "проблемы" ресурсов я таки ошибался--ее не существует
Так что, теперь рецепт должен работать:
1) делаем релокацию DLL под нужный нам ImageBase (к примеру, 600000), удаляем релоки и получаем "статическую либу";
2) в хвост exe (после его секций), записываем (в виде отдельной секции) PE-header dll, а затем все остальные ее секции, и отражаем этот факт в PE-заголовке (exe);
3) ставим в заголовке exe ссылку на директорию экспорта dll (можно не делать, но это должно позволить вызывать функции dll как "свои": Declare Function DllFnXXX Lib "proga.exe");
4) делаем ПРАВИЛЬНЫЙ вызов DllMain:

примерно так Call EntryPoint (lpImageDosHeader, %DLL_PROCESS_ATTACH, 0)

5) заполняем импорт либы (это ЕДИНСТВЕННОЕ, что мы делаем вручную ;
6) NOP;
7) ?А если в либе есть TLS--будет работать?


PPS
А вообще, надо бы глянуть, как это делает MoleBox. Любопытно: работают ли GetModuleHandle/GetProcAddress в его исполнении?

[Хакер]

Автор, а зачем тебе такой изврат с выносом экспортов dll в экспорты exe?

[jangle]

jangle
А вот от готовой процедуры заполнения импорта я бы не отказался (хоть на каком-нибудь бейсике)

Могу выложить рабочий сэмпл, например с прошитым архиватором zlib.dll внутри экзешника.

[0xy]

Автор, а зачем тебе такой изврат с выносом экспортов dll в экспорты exe?

это должно позволить вызывать функции dll как "свои": Declare Function DllFnXXX Lib "proga.exe"

Хотя способ, конечно, корявый.
По-хорошему, надо бы зарегистрировать "модуль" в структурах Винды, чтобы его увидела GetModuleHandle (или просто захучить последнюю) . Но я не знаю, как это сделать.

[Хакер]

По-плохому.

[0xy]

Хакер
Ну, тогда, пожалуй, лучше вообще отказаться от этой затеи.

Собственно, вариант с сохранением dll в TEMP на порядок проще, да и надежнее.

[0xy]

Походу, кто-нибудь знает, как в Win 9x сделать надежный ЛОКАЛЬНЫЙ хук Api? Cплайсинг там не рулит (перехват получается глобальным)

[arthur2]

Cплайсинг

А что это?

Походу, кто-нибудь знает, как в Win 9x сделать надежный ЛОКАЛЬНЫЙ хук Api?

Так же, как и везде:
SetWindowsHookEx

[Twister]

А что это?

Получение контроля над кодом путем его перенаправления на свой обработчик.

Так же, как и везде:
SetWindowsHookEx

Это совсем не то, о чем говорит Oxy. Он имел ввиду не установку оконных хуков, а локальный сплайсинг в 9х.

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

[jangle]

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

Это в какую другую сторону? Новый способ загрузки DLL изобрел?

[Twister]

Новый способ загрузки DLL изобрел?

Вот именно что нет Зачем изобретать велосипед, когда все уже реализовано системой? Я выше немного неверно выразился - в другую сторону ковырять не надо, надо просто ковырнуть глубже. Скорректировать импорт и релоки дело плёвое, код хоть сейчас могу дать. А вот заставить библиотеку быть библиотекой... Для этого модуль как минимум должен быть зарегистрирован в PEB_LDR_DATA (иначе первый же антивирь/антируткит начнет дико орать на такую dll). Руками я этого не делал, да и не рекомендую. Так же надо не забыть уведомить все другие модули о загрузке новой dll.

Вполне реализуемым решением может быть написание собственной LdrLoadDll(), используя при этом готовые функции из ntdll. Благо в ней используется не так уж много неэкспортируемых/недокументированных функций и переменных. Все что надо, это RtlCreateActivationContext(), RtlActivateActivationContext(), LdrpAttachProcess() и критическая секция Peb->LoaderLock.

[jangle]

Новый способ загрузки DLL изобрел?

Вот именно что нет Зачем изобретать велосипед, когда все уже реализовано системой? Я выше немного неверно выразился - в другую сторону ковырять не надо, надо просто ковырнуть глубже. Скорректировать импорт и релоки дело плёвое, код хоть сейчас могу дать. А вот заставить библиотеку быть библиотекой... Для этого модуль как минимум должен быть зарегистрирован в PEB_LDR_DATA (иначе первый же антивирь/антируткит начнет дико орать на такую dll). Руками я этого не делал, да и не рекомендую. Так же надо не забыть уведомить все другие модули о загрузке новой dll.

Вполне реализуемым решением может быть написание собственной LdrLoadDll(), используя при этом готовые функции из ntdll. Благо в ней используется не так уж много неэкспортируемых/недокументированных функций и переменных. Все что надо, это RtlCreateActivationContext(), RtlActivateActivationContext(), LdrpAttachProcess() и критическая секция Peb->LoaderLock.

Какой ужос... Ничего не понял, но видимо что-то сложное для понимая.. Не для средних умов короче ))

[Twister]

Не для средних умов короче

Да ладно, я же знаю - ты способный малый. Просто через-чур упрямый иногда.

LdrLoadDll() это последняя экспортируемая функция, которая грузит dll. Все остальное - просто обёртки над ней. Самый-самый native-уровень. Загляни в нее идой, вооружись сорцами винды (в wrk её нет), msdn и все станет ясно.

[jangle]

LdrLoadDll() это последняя экспортируемая функция, которая грузит dll. Все остальное - просто обёртки над ней. Самый-самый native-уровень. Загляни в нее идой, вооружись сорцами винды (в wrk её нет), msdn и все станет ясно.

Пример рабочего кода сможешь выложить?

[Twister]

Пример рабочего кода сможешь выложить?

Эм... Пример рабочего кода чего? LdrLoadDll()? Могу, часа через четыре, как до дома доберусь. Впрочем, если нет сорцев винды, можешь поглядеть в ReactOS, они очень похожи (но только похожи !!!). Если же ты про весь метод, то нет, не выложу.