I've injected some code to be called with the e8 opcode but when it does the program crashes.

When I run through the code with softice, instead of ret going to the next opcode, a NOP, it goes to address 0x00000000, then after that to the same random line every time(0x77FA15FC) instead of 0x6FF071C5 like it should. Because of my problem I've took out the extra code and left just the original code to be executed but the problem is still persisting.

The code to be called simply looks like:


void __declspec(naked) PatchCode(void)
{
__asm
{
sub esp, 0x238 // original code at patch location
ret
}
}


Any help would be appreciated.
Posted on 2004-02-05 02:01:22 by Maddox
When debugging with softice, look at the stack and see if the sub esp,0x238 really gets the right value for the stack or not. Seems to me you're sub'ing too little or too much.

Fake
Posted on 2004-02-05 04:07:09 by Fake51
When you subtract values from esp you are allocating stack space. Is that what you are trying to achieve?
Posted on 2004-02-05 07:26:39 by roticv

When debugging with softice, look at the stack and see if the sub esp,0x238 really gets the right value for the stack or not. Seems to me you're sub'ing too little or too much.

Fake


That is the original code from the application, IE, that is the EXACT code that would have been called even if I hadn't patched that location. That's why this problem is so weird.
Posted on 2004-02-05 09:17:40 by Maddox
But is there push ebp and mov ebp, esp in the code (and of course leave or similar instructions)? I bet there is because I think the function will result in the stack being imbalanced.
Posted on 2004-02-05 09:21:12 by roticv
Yeah, roticv is right, if this is the original code something is likely wrong: sub esp,238 typically sets up a stack space - if you don't realign it, you won't be jumping back to original code but to unknown parts. And jumping to 0x00000000 does seem to indicate this being the problem.

Fake
Posted on 2004-02-05 10:54:24 by Fake51
If that was the code that was overwritten by the CALL, then the RET is wrong. As everyone else says, the code changes the stack, and your return address is buried (no longer at the top of the stack).
Posted on 2004-02-05 13:18:20 by tenkey
Ah ok, I understand now. I installed my patch to a different location and it works perfect now.
Posted on 2004-02-05 18:37:59 by Maddox