Tutorial Set 1 - Finding Player Base
This page is a sub page of: Tutorial Set 1
For more detailed instructions on finding values please see:
- Cheat Engine Tutorial Guide (x32)
- Cheat Engine Tutorial Guide (x64)
- Finding Values - Integers
- Finding Values - Floats
- Creating a cheat table - Full guide
Step 1[edit]
So I like to start by finding the player coordinates to start my search for the player base, and having an address for health will help.
So I have already found the Z coordinate for the player, add will now check what accesses the address.
And this is what I find.
So the blue fires constantly, the green seemed to fire randomly, and the purple fired when jumping.
To aid in the task I like to setup a quick hook, to grab the player coordinates base address, so I can have it on my table for reference.
So let's just check that first instructions on the list, it may prove the fire to often and cause problems. But let's just check to see what addresses are accessed by that instruction. But note the SUBPS when checking the instruction, the address will probably be the X coordinate (Z coordinate address - 8) because this is a packed instruction so it works on 16 bytes at a time.
And I find only one address. So let's setup a hook there to start.
Here is my working script.
And here is how the table is setup (after a game restart).
Step 2[edit]
Now we need to see what access the coordinates to get a base address, stored in the instructions registry, to start. But since we made our coordinate hook we can just grab the base that we store there, it will be the same since all the instructions that accessed it use the same offsets.
Note: I find it best to start with an instruction that constantly fires to insure that the base look up will also constantly fire.
So I will be searching for "00000000ED0A8600", in a size that matches the process's pointer size. And Since this is a 64 bit game we need to use an 8 byte type in hexadecimal format. But if this was a 32 bit game we would need to use a 4 byte type in hexadecimal format.
So let's start scanning, so after the first scan go back to the game and just run around and do stuff to try and spot and weed out any address that don't always hold the value, remember to try menus as well.
Note: You will find the address for the coordinate hook's base storage (i.e.: ptrCoordHook, 13FFF0000)
So we can add the ones that still hold our address to the table then let's see what accesses these.
Note: In many games you may have hundreds of addresses to check so this does take some time, and that's why Cheat Engine has the pointer scanner but some times this is much quicker and more likely to succeeded with some patience and practice.
Tip: Even after finding one that gets accessed, stop the debugger, but check some more. That first one may not actually be a good base, it could prove to be a dead end, and you will have to start over. This is where the patience comes in.
Tip: Use the F5 short-cut to check what accesses an address.
So this is what I got from the second address (top) and the third address (bottom). And that "+148" is used more so let's just start there. So let's mark that address with a "+148" as the description and put that some where we can reference later.
Note: I also like to stop the debuggers but not close the ones that are in the route of my back tracing.
So here the "R8" registry holds the base of our base so let's just copy the address and then do a scan for that one.
And after we check that none are changing values let's see what accesses these.
So only 2 of the addresses I found get accessed regularly, and I just like the way the "+48" looks (but this is a guess). So that is the direction I will be going.
So let's scan for the address stored in the instructions registry. And then start to check what accesses these.
So after Checking 48 addresses this is what I found.
The instructions with the "+48" was the first instructions found and I'm betting that it's a looping pointer, and thus a dead end. And you will often run into looping pointers when doing this. It may be a part of the inheritance system of the language used to write the compiler used for the game or engine, or a part of the inheritance system of the game or engine it self.
And the instructions marked in blue look like they might be part of an actor look up function, again a guess but I will be adding the instructions static address to my table and mark it so I can investigate it later.
But I'm liking that "+28" for the base, so down that road I shell go. Now this far in I like to find an instruction that only accesses this base, and add the instruction's static address to the table in case of a crash.
So let's scan for that base and start checking these to see what accesses them.
So I see that instruction with the variable offset, and the only other one I get is that "+38". So let's scan for that base and again see what accesses that address found in the scan.
And after checking 62 addresses this is what I find.
Just a guess, but I like that "+338". My thinking is the player object will always have more functions using it, so we should get more instructions.
Again I will and that instructions static address to the table.
And after a lot of addresses this is what i found.
So that "+28" looks good to me.
Now at this point it's good to note that we could stop and use an injection to hook that base for our table to use and then start using the pointer scanner to do the rest, no certainties though.
But let's just keep going for now.
So after checking like 70 some odd addresses this is what I find.
So the 2 instructions with the "+10" offset looks like it might be right.
So yet again let's grab that base address and do a scan, and start checking to see what accesses those addresses.
And after checking the only 3 address that I got in the scan this is what I found. In checking what addresses this instruction accesses I find a list, So lets go back a level and hook an instruction that only access the 1 base address.
Note: I went back a level to the other 5 instructions with the "+10" offset and found the same results, so this may be a dead end or just the end. This instruction may be the final actor look up function, and we could search the registries for some kind of identifier but I hate guess work.
So let's go back a level find an instruction that only accesses the 1 base address, and hook that to grab a base and start to try the pointer scanner.
So here is my script.
And the AOB I'm using.
AOB: 48xxxxxx48xxxxxx48xxxxxxxxxxxx48xxxx74xx48xxxxxxxxxxxx48xxxx74xx80xxxxxx74xx48xxxxxxxxxxxx4Cxxxxxx4Dxxxx74
Note: If the registries or offsets for the instruction change this will fail because of the assert. But the AOB should still find it, allowing for easier updating of the script.
So here is what my table is looking like.
And now let's build our pointer. So we should need a pointer like this to reach the X coordinate.
[[[[[[[[ptrPlayerBaseHook]+10]+28]+338]+38]+28]+48]+148]+80
Note: At this point we could start to use the pointer scanner to find a static base, just pointer scan for the base address stored in the player base hook (i.e.: The values stored in the ptrPlayerBaseHook symbol.
And that's the best I can do for finding a base address, hope it helps.
