New comp issues...

[lanman92]

Haha, the 64-bit may be the problem. I don't know anything about 64-bit Vista. Ugh, my XP/hr went down like 50k. Lol.

[cloud_wizard]

You may consider wiping your drive and taking it back. At present, there's not much reason to upgrade to a 64 bit operating system unless you use a program that would greatly benefit from running on one. Or a program that will only run on one.

[lanman92]

I'm gonna do a little more work. Maybe try injecting a BP opcode before my code gets executed. If not, I'm totally screwed. I know there has to be some way to do this. Where are you Cypher...

[Apoc]

x64 systems are fun to deal with. Firstly, try compiling your programs targeting the x64 platform. You NEED to disable DEP on your PC as x64 PC's have this on by default, and will more often than not, not allow you to do any tinkering in another process.

Your other options, are to set the security tokens in the process. (Google for it.)

[lanman92]

I disabled DEP, but not sure what I need to do to make the program target a x64 app. Doesn't WoW install as 32-bit?

[Apoc]

Right click your solution -> Platform/Target Platform -> x64 (You may need to do this in the project preferences)

[lanman92]

I googled and did that, but it still didn't work. It works to inject a x64 dll with a 32 bit app, I'm assuming?

[Cypher]

I'm running Windows Server 2008 x64, with hardware DEP enabled. Don't compile as x64, it won't work. I compile all my projects as x86 (you have to, because WoW is x86) and it works fine for me. Please post the code you're using to inject your DLL.

The issue is not your architecture, its your code.

[lanman92]

Here ya go...

 
#include "stdafx.h"
#pragma comment(lib, "detours.lib")
int SpeedHack = 8;
DETOUR_TRAMPOLINE(BOOL WINAPI QueryPerformanceCounter_Trampoline(LARGE_INTEGER *lp), QueryPerformanceCounter);
BOOL APIENTRY DllMain( HMODULE hModule,
DWORD ul_reason_for_call,
LPVOID lpReserved
)
{
switch (ul_reason_for_call)
{
case DLL_PROCESS_ATTACH:
DisableThreadLibraryCalls(hModule);
CreateThread( NULL, 0, ( LPTHREAD_START_ROUTINE ) SpeedThread, NULL, 0, NULL );
case DLL_PROCESS_DETACH:
DetourRemove((PBYTE)QueryPerformanceCounter_Trampoline, (PBYTE)QueryPerformanceCounter_Detour);
break;
}
return TRUE;
}
void SpeedThread()
{
DetourFunctionWithTrampoline((PBYTE)QueryPerformanceCounter_Trampoline, (PBYTE)QueryPerformanceCounter_Detour); 
return;
}
 
BOOL WINAPI QueryPerformanceCounter_Detour(LARGE_INTEGER *lp)
{
static LONGLONG oldfakevalue = 0; 
static LONGLONG oldrealvalue = 0; 
LONGLONG newvalue; 
BOOL ret; 
double factor = 1.0; 
if(oldfakevalue == 0 || oldrealvalue == 0){
oldfakevalue = lp->QuadPart; 
oldrealvalue = lp->QuadPart; 
}
ret = QueryPerformanceCounter_Trampoline(lp); 
newvalue = lp->QuadPart; 

if(GetAsyncKeyState(VK_SHIFT))
{
if(SpeedHack >=1) factor=SpeedHack;
}
newvalue = oldfakevalue + (LONGLONG)((newvalue - oldrealvalue)* factor); 
oldrealvalue = lp->QuadPart; 
oldfakevalue = newvalue; 
lp->QuadPart = newvalue; 
return ret; 
}

[lanman92]

Sorry for double post... Does detours not work right for x64? I'm thinking that's it. It's not even crashing WoW. I'm getting the handle though.

[Cypher]

Sorry for double post... Does detours not work right for x64? I'm thinking that's it. It's not even crashing WoW. I'm getting the handle though.

Please read the post right above your code. >_>

I repeat:
I am on a 64-bit chip, running a 64-bit operating system, and I have no problems hacking WoW or any other game for that matter. The problem is with your code I would assume.

Please post any code thats failing and I will test it on my system so I can diagnose if the problem is hardware or software, then provide a fix.

[lanman92]

The code I posted doesn't work. It worked perfectly on my x86 laptop. I turned of DEP, and virtually every other protection on my comp. I can't find out why this doesn't work...

[Cypher]

The code I posted doesn't work. It worked perfectly on my x86 laptop. I turned of DEP, and virtually every other protection on my comp. I can't find out why this doesn't work...

CreateThread( NULL, 0, ( LPTHREAD_START_ROUTINE ) SpeedThread, NULL, 0, NULL );

That is why I think. You're 'doing a kynox' as I have dubbed it, caus he does the same retarded thing.

DONT ****ING CAST THREAD CALLBACKS AS AN LPTHREAD_START_ROUTINE.

If you really wanna use CreateThread this is the correct way:

DWORD CALLBACK ThreadProc(LPVOID lpParameter)
{
	// code goes here
}

CreateThread(NULL,0,&ThreadProc,NULL,0,NULL);

Yes if you want to use params casting them and them alone is acceptable. But do NOT cast your callback pointer.

Even if that isn't the problem, it is still a very big potential problem with your code. Reasons are outlined here:
The Old New Thing : Uninitialized garbage on ia64 can be deadly

[lanman92]

Well. My dll isn't even being injected. ****. Time to use a public injector, since MemoryLib doesn't like x64...

[Cypher]

At any rate, that will still cause problems.

I personally use a slightly modified version of ForceLib and it works on x64.