Page 1 of 1

Hacking Solution?

PostPosted: Mon Apr 25, 2011 8:30 am
by PsychoTron
I've been decoding a game, and have a .dll injected, several hooks in place, and a few code patches, etc,. (I've made a lot of progress since the last time I was here.)

Here is the kind of stuff I'm trying to do now. This will be a new function, that needs to be in the games memory space.

Code: Select all
Note: This is just a made up example.
static __declspec(naked) int GetHealth()
{
   static int Result = 0;
   
        // My ASM isn't that great yet, so.. This may be wrong...
   __asm
   {
      mov eax, dword ptr ds:[0x005CB2C8]
      mov Result, eax
   }

   return Result;
}
// I'll probably have to write prolog\epilogs since these will be new functions.


I have several questions, is this a smart thing to do? Is it even possible? (Not sure why it wouldn't be.) What's the best way to go about it. (I know I need a code cave, but, are there any C++ methods I can use to find them, I plan to create lot's of functions. I can use MHS, but, would prefer an automatic method in my .dll, that way I can just write code, tell it to inject itself, and be done with it.)

This method should be fine, so long as the addresses are globals, not locals, correct? Would Read\Write process memory be a better solution?

That about covers my concerns, any help would be appreciated. :)

Re: Hacking Solution?

PostPosted: Mon Apr 25, 2011 10:49 am
by L. Spiro
Getting the code into the game only involves DLL injection.
Simply code your function in a DLL.
If the function is not replacing another function (IE: it is new) then you don’t need it to be naked.

Reading from an address that never moves can be hardcoded, but a more proper way is to calculate the address based off the base of the module containing the address, and the offset from that base that takes you to the desired address. It is also more of a pain in the ass and not strictly necessary when the module never moves to a new address.

After the DLL is injected you can reroute code to your function simply using local memory writes.


L. Spiro

Re: Hacking Solution?

PostPosted: Mon Apr 25, 2011 10:58 am
by PsychoTron
L. Spiro wrote:Getting the code into the game only involves DLL injection.
Simply code your function in a DLL.
If the function is not replacing another function (IE: it is new) then you don’t need it to be naked.


Okay, thanks. :)

L. Spiro wrote:Reading from an address that never moves can be hardcoded, but a more proper way is to calculate the address based off the base of the module containing the address, and the offset from that base that takes you to the desired address. It is also more of a pain in the ass and not strictly necessary when the module never moves to a new address.


Yeah, the address is in the .exe, so it's always going to be the same. (ie, already a pointer.)

L. Spiro wrote:After the DLL is injected you can reroute code to your function simply using local memory writes.


Can you elaborate, I'm not sure what you mean here. ? (A simple example might help, I learn better with visuals.)

I'm mainly wanting to use the functions to get\manipulate data from the game.

---

Btw, I've probably thanked you before, but thanks again for MHS, it has pretty much replaced every other hacking tool I ever used. :)

I use IDA to mark down changes, and track my decoding progress, I use MHS for everything else, it works great.

Re: Hacking Solution?

PostPosted: Wed Apr 27, 2011 4:29 am
by PsychoTron
Any chance you can explain what you meant by rerouting the code to my functions?

I have plenty of code available for doing the stuff, so, I'm sure I have the tools to do what you are suggesting, I just don't get what you mean.

I would really appreciate it if you could help me out here.

Re: Hacking Solution?

PostPosted: Wed Apr 27, 2011 2:37 pm
by L. Spiro
I mean placing a JMP from the original function to yours.
That means the game calls their function, goes into it, and is immediately sent to your function instead.
Once the control has reached their function, the stack has already been prepared. You need to unwind based on what was done inside their original function before control was averted to yours.


The alternative is to change the original code to call your function instead of calling the original function.


In any case, you can change any code to any other code using ::memcpy();—a local modification.


L. Spiro

Re: Hacking Solution?

PostPosted: Wed Apr 27, 2011 3:23 pm
by PsychoTron
L. Spiro wrote:I mean placing a JMP from the original function to yours.
That means the game calls their function, goes into it, and is immediately sent to your function instead.
Once the control has reached their function, the stack has already been prepared. You need to unwind based on what was done inside their original function before control was averted to yours.


The alternative is to change the original code to call your function instead of calling the original function.


In any case, you can change any code to any other code using ::memcpy();—a local modification.


L. Spiro


Alright, I understand what you mean now, thanks. :)

I already have a method for doing stuff like that, I was really hoping to create a new function, that acted like it was original game code, but I guess it isn't possible. (ie, as if the original programmers had made the function, ie, without replacing\changing\rerouting existing functions. Hope you understand what I mean.)

My method works like this..

0x00000001: mov VAR, value
0x00000002: more code..

I overwrite that with this.

0x00000001: jmp MyFunction -> [0x00000008]
0x00000002: more code..

0x00000008: mov Var, value
0x00000009: mov Store, Var // This is a C++ var. (Store)
0x00000010: jmp [0x00000002] // Then just return execution to the original function.

--

There are lot's of issues with this method, mainly having to do with multiple functions writing the target value.

If all the functions that write the target value, are only called when the game needs them, ie, not called every frame, then I would need to hook every single one to make sure I always have the proper value.

Since the values are globals(in most cases), using ReadProcessMemory, would be a better solution.

However, I want to inject a completely new function into a code cave, and then hook that function. That way I can always get the current value, and avoid ReadProcMem, which, seems inappropriate to me for some reason. (It's probably fine, I'm probably just fretting over nothing, but it seems out of place in a hook, it's more of a trainer technique in my mind.)

Re: Hacking Solution?

PostPosted: Wed Apr 27, 2011 8:09 pm
by L. Spiro
::ReadProcessMemory() only applies if you are working outside of the target process.
If you are injecting a DLL then use ::memcpy() or read the RAM directly.


L. Spiro

Re: Hacking Solution?

PostPosted: Wed Apr 27, 2011 11:11 pm
by PsychoTron
L. Spiro wrote:::ReadProcessMemory() only applies if you are working outside of the target process.
If you are injecting a DLL then use ::memcpy() or read the RAM directly.


L. Spiro


Alright, well that makes me feel better about it, I just was avoiding RPM, but memcpy() should work. :)

Well, thanks a lot L. Spiro, I appreciate you taking time to help me out. :D