Заметил любопытную вещь - при создании потока в удалённом процессе и внедрении в него кода сам процес приостанавливается и ждёт завершения работы вновь созданного потока. Почему так происходит ведь это должен быть отдельный поток? Как это можно обойти?

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

Попробуй SetThreadPriority() с параметром THREAD_PRIORITY_BELOW_NORMAL или THREAD_PRIORITY_LOWEST.

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

Сделал следующим образом:
hThread = CreateRemoteThread(hProcess, NULL, 0,
pfnThreadRtn, pszLibFileRemote, CREATE_SUSPENDED/*0*/, NULL);

SetThreadPriority(hThread, THREAD_PRIORITY_LOWEST);
ResumeThread(hThread);
Во внедряемой dll в функции DllMain стоит просто запуск ShowMessage c одной кнопкой OK. При внедрении в процес Explorer'а несмотря на установленный низкий приоритет вновь создаваемого потока, пока не нажмёшь на кнопку ОК Explorer просто подвисает.

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

Может какой-нибудь MB_TASKMODAL месажбоксу поставил? Сама CreateRemoteThread, естественно, такой проблемы не имеет.

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

Вот код моей DLL:
int WINAPI DllEntryPoint(HINSTANCE hinst, unsigned long reason, void* lpReserved)
{char s[40];
char szProcessName[MAX_PATH] = "unknown";
int res = 0;

if(reason == DLL_THREAD_ATTACH)
{// Get a handle to the process.
HANDLE hProcess = OpenProcess( PROCESS_QUERY_INFORMATION | PROCESS_VM_READ, FALSE, GetCurrentProcessId());

// Get the process name.
if (NULL != hProcess )
{
HMODULE hMod;
DWORD cbNeeded;

if(EnumProcessModules( hProcess, &hMod, sizeof(hMod), &cbNeeded) )
{
GetModuleBaseName( hProcess, hMod, szProcessName, sizeof(szProcessName) );
}
else return 0;
}
else return 0;

CloseHandle( hProcess );


strcpy(s, "Ïðîèçâåäåíà èíêàïñóëÿöèÿ â ïðîöåññ ");
strcat(s, szProcessName);
MessageBox(NULL, s, "Èíêàïñóëÿöèÿ", MB_OK);
}

return 1;
}

Ижектор написан по Рихтеру.

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

Цитата из MSDN:

Warning On attach, the body of your DLL entry-point function should perform only simple initialization tasks, such as setting up thread local storage (TLS), creating objects, and opening files. You must not call LoadLibrary in the entry-point function, because you may create dependency loops in the DLL load order. This can result in a DLL being used before the system has executed its initialization code. Similarly, you must not call the FreeLibrary function in the entry-point function on detach, because this can result in a DLL being used after the system has executed its termination code.

Calling functions other than TLS, object-creation, and file functions may result in problems that are difficult to diagnose. For example, calling User, Shell, COM, RPC, and Windows Sockets functions (or any functions that call these functions) can cause access violation errors, because their DLLs call LoadLibrary to load other system components. While it is acceptable to create synchronization objects in DllMain, you should not perform synchronization in DllMain (or a function called by DllMain) because all calls to DllMain are serialized. Waiting on synchronization objects in DllMain can cause a deadlock.

To provide more complex initialization, create an initialization routine for the DLL. You can require applications to call the initialization routine before calling any other routines in the DLL. Otherwise, you can have the initialization routine create a named mutex, and have each routine in the DLL call the initialization routine if the mutex does not exist.

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

Проблема не в том, что какая-то из функций dll отрабатывает не правильно, а в том, как ведёт себя поток. Да и к данному случаю эта цитата не относится в полной мере, т.к. dllка грузится в уже давно инициализированый процесс со всеми его родными dll

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

Aivengo
Это цитата к функции DllMain, при чем тут инициализация самого процесса?
Если ты вызываешь какой-то сложный код из DllMain, то не факт, что он отработает верно. В другой конфигурации винды сообщения мессаджбокса вообще может быть не будут обрабатываться.
HoBleen пишет:
Waiting on synchronization objects in DllMain can cause a deadlock.
Мб что-нибуть такого плоана происходит.

Aivengo пишет:
а в том, как ведёт себя поток.
Уверен, что именно потоки приостановлены, а не окна не получают свои сообщения?

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

сейчас попробовал заменить весь код dll на sleep(20000)... - таже самая картина...
есть какие-нибудь соображения, как это можно обойти?

ЗЫ:
Спасибо за помощь

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

Попробуй SetTimer(0, 0, 0 /*или свое значение*/, &Proc);

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

сделал
SetTimer(NULL, 0, 200000, NULL);
вообще ничего не происходит... никакой реакции на эту функцию... поток тутже завершается... без предварительного ожидания...

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

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

UINT_PTR SetTimer(
HWND hWnd, // handle to window
UINT_PTR nIDEvent, // timer identifier
UINT uElapse, // time-out value
TIMERPROC lpTimerFunc // timer procedure
);

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

Сделал:

VOID CALLBACK TimerProc( HWND hwnd, UINT uMsg, UINT idEvent, DWORD dwTime)
{
MessageBox(NULL, "Timer", "Èíêàïñóëÿöèÿ", MB_OK);
}

