CreateRemoteThread on LoadLibrary and get the HMODULE back

Question

I am doing the DLL injection job recently, so I have did some research into it on google. Now I know use CreateRemoteThread is a good way.

The ASLR(Address space layout randomization, since Windows Vista) makes the address of kernel32.dll is random, but this does not affect the whole, because in a session the base address of kernel32.dll in all processes is just the same - until the Operating System reset.

So this code may be safe normally:

void launchAndInject(const char* app, const char* dll)
{
    STARTUPINFOA si = {0};
    si.cb = sizeof(si);
    PROCESS_INFORMATION pi = {0};

    if (CreateProcessA(app, NULL, NULL, NULL, FALSE, CREATE_SUSPENDED, NULL, NULL, &si, &pi))
    {
        LPVOID loadLibrary = GetProcAddress(GetModuleHandleA("kernel32.dll"), "LoadLibraryA");
        if (loadLibrary == NULL) {
            return;
        }
        SIZE_T len = ::strlen(dll) + 1;
        LPVOID addr = VirtualAllocEx(pi.hProcess, NULL, len, MEM_RESERVE|MEM_COMMIT, PAGE_READWRITE);
        if (addr == NULL) {
            return;
        }
        if (!WriteProcessMemory(pi.hProcess, addr, dll, len, NULL)) {
            return;
        }
        HANDLE th = CreateRemoteThread(pi.hProcess, NULL, 0, (LPTHREAD_START_ROUTINE)loadLibrary, addr, 0, NULL);
        WaitForSingleObject(th, INFINITE);
        DWORD ret = 0;
        GetExitCodeThread(th, &ret);
        CloseHandle(th);
        ResumeThread(pi.hThread);
    }
}

The exit code of the injecting thread is just the returned value by LoadLibrary, so ret is just the HMODULE of loaded DLL(in child process of course), it works like a magic, so far so good.

I have read many projects about DLL injection, they use DLLMain to do lots of jobs - like creating thread, or hook APIs, and so on. They must be very carefully to do these things, refers to the document "Best Practices for Creating DLLs" of Microsoft, behaviors such as creating thread might cause dead-lock, "The ideal DllMain would be just an empty stub", so I don't think this is a very good way.

So, get the HMODULE of the loaded DLL is important. With this handle, you can use CreateRemoteThread to call a export function of injected DLL, do whatever you want, no need to worry about the loader-lock things.

Unfortunately, the code above only works with 32bit processes, this is because the type of thread's exit code is DWORD - a 32bit unsigned integer, but HMODULE is a pointer, it can be 64bit. So in 64bit process, you may get a DWORD value 0xeb390000 from GetExitCodeThread, but in fact the HMODULE returned by LoadLibrary is 0x7feeb390000. 0xeb390000 is just a truncated 64bit pointer.

How can we fix this issue ?

Answer 1

You could assume that the code as shown is likely to work and that the truncated HMODULE is likely to actually be fine most of the time as modules are usually loaded low enough in the process address space that it doesn't matter. To ensure that the code always works though you could follow your 'broken' example code with a call to EnumProcessModules() function. If the returned HMODULE appears in the list of process modules for the target process then you're good to go. If not, you need to iterate the returned HMODULEs and call GetModuleBaseName() or GetModuleFileNameEx() until you locate your injected DLL.

Alternatively, if you're already running as a custom debugger (which I find useful when I want to inject anyway), then you can match the module that's loaded when you inject up to the corresponding LOAD_DLL_DEBUG_EVENT that will be reported by WaitForDebugEvent(). This would give you the both the HMODULE (base of image) and image file name and the event would occur immediately after you injected your DLL.

Personally I'd take the later approach, but in practice I've yet to see the truncated HMODULE returned from the broken code to be anything but correct, but I expect I've just been lucky and am relying on the loader to load DLLs low in the process's address space.

Answer 2

For 64bit process, I could use IPC (http://msdn.microsoft.com/en-us/library/windows/desktop/aa365574%28v=vs.85%29.aspx) to get the HMODULE back.

I should note that not every IPC mechanism could works in DLLMain, for example Pipe will cause dead-lock, refer to the document "Best Practices for Creating DLLs" (http://download.microsoft.com/download/a/f/7/af7777e5-7dcd-4800-8a0a-b18336565f5b/DLL_bestprac.doc) of Microsoft, call functions in kernel32.dll (except some specified functions) will be OK.

I have tested shared memory (on Windows XP with SP3 and Windows 7 64bit PRO), it works.

Answer 3

You can safely use the returned 32-bit handle as according to https://docs.microsoft.com/en-us/windows/desktop/WinProg64/interprocess-communication, 64 bit windows still use 32-bit handle.

64-bit versions of Windows use 32-bit handles for interoperability. When sharing a handle between 32-bit and 64-bit applications, only the lower 32 bits are significant, so it is safe to truncate the handle (when passing it from 64-bit to 32-bit) or sign-extend the handle (when passing it from 32-bit to 64-bit). Handles that can be shared include handles to user objects such as windows (HWND), handles to GDI objects such as pens and brushes (HBRUSH and HPEN), and handles to named objects such as mutexes, semaphores, and file handles.