 |
Cheat Engine
The Official Site of Cheat Engine
|
| View previous topic :: View next topic |
| Author |
Message |
_Kasai
How do I cheat?
![]() Reputation: 0
Joined: 25 Feb 2026
Posts: 2
|
 Posted: Wed Feb 25, 2026 1:46 pm Post subject: No pointers found for address with a given offset |
 |
|
Hello,
I'm fairly new to cheat engine and I'm trying to find a pointer in the game Super Fancy Pants Adventure. The value I'm looking for triggers a glitch I'm looking to reproduce for speedrunning.
Once I found the value in cheat engine, I tried using "Find out what accesses this address" and "Find out what writes to this address" to figure out what the last offset for a pointer would be. All the assembly instructions that pop up use an offset of 70 or 78. (e.g. "fld qword ptr [esi+70]")
From here I ran a pointer scan, specifying "pointers must end with specific offsets" and entered 70 and 78 as the offset options. The pointer scan always returns no results. How can this be? If these values are being accessed by a pointer in the assembly code, shouldn't a pointer path exist? What am I missing?
|
|
| Back to top |
|
 |
Csimbi
I post too much
 Reputation: 98
Joined: 14 Jul 2007
Posts: 3360
|
| Posted: Wed Feb 25, 2026 2:35 pm Post subject: |
|
|
You already have the code and the pointer is in esi.
Why'd you scan for anything else?
Just use esi directly.
|
|
| Back to top |
|
|
ParkourPenguin
I post too much
 Reputation: 153
Joined: 06 Jul 2014
Posts: 4740
|
| Posted: Wed Feb 25, 2026 2:44 pm Post subject: |
|
|
| _Kasai wrote: | | From here I ran a pointer scan, specifying "pointers must end with specific offsets" and entered 70 and 78 as the offset options. |
That's not how that works. One is the last offset, the next is the second-to-last offset, and so on. If you don't know the last offset for certain, don't enter anything.
If that still doesn't work, a static pointer path might not exist for many reasons. Code injection is an alternative. Search "injection copy"
_________________
I don't know where I'm going, but I'll figure it out when I get there. |
|
| Back to top |
|
|
_Kasai
How do I cheat?
![]() Reputation: 0
Joined: 25 Feb 2026
Posts: 2
|
| Posted: Wed Feb 25, 2026 4:31 pm Post subject: |
|
|
| ParkourPenguin wrote: | | That's not how that works. One is the last offset, the next is the second-to-last offset, and so on. If you don't know the last offset for certain, don't enter anything. |
Ah, I see. Looks like I misunderstood how that worked.
Turns out the issue (I think) had to do with the address itself. When I used "Find out what accesses this address", the value of esi+70 wasn't actually the address of my value. The actual address I found was a few bytes over from there (My value was at 063C8AD3, whereas the instruction is accessing 063C8AD0). I'm assuming the instruction I found accessed that whole 8-byte chunk of memory, starting at 063C8AD0?
What I'm trying instead is setting the offset to 70 like before, but doing a pointer scan for 063C8AD0 instead. That's turning up a lot of results (before adding a pointer map or anything else). Is this the correct approach?
| Csimbi wrote: | You already have the code and the pointer is in esi.
Why'd you scan for anything else?
Just use esi directly. |
I'm not sure I totally understand what you mean. The esi register has the address of my value, right? At least once you add the +70 offset. But that's not the actual location of the pointer itself. What do you mean by "just use esi directly?"
|
|
| Back to top |
|
|
ParkourPenguin
I post too much
Reputation: 153
Joined: 06 Jul 2014
Posts: 4740
|
| Posted: Thu Feb 26, 2026 2:01 pm Post subject: |
|
|
| _Kasai wrote: | | My value was at 063C8AD3 |
That's an unusual address for a value to be at. Normally, most values are 4 or 8 bytes in size and aligned on a 4 or 8 byte boundary respectively: e.g. 4-byte addresses end in 0, 4, 8, or C.
IIRC the pointer scanner assumes a 4-byte alignment when compressing files used in pointer scanning. There should be an option hidden somewhere when you start scanning to disable compression (make sure you use multiple unique pointer maps when scanning) which should allow the pointer scanner to work with any alignment; however, I can't think of anything wrong with simply adjusting the last offset yourself. e.g. if the address you want is 063C8AD3, pointer scan for 063C8AD0, take any good result, and add 3 to the final offset of it.
| _Kasai wrote: | | What I'm trying instead is setting the offset to 70 like before, but doing a pointer scan for 063C8AD0 instead. That's turning up a lot of results (before adding a pointer map or anything else). Is this the correct approach? |
Yes, that should be fine. Manually adjust the last offset when you get a good result.
I would strongly suggest you always generate and use at least 1 extra pointer map when pointer scanning for a new address. Rescanning a pointer map is fine. See this video:
https://www.youtube.com/watch?v=3dyIrcx8Z8g
| _Kasai wrote: | | I'm assuming the instruction I found accessed that whole 8-byte chunk of memory, starting at 063C8AD0? |
I'd need to see the exact instruction. e.g. looking at `fld qword ptr [esi+70]`, the "qword ptr" part means the instruction should access the data at "esi+70" as a quadword (word = 2 byte, quadword = 4*2 = 8 bytes).
If that `fld qword ptr` instruction really does access your value, it's very weird why you're accessing a byte in the middle of such a value. Try adding the address 063C8AD0 to the address list manually and change the type to double (8-byte floating point type). It might make more sense.
_________________
I don't know where I'm going, but I'll figure it out when I get there. |
|
| 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
|
|
FAQ
Search
Memberlist
Usergroups
Register
Profile
Log in to check your private messages
Log in
