Cheat Engine Finding Values

[Eugene Aubry]

Wouldit be possible to avoid searching values and setting them (i explained, what I need bellow) in cheat engine? I know you can find pointers of adreses and create trainer, but the problem is that the apps, I use cheat engine on, get updated a lot by my companies, and the pointers change every time.Meaning, I would have to create new trainers multiple times a week. Basically almost every day..

I'm not asking for complete code, but some detailed info with links would be highly appreciated, as I have used cheat engine a lot, and I know a lot about programing, I have 0 experience and knowledge about cheat engine scripting.

Would it be possible to automate this? Yes it would be. You could automate this by creating a cheat engine script at the least or creating a trainer. Your question also states that you want to do it without creating a trainer, so no.

When the game you're working on updates frequently, you are correct that pointers become a burden to reverse and update each patch. The solution is to use array of byte signature scanning to locate assembly instructions that access the variables you're wanting to access. Don't worry CE has you covered on that as well, AOBScan().

Most of the time you can create a script that will handle updates. For example, once you find the address, right-click and do 'find out what accesses this address'. Wait for something to change the value and the window that pops up will show you the code that changes that address. Right-click on one of the results and open the disassembler. Let's say it's the line movsd xmm0,[ecx] here:

Select that line and hit CTRL+A to open the auto-assembler window. Then from the Template menu select 'AOB Injection'. Save this to your table and close the window, then open up that new script. There will be a line near the top that starts with aobscanmodule. If you see an error there it couldn't determine a unique signature for that memory location. If there is no error, then when the game is updated and the addresses change, it should still be able to find it. There should be a section that looks like this:

This is relocated code. The original code in the game is replaced with a jmp to a newly allocated memory area where this code is assembled, then the jmp return goes back to after that code in the original memory region.

You need to know a touch of assembly. The instruction movsd xmm0,[ecx] loads the floating point value in the memory location pointed to by ecx into the xmm0 register. This accesses the memory location you care about, so you could just set that value like this:

Now whenever the program tries to run that code which accesses that memory location, it will instead jump to the new memory location, update the value at that address to 500.0, then run the original code and jump back.

When the aobscanmodule line does show an error it means that there are too many sections of code that are too similar. The logic looks backwards and forwards several lines of assembly and looks for the hex bytes, ignoring addresses that might change if the game is updated. For instance nothing in that code will probably change when the game is updated, there are no pointers and just one fairly close jmp instruction.

To be extra careful you might want to stop the window that is finding code accessing that address, then right-click on that line of code and select 'find out what addresses this instruction accesses'. If more than one address appears in the window then you're kinda screwed without more help because it is a generic piece of code used for more values than just the one you care about.

I want to be able to fly around in the Pwn Adventure 3 especially because my first attempt at flying was not so great. I was only able to jumping high and float down slowly, or I could also somewhat freeze myself in mid-air, but it was very glitchy because of gravity. Hence it wasn't a great experience like you would imagine flying to be. So let's try this again on Windows.

To fly around we need to find where the position of the player is stored in memory. To do that we need to use the incremental scanning option provided by Cheat Engine to find the address. But we don't know exactly what we are looking for.

It's absolutely fine to do some trial and error with assumptions, but then I was watching a guided hacking video, and they were scanning for the height position - and that makes perfect sense because it's very likely that when you are higher or lower, the value would increase or decrease.

Hopefully, we can bring the number of possible addresses further down with the process we have already been doing a few times. Eventually, we reach a point where we have a lot of similar values that seem to be connected to the position.

To filter out the last few dozens or hundred of addresses, we can try to freeze the address' values. This will be an indicator for us to see if we have the correct value. Freezing all the suspected values will not let us jump properly, and that's exactly what we are looking for. You can freeze the values with the checkbox in the table, or pressing [space].

We can select only half of them, so that we can do a binary search for the value that froze our position. When we freeze a value, Cheat Engine will continuously set the value to the original one, and this should kinda freeze the player's height. Now based on the results of the first half, we continue making binary search decisions.

In my case, the first half did not work, so I selected the other half of the remaining addresses, and when I tried to jump, I was immediately pulled back to our current position this means that one of these addresses control the character's position. So I deleted the addresses that I didn't select and repeated this process. Eventually we get it down to just a few addresses in the list and find the real value.

Well, typically, we store a coordinate or a position value in a simple struct or array like (x,y,z), which means the other values should be right next to each other. So to find out the adjacent values, let's open up the memory view and observe. When we look around in the game, we see multiple values being updated. So these values seem to relate to the camera view direction. And when we don't change the camera's position but simply walk around, we see three packs of three values being updated. They could be X, Y, and Z.

The height value that we could modify is right next to the other coordinates! Now let's add these addresses to the list and try modifying them. Let's set X it to 0. We teleported to somewhere under the map! We are actually below Blocky's Revenge challenge room.

While playing around with the teleportation, the game crashed, which means all the values we had before are useless now. We have to do it all over again. As you can see, it can be tedious from time to time.

After finding the values by doing it all over again, it's time to do some pointer scans so that we don't lose the correct values. For finding the pointer, I want to do something special for the base address. We set the From and To range like shown below.

Cheat Engine supports strings as the address of a module. From last video we already found pointers based on this module, so I assume this could be a good reliable start for pointers. After the scan, we find about 99 different pointers from the base address. Our original offset from last video for the selected skill was at 0x0097e48 - let's see if we find that in the list.

So let's add a few of those to the address list, and then we kill the game, restart it, login, select a character and attach the Cheat Engine to the new Pwn Adventure process. Now if we look at the list, it points to some actual values. This looks good.

If we check out the pointer scan results from earlier, we see that some of them point to the correct values, but also many don't. But now that we have the right value, we can rescan the pointer list for only valid chains.

After the scan we have about 18 left and all of these should work. As you can see, they are just some kind of variation from another. This gives us confidence that the pointer path we found is reliable.

If we change the value of this address, we teleport, but we stay in mid-air. Gravity doesn't seem to apply to this change - because it's the player's camera, not the player. However, as soon as we move the camera it gets updated and we are back down.

Looking around the vicinity of the address, we can find the other coordinates as we did before and we can see it update when we move around. Also, we can find some other values that seem to be connected to the view direction, and when changing them, we also seem to control the camera tilt.

When I saw that I had an idea. I always wanted to fly around properly but the gravity in-game was always a problem. But it looks like we can fly freely without being affected by the gravity if we used the camera instead of the player.

We need to find a way not to update the camera view once the real character is moved. To do that first we can, of course, check what updates this variable or what writes to this memory location. We can use that cool Cheat Engine feature "Find out what writes to this address - F6" and then we go into the game, move the camera and we see the instruction in the assembly that writes to that address. We can override this assembly instruction with nops (No Operation) - doing this will simply do nothing anymore.

We can also freeze the position of the camera by doing the same thing. We find out which instructions write to the variable and replace the instruction with nops. Now we can't move at all, but we can update the values from Cheat Engine, and it updates in the game. This means we should be able to create a "game hack" that allows us to fly around the map as we like. However, that's for the next blog post, stay tuned!

Are server-sided values highly secured and impossible to find? No, at least one address out of billions of addresses connect to a server-sided address/value; also, if the value isn't server-sided, it's likely to be encrypted. Either way, it's hard to find, but NOT impossible. Why? Your display in the game will never update itself if there's not a display value, but this value can be randomizing at all times. As seen from the Lordz.io hacks, despite the game being multiplayer, you can still change a lot of display values, although you aren't changing the actual bytes that store the values.

3a8082e126