Memory Hacking Software

I'm working on a new game, and it seems to dislike being hacked. (It shouldn't have any protection aside from DMA, it's a NoCD.)

I used your Auto-Assemble feature to produce an identical patch to one I am applying from C++, and yours works, while mine fails. ? (Crashes)

I've checked the debugger, and my patch is being applied, and looks just like yours. So I don't get it, are you catching errors or something? (The game uses SEH functions, lot's of them, could this be an issue? My hooks should be fine, I use the same code for other games without issues. It always writes my patches perfectly.)

Also, if it helps, I'm using MS Detours for some stuff, and I have this issue with it. (This method also works fine in other games.)

Code: Select all

DWORD __stdcall Hook_Tester(DWORD value)
{      
   DWORD res = Real_Tester(value);
    Log(value); // Prints to console.
   return res;
}


That code works fine.

Code: Select all

DWORD __stdcall Hook_Tester(DWORD value)
{      
    Log(value);
   return Real_Tester(value);
}


This version crashes the game. (All my Detours have this issue, if I make any changes before calling the original function, it crashes the game.)

--

So is any of this ringing any bells? I can show you any code you need to see, etc,. I just didn't want to flood this post with excess info, since I don't know what's relevant. (Never had this issue before.)

I thought I was corrupting the stack\registers, etc, but I tried pushad\popad\pushfd\popfd, I checked my version against yours, etc,. I can't figure out what the problem is.

---

Edit: Also, casting functions to pointers, and invoking them crashes the game too. (This also works fine in other games.)

The only thing I can think of, is, that you are applying some sort of fix, that I'm not, or something. As far as causes, I was reading about SEH, and it appears to make a copy of the stack, and compares it against the original to look for exceptions, that's what I think is causing this.

Sometimes (usually) simple is better.

When my ASM injector runs it calculates the number of instructions being overwritten by the JMP and how many bytes are in those instructions.
Then optionally allows you to add them to the end of your own ASM before JMP’ing back to the original code.
Normally you hook the call to the function rather than the function itself, though you can go either way.

Detours is complicated, and it does not do exactly the same thing (you hook the function itself rather than the call to the function).

If it is doing SEH checks, these probably are getting in the way.
Debug the game is possible and see what Detours has written.
Detours is designed to allow you to completely replace a function with your own, and optionally call the original function too.
To facilitate this functionality its injection will be much more complicated than in MHS.


If you have a static injection, it would be best to just use MHS to get the actual bytes to write to RAM and then just write those bytes to RAM.

Also, try naked functions. With care.


L. Spiro

Alright, I'll give some of your suggestions a try.

Btw, I must not have been clear, I use Detours, but, I also use a method that writes the bytes just like MHS, I mainly use it for mid function hooks, or patches. (The difference is, it gets the code from my C++, rather than a byte array, ie, it reads the __asm and uses that, that's why I have the naked functions, because I don't want epilog\prolog\s in a patch.)

Both methods are failing when I mess with values on the stack. (Even just logging them can sometimes crash the game.)

Regardless, I have a function that can write byte arrays too, I'll try some simple single instruction patches, ie, (mov eax, 1) -> (mov eax, 5), etc,.

Anyways, thanks, I'll report back on my results.

Instructions such as CALL and RET/RETN implicitly modify the stack.
Using a non-naked function in C++ is also an implicit source of stack modification.

Keep these in mind as you work.


L. Spiro

Makes sense, I'll have to try to tread lightly then.

I just tried a single instruction patch, and it worked without crashing, for simplicity, I replaced the instruction with an identical instruction, just to rule out any protection scheme catching me writing data.

Next, I'll try making a new change, but the code uses so much DMA, it's hard to make simple changes, it's always working with pointers, so I can easily crash it, if I'm not careful. (I'll have to find something like, increase money, etc, where I can get away with adding values, etc,.)

Well, after some more testing, even MHS injected code will crash the game, it must be SEH causing the issue. ? (Or else it uses some method like, GetTickCount(), to check execution time, etc,. It's doing something block my efforts, that is for sure.)

I can access vars, and have a game loop hook, so I should still be able to hack the game, just not using such brute force methods. Which limits me in a number of ways, but, with enough studying, I should be able to work around most of the issues that are in my way.

My main goal is to fix a game bug, it's a very annoying bug.