Code Caving WoW [With Code (C++)]

[blizzo]

** If anything is unclear, I'm sorry. The code isn't great cos i hacked it together this afternoon just a PoC. Enjoy! **

I dunno if anyone has posted anything about using a code cave to run functions in Wow instead of injecting a DLL, but I'm going to now.

First, for those that don't know what a code cave is:
It is somewhere in a remote process' memory where you put your own code, maybe some space that isn't used or some space that you allocate with VirtualAllocEx and free with VirtualFreeEx

You can insert code in to this space and then run it!

After you insert your code you can pause the current thread, change the instruction pointer to where your code is, then resume the thread. This will run your code.
Of course, if you jump to some code that uses registers/flags and you don't restore them bad things will happen. The easiest way to do that is just to push them on the stack at the start of the injected code and pop them off at the end.
Also you'll probably want to return to where the thread was before your code ran, so you'll need to push the return address on to the stack first.

		push 0xDEADBABE		//   Placeholder for the return address
		pushfd				//   Save the flags and registers
		pushad
		//-- Something useful goes here :)
		popad				//   Restore the registers and flags
		popfd
		ret					//   Return control to the hijacked thread

Something like that would be a good start.

So... HOWTO:
Here's what i did:

1. Find the target Window Handle
2. Find the main thread ID
3. Open the process PID
4. Open the thread
5. Allocate space for the code
6. Make any changes to the "to-be-injected" code (return address, etc.)
7. Write the code to the allocated space
8. Pause the thread
9. Update the instruction pointer to point the allocated space
10. Resume the thread
11. Wait a bit for the code to run
12. De-allocate the memory allocated for the code
13. Have a beer

In you code you could call a function or whatever, but you won't be able to get any return values... unless you allocate some space for the result and have you code write that result to that known location and then read it later. So in addition to the above you must:

1. Allocate space for the result
2. Edit your code to write to the allocated location
3. Read the result after the thread is resumed

I have produced some code (in C++) that will do all of this, it can be found here: Nopaste - Wow CodeCave.
It calls the CompareUnitFaction function to get the reaction of one unit's faction to another.
It doesn't do anything fancy and the Unit 1 and Unit 2 base addresses are hardcoded in. But if you don't know how to find them this really isn't for you

*
Credit here to kynox and Shynd for info about CompareUnitFaction
Finding the functions and working out the arguments takes some time and a good disassembler/debugger, personally I like IDA (cos I can do other things - mega drive hehe)
*

