LabVIEW
Injecting a DLL into an EXE?
@oliver_alarm2079 wrote:
Nevermind, you guys arent understanding my question
That's quite possibly because you haven't explained yourself well at all. What I call injecting a DLL into a process is quite a bit different than what the VI does that you have posted.
In C your LabVIEW code looks something like:
hProcess = OpenProcess(PROCESS_CREATE_THREAD, 0, procId);
pLoad = GetProcAddress(GetModuleHandle("kernel32.dll"), "LoadLibraryA");
pMem = VirtualAllocEx(hProcess, 0, strlen(dllName) + 1, 0x1000, 0x04);
WriteProcessMemory(hProcess, pMem, dllName, strlen(dllName), *lpNumberOfBytesWritten);
CreateRemoteThread(hProcess, 0, 0, pLoad, pMem, 0, 0);
Several things about this if you look in MSDN
1) no error handling at all, each of those functions can fail, but you do not check anything here. The error cluster is only there to handle errors that are happening while LabVIEW tries to call that function dynamically. LabVIEW can NOT even try to guess how to find out if a function has failed in itself.
2) WriteProcessMemory specifically says that the function requires PROCESS_VM_WRITE and PROCESS_VM_OPERATION to the process identified with the handle, yet you open the process handle only with PROCESS_CREATE_THREAD, so WriteProcessMemory will ALLWAYS fail no matter what.
3) CreateRemoteThread requires even more access rights to be available for the process handle than the previous function and will fail ALLWAYS too.
Also I'm not seeing what this should accomplish really. You set the kernel32.LoadLibrary function as thread function, which then would load your DLL into memory but immediately quits after that. Do you intend to put anything into the DLLMain function to hook even more into that process? You are aware that DLLMain is not allowed to do a whole bunch of things since the OS loader lock may eventually deadlock if you try to do even more LoadLibrary and what else mumbobumbo in there?
