Инжектирование dll. Жизнь через DllMain .

Как известно ,многие "полезные" r-3 утилиты существуют в виде dll . Которая привязывается к чужому процессу , например iexplorer.exe .
Азмъ уже прочел главы Рихтера , насчет длл .
Но не могу измыслить метода , которым они там существуют .
Ведь , как помню , после вызова dll приостанавливаются ВСЕ треды , до окончания DllMain .
И , стало быть , реализовать цикл нельзя , ибо повиснет процесс .
Мыслю , что можно поставить локальных хуков , и из них вызывать функции dll в случае событий. Но всеравно не ясно , как сделать
функционал , который требует циклов .
Например если открыть сокет , тогда его нужно постоянно опрашивать , черт знает как .
Я чего-то упустил в картине мира , или все так и есть и нужно извращаться с хуками ?

 

где ты это прочитал?

CreateThread

 

Т е таки не все останавливаются ?
Ну значит не так понял великого Рихтера . Извратил писание его . Сделал ложью слова истины его .
Благодаствую , досточтимый брат в asm'e , rain. Ты двумя строками отвратил меня от ереси .

 

Насколько помню у Рихтера было о том что нельзя вызывать из DllMain функции, которые могут потребовать подгрузку других DLL. Соотвественно CreateThread к ним не относится, ибо она сидит в kernel32.dll которая уже загружена. А уже в функции треда таких ограничений нет.

 

А что случится?

 

loadlibrary подгружает из дллмэйн нормально либы.

 

Код (Text):

1. int WINAPI DllMain( HANDLE, DWORD, LPVOID )
2. {
3.     __asm int 3;
4.     HMODULE hDll = LoadLibrary("comctl32.dll");
5.     return TRUE;
6. }

все нормально

 

Заранее извиняюсь за большой объём цитирования, но, вряд ли у меня получится сказать лучше автора.

Код (Text):

1. BOOL WINAPI DllMain(HINSTANCE hinstDll, DWORD fdwReason. LPVOIO flmpLoad) {
2. HANDLE hThread;
3. DWORD dwThreadld;
4. switch (fdwReason) {
5.     case DLL_PROCESS_ATTACH:
6.         // DLL проецируется на адресное пространство процесса
7.         // создаем поток для выполнения какой-то работы
8.         hThread = CreateThread(NULL, 0, SomeFunction, NULL, 0, &dwThreadId);
9.         // задерживаем наш поток до завершения нового потока
10.         WaitForSingleObject(hThread,INFINITE);
11.         // доступ к новому потоку больше не нужен
12.         CloseHandle(hThread);
13.     break;
14.     case DLL_THREAD_ATTACH:
15.         // создается еще один поток
16.     brеак;
17.     case DLL_THREAD_DETACH:
18.         // поток завершается корректно
19.     break;
20.     case DLL_PROCESS_DETACH:
21.         // DLL выгружается из адресного пространства процесса
22.     break;
23.     }
24. return(TRUE);
25. }

 

roman_pro
Здесь кодер сам себе злобный буратино, а не козни системы. Да и цитата эта к вопросу о создании потока в DllMain, а не к LoadLibrary.

 

тут конечно, Рихтер загул.

вот сижу и думаю, какая информативная тема...

 

IceStudent
По поводу LoadLibrary меня проглючило, ибо помнил только что вызовы DllMain упорядочиваются. Вот теперь освежил память и понял что ничего преступного в LoadLibrary в DllMain нет, для чистоты совести проверил - всё грузится. Так что иногда лишняя информация только вредит

 

преступного ничего нет и все отрабатывает но microsoft нерекомендует

 

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