Answer the question
In order to leave comments, you need to log in
Unable to inject dll into process?
Hello.
There is such a code for injecting a dll into a process
HANDLE h_process = OpenProcess(PROCESS_ALL_ACCESS, FALSE, PID);
char fullDLLPath[_MAX_PATH];
GetFullPathNameA(file_name.c_str(), _MAX_PATH, fullDLLPath, NULL);
LPVOID DLLPath_addr = VirtualAllocEx(h_process, NULL, _MAX_PATH,
MEM_COMMIT | MEM_RESERVE, PAGE_READWRITE);
WriteProcessMemory(h_process, DLLPath_addr, fullDLLPath,
strlen(fullDLLPath), NULL);
LPVOID LoadLib_addr = GetProcAddress(GetModuleHandleA("Kernel32"),
"LoadLibraryA");
HANDLE h_rThread = CreateRemoteThread(h_process, NULL, 0,(LPTHREAD_START_ROUTINE)LoadLib_addr, DLLPath_addr, 0, NULL);
WaitForSingleObject(h_rThread, INFINITE);
DWORD exit_code;
GetExitCodeThread(h_rThread, &exit_code);
CloseHandle(h_rThread);
VirtualFreeEx(h_process, DLLPath_addr, 0, MEM_RELEASE);
CloseHandle(h_process);
return (HANDLE)exit_code;
di.inject_DLL("module.dll", di.GetPID("winhex.exe"));
HANDLE hSnap = CreateToolhelp32Snapshot(TH32CS_SNAPPROCESS, NULL);
PROCESSENTRY32 pe32;
pe32.dwSize = sizeof(PROCESSENTRY32);
if (hSnap) {
if (Process32First(hSnap, &pe32)) {
if (strcmp(pe32.szExeFile, processname.c_str()) == 0) {
return pe32.th32ProcessID;
}
}
while (Process32Next(hSnap, &pe32)) {
if (strcmp(pe32.szExeFile, processname.c_str()) == 0) {
return pe32.th32ProcessID;
}
}
CloseHandle(hSnap);
return 0;
}
else {
return 0;
}
Answer the question
In order to leave comments, you need to log in
Laughed myself. The decision was easy enough.
I called the function incorrectly.
Called:
di.inject_DLL("winhex.exe", di.GetPID("winhex.exe"));
di.inject_DLL("module.dll", di.GetPID("winhex.exe"));
Try like this:
LPVOID LoadLib_addr = GetProcAddress(GetModuleHandleA("kernel32.dll"), "LoadLibraryA");
if (h_rThread)
{
<код>
}
Of course, I understand that laziness, but you always need to write error handling, then it would be obvious where the problem is. I have 2 options why it might not work:
1. The bitness of your application is not the same as that of the attacked process.
2. The location of kernel32 in the attacked process is different from the location in yours.
Didn't find what you were looking for?
Ask your questionAsk a Question
731 491 924 answers to any question