AppInit_DLLs не внедряет DLL...А дожно.

Привет.
Есть такая проблема. Моя длл,прописаная в реестре в ключе AppInit_DLLs не внедряется в инсталяторы Wise Installation...
Вернее внедрется,но только в запускаемый ЕХЕ.
Далее,если проследить за работой Wise Installation,он создает файл, к примеру GLBDF.tmp,пишет в него- И запускает процесс с этим именем.
Смотрим через PExplorer (или task manadger-кому как удобно) -появился процесс GLBDF.tmp,он юзает user32.dll-но вот не понятно-почему же не подгружается моя либа?
Конечно,можно было забить на AppInit_DLLs,но другого варианта внедрения в вновь создаваемые процессы -я не вижу.Пробывал перехватом CreateProccess, однако выполнить CreateRemoteThread я могу только после того, как верну выполнение оригинальной функции CreateProccess.А пока выполнится CreateRemoteThread, я много смогу пропустить из вызова функции,неуспев поставить перехват.
Сообственно главный вопрос-кто дурит AppInit_DLLs,и как можно еще внедрится в новый процесс..

 

Только что сделал эксперимент.Создал свой ехе,по нажатию кнопки,происходит создание процесса.Так вот,моя длл вклинивается в ехе,затем нажимаю кнопку- процесс создается (стандартное WIN приложение),а вот в него уже никто не вклинивается.
Никто не появилось новых мыслей?

 

Вообще вот такой вариант конечный.
Если запускаемое приложение (у меня проект MFC) имеет сборку Use MFC in a Shared DLL-я туда НЕ ВНЕДРЯЮСЬ,если Use MFC in a Static Library-внедряюсь..
Хм..И что же может быть виной всему?

 

CreateProcess можешь перехватить, а потом при помощи CreateRemoteThread внедрять в него

 

Rustem,а разве можно,не отпустив (вернув ) оригинальный вызов CrtateProccess внедрится внего.
На голову приходит только такой вариант-перехватить CraeteProceess, запустить его из своего ехе в флагом приостановки, вернуть оригинальной функции результат своего запуска, и опять же у себя внедрится через CreateRemoteThread.
Только вот вопрос-можно ли внедрится в замороженый (приостановленый) процесс?

 

coocky
* по поводу почему не работает AppInit_DLLs читайте разъяснение от ms:
http://support.microsoft.com/kb/197571

* по поводу внедрения в замороженный процесс:
было бы интересно услышать как можно внедрииться в незамороженный процесс, не рискуя при этом порушить его на хрен. там уйма способов, навскидку:
- берем контекст, читаем содержимое памяти под EIP, пишем поверх него свой код, который делает все, что задумано, а потом восстанавливает старое содержимое;
- вариаация предыдущего способа, только сейчас мы читаем ESP, раскручиваем стек, находим адрес возврата и подменяем его указатель на свой код, внедренный тем или иным способом (VirtualAllocEx или через прямую модификацию ненужной/незанятой области памяти)

 

kaspersky Спасибо,где-то в ваших словах заблещела надежда.Где-то в глубине..

Читал,уже и не раз
Увидел всего 2 ограничения.
1.Typically, only the Administrators group and the LocalSystem account have write access to the key that contains the AppInit_DLLs value.
2.Therefore, executables that do not link with User32.dll do not load the AppInit DLLs. There are very few executables that do not link with User32.dll.


USER32.dll-есть в запускаемом процессе (ну верю я PExplorer)
Права-нормальные.Все в реестре записывается.Мало того-в 99% приложений все внедряется..

Немного не понял.А можно ссылочку на код?
Этот метод работает с замороженным процессом?

 

coocky
> Этот метод работает с замороженным процессом?
на всякий случай учтони, что ты имеешь ввиду под замороженным процессом.

> Немного не понял.А можно ссылочку на код?
навскидку пример кода у себя на диске я не найду...
с какого места ты не понял?

