Cheat Engine Forum Index Cheat Engine
The Official Site of Cheat Engine
 
 FAQFAQ   SearchSearch   MemberlistMemberlist   UsergroupsUsergroups   RegisterRegister 
 ProfileProfile   Log in to check your private messagesLog in to check your private messages   Log inLog in 


A question about pointers

 
Post new topic   Reply to topic    Cheat Engine Forum Index -> Cheat Engine
View previous topic :: View next topic  
Author Message
stillnab
How do I cheat?
Reputation: 0

Joined: 19 Apr 2024
Posts: 3

PostPosted: Fri Apr 19, 2024 2:43 pm    Post subject: A question about pointers Reply with quote

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!



cap3.PNG
 Description:
Trying again
 Filesize:  11.98 KB
 Viewed:  659 Time(s)

cap3.PNG



cap2.PNG
 Description:
Trying to add the pointer
 Filesize:  14.46 KB
 Viewed:  659 Time(s)

cap2.PNG



cap1.PNG
 Description:
Instructions that modify the coins address
 Filesize:  73.63 KB
 Viewed:  659 Time(s)

cap1.PNG


Back to top
View user's profile Send private message
ParkourPenguin
I post too much
Reputation: 142

Joined: 06 Jul 2014
Posts: 4342

PostPosted: Fri Apr 19, 2024 3:09 pm    Post subject: Reply with quote

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
View user's profile Send private message
stillnab
How do I cheat?
Reputation: 0

Joined: 19 Apr 2024
Posts: 3

PostPosted: Fri Apr 19, 2024 10:20 pm    Post subject: Reply with quote

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
View user's profile Send private message
ParkourPenguin
I post too much
Reputation: 142

Joined: 06 Jul 2014
Posts: 4342

PostPosted: Sat Apr 20, 2024 2:46 am    Post subject: Reply with quote

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
View user's profile Send private message
stillnab
How do I cheat?
Reputation: 0

Joined: 19 Apr 2024
Posts: 3

PostPosted: Sun Apr 21, 2024 8:10 am    Post subject: Reply with quote

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
View user's profile Send private message
Display posts from previous:   
Post new topic   Reply to topic    Cheat Engine Forum Index -> Cheat Engine All times are GMT - 6 Hours
Page 1 of 1

 
Jump to:  
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


Powered by phpBB © 2001, 2005 phpBB Group

CE Wiki   IRC (#CEF)   Twitter
Third party websites