(K32)GetModuleBaseNameW: win32 error: failed to resolve the file name of the target process

[broihon]

(K32)GetModuleBaseNameW: win32 error: failed to resolve the file name of the target process

[Broihon]

I never intended this library to inject into a suspended process so it's not a bug in my opinion. Additionally this is caused by the insane lack of documentation of the used API.

The executable name is only used for the debug output and not critical for the injection process but my train of thought was if the injector isn't even able to grab a module name then the injection would most certainly not work anyway. And I still consider this a logical assumption to make but again, logic doesn't work when you deal with Windows.

I did some research on why this fails and it's honestly insane. It's not which dll the function belongs to and obviously there is absolutely no documentation on this. It turns out that PEB::Ldr is a nullptr when the process gets created in a suspended state.
All the modules are already loaded but the pointer to the PEB_LDR_DATA is just 0. Why? No clue. Does it make any sense? No. Is it mentioned anywhere? No.
Anyway, switching to an API that queries kernel data instead of usermode data will do the trick.

Edit: QueryFullProcessImageName will do the trick as it calls NtQueryInformationProcess with the ProcessImageFileNameWin32 flag internally.

[netcorefan1]

Sorry for reopening this, but I wanted to thank you for the time you have taken to investigate and to confirm that your fix worked. QueryFullProcessImageName works along with the resuming process. Do you will apply this fix in the next release?
Although injecting into a suspended process was not on the scope of the library, if I am not wrong by using NtCreateThreadEx everything was already in your hands (unless there are other bad surprises to expect I would say that injecting a dll in a suspended notepad process and resume it from inside the injected dll is a great result. This will open to the possibility to deal with detection mechanism and hooking all the API calls a process can do before it starts. I would say it adds a great value to your injector.

The executable name is only used for the debug output and not critical for the injection process but my train of thought was if the injector isn't even able to grab a module name then the injection would most certainly not work anyway. And I still consider this a logical assumption to make but again, logic doesn't work when you deal with Windows.

Even if it is not critical to the injection process your logical assumption for me it is enough to take care about this and in order to be bring an extra level of safety after this fix I need to make you to quick questions:

• After the fix I experienced for the first time several times injection timeout and honestly I can't imagine how that function replacement can even have some sort on influence. I will investigate to see what could be the cause. There is a Timeout field in the Injection struct, you think can help with this?
• To resume the thread I just call ResumeThread(hThread); but I saw from other libraries they do that way:

if((hThread = OpenThread(THREAD_SUSPEND_RESUME, FALSE, ThreadID)) == NULL)
        THROW(STATUS_INTERNAL_ERROR, L"Unable to open wake up thread.");

    if(!ResumeThread(hThread))
        THROW(STATUS_INTERNAL_ERROR, L"Unable to resume process main thread.");

What could be the correct way?