* пользоваться ReadProcessMemory/WriteProcessMemory умеешь?

* как работать с GetThreadContext знаешь?

* дескриптор потока получить сможешь?

ок. ладно допустим, не сможешь. и GetThreadContext не хочешь юзать.
да и зачем его юзать. ну ReadProcessMemory/WriteProcessMemory ты
просто обязан уметь пользоваться

находишь в адресном пространстве процесса-жертвы
системную DLL с какой-нидь часто вызывааемой функцией,
делаешь в ее начало jmp на _очень_редко_используемую_функцию_
(ну или в общем случае, на функцию, которой нет в импорте процесса-жертвы,
но тут еще импорт разбирать придется), вот и все...

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

весьма окейный метод.

 

Вообщем все Что ты написал-для меня известно лишь на словах и в общих чертах.
Я вообще хотел делать так.Внедряюсь в приложение,перехватываю CreateProccess,отсылаю своему ехе все поля фукции.
Далее у меня есть код внедрения в процесс,через CreateRemoteThread

Код (Text):

1. BOOL fOk = FALSE; // Assume that the function fails
2.   HANDLE hProcess = NULL, hThread = NULL;
3.   PWSTR pszLibFileRemote = NULL;
4.  
5.     // Get a handle for the target process.
6.     hProcess = OpenProcess(
7.       PROCESS_QUERY_INFORMATION |   // Required by Alpha
8.       PROCESS_CREATE_THREAD     |   // For CreateRemoteThread
9.       PROCESS_VM_OPERATION      |   // For VirtualAllocEx/VirtualFreeEx
10.       PROCESS_VM_WRITE,             // For WriteProcessMemory
11.       FALSE, dwProcessId);
12.     if (hProcess == NULL)
13.     {
14.       if (pszLibFileRemote != NULL)
15.         VirtualFreeEx(hProcess, pszLibFileRemote, 0, MEM_RELEASE);
16.  
17.       if (hThread  != NULL)
18.         CloseHandle(hThread);
19.  
20.       if (hProcess != NULL)
21.         CloseHandle(hProcess);
22.       return FALSE;
23.     }
24.  
25.     // Calculate the number of bytes needed for the DLL's pathname
26.     int cch = 1 + lstrlenW(Dll_name.GetBuffer());
27.     int cb  = cch * sizeof(WCHAR);
28.  
29.     // Allocate space in the remote process for the pathname
30.     pszLibFileRemote = (PWSTR)
31.       VirtualAllocEx(hProcess, NULL, cb, MEM_COMMIT, PAGE_READWRITE);
32.     if (pszLibFileRemote == NULL)
33.     {
34.       if (pszLibFileRemote != NULL)
35.         VirtualFreeEx(hProcess, pszLibFileRemote, 0, MEM_RELEASE);
36.  
37.       if (hThread  != NULL)
38.         CloseHandle(hThread);
39.  
40.       if (hProcess != NULL)
41.         CloseHandle(hProcess);
42.       return FALSE;
43.     }
44.  
45.     // Copy the DLL's pathname to the remote process's address space
46.     if (!WriteProcessMemory(hProcess, pszLibFileRemote,
47.       (PVOID) Dll_name.GetBuffer(), cb, NULL))
48.     {
49.       if (pszLibFileRemote != NULL)
50.         VirtualFreeEx(hProcess, pszLibFileRemote, 0, MEM_RELEASE);
51.  
52.       if (hThread  != NULL)
53.         CloseHandle(hThread);
54.  
55.       if (hProcess != NULL)
56.         CloseHandle(hProcess);
57.       return FALSE;
58.     }
59.  
60.     // Get the real address of LoadLibraryW in Kernel32.dll
61.     PTHREAD_START_ROUTINE pfnThreadRtn = (PTHREAD_START_ROUTINE)
62.       GetProcAddress(GetModuleHandle(TEXT("Kernel32")), "LoadLibraryW");
63.     if (pfnThreadRtn == NULL)
64.     {
65.       if (pszLibFileRemote != NULL)
66.         VirtualFreeEx(hProcess, pszLibFileRemote, 0, MEM_RELEASE);
67.  
68.       if (hThread  != NULL)
69.         CloseHandle(hThread);
70.  
71.       if (hProcess != NULL)
72.         CloseHandle(hProcess);
73.       return FALSE;
74.     }
75.  
76.     // Create a remote thread that calls LoadLibraryW(DLLPathname)
77.     hThread = CreateRemoteThread(hProcess, NULL, 0,
78.       pfnThreadRtn, pszLibFileRemote, 0, NULL);
79.     if (hThread == NULL)
80.     {
81.       if (pszLibFileRemote != NULL)
82.         VirtualFreeEx(hProcess, pszLibFileRemote, 0, MEM_RELEASE);
83.  
84.       if (hThread  != NULL)
85.         CloseHandle(hThread);
86.  
87.       if (hProcess != NULL)
88.         CloseHandle(hProcess);
89.       return FALSE;
90.     }
91.  
92.     // Wait for the remote thread to terminate
93.     WaitForSingleObject(hThread, INFINITE);
94.  
95.     fOk = TRUE; // Everything executed successfully
96.  
97.     // Free the remote memory that contained the DLL's pathname
98.     if (pszLibFileRemote != NULL)
99.       VirtualFreeEx(hProcess, pszLibFileRemote, 0, MEM_RELEASE);
100.  
101.     if (hThread  != NULL)
102.       CloseHandle(hThread);
103.  
104.     if (hProcess != NULL)
105.       CloseHandle(hProcess);
106.   return fOk;