а в DllMain только:
SetTimer(NULL, 0, 200000, (TIMERPROC)TimerProc);

никакой реакции

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

Ну и надо ждать 200 секунд =)
Если и так не работает, можно попробовать и другие методы синхронизации..

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

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

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

А откуда ты знаешь? Мб все так и спланировано - остановка всех потоков до загрузки длл. По идее загрузка ведь не должна быть медленной => ни на кого это повлиять не должно.
Хотелось бы послушать спецов в области архитектуры Windows по этой теме. Она довольно интересная ИМХО.

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

Aivengo пишет:
Ижектор написан по Рихтеру.

Не нашел, где у Рихтера написано про
reason == DLL_THREAD_ATTACH

зато есть:
"На этом этапе DLL внедрена в удаленный процесс, а ее функция DllMam получила уведомление DLL_PROCESS_ATTACH и может приступить к выполнению нужного кода"

Aivengo пишет:
при создании потока фуекцией CreateRemoteThread все остальные потоки в процессе останавливаются до тех пор пока не выполнится этот...
Повторю, что это бред, уж извиняй за прямоту. С CreateThread не возникает подобных проблем, а она реализована как раз через CreateRemoteThread А вот с loader lock'ом постоянно траблы.

Кста, у того же Рихтера есть рабочий пример перечисления имиджей. Только там VirtualQuery, а не EnumProcessModules (а что должна вернуть последняя функцияя _в_процессе_ загрузки модуля? )

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

2S_T_A_S_
Замена DLL_PROCESS_ATTACH на DLL_THREAD_ATTACH не меняет в данном случае ровным счётом ничего кроме того, что момент выполнения кода в данном случае несколько смещается по времени.

Изменение кода DLL до:

#include <vcl.h>
#include <windows.h>
#include "psapi.h"
#pragma hdrstop
#pragma argsused

VOID CALLBACK _export TimerProc(
HWND hwnd, // handle of window for timer messages
UINT uMsg, // WM_TIMER message
UINT idEvent, // timer identifier
DWORD dwTime // current system time
)
{
char s[40];
char szProcessName[MAX_PATH] = "unknown";
int res = 0;

KillTimer(NULL, idEvent);

HANDLE hProcess = OpenProcess( PROCESS_QUERY_INFORMATION | PROCESS_VM_READ, FALSE, GetCurrentProcessId());

// Get the process name.
if (NULL != hProcess )
{
HMODULE hMod;
DWORD cbNeeded;

if(EnumProcessModules( hProcess, &hMod, sizeof(hMod), &cbNeeded) )
{
GetModuleBaseName( hProcess, hMod, szProcessName, sizeof(szProcessName) );
}
else return;
}
else return;

CloseHandle( hProcess );


strcpy(s, "Произведена инкапсуляция в процесс ");
strcat(s, szProcessName);
MessageBox(NULL, s, "Инкапсуляция", MB_OK);
}

int WINAPI DllEntryPoint(HINSTANCE hinst, unsigned long reason, void* lpReserved)
{
if(reason == DLL_PROCESS_ATTACH)//(reason == DLL_THREAD_ATTACH)
{
if(!SetTimer(NULL, 0, 10000, (TIMERPROC)TimerProc))
MessageBox(NULL, "Не могу создать таймер.", "Инкапсуляция", MB_OK);

MessageBox(NULL, "DLL_PROCESS_ATTACH", "Инкапсуляция", MB_OK);
}

return 1;
}
//-------------------------------------------------------------------- -------
ровным счётом ничего не дала... результат тотже, правда не понятно почему функция таймера вызывается только в том случае, если DllMain ещё не завершилась (специально туда MessageBox сунул)... иначе ничего не происходит. Каким образом можно ещё переиграть? Может имеет смысл попытаться после загрузки Dll через CreateRemoteThread вызвать через него же нужную функцию в этой dll? Правда тогда надо будет каким-то образом вычислить её адрес в новом процессе. Если да, то как?

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

Возьми _рабочий_ пример Рихтера. Без всяких #include <vcl.h> (кстати, что это?)

Aivengo пишет:
Может имеет смысл попытаться после загрузки Dll через CreateRemoteThread вызвать через него же нужную функцию в этой dll? Правда тогда надо будет каким-то образом вычислить её адрес в новом процессе
Её адрес вычислять не нужно он известнен. Вместо CreateRemoteThread поёдёт и CreateThread, но это скорее всего лишнее.

9bc6_12.02.2007_CRACKLAB.rU.tgz - 22-ImgWalk.zip

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

компилил под CBuilder... #include <vcl.h> - Visual Class Library... автоматом вставляется...
что-то я не совсем понимаю... почему это лишнее?

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

Лучше убери её то хрен знает что с памятью она делает...

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

Деадлок в загрузчике на LdrpLoaderLock.

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

bowrouco
Да Вы батенька некропостер - уже столько старых тем апнули.

-----
Don_t hate the cracker - hate the code.

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

mysterio
Говорите как будто чтото в в оси изменилось. Как был дедлок тогда так он и в W8 остался.

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

bowrouco
Проблема не в этом, а в том что апаются никому не нужные старые топики.

-----
Don_t hate the cracker - hate the code.

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