Making your table have the right addresses each time without having to re-scan every time you run
the game is something everybody wants, but a lot of people aren't sure how it's done. Finding the
game's native pointer path for the value you want to keep track of is the traditional way, but just
because it's traditional doesn't mean it's the best. In fact with how complex games are getting and
how many of them are being written in dynamically-managed languages nowadays (with some games
actually getting compiled in RAM each launch), a lot of games don't even have native pointer paths
built off of static base addresses anymore and the traditional pointer-finding method fails.
So I'm going to show you three modern techniques to make your table re-find the data for you each run.
For this tutorial I will be using the game Rogue Legacy as it's written in .NET and thus benefits from this.
Cheat Engine has a pointer scanner function now that's capable of finding all sorts of pointer paths
that the traditional methods won't find. It's fairly easy to use too. The first thing you're going to want
to do is the same as in any hack, and that is to scan the game to find what the current address of a
value is. In this case I'll go for health. Once you have that value found and it's in your table, right-click
it and choose one of the Find What ... This Address options.
Tip: I recommend you use "accesses" when possible, but in many cases "accesses" will be really slow
(for example when looking at coordinates) so choose "writes" if "accesses" is slowing things down.
Once Cheat Engine is logging what happens to our health address, I'm going to run around like a ninny
and get hit a few times and then look at the log window and see what popped up. In this case we're
trying to find the offset for health.
In this case it's pretty obvious that the offset is +118. You'll use this info to narrow down the pointer
searches. What you want to do now is Stop and Close that (bottom-right button) and then go back to
the normal address list. Right-click the health address you found and choose to run the Pointer Scanner.
When you do you'll see something like this pop up.
See the red highlighted parts? You're going to want to tell it to only keep results that end with a
certain offset, and then tell it that the final offset is 118 (because that's what we saw earlier).
The other two things you may want to change are the maximum offset (in this box it's decimal!)
and the depth. Generally the newer and more complex the game is, the bigger the max offset and
depths you may need to go. I recommend starting with an offset of 1024 and a depth of 4 for most
games, and if that ends in failure after a rescan then raise the values and try again. Anyways for
this game I'm using for an example, what's shown in the screen should be fine.
When you start the scan, it'll have you save the scan results somewhere. I recommend you choose a
place other than where your cheat tables are. I personally just made a "pointer scans" folder inside
the cheat table folder. Name the scan whatever you like. The scanning process can take from a minute
to an hour or more depending on the offset/depth...
So I recommend you have some Youtube videos or something to do in the meantime. Once it's done
with the initial scan you should see the results. Just like with a normal scan, the first set of results will
be the biggest, don't be scared by the number of results. What I recommend you do now is close the
game and restart it. Get back to where you were before, and scan for your health address, right-click it,
and open the pointer scanner. But this time, close the main popup window because you'll want to open
the previous scan results and work from there.
Simply put in the new address and let it filter the scan down. You could also simply give it the current
value instead of the address and let it work off of that, and while that is less work, it's also less precise,
as in it won't filter out as many bad pointers as specifying the new address itself will filter out.
Do a couple of rescans until you've narrowed it down to the point that it stops dropping tons of pointers
each scan. Unlike scanning for memory addresses normally, when doing pointer scans you will often
end up with a bunch of different pointers that work. Just like in life, there's many paths that can lead
to the same result, so don't expect the pointer scanner to go down to just 1-3 options like with normal
scans, because with many games you'll be left with 100 or more, all functional.
If pointer scanning isn't your thing or it's taking too long for you, a much faster method is to inject some
code that will copy the base address of the structure for us. As you saw in the above method, by looking
at code that reads/writes the address you can often find an offset. If you're looking for something like
player health, generally other stats like the player's mana and strength or whatever will be in the same
structure. You can try to find these addresses normally and see if they're very close or similar, if they're
very close to eachother (~1024 +/-) than you can usually be assured that they're in the same structure.
So the basic idea is to find some code that works on something in the structure, and then edit that code
a bit to make it copy the right data for us every time. The first obstacle will be to find code that only
affects the structure you want. For Rogue Legacy, let's find our health value, find what accesses it (as
before you may need writes instead if accesses brings up way too many things), then once you have some
functions there click Stop. Pick one of the instructions that has something like "eax+00000188" in it.
Basically you'll want a function that works off of a register plus an offset, so we know that it deals
with the base address of the data we want. Once you see an acceptable target, click one of the functions
and then click the "Show Disassembler" button to open the memory viewer at the right location.
So at the time that target code executes, ebx+00000118 is our health value. This means that ebx contains
the base address of the player structure and +0x118 bytes from that is the health value. So if we can edit
this script to constantly copy the value of ebx out for us, we can have a "pointer" to the player's health
address (and any other stats in the structure) that won't break across restarts!
Anyways as you see in the screenshot, this will show the game's code that's In the disassembler window,
and now we want to see if that target code works off of just the data we want (which is good) or if it's a
shared/global function that works for lots of different things (we don't want that in this case). Right-click
the code and click "Find what addresses this instruction accesses" and you'll see a new window.
Play the game some more and do various things, and check back on that window now and then. If it only
shows one address as being accessed (which is in this case our health address) then you're good. However
if it shows multiple addresses as being accessed, then that's not a decent target for this technique and you
will want to target something else. Preferably something that's either unique to the player (such as MP if
enemies don't have MP limits) or something that's only displayed for you and not the enemies (like some
of your stats or something).
So once you've found code and you're certain it only affects the address you're targeting and has the right
notation in it (register+offset so we know it knows about the base address), it's time to actually write the
script for it. With the line of code highlighted in the disassembler, press CTRL+A and that should open the
Auto Assembler window. In there go to Template - Cheat Table Framework Code, and then click
Template - AOB Injection. Click okay on the address it asks for (by default it'll use the address of the
line that was highlighted when you opened the AA window), and when it asks for a name you should give
it something short and descriptive. In our case we're targeting code that reads HP, so here I chose
"hpreading".
After accepting that, you'll see the injection script template that CE has generated. After erasing the
comments and spacing (I do that just so I don't have to scroll all the time), it'd look something like this.
Now in order to tell this script to additionally copy the base address for our use, we'll add just two lines to it.
The first line, the globalalloc() function, is shorthand for allocating some memory and registering a label to
it globally for other scripts and things to use. The first argument is the name for the label. Personally I
pick something like _xbase because I try to use an underscore to mark things exposed for the table, and I try
to name the base address value copies something meaningful. The second argument is the number of bytes
to allocate. For 32-bit programs and things using less than 4GB of RAM, in most cases you'll only need 4
The second addition is what tells the game to actually copy the base address for us. In almost all cases
it's as simple as telling AA to do "move, into the value of the allocated memory, the contents of the register".
Replace the register with whatever one is actually used with the offset in the original code, of course.
The idea is that when this script is turned on, the code that you targeted will also copy the base address of that
structure to the allocated memory each time. And this memory has a label that we can use in the table to
reference it. So after adding those lines to your script, go to File - Assign To Current Cheat Table.
Do not click "Execute".
Now that script should be an entry in your cheat table. You'll probably want to close the AA window and then
rename the script copy in the table or something. You should be able to check it, and it should enable. Then
to actually see the fruit of your labor and use the results of that script, in CE's upper portion click the
"Add address manually" button. In there, you can use either the pointer syntax or manually type in the base
and offset like [_playerbase]+118.
Yup, there we go, as long as that script is turned on the game will be copying the base address of the player
structure for our use, and we can pull up anything in that structure with that syntax. So you can keep finding
stats in that structure, and then with one script the game will always tell you the right addresses!
So you may have a structure (set of stats/options) that you want to target, but in some situations pointer
scanning and injection just aren't feasible options. You may be working with a game running in an
interpreted environment (flash, web browser, scripting) or one that updates quite often and the code
changes while the data you're targeting stays mostly the same. In these cases and more, you can create a
scan right to the data structure you need instead and have CE fill in the rest of the addresses for you.
So, going on the same example as above, finding the health address and it's offset. You're going to want
to do to two things with that offset. You're going to want to write it down for later (write something like
"+118 = health" in notepad) and you're going to want to take your health address and subtract 118 from
it in hex. The default Windows calculator program can operate in hex if you put it in scientific mode first.
Once you have your health address with 118 (in hex) subtracted from it, that's the address to the
start of the player/character structure. Back in CE, click Add Address Manually and put in that
address. The type doesn't really matter, but I tend to make it binary so that it stands out visually in
the address list. I did it here and named it Player Structure Start, though a name isn't really needed.
Now you're going to want to click that address and press CTRL+B to open the Memory Browser. You
should see a new window, and the bottom half will be divided into three sections, like the screenshot.
You're probably going to want to resize the Memory Browser window until the middle section measures
16 bytes/pairs across, like in the screenshot.
The left section is the starting address of each row, the middle of the actual RAM contents in Hexadecimal,
and the last row is the RAM contents expressed in ASCII. For this we want to focus on the middle section.
Click and drag in the middle section to select the first three rows or so. For some games just the first two
will do, for others you may need 5-7 rows, but for Rogue Legacy 3 is all we'll need. Once you have the
rows selected, press CTRL+C to copy them and then go and paste them into Notepad or something, making
sure to add back in the line breaks.
Then you'll want to close the game, start it back up, and do this again, copying another sample of what that
data looks like. I recommend doing things like loading in different characters and settings and a few
restarts just to make sure you have a wide range of samples. Here's four I picked up for this example.
**Code:** |
A8 1E 17 01 00 00 00 00 00 00 00 00 28 12 88 03
00 00 00 00 8F 00 00 00 56 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 40 00 00 00 00
A8 1E E3 00 00 00 00 00 00 00 00 00 28 12 88 03 A8 1E 6B 03 00 00 00 00 00 00 00 00 28 12 87 03 A8 1E 75 05 00 00 00 00 00 00 00 00 28 12 75 03 |
**Code:** |
A8 1E ?? 0? 00 00 00 00 00 00 00 00 28 12 ?? ?? 00 00 00 00 8F 00 00 00 56 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 40 00 00 00 00 |
Now that you have your data signature to the player base, it's time to make the script that will scan for it.
Go back to the memory browser and in it, press CTRL+A to open the Auto Assemble window. Paste this.
**Code:** |
[ENABLE]
aobscan(player, A8 1E ?? 0? 00 00 00 00 00 00 00 00 28 12 ?? ?? 00 00 00 00 8F 00 00 00 56 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 40 00 00 00 00)
label(_player)
registersymbol(_player)
player: [DISABLE] |
If you can click to check that script and it checks (it may take a second or two while it scans), then you're
good to continue. If it does not check by the time CE starts responding again, then that means it could
not find a match for the signature so you should double-check on that.
So what was all this signature work for anyways? Well, now's the time to see the fruits of your labor.
Remember how I had you note down what the health address was? Well, go to add an address manually
and for the address, type _player+118 (or whatever the health offset is). That's right, CE will understand
what you mean and when you run the script and it finds the player structure start and assigns it the label
of _player, any other addresses that work off of that will have it filled in. So let's say I added mana too.
Then I check the script and...
Bam, the table did the scan and finding and assigning for me so I don't need to scan for those values
manually any more. All you have to know is a signature for the structure and the offsets, and you can
make a scan like this. When it breaks, generally you only need to update the signature being scanned
for and the rest will fix itself. Feel free to keep scanning and adding offsets!