View previous topic :: View next topic |
Author |
Message |
jobeth213 Newbie cheater Reputation: 0
Joined: 27 Sep 2016 Posts: 22
|
Posted: Fri Nov 13, 2020 10:48 pm Post subject: Code cave crashing the game using C++ |
|
|
Hi guys I am trying to call a function from the game outside of game exe(using my own exe program) but the game is always crashing, in cheat engine it work, but in my program it is crashing. The game is x86
Here is the full code in C++. Every GetLastError is returning 0, but the game is still crashing.
Code: |
if (!isInjectionDone)
{
BYTE codeCave[16] = { 0x6A ,0x00 //PUSH 00
,0x6A ,0x00 //PUSH 00
,0x6A ,0x01 //PUSH 01
,0xB9 ,0x00 ,0xB5 ,0x2E ,0x01 //mov ecx,012EB500
,0xE8 ,0x2F ,0xF6 ,0xFC ,0xFF //call 004DA8E0
};
isInjectionDone = true;
} |
_________________
I'm idiot
Last edited by jobeth213 on Sun Nov 15, 2020 6:00 pm; edited 2 times in total |
|
Back to top |
|
|
ParkourPenguin I post too much Reputation: 140
Joined: 06 Jul 2014 Posts: 4289
|
Posted: Fri Nov 13, 2020 11:36 pm Post subject: |
|
|
The E8 CALL opcode uses a rel32 displacement from RIP (address of next instruction). The address of the memory given by VirtualAllocEx shouldn't be assumed to be deterministic unless the second parameter, lpAddress, is not NULL. You'll need to do a little math and change the rel32 displacement depending on where the instruction is located in memory.
That's the first thing I saw that was wrong. I didn't look at the rest in much detail.
_________________
I don't know where I'm going, but I'll figure it out when I get there. |
|
Back to top |
|
|
jobeth213 Newbie cheater Reputation: 0
Joined: 27 Sep 2016 Posts: 22
|
Posted: Fri Nov 13, 2020 11:47 pm Post subject: |
|
|
ParkourPenguin wrote: | The E8 CALL opcode uses a rel32 displacement from RIP (address of next instruction). The address of the memory given by VirtualAllocEx shouldn't be assumed to be deterministic unless the second parameter, lpAddress, is not NULL. You'll need to do a little math and change the rel32 displacement depending on where the instruction is located in memory.
That's the first thing I saw that was wrong. I didn't look at the rest in much detail. |
Can you teach me how to do math bro, I don't know too much about asm, I just found this function by reading alittle about asm.
_________________
I'm idiot |
|
Back to top |
|
|
Csimbi I post too much Reputation: 94
Joined: 14 Jul 2007 Posts: 3108
|
Posted: Sat Nov 14, 2020 3:41 am Post subject: |
|
|
Should be simple math - just calculate the offset from following instruction (EIP/RIP likeParkourPenguin said) and use that offset.
Might be a good idea to debug on the first try to see if you land on the right instruction of the call.
As you said, CE will do it right - you can debug that and see what's the difference between your offset and CE's, then adjust your math.
|
|
Back to top |
|
|
ParkourPenguin I post too much Reputation: 140
Joined: 06 Jul 2014 Posts: 4289
|
Posted: Sat Nov 14, 2020 12:02 pm Post subject: |
|
|
- Take the address of the call instruction and add 5 to it. This is the address of the next instruction and where it will be jumping from.
- Subtract that value from the address you're jumping to.
- Write the resulting signed little-endian 32-bit integer to the rel32 displacement in the call instruction.
e.g. if VirtualAllocEx gives 0x65A00000, the bytes would be 004DA8E0 - 65A00010 = D0 A8 AD 9A
_________________
I don't know where I'm going, but I'll figure it out when I get there. |
|
Back to top |
|
|
jobeth213 Newbie cheater Reputation: 0
Joined: 27 Sep 2016 Posts: 22
|
Posted: Sat Nov 14, 2020 10:02 pm Post subject: |
|
|
ParkourPenguin wrote: | - Take the address of the call instruction and add 5 to it. This is the address of the next instruction and where it will be jumping from.
- Subtract that value from the address you're jumping to.
- Write the resulting signed little-endian 32-bit integer to the rel32 displacement in the call instruction.
e.g. if VirtualAllocEx gives 0x65A00000, the bytes would be 004DA8E0 - 65A00010 = D0 A8 AD 9A |
thank you ParkourPenguin Its working now but I am getting
57 (0x39)
A network adapter hardware error occurred,
from GetLastError() of VirtualFreeEx then the game crash,(I can see the function being called from the game though)
_________________
I'm idiot |
|
Back to top |
|
|
ParkourPenguin I post too much Reputation: 140
Joined: 06 Jul 2014 Posts: 4289
|
Posted: Sat Nov 14, 2020 10:35 pm Post subject: |
|
|
Are you sure you got this working in CE? Did you use the auto assembler (alloc, createthread, etc) or something else?
Unless the function 004DA8E0 kills the thread, there's nothing stopping your thread. If that function simply returns, it'll run memory you didn't initialize. Add a ret instruction after the call, or do a tail call.
Also, read the documentation before using an API:
Quote: | VirtualFreeEx function
...
dwSize
The size of the region of memory to free, in bytes.
If the dwFreeType parameter is MEM_RELEASE, dwSize must be 0 (zero). | https://docs.microsoft.com/en-us/windows/win32/api/memoryapi/nf-memoryapi-virtualfreeex
_________________
I don't know where I'm going, but I'll figure it out when I get there. |
|
Back to top |
|
|
jobeth213 Newbie cheater Reputation: 0
Joined: 27 Sep 2016 Posts: 22
|
Posted: Sat Nov 14, 2020 10:55 pm Post subject: |
|
|
ParkourPenguin wrote: | Are you sure you got this working in CE? Did you use the auto assembler (alloc, createthread, etc) or something else?
Unless the function 004DA8E0 kills the thread, there's nothing stopping your thread. If that function simply returns, it'll run memory you didn't initialize. Add a ret instruction after the call, or do a tail call.
|
Edit:I solve it now,thanks ParkourPenguin. You are right add RET opcode in the codeCave. I added the wrong byte hex 0x03 instead of 0xC3
_________________
I'm idiot |
|
Back to top |
|
|
|