[QUESTION] Issues with OpenProcess C++ Win7 64bit

[_Mike]

487 is ERROR_INVALID_ADDRESS (System Error Codes (Windows)), not access denied.
The code you posted in the OP is a bit to messy for me to want to properly read it , but you are overcomplicating things imo.
Just write the name of the dll to the target and CreateRemoteThread into LoadLibrary directly, then get the offset to your function locally, and CreateRemoteThread into that.

[Azzie2k8]

487 is ERROR_INVALID_ADDRESS (System Error Codes (Windows)), not access denied.
The code you posted in the OP is a bit to messy for me to want to properly read it , but you are overcomplicating things imo.
Just write the name of the dll to the target and CreateRemoteThread into LoadLibrary directly, then get the offset to your function locally, and CreateRemoteThread into that.

Maybe you are right and I should really just get to a working version...I will amke a strip down version of it.

[_Mike]

I just had a closer look at your code and the main problem I can see is your threadstart function. It's to dependent on specific compiler settings to work, mainly that /RTCs cannot be enabled. (unless you make sure that the crt dll has the same location in both your injector and target, or you relocate the call manually)
There's also
funcsize = (DWORD)threadend-(DWORD)threadstart;
which might be a problem.. As far as I know there's nothing in the C(++) standards that says that functions have to be linked in the same order that they appear in the source code.
Yes, it currently works like that in msvc but it's unreliable to depend on in my opinion.

[Azzie2k8]

I just had a closer look at your code and the main problem I can see is your threadstart function. It's to dependent on specific compiler settings to work, mainly that /RTCs cannot be enabled. (unless you make sure that the crt dll has the same location in both your injector and target, or you relocate the call manually)
There's also
funcsize = (DWORD)threadend-(DWORD)threadstart;
which might be a problem.. As far as I know there's nothing in the C(++) standards that says that functions have to be linked in the same order that they appear in the source code.
Yes, it currently works like that in msvc but it's unreliable to depend on in my opinion.

Okay thanks alot. I am using a slightly different approach now thanks to Boredevil. Anyways since this problem is solved now I will need to Hook a function to execute my code, right ? I don't want to bother anyone with this but if you already know a good place where I can read up about this I'd be very happy if you posted a link.
Btw thanks to everyone who participated in this thread

[Azzie2k8]

I have another issue that I dont understand but I dont want to open a new thread for this.

I try to hook End Scene via MS Detours 1.5 but wow constantly crashes when DetourFunction is called.

What am I doing wrong here ?

HRESULT (__stdcall *Real_EndScene)(LPDIRECT3DDEVICE9);

HRESULT __stdcall My_EndScene(LPDIRECT3DDEVICE9 device)
{
	return Real_EndScene(device);
}


UINT CALLBACK Install( LPVOID lpParam)
{	
	DWORD pDevice_1 = *(DWORD*)(0x00C5DF88);
	DWORD pDevice_2 =  *(DWORD*)(pDevice_1 + 0x397C); //This contains another pointer so we will dereference again
	DWORD pDevice = *(DWORD*)pDevice_2; // Pointer to Class VMT 
	DWORD EndScene = *(DWORD*)(pDevice +0xA8); // Offset off EndScene within classes VMT

	Real_EndScene = (HRESULT (__stdcall *)(LPDIRECT3DDEVICE9))DetourFunction((PBYTE)EndScene,(PBYTE)My_EndScene);

	return 0;
}

[JuJuBoSc]

Because you don't add baseAddress to first offset, as already stated many time.

[Azzie2k8]

Because you don't add baseAddress to first offset, as already stated many time.

uhm I thought that was coming with the 4.whatever patch ? Is it already using ASLR?

[Cheatz0]

uhm I thought that was coming with the 4.whatever patch ? Is it already using ASLR?

4.0.1 - Which is now.

[Azzie2k8]

Lol I didnt even know...sry i dont play wow

well then time to go lookup how that one works