I have written a DLL-Injector in C++ recently, for which the requirements were the following
It came quickly to my notice, that the call of GetProcAddress("LoadLibraryA") in the Injector returns an "unusable" handle as the 32 bit target has another kernel32.dll loaded and the address of the function there is different, so injection fails (The remote thread can not be started using the returned address/handle). Furthermore, the 32 bit process has the kernel32.dll loaded at a different base address, which makes creation of the remote thread even more impossible.
To make clear what I mean, the following happens:
When injecting a 64 bit process from a 64 bit process, and 32 bit from 32 bit, there is usually no problem, as the kernel32.dll is (most likely) loaded at the same base address and the same function address can be used - that's my unterstanding so far. In this case however the conditions differ.
To overcome the problem I did the following steps:
This approach actually works very well, but I can't get rid of the thought that this is total overhead and there must be a more simpler solution to inject 32 bit targets from 64 bit injectors.
I have two questions, for which I am very grateful if they could be answered here:
Any answers are very much appreciated, thanks!
EDIT: Oh my gosh... I just realized, that I described the situation wrong in my initial post. The INJECTOR is 64 bit, and the TARGET is 32 bit (Initially it was the other way around, but I already corrected it). Ben Voigt's comments down below are totally true, the call to EnumProcessModulesEx would fail. A big big BIG sorry for that confusion :(
I stumbled upon this thread looking for a solution for the same problem.
So far I'm inclined to use another simpler solution. To obtain a 32-bit kernel proc address, the 64-bit process can just execute a 32-bit program that will look up the proc addresses for us:
#include <Windows.h>
int main(int argc, const char**)
{
if(argc > 1)
return (int) LoadLibraryA;
else
return (int) GetProcAddress;
}
This answer addresses an earlier version of the question, it is mostly irrelevant to the case of a 64-bit injector.
Are you saying that approach works? Because according to the documentation , you can't get information about 64-bit processes from WOW64:
If the function is called by a 32-bit application running under WOW64, the dwFilterFlag option is ignored and the function provides the same results as the EnumProcessModules function.
( EnumProcessModules
explains the restriction further)
If this function is called from a 32-bit application running on WOW64, it can only enumerate the modules of a 32-bit process. If the process is a 64-bit process, this function fails and the last error code is ERROR_PARTIAL_COPY (299).
But you really do need to find the base address where kernel32.dll
loaded, because of ASLR .
I think you could use the debug symbols API to save yourself parsing the PE header and export table. This route should yield the required information for the 32-bit injector; 64-bit target case as well, although I still don't see how you're going to pass a 64-bit address to CreateRemoteThread
.
Normally these debug symbol functions require a .pdb or .sym file to operate, however I'm pretty sure they also get information from a DLL export table (just going from experience of what a debugger shows for files where I don't have symbols present).
The technical post webpages of this site follow the CC BY-SA 4.0 protocol. If you need to reprint, please indicate the site URL or the original address.Any question please contact:yoyou2525@163.com.