Привет. Есть такая проблема. Моя длл,прописаная в реестре в ключе 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-внедряюсь.. Хм..И что же может быть виной всему?
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): BOOL fOk = FALSE; // Assume that the function fails HANDLE hProcess = NULL, hThread = NULL; PWSTR pszLibFileRemote = NULL; // Get a handle for the target process. hProcess = OpenProcess( PROCESS_QUERY_INFORMATION | // Required by Alpha PROCESS_CREATE_THREAD | // For CreateRemoteThread PROCESS_VM_OPERATION | // For VirtualAllocEx/VirtualFreeEx PROCESS_VM_WRITE, // For WriteProcessMemory FALSE, dwProcessId); if (hProcess == NULL) { if (pszLibFileRemote != NULL) VirtualFreeEx(hProcess, pszLibFileRemote, 0, MEM_RELEASE); if (hThread != NULL) CloseHandle(hThread); if (hProcess != NULL) CloseHandle(hProcess); return FALSE; } // Calculate the number of bytes needed for the DLL's pathname int cch = 1 + lstrlenW(Dll_name.GetBuffer()); int cb = cch * sizeof(WCHAR); // Allocate space in the remote process for the pathname pszLibFileRemote = (PWSTR) VirtualAllocEx(hProcess, NULL, cb, MEM_COMMIT, PAGE_READWRITE); if (pszLibFileRemote == NULL) { if (pszLibFileRemote != NULL) VirtualFreeEx(hProcess, pszLibFileRemote, 0, MEM_RELEASE); if (hThread != NULL) CloseHandle(hThread); if (hProcess != NULL) CloseHandle(hProcess); return FALSE; } // Copy the DLL's pathname to the remote process's address space if (!WriteProcessMemory(hProcess, pszLibFileRemote, (PVOID) Dll_name.GetBuffer(), cb, NULL)) { if (pszLibFileRemote != NULL) VirtualFreeEx(hProcess, pszLibFileRemote, 0, MEM_RELEASE); if (hThread != NULL) CloseHandle(hThread); if (hProcess != NULL) CloseHandle(hProcess); return FALSE; } // Get the real address of LoadLibraryW in Kernel32.dll PTHREAD_START_ROUTINE pfnThreadRtn = (PTHREAD_START_ROUTINE) GetProcAddress(GetModuleHandle(TEXT("Kernel32")), "LoadLibraryW"); if (pfnThreadRtn == NULL) { if (pszLibFileRemote != NULL) VirtualFreeEx(hProcess, pszLibFileRemote, 0, MEM_RELEASE); if (hThread != NULL) CloseHandle(hThread); if (hProcess != NULL) CloseHandle(hProcess); return FALSE; } // Create a remote thread that calls LoadLibraryW(DLLPathname) hThread = CreateRemoteThread(hProcess, NULL, 0, pfnThreadRtn, pszLibFileRemote, 0, NULL); if (hThread == NULL) { if (pszLibFileRemote != NULL) VirtualFreeEx(hProcess, pszLibFileRemote, 0, MEM_RELEASE); if (hThread != NULL) CloseHandle(hThread); if (hProcess != NULL) CloseHandle(hProcess); return FALSE; } // Wait for the remote thread to terminate WaitForSingleObject(hThread, INFINITE); fOk = TRUE; // Everything executed successfully // Free the remote memory that contained the DLL's pathname if (pszLibFileRemote != NULL) VirtualFreeEx(hProcess, pszLibFileRemote, 0, MEM_RELEASE); if (hThread != NULL) CloseHandle(hThread); if (hProcess != NULL) CloseHandle(hProcess); return fOk; Вообщем Рихтеровская фишка.Вообщем я думал где-то здесь создать CreateProccess с перехвачеными параметрамии флагом CREATE_SUSPENDED,затем внедрится,запуститься и сделать ResumeThread. Вот и вопрос-можно ли так сделать и если можно-в каких местах? Если можно-подправтье этот код для моей ситуации Спасибо
coocky код не смотрел. 1) зачаем перехватывать CreateProcess?! какое это имеет отношения к внедрению?! любой перехват потенциально небезопасен в смысле глюков и при этом ты рискуешь огрести по полной от всяких там аверов и фаерв. если стоит задача отследить запуск какого-то конкретного процесса и внедриться в него до начала его выполнения - тогда так прямо и говори. 2) удаленные потоки - ну.... тут вообще ругаются все проактивные сторожа, к тому же они легко отлавливаются. я уже как-то постил сюда утилиту, которая это делает. в смысле находит (и довольно надежно) удаленные потоки, созданные всякой нечисть. 3) посмотрел код по диагонали. под вистой он не будет работать из-за рандомизации адресного пространства и там надо разбирать импорт вручную.
kaspersky Да..Задача в том и состоит,что б внедрится в процесс,до начала его выпонения.. В любой процес,который юзает USER32.dll Мне под висту и ненадо.Только 2000,и ХР. Я не играюсь с кодом, это моя работа.И не трояны.... Дело в том, что я тогда и не понимаю,как можно попасть в другой процесс,не перехватив CreateProccess... Вот что получилось у меня Итак ,перехватываю создание процесса эксплорером (CreateProccessA и CreateProccessW) c с помощью свое длл и Detours Вод код функции перехватчика Код (Text): if(dwCreationFlags&CREATE_SUSPENDED) { ret= pCreateProccessA( lpApplicationName, lpCommandLine, lpProcessAttributes,lpThreadAttributes, bInheritHandles, dwCreationFlags, lpEnvironment, lpCurrentDirectory,lpStartupInfo,lpProcessInformation); // передаю dwProcessId в ехе и выполняю внедрение в процесс с помощью выше написаного кода по рихтеру; } else { dwCreationFlags|=CREATE_SUSPENDED; ret= pCreateProccessA( lpApplicationName, lpCommandLine, lpProcessAttributes,lpThreadAttributes, bInheritHandles, dwCreationFlags, lpEnvironment, lpCurrentDirectory,lpStartupInfo,lpProcessInformation); // передаю dwProcessId в ехе и выполняю внедрение в процесс с помощью выше написаного кода по рихтеру; } ResumeThread (lpProcessInformation->hThread) return ret; Однако многие программы глючат при старте-не до конца инициализируются.. kaspersky мне не важны сторожа или скрытость Мне надо явно внедрится ..И все.. Внедрится в новь создаваемый процесс..
Ребята, вроде бы как решил проблему с помощью самой же Detours Вот код внутри перехвата CreateProccess Код (Text): //Снимаю перехват,что б не ловить себя DetourTransactionBegin(); DetourUpdateThread(GetCurrentThread()); DetourDetach(&(PVOID&)pCreateProccessW,pUnrealCreateProccessW); DetourTransactionCommit(); // Это функция Detours работает очень корректно bool i=DetourCreateProcessWithDllW(lpApplicationName, lpCommandLine,lpProcessAttributes,lpThreadAttributes,bInheritHandles,dwCreationFlags,lpEnvironment,lpCurrentDirectory,lpStartupInfo,lpProcessInformation,"c:\\winnt\\system32\\my2.dll","my.dll",NULL); //Снова цепляю перехват DetourTransactionBegin(); DetourUpdateThread(GetCurrentThread()); DetourAttach(&(PVOID&)pCreateProccessW,pUnrealCreateProccessW); DetourTransactionCommit(); return i;
Код (Text): invoke GetStartupInfo, StartUpInfo invoke CreateProcess, 0, bufferCreateProcess, 0, 0, 0, CREATE_SUSPENDED, 0, 0, StartUpInfo, ProcessInfo invoke VirtualAllocEx,[ProcessInfo.hProcess], 0, 1000h, MEM_COMMIT+MEM_RESERVE, PAGE_EXECUTE_READWRITE mov dword [Addr_Alloc], eax ; test ; invoke ReadProcessMemory, [ProcessInfo.hProcess], eax , buffer, 100h, 0 ; здесь заполняем блок NEW_CODE_BEGIN всем, чем нужно ; те. кодом для подгрузки DLL, выполнения каких-либо действий и пр. ; ; не забываем сделать, на пример, splicing или любым другим способом переход с OEP ; созданного процесса на код в аллок.памяти. а новом коде не забудем восстановить ; OEP процесса-носителя invoke WriteProcessMemory, [ProcessInfo.hProcess], [Addr_Alloc], NEW_CODE_BEGIN, LENGTH_NEW_CODE, 0 ; transfert from "NEW_CODE_BEGIN" ; to virtual memomy invoke ResumeThread, [ProcessInfo.hThread] ; lunch thread/target invoke CloseHandle, dword [ProcessInfo.hProcess] ; invoke CloseHandle, dword [ProcessInfo.hThread] ;
была такая же проблема. решил тем, что убрал WaitForSingleObject, который на потоке запускаемом делал..
coocky Кстати, у меня была проблема внедрения с этим ключом, если в импорте проги содержался d3d9.dll, а мне как раз и надо было только в игры пришлось инжектить по-другому