|
Cheat Engine The Official Site of Cheat Engine
|
View previous topic :: View next topic |
Author |
Message |
stillnab How do I cheat? Reputation: 0
Joined: 19 Apr 2024 Posts: 3
|
Posted: Fri Apr 19, 2024 2:43 pm Post subject: A question about pointers |
|
|
Hello everyone,
So I've downloaded a small game to practice reverse engineering, and I started by finding the coins address after multiple scans (for example 1B0DAE2C)
To get the offset, aside from the pointer scanning method, I found out what writes to the address and adds coins, and I've came across the following info:
072A8A4D:
072A8A47 - 8B 75 08 - mov esi,[ebp+08]
072A8A4A - 8B 45 0C - mov eax,[ebp+0C]
072A8A4D - 89 46 1C - mov [esi+1C],eax <<
072A8A50 - 8B 76 08 - mov esi,[esi+08]
072A8A53 - 8B C6 - mov eax,esi
so i verified eax = new coins value, esi+1C equals my coins address, and verified esi is the player address but that changes each game session
a little above, esi = ebp+08 (and I found out ebp stays the same after restarting the game)
I then went to add ebp as a pointer base address and +08, 1C as offsets
but that always returned a wrong address, what am I doing wrong?
I also summed ebp+08 together as base address then made one offset (1C) but same wrong result
I know it shouldn't be that simple but I'm lost on what to do next. Appreciate any help during my learning journey, thanks!
Description: |
|
Filesize: |
11.98 KB |
Viewed: |
659 Time(s) |
|
Description: |
Trying to add the pointer |
|
Filesize: |
14.46 KB |
Viewed: |
659 Time(s) |
|
Description: |
Instructions that modify the coins address |
|
Filesize: |
73.63 KB |
Viewed: |
659 Time(s) |
|
|
|
Back to top |
|
|
ParkourPenguin I post too much Reputation: 142
Joined: 06 Jul 2014 Posts: 4342
|
Posted: Fri Apr 19, 2024 3:09 pm Post subject: |
|
|
stillnab wrote: | ebp+08 (and I found out ebp stays the same after restarting the game) | EBP is being used as the stack frame pointer. The value at ebp+08 is a temporary whose lifetime is limited to only that function. You can't use it as a pointer since it's not being used as that particular pointer >99% of the time.
You'd have to look much further to find the actual next node in the pointer path. `ebp+8` is the first parameter passed to the function (assuming stdcall/cdecl; there are other calling conventions that use registers for parameters). Look at the caller to see where this parameter comes from.
Code: | ...
mov edx,[ebp+0C]
push ecx
push [edx+40]
call wherever
push ebp
mov ebp,esp
...
mov esi,[ebp+08]
mov eax,[ebp+0C]
mov [esi+1C],eax
...
mov esp,ebp
pop ebp
ret
... | Here, 0x1C is the last offset and 0x40 is the next-to-last offset.
_________________
I don't know where I'm going, but I'll figure it out when I get there. |
|
Back to top |
|
|
stillnab How do I cheat? Reputation: 0
Joined: 19 Apr 2024 Posts: 3
|
Posted: Fri Apr 19, 2024 10:20 pm Post subject: |
|
|
ParkourPenguin wrote: | stillnab wrote: | ebp+08 (and I found out ebp stays the same after restarting the game) | EBP is being used as the stack frame pointer. The value at ebp+08 is a temporary whose lifetime is limited to only that function. You can't use it as a pointer since it's not being used as that particular pointer >99% of the time.
You'd have to look much further to find the actual next node in the pointer path. `ebp+8` is the first parameter passed to the function (assuming stdcall/cdecl; there are other calling conventions that use registers for parameters). Look at the caller to see where this parameter comes from.
Code: | ...
mov edx,[ebp+0C]
push ecx
push [edx+40]
call wherever
push ebp
mov ebp,esp
...
mov esi,[ebp+08]
mov eax,[ebp+0C]
mov [esi+1C],eax
...
mov esp,ebp
pop ebp
ret
... | Here, 0x1C is the last offset and 0x40 is the next-to-last offset. |
Thanks for the tips.
I just want to confirm, do you mean I should step out of functions and track esi until it's 00000000 then take the 1st assigned address as base then offsets from there?
So far that's the way I learned it through reverse engineering (from gamehacking academy) I hope I didn't get it wrong
I was also wondering, pointer scanning returns A LOT (tens or even hundreds) of correct pointers that point to the right place after multiple game restarts, is that something I should worry about? Should I still narrow my scanning until there are a couple ones?
Thank you
|
|
Back to top |
|
|
ParkourPenguin I post too much Reputation: 142
Joined: 06 Jul 2014 Posts: 4342
|
Posted: Sat Apr 20, 2024 2:46 am Post subject: |
|
|
stillnab wrote: | I just want to confirm, do you mean I should step out of functions and track esi until it's 00000000 then take the 1st assigned address as base then offsets from there? | No. I don't know why esi being 0 would be of any particular importance, and it's not like stepping over instructions would let you go backwards in time to see what esi was.
The value of any particular node in the pointer path isn't that important. If you really want to find a pointer path by analyzing assembly, you only need to look at assembly.
Start at an instruction that accesses the address you want to find a pointer path to. Take note of any dereferences made (i.e. [esi+1C]) and where the current node came from (i.e. `mov esi,[ebp+08]` => esi = 1st parameter), step over instructions until you get to the caller, and repeat until you eventually come to a static address. Or maybe you don't, and the base address is just a local in the stack that lives for the entire lifetime of the game- effectively a static address.
Maybe you'll come across something weird, like a hash table, before you get to any kind of static address.
The pointer scanner will find any path, not just the path(s) the game uses. Tens, hundreds, even thousands isn't unexpected.
I'd prefer paths with lower max level & offsets. Common offsets can also indicate which nodes are more likely used by the game. Of course, as long as they work, they're all correct in a practical sense.
_________________
I don't know where I'm going, but I'll figure it out when I get there. |
|
Back to top |
|
|
stillnab How do I cheat? Reputation: 0
Joined: 19 Apr 2024 Posts: 3
|
Posted: Sun Apr 21, 2024 8:10 am Post subject: |
|
|
ParkourPenguin wrote: | stillnab wrote: | I just want to confirm, do you mean I should step out of functions and track esi until it's 00000000 then take the 1st assigned address as base then offsets from there? | No. I don't know why esi being 0 would be of any particular importance, and it's not like stepping over instructions would let you go backwards in time to see what esi was.
The value of any particular node in the pointer path isn't that important. If you really want to find a pointer path by analyzing assembly, you only need to look at assembly.
Start at an instruction that accesses the address you want to find a pointer path to. Take note of any dereferences made (i.e. [esi+1C]) and where the current node came from (i.e. `mov esi,[ebp+08]` => esi = 1st parameter), step over instructions until you get to the caller, and repeat until you eventually come to a static address. Or maybe you don't, and the base address is just a local in the stack that lives for the entire lifetime of the game- effectively a static address.
Maybe you'll come across something weird, like a hash table, before you get to any kind of static address.
The pointer scanner will find any path, not just the path(s) the game uses. Tens, hundreds, even thousands isn't unexpected.
I'd prefer paths with lower max level & offsets. Common offsets can also indicate which nodes are more likely used by the game. Of course, as long as they work, they're all correct in a practical sense. |
Thanks for the insights! perhaps it isn't worth it going through assembly for pointers, I guess I'll just go with pointer scanning
|
|
Back to top |
|
|
|
|
You cannot post new topics in this forum You cannot reply to topics in this forum You cannot edit your posts in this forum You cannot delete your posts in this forum You cannot vote in polls in this forum You cannot attach files in this forum You can download files in this forum
|
|