Вообщем Рихтеровская фишка.Вообщем я думал где-то здесь создать CreateProccess с перехвачеными параметрамии флагом CREATE_SUSPENDED,затем внедрится,запуститься и сделать ResumeThread.
Вот и вопрос-можно ли так сделать и если можно-в каких местах? Если можно-подправтье этот код для моей ситуации
Спасибо

 

coocky
код не смотрел.
1) зачаем перехватывать CreateProcess?! какое это имеет отношения к внедрению?! любой перехват потенциально небезопасен в смысле глюков и при этом ты рискуешь огрести по полной от всяких там аверов и фаерв. если стоит задача отследить запуск какого-то конкретного процесса и внедриться в него до начала его выполнения - тогда так прямо и говори.

2) удаленные потоки - ну.... тут вообще ругаются все проактивные сторожа, к тому же они легко отлавливаются. я уже как-то постил сюда утилиту, которая это делает. в смысле находит (и довольно надежно) удаленные потоки, созданные всякой нечисть.

3) посмотрел код по диагонали. под вистой он не будет работать из-за рандомизации адресного пространства и там надо разбирать импорт вручную.

 

kaspersky
Да..Задача в том и состоит,что б внедрится в процесс,до начала его выпонения..
В любой процес,который юзает USER32.dll

Мне под висту и ненадо.Только 2000,и ХР.
Я не играюсь с кодом, это моя работа.И не трояны....
Дело в том, что я тогда и не понимаю,как можно попасть в другой процесс,не перехватив CreateProccess...
Вот что получилось у меня
Итак ,перехватываю создание процесса эксплорером (CreateProccessA и CreateProccessW) c с помощью свое длл и Detours
Вод код функции перехватчика

Код (Text):

1.   if(dwCreationFlags&CREATE_SUSPENDED)
2.   {
3.  ret=  pCreateProccessA( lpApplicationName, lpCommandLine, lpProcessAttributes,lpThreadAttributes, bInheritHandles, dwCreationFlags, lpEnvironment, lpCurrentDirectory,lpStartupInfo,lpProcessInformation);
4.  
5. // передаю dwProcessId в ехе и выполняю внедрение в процесс с помощью выше написаного кода по рихтеру;
6.  
7.   }
8.   else
9.   {
10. dwCreationFlags|=CREATE_SUSPENDED;
11.  
12.  ret=  pCreateProccessA( lpApplicationName, lpCommandLine, lpProcessAttributes,lpThreadAttributes, bInheritHandles, dwCreationFlags, lpEnvironment, lpCurrentDirectory,lpStartupInfo,lpProcessInformation);
13.  
14. // передаю dwProcessId в ехе и выполняю внедрение в процесс с помощью выше написаного кода по рихтеру;
15.  
16.   }
17.  
18. ResumeThread (lpProcessInformation->hThread)
19.  
20. return ret;

Однако многие программы глючат при старте-не до конца инициализируются..
kaspersky мне не важны сторожа или скрытость Мне надо явно внедрится ..И все.. Внедрится в новь создаваемый процесс..

 

В ICE за процесом загрузки понаблюдай ... может она грузица тока потом вылетает ???

 

Ребята, вроде бы как решил проблему с помощью самой же Detours
Вот код внутри перехвата CreateProccess

Код (Text):

1. //Снимаю перехват,что б не ловить себя
2.  DetourTransactionBegin();
3.   DetourUpdateThread(GetCurrentThread());
4.   DetourDetach(&(PVOID&)pCreateProccessW,pUnrealCreateProccessW);
5.   DetourTransactionCommit();
6. // Это функция Detours работает очень корректно
7.   bool i=DetourCreateProcessWithDllW(lpApplicationName, lpCommandLine,lpProcessAttributes,lpThreadAttributes,bInheritHandles,dwCreationFlags,lpEnvironment,lpCurrentDirectory,lpStartupInfo,lpProcessInformation,"c:\\winnt\\system32\\my2.dll","my.dll",NULL);
8. //Снова цепляю перехват  
9. DetourTransactionBegin();
10.   DetourUpdateThread(GetCurrentThread());
11.   DetourAttach(&(PVOID&)pCreateProccessW,pUnrealCreateProccessW);
12.   DetourTransactionCommit();
13. return i;

 

Код (Text):

1.          invoke    GetStartupInfo, StartUpInfo            
2.  
3.          invoke    CreateProcess, 0, bufferCreateProcess, 0, 0, 0, CREATE_SUSPENDED, 0, 0, StartUpInfo, ProcessInfo
4.  
5.          invoke    VirtualAllocEx,[ProcessInfo.hProcess], 0, 1000h, MEM_COMMIT+MEM_RESERVE, PAGE_EXECUTE_READWRITE
6.          mov       dword [Addr_Alloc], eax
7. ; test
8.     ;    invoke    ReadProcessMemory,  [ProcessInfo.hProcess], eax ,  buffer, 100h, 0            
9.  
10. ; здесь заполняем блок NEW_CODE_BEGIN всем, чем нужно
11. ; те. кодом для подгрузки DLL, выполнения каких-либо действий и пр.
12. ;
13. ; не забываем сделать, на пример, splicing или любым другим способом переход с OEP
14. ; созданного процесса на код в аллок.памяти. а новом коде не забудем восстановить
15. ; OEP процесса-носителя
16.  
17.          invoke    WriteProcessMemory, [ProcessInfo.hProcess], [Addr_Alloc], NEW_CODE_BEGIN, LENGTH_NEW_CODE, 0
18.                                                                      ; transfert from "NEW_CODE_BEGIN"
19.                                                                      ; to virtual memomy
20.  
21.          invoke    ResumeThread,  [ProcessInfo.hThread]                                         ; lunch thread/target
22.  
23.          invoke    CloseHandle, dword [ProcessInfo.hProcess]                                    ;
24.          invoke    CloseHandle, dword [ProcessInfo.hThread]                                     ;

 

была такая же проблема. решил тем, что убрал WaitForSingleObject, который на потоке запускаемом делал..

 

coocky
Кстати, у меня была проблема внедрения с этим ключом, если в импорте проги содержался d3d9.dll, а мне как раз и надо было только в игры пришлось инжектить по-другому