LoadLibrary,DllMain,Кто загрулил DLL?

Как узнать хэндл молуля(для вызова "GetProcAddress") загрузившего мою DLL?

Спасибо.

 

Чушь какая-то.

 

гы GetModuleHandle =)

 

Ok, расширим

Допустим, имеется некая программа(например WinAmp) для которой я написал плагин в виде DLL.
Когда WinAmp загружает мой плагин (при помощи LoadLibrary), в моей DLL вызывается функция DllMain
с флагом "DLL_PROCESS_ATTACH", внутри этой функции(DllMain) необходимо узнать хендл модуля
вызывавшего LoadLibrary, для того чтобы используя этот хендл получить(GetProcAddress) и вызвать
несколько функций из молуля загрузившего мою DLL.
Имя исполняемого файла неизвестно, к томуже вызов LoadLibrary и функции которые необходимо вызвать
могут располагатся в другой DLL(а не в EXE).

Возможно ли такое белыми средствами?

 

AlexCab
да, не только белами но и серыми,черными и желтыми.
sl0n уже написал. Если не нравиться то смотрите в PEBе.

 

Ну и какой же параметр надо передать в GetModuleHandle, чтобы узнать кто вызвал LoadLibrary?

AlexCab
Опиши что хочешь сделать, может найдётся нормальный способ. И ещё напиши насколько документированным должно быть решение.

 

--бред противоречивый

--вызываю то не знаю чего не известно откуда =D

 

asd
Я нашол другое решение, но оно менее удобно(пользователю прийдётся конфигурировать вручную), и потому мне интересно возможно ли это?

RET
Известно что функции которые необходимо вызвать находятся(экспортируются)
в том-же модуле(EXE или DLL) что и вызов LoadLibrary.

 

AlexCab
Может так?
Твоя dll

Код (Text):

1. format PE GUI 4.0 DLL
2. include 'C:\fasmw\INCLUDE\win32a.inc'
3.  
4. entry DllMain
5.  
6. section '.code' code readable writeable  executable
7.   proc DllMain hinstDLL,fdwReason,lpvReserved
8.       xor eax, eax
9.       inc eax
10.       ret
11.   endp
12.  
13. proc SomeProc lpWindowName
14. nop
15. nop
16. nop
17. nop
18.     mov eax, [fs:30h]   ; Здесь находиться Peb fs:[eax].TEB.Peb
19.     mov eax, [eax+0Ch]  ; Смещаемся к структуре PEB_LDR_DATA
20.     mov eax, [eax+0Ch]  ; Смещаемся к структуре PEB_LDR_DATA.InLoadOrderModuleList.Flink
21.     mov eax, [eax+18h]  ; В eax базовый адрес загрузки a01.exe <<<<<<<<<!!!!!!!!
22.   ret
23. endp
24.  
25. section '.idata' import readable writeable
26.   library user32,'user32.dll'
27.  include 'C:\fasmw\INCLUDE\APIA\user32.inc'
28.  
29. section '.edata' export data readable
30.   export 'sml.dll',\
31.      SomeProc,'SomeProc'
32.  
33. section '.reloc' fixups data discardable

Ну и в eax получишь базовый адрес загрузки модуля a01.exe
вызвавшего твою sml.dll

 

Зная по каким правилам и каков интервейс, такой подход может быть полезен в некоторых случаях.

AlexCab
Вы не ответили на мой вопрос. Я спросил какова цель всего этого, а не как вы решили её достичь.

 

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

 

Ничем не поможет. Представьте ситуацию:

Код (Text):

1. 1. Загружается test.exe
2. 2. test.exe загружает test_dll.dll
3. 2. test.exe загружает bla_bla_bla_dll.dll
4. 3. test_dll.dll загружает test_dll2.dll

В коде test_dll2.dll нам надо определить, кто "нас" загрузил. Проход по спискам загруженных модулей покажет нам bla_bla_bla_dll.dll, что, очевидно, не является верным ответом.

Верным решением будет анализ стека. Для ХР:
нужно найти первый возврат из LoadLibraryExW в kernel32.dll, это будет отправной точкой. Далее анализ необходимо сделать чуть более "интеллектуальным", т.к. загрузить библиотеку можно разными функциями. Писать долго, думаю картинка всё объяснит нагляднее:

 

Т.к. это плагин, то 100% грузится по LoadLibrary => бряк на LoadLibrary и всё. Если это лишь частный случай, кто мешает написать либу, которая будет грузится до основной длл и отслеживать вызов другой?

 

RET зачем этот гемор, раскрутить стек нормальный вариант, и не сложный.

 

DllMain библиотеки вызывается уже после того, как начнёт работать LoadLibrary. Т.е. внутри загруженной библиотеки этот бряк ничего не даст. Ловить нужно момент выхода из неё, а это всё равно разбор стека для поиска адреса возврата.

Код (Text):

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

Радикальный метод, я бы сказал

 

GetModuleFileName

 

Нда, а вопрос-то интересный! Микрософт дает на поиск "modules currently mapped into the address space of the calling process" практически единственную ссылку, относящуюся к теме:

То есть определяем главного (.exe), получаем список модулей, по каждому модулю опять список модулей, и так пока не найдете ваш. И получите не только одного вызывавшего, но полную информацию о всех используемых dll и порядке их загрузки. Не проверял, но источник надежный =))

 

FatMoon
Я об этом говорил (про пеб) psapi,toolhelpapi и т.д. сведуть ся к RtlQueryProcessDebugInformation и т.п.. Не поможет, как доказал Twister но можно как доп инфу использовать. Здесь или раскрутка стека или контроль со стороны (тот же хук/бряк) из другой либы, загруженной ранее).

 

Не понял, почему не поможет. Если "прочитать последние N через "mov eax, [fs:30h]..." и решить что предшествующая была нашим вызывателем", то не поможет. А если psapi - почему это не поможет?

 

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