The CompareUnitFaction (as it's being called) function takes two arguments, a pointer to the current Unit and a pointer to the second Unit. The current Unit is in the register ECX and the second Unit is pushed on to the stack. In my code it is called by doing:

		push 0xDEADBABE		//	Place holder for Unit2
		mov ecx, 0xDEADBABE	//	Place holder for Unit1
		mov eax, 0x005D4AB0	//	Offset for the CompareUnitFaction function
		call eax

This will run and return the faction's reaction to you in EAX, I used this code to right that value in to memory where it could be read:

		mov ebx, 0xDEADBABE	//	Offset to read result from :)
		mov dword ptr [ebx], eax

In the program the place holders are replaced with memcpy after the memory protection has been changed.
injectCode is the function with the asm in it :

void __declspec(naked) injectCode(void){ _asm { ... } }

naked means no prologue or epilogue

		// Return address
		memcpy((LPVOID)((DWORD)injectCode + 0x01),	&oldIP, 4);
		// Unit2 base address
		memcpy((LPVOID)((DWORD)injectCode + 0x08),	&dwUnit2, 4);
		// Unit1 base address
		memcpy((LPVOID)((DWORD)injectCode + 0x0D),	&dwUnit1, 4);
		// Result address
		memcpy((LPVOID)((DWORD)injectCode + 0x19),	&dwResutlAddress, 4);

OK, think that covers everything. I have NOT tested this on a live server only on an emulated server so I dunno if you'll get disconnected or whatever. I didn't on the emulated server i was on (OpenAscent TRUNK r334/Release-Win-X86).
If i have missed anything or you have any question I will try to answer them as best I can

Edit: Here is an output from the program very verbose hehe

[?] PID:        2980
[?] TID:        3012
[?] HWND:       0x00460816
[?] Handle:     0x7A4
[?] Code to inject: 0x00401000 - 0x00401030 (0x00000030)
[?] Thread Paused...
[?] Old Instruction Pointer : 0x7C90EB94
[?] Enabled modify for inject-code...OK!
[?] Updating return address (0x00401001 -> 0x7C90EB94)...OK
[?] Updating Unit2 address (0x00401008 -> 0x1070D0F0)...OK
[?] Updating Unit1 address (0x0040100D -> 0x105F8008)...OK
[?] Updating result address (0x00401018 -> 0x08FD0000)...OK
[?] Writing code stub to 0x01710000...pass.
[?] Updating the thread context...pass.
[?] Thread Resumed at 0x01710000...done!
[?] GetFactionHostility(0x105F8008, 0x1070D0F0) = 0x00000004
[?] Closing thread...done
[?] Freeing memory...done.
[?] Closing process...done.

[Shynd]

Link seems to be dead. Nice work, though.

[blizzo]

OK, link is fixed. Thanks for pointing that out Shynd

[Shynd]

Only suggestion I'd make is instead of sleeping a static 2000ms while waiting for it to execute, I'd do a loop while reading memory on your dwResult address, waiting for the result to != 0 (or initialize it as 0xFFFFFFFF and sleep until it != 0xFFFFFFFF).

DWORD dwResult = 0xFFFFFFFF;
WriteProcessMemory(hProcess, pInjectResult, (LPVOID)dwResult, sizeof(DWORD), NULL);
for (int i = 0; i < 200 && dwResult == 0xFFFFFFFF; i++)
{
    if (!ReadProcessMemory(hProcess, pInjectResult, &dwResult, sizeof(DWORD), &dwBytesRead ))
        break;
    Sleep(10);
}

Slightly more overhead, but you'll get the result as soon as it's available.

[blizzo]

Yes, that is a good idea I have something similar in my new code already. But you're code looks better
However, you do have to wait a bit longer after it has finished to make sure that the flags and registers are popped off the stack and ret is called otherwise Wow will crash cos the memory is deallocated while it's still being executed hehe. The Wow send error report is pretty useful for debugging (no surprise) I don't know enough (anything) about writing a debugger but some kind of break point would be a useful thing, at the return address so you read the result and de-allocate the memory then. Maybe when it's not 4AM

[Shynd]

You could also always do: (pseudo code)

HANDLE hThread = CreateRemoteThread(hProcess, NULL, NULL, (LPTHREAD_START_ROUTINE)codecaveaddress, NULL, NULL, NULL);
WaitForObject(hThread, INFINITE);
DWORD dwExit;
GetExitCodeThread(hThread, &dwExit); //dwExit is now the value of EAX when RETN is hit

Little more overhead but it makes it much easier to handle. If you're only calling it every once in a while, it shouldn't cause any problems.


And writing a debugger isn't too difficult. DebugActiveProcess API for the win. You just have to handle the breakpoints in the correct manner, something that's not documented very many places (if you're still interested, even after understanding how easily debuggers can be detected, let me know and I'll make a post about it).


Edit: Oh yeah, +Rep

[kynox]

You could also always do: (pseudo code)

HANDLE hThread = CreateRemoteThread(hProcess, NULL, NULL, (LPTHREAD_START_ROUTINE)codecaveaddress, NULL, NULL, NULL);
WaitForObject(hThread, INFINITE);
DWORD dwExit;
GetExitCodeThread(hThread, &dwExit); //dwExit is now the value of EAX when RETN is hit

Little more overhead but it makes it much easier to handle. If you're only calling it every once in a while, it shouldn't cause any problems.


And writing a debugger isn't too difficult. DebugActiveProcess API for the win. You just have to handle the breakpoints in the correct manner, something that's not documented very many places (if you're still interested, even after understanding how easily debuggers can be detected, let me know and I'll make a post about it).


Edit: Oh yeah, +Rep

This method won't work for any functions that read from the TLS (Being that its Thread local storage). Opening another thread won't have the TLS data in it, though you can put it in yourself

[Shynd]

Good catch, was still thinking in terms of other gamehacking I've done in the past. Hadn't really thought about it =p.

[kynox]

Haha, Yeah, it gave me a real run around when i first started out. In the end though i just hacked up some code to set the TLS in my thead to the s_curMgr pointer. Works a treat

[blizzo]

Looks good, I will have a go with create remote thread and setting the TLS.
Thanks for the rep Shynd

[blizzo]

I'm not an X86 ASM expert so I dunno if this is the best way to do it, but it appears to work:

This code will load the address of the Object Manager in to EAX. Not really of any use but easy to check to see if it worked.

0x00153C60 is the linear address of the thread-local storage array for the main thread.
FS:0x2C is where the linear address of the thread-local storage is stored, so if you over write it it should be good. Please correct me if i am wrong :]

AT&T Style
push %fs:0x2C
movl $0x00153C60, %fs:0x2C
movl %fs:0x2C, %eax
movl (%eax), %eax
movl 0x10(%eax), %eax
pop %fs:0x2C

Intel Style (Untested)
PUSH FS:0x2C
MOV FS:0x2C, 0x00153C60
MOV EAX, FS:0x2C
MOV EAX, DWORD PTR [EAX]
MOV EAX, DWORD PTR [EAX + 0x10]
POP FS:0x2C

I'm not that exactly how you write it in Intel style asm, i have been using GCC and that uses AT&T syntax which is pretty different.