Process Running Dll Injection C++

[BitHacker]

I'm not sure why this isn't letting me inject this testdll3.dll into the process. Everything is correct all my variables are getting the correct data. All memory regions are getting the proper flags. I'm fed up with it. My output is below.

Can anyone tell me what I'm doing wrong?

You can drop a test dll into the diablo III.exe folder.... This could will read it and try to inject it into a running process.

#undef UNICODE
#include <vector>
#include <string>
#include <windows.h>
#include <Tlhelp32.h>
#include <iostream>
#include <Psapi.h>

using namespace std;

int main(void)
{
    vector<string>processNames;
    PROCESSENTRY32 pe32;
    pe32.dwSize = sizeof(PROCESSENTRY32);
    HANDLE hTool32 = CreateToolhelp32Snapshot(TH32CS_SNAPPROCESS, NULL);
    BOOL bProcess = Process32First(hTool32, &pe32);
    if(bProcess == TRUE)
    {
        while((Process32Next(hTool32, &pe32)) == TRUE)
		{
            processNames.push_back(pe32.szExeFile);

			if(strcmp(pe32.szExeFile, "Diablo III.exe") == 0)
			{
				string dllPathMod;
				char DirPath[MAX_PATH];
				char* FullPath = new char[MAX_PATH];
				
				//Grab handle 
				HANDLE hProcess = OpenProcess(PROCESS_ALL_ACCESS, FALSE, pe32.th32ProcessID);

				//Grab File location
				GetProcessImageFileName(hProcess, DirPath, sizeof(DirPath));

				//Save Path into string
				dllPathMod = DirPath;
				dllPathMod.erase( dllPathMod.size() - 14 );

				//Convert back to char[]
				char* dllPath = new char[dllPathMod.size() + 1];
				dllPath[dllPathMod.size()] = 0;
				memcpy(dllPath, dllPathMod.c_str(), dllPathMod.size());
				
				//Copy Path
				sprintf_s(FullPath, MAX_PATH, "%s\\testdll3.dll", dllPath);

				//Finding LoadLibraryAddr
				LPVOID LoadLibraryAddr = (LPVOID)GetProcAddress(GetModuleHandle("kernel32.dll"), "LoadLibraryA");

				//Allocate memory inside diablo III.exe
				LPVOID LLParam = (LPVOID)VirtualAllocEx(hProcess, NULL, strlen(FullPath), MEM_RESERVE | MEM_COMMIT, PAGE_READWRITE);

				//Write to memory
				WriteProcessMemory(hProcess, LLParam, FullPath, strlen(FullPath), NULL);

				//Create a thread inside virtual address space of diablo III.exe
				CreateRemoteThread(hProcess, NULL, NULL, (LPTHREAD_START_ROUTINE)LoadLibraryAddr, LLParam, NULL, NULL);


				CloseHandle(hProcess);
				delete [] FullPath;
				delete [] dllPath;				
			}
		}
    }
    CloseHandle(hTool32);
    return 0;
}

My Output:


-Bit_Hacker

[DrGonzo]

*Prepares for shit storm*

This is a no question section. If you have programming questions take it to stack overflow.

Didn't bother reading code but try running as admin and setting debug privilege. If that doesn't work find better copypasta.

[BitHacker]

FearAndLawyering,

Thanks for your input but I wrote all of it

-Bit_Hacker

[Valtharak]

or in the programming section

[_Mike]

Knowing the win32 API would help And so would checking GetLastError when LoadLibrary fails.
Hint: Fix your namespace.

[Yazuak]

I'd imagine it's failing because your paths are in device format. Try using something other than

GetProcessImageFileName to retrieve the path. (You want something that begins with "C:\\" or similar.)

[_Mike]

(You want something that begins with "C:\\" or similar.)

No need. LoadLibrary is fully capable of handling device paths. All you need is the right namespace prefix.
Doesn't anyone know the windows apis these days? I blame C# for that

[bossfong]

Looking at your FullPath variable it seems to be screwed. From what I see you're trying to load your DLL from a noname folder inside Diablo3 folder.
Also:
Why have it simple when you can do it complicated:

        HWND hWindow;

	while (!(hWindow = ::FindWindow(NULL, "Diablo III")))
	{
		Sleep(100);
	}

	std::cout << "Found Diablo3" << std::endl;

	DWORD procid;

	::GetWindowThreadProcessId(hWindow, &procid); // NO ERROR CHECKING

No ProcessAPI, loops and shit involved. l2msdn

[BitHacker]

bossfong,

I got it working:

#undef UNICODE
#include <vector>
#include <string>
#include <windows.h>
#include <Tlhelp32.h>
#include <iostream>
#include <Psapi.h>

using namespace std;

int main(void)
{
    vector<string>processNames;
    PROCESSENTRY32 pe32;
    pe32.dwSize = sizeof(PROCESSENTRY32);
    HANDLE hTool32 = CreateToolhelp32Snapshot(TH32CS_SNAPPROCESS, NULL);
    BOOL bProcess = Process32First(hTool32, &pe32);
    if(bProcess == TRUE)
    {
        while((Process32Next(hTool32, &pe32)) == TRUE)
		{
            processNames.push_back(pe32.szExeFile);

			if(strcmp(pe32.szExeFile, "Diablo III.exe") == 0)
			{								
				char* FullPath = new char[MAX_PATH];
				HANDLE hProcess = OpenProcess(PROCESS_ALL_ACCESS, FALSE, pe32.th32ProcessID);
				sprintf(FullPath, "testdll3.dll");
				LPVOID LoadLibraryAddr = (LPVOID)GetProcAddress(GetModuleHandle("kernel32.dll"), "LoadLibraryA");
				LPVOID LLParam = (LPVOID)VirtualAllocEx(hProcess, NULL, strlen(FullPath), MEM_RESERVE | MEM_COMMIT, PAGE_READWRITE);
				WriteProcessMemory(hProcess, LLParam, FullPath, strlen(FullPath), NULL);
				CreateRemoteThread(hProcess, NULL, NULL, (LPTHREAD_START_ROUTINE)LoadLibraryAddr, LLParam, NULL, NULL);
				CloseHandle(hProcess);
				delete [] FullPath;
			}
			
			// Add break for while loop
		}
    }
    CloseHandle(hTool32);
    return 0;
}

i got it working by changing this line of code:

sprintf_s(FullPath, MAX_PATH, "%s\\testdll3.dll", dllPath);

to:

sprintf(FullPath, "testdll3.dll");

[Yazuak]

No need. LoadLibrary is fully capable of handling device paths. All you need is the right namespace prefix.
Doesn't anyone know the windows apis these days? I blame C# for that

I know more about them now than I did a second ago.

[Cypher]

Knowing the win32 API would help And so would checking GetLastError when LoadLibrary fails.
Hint: Fix your namespace.

I think he's too busy worrying about this being a "C# only forum" to actually learn C++ and the Win32 API.

[BitHacker]

Cypher,

Ya, thats why I got it to work without any help from this forum right? Piss off....

-Bit_hacker

[Cypher]

Cypher,

Ya, thats why I got it to work without any help from this forum right? Piss off....

-Bit_hacker

Anyone can fiddle around with code until it seems to work. If you actually understood what you are doing though you'd notice the numerous bugs and corner cases in your code.

Not to mention the fact that your 'fix' doesn't actually fix the issue you were having, you've simply reverted to using a relative path now instead of an absolute one (which introduces more potential issues).

EDIT:

I forgot to mention, if you actually did error checking in your code, you could easily pinpoint what was failing and why.

1. Check return value of function. If function returns an error code, go to step 3. If it returns a boolean (or a pointer) continue to step 2.
2. Call GetLastError to retrieve the error code.
3. Look up what the error code means on MSDN/Google.
4. Fix the problem.

The same applies to functions you call in the remote process (i.e. LoadLibraryA <-- Protip: This is one of the potential problems with your code, but I digress...).

If you (understandably) don't want to use a dynamic code generation library (like AsmJit), or write a 'wrapper' for your LoadLibrary call in assembly then copy it over to the remote process, you can just fire up a debugger on your target, set a breakpoint for your call to LoadLibrary, then inspect the LastError value in the TEB (most debuggers have a command/window to show this automagically). Then you just MSDN/Google the error code as normal (or at least provide such information in your post so we don't have to try and mentally debug your program for you).

[BitHacker]

Cypher,

Thank you for not flaming and making constructive criticism. I will take what you said under my wing bro.

-Bit_Hacker

[zewt]

wrong thread post :x sorry