Внедрение из 32-битной программы 64-битной dll в 64-битный процесс, возможно ли?

Добрый вечер. Для внедрение dll в сторонний процесс использую метод из книги Рихтера.
Суть этого метода - создать удаленный поток в нужном процессе, в качестве функции указать LoadLibrary
с необходимой dll. Если программа, dll и процесс одинаковой битности, то проблем нет.
А как сделать, чтобы можно было из 32-битной программы также внедрять 64-битные dll в 64-битные процессы?

Код (Text):

1. BOOL WINAPI InjectLibW(DWORD dwProcessId, PCWSTR pszLibFile)
2. {
3.     BOOL fOk = false;
4.     HANDLE hProcess = NULL, hThread = NULL;
5.     PWSTR pszLibFileRemote = NULL;
6.  
7.     __try {
8.         // Получаем описатель целевого процесса.
9.         hProcess = OpenProcess(
10.             PROCESS_ALL_ACCESS
11.             /*
12.             PROCESS_CREATE_THREAD |
13.             PROCESS_QUERY_INFORMATION |
14.             PROCESS_VM_OPERATION |
15.             PROCESS_VM_WRITE |
16.             PROCESS_VM_READ */,
17.             FALSE, dwProcessId);
18.         if (hProcess == NULL) __leave;
19.  
20.         // Определяем, сколько байтов нудно для строки с полным именем DLL.
21.         int cch = 1 + lstrlenW(pszLibFile);
22.         int cb = cch * sizeof(WCHAR);
23.  
24.         // Выделяем блок памяти под эту строку.
25.         pszLibFileRemote = (PWSTR)VirtualAllocEx(hProcess, NULL, cb, MEM_COMMIT, PAGE_READWRITE);
26.         if (pszLibFileRemote == NULL) __leave;
27.  
28.         // Копируем эту строку в адресное пространство удаленного процесса.
29.         if (!WriteProcessMemory(hProcess, pszLibFileRemote, (PVOID)pszLibFile, cb, NULL)) __leave;
30.  
31.         // Получем истинный адрес LoadLibraryW в Kernel32.dll
32.         PTHREAD_START_ROUTINE pfnThreadRtn = (PTHREAD_START_ROUTINE)GetProcAddress(GetModuleHandle(TEXT("Kernel32")), "LoadLibraryW");
33.         if (pfnThreadRtn == NULL) __leave;
34.  
35.         // Создаем удаленный поток, вызывающий LoadLibraryW
36.         hThread = CreateRemoteThread(hProcess, NULL, 0, pfnThreadRtn, pszLibFileRemote, 0, NULL);
37.         DWORD err = GetLastError();
38.         if (hThread == NULL) __leave;
39.  
40.         // Ждем завершение удаленного потока.
41.         WaitForSingleObject(hThread, INFINITE);
42.  
43.         fOk = TRUE;
44.     }
45.     __finally{
46.         // Очистка.
47.         if (pszLibFileRemote != NULL) VirtualFreeEx(hProcess, pszLibFileRemote, 0, MEM_RELEASE);
48.  
49.         if (hThread != NULL) CloseHandle(hThread);
50.  
51.         if (hProcess != NULL) CloseHandle(hProcess);
52.     }
53.  
54.     return fOk;
55. }
56.  

То есть, каким-то образом надо получить точку входа для функции LoadLibraryW в 64-битном процессе.

Код (Text):

1.  
2. // Получем истинный адрес LoadLibraryW в Kernel32.dll
3. PTHREAD_START_ROUTINE pfnThreadRtn = (PTHREAD_START_ROUTINE)GetProcAddress(GetModuleHandle(TEXT("Kernel32")), "LoadLibraryW");
4.  

Подскажите, пожалуйста.

 

Это никак не сделать. Юзайте x64 инжектор.

 

Я, конечно, ничем подобным не занимался, однако гугл дает возможность ответить на этот вопрос
https://stackoverflow.com/questions...s-memory-of-a-64-bit-process-from-a-32bit-app
http://www.cyberforum.ru/win-api/thread932651.html

 

Вообще можно так извратиться https://github.com/OpenWireSec/meta...source/common/arch/win/i386/base_inject.c#L68

Ага, прочитать != сделать инжект

 

https://gist.github.com/David-Reguera-Garcia-Dreg/cc8dde5901d51a922c8c336b5adb7374
https://github.com/rwfpl/rewolf-wow64ext/
https://www.opensc.io/showthread.php?t=18507
будет полезно, почти готовое решение

 

unc1e, Это все совсем не полное решение.
Револьф работает, но надо пулы домерджить для потока.
Потом надо шеллы запилить под 2 платформы - если ПЕ грузить.
Надо определить битность процесса итд.
Но если через лоадлайбрари, то там можно с колес на револьфе сделать, добавить X64Call для этой апи.

 

superakira,
> Это все совсем не полное решение ... Но если через лоадлайбрари

 

unc1e, да и для такого - все равно надо допиливать

 

При внедрении из процесса x86 в x64, вся магия заключается в переводе процессора из режима x86 в x64. В x86 процессе грузятся 2 ntdll, переводим процессор в нужный контекст, ищем адреса и стартуем. Описание можно посмотреть здесь. http://blog.rewolf.pl/blog/?p=102

 

unc1e,

Нет никакой проблемы переключать моды на асм. Вы просто не понимаете проблему - они не могут сделать это на си и прочем скрипте. В этом и суть вопроса. При смене мода кодировка инструкций изменяется и код, который выдал компилер становится нерабочим. По этой причине они и задают эти вопросы. Решения нет - кроме как учить матчасть.

 

Как нельзя, asm вставкой для си. В x64 asm нужно добавить 0x48 опкод перед командами и все, компиль x86 с x64 asm.

 

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

.code32
xor eax, eax
inc eax
nop
jz _x64

_x86: <32-битный шелл>
_x64: <64-битный шелл>

если процессор в 64-битном режиме, то он расценивает этот код как xor eax, eax и nop с префиксом... эта херня частенько используется в сплойтах, какие проблемы использовать в своем коде?

 

Indy_, все ссылки уже есть. и револьф тоже. для ТС работы на 10 минут под его задачу. Это с клоном с гитхаба и всовыванием в свой проект.
Darkness Archangel, уже все ссылки привели.