Cheat Engine

[lucidity]

Hello everyone!

I've been learning the basics of gamehacking for a few months by reading these forums and I've been able to get really far with the available information and what's provided in the tutorial (and a bit of a programming background, but unfortunately no assembly until recently).

So far I've been successful in completing the tutorial and getting several values from a game, which work 99% of the time on 5 different computers, but sometimes the offset value changes.

I have the following values:
Current HP
Current MP
Max HP
Max MP

All of those values work - all of the time: even when the problem I'm writing about occurs, the above values work as expected.

There are some other values which aren't going to be meaningful to you unless you happen to play this game. As some background, these values are relative to a minigame, and they're generated server-side and passed to the client. I'd like to be able to track them automatically instead of writing them down, but sometimes my values won't work.

The problem values are all in very close proximity in memory, and the HP/MP values are much earlier in memory. I understand that's probably a result of the server-side nature of what is happening, but I'm able to -very- consistently get these values. Furthermore, I can guarantee that the value I am seeking is at one of two addresses, but I would prefer to really know how to find it and not just write a conditional statement as a band-aid.

If one of the values is normally located at:

game.exe+00FDFDFD, offset 215F

...it will occassionally be moved (during runtime) from that location to:

game.exe+00FDFDFD, offset 22DF (+180)

The difference for all of these problem values is *always* 0x180, but I'm not clear what the signficiance of that is. I've tried really hard to find other pointers that work (up to and including lv7) but these lv1 pointers are very reliable with the exception of this problem which is very consistent in nature. The scanner never seems to find alternative values, either during this problem or otherwise.

I've also tried to search memory for some kind of "offset complement" value, like 0 during a fresh restart and 0x180 during an occurance of this problem.

Once this happens, the +0x180 address becomes reliable until the game is restarted (I've never seen it increment).

I've tried to work this problem really hard but I'm not familiar with windows APIs or memory scanning in general... is it possible these values are part of some kind of larger struct that grows over time and displaces them?

When I scan during the problem I would get the same base address (game.exe+00FDFDFD), but the pointer scanner returns a different offset value. The offset value is the only thing that changes when the problem is occuring, and it changes for all of the problem values at the same time.

Can anyone give me some direction on this? Sorry if I got to rambling, but I wanted to try to give the best context possible.

Thanks for reading!

[Dark Byte]

that just means that the pointer is a level 2 or even higher pointer (high offsets are usually an indication of that)

Try using the debugger to find out the actual last offset or do a pointerscan with more levels

[lucidity]

Thanks Dark Byte! I'll give that a shot and report back but it may take a while because I need to run the scan, and I need to reproduce the problem.

Most of what I've seen on these forums suggests starting 4 or 5 levels, so I was already under the impression that 7 was high. Also, I'm running with a maximum offset of 65536. Can you recommend a reasonable maximum number of levels? Should I try 10, 15? 20?

I'd also be curious to know approximately what you consider to be a high offset so I can benefit from such clues in the future.

I really appreciate the help

[Dark Byte]

structsizse of 4096 is good enough, although 2048 is fine most of the time
(higher structsize will find more, but can also find overlapped memory regions (e.g object 1 is 64 bytes, object 2 is 512 bytes, it would then find object 2's value and assign it to object 1's offset)

as for level, level 5 is good enough, but if it doesn't take to long try a level 6 and then a level 7 until it takes too long for you. Just be sure you do regular rescans on the list to filter out the wrong pointers

[lucidity]

The problem I seem to be having with those pointers is that no pointer up to lv14 has been valid under both circumstances. Looking at the region of memory all night I've become convinced that's some kind of data structure since there are 10-20 evenly spaced elements, most filled with null bits but holding space, and that memory area has other elements added and taken from it, so the number of elements fluctuates depending on what you're doing.

I'm confused about the pointerscan startup, and how PTR files can be used (or if I am really looking for the "Improved pointerscan with gathered heap data" option).

During pointerscan, first you see a progress bar go across the bottom of the window with no contents within the pointer scan window, then the collapsed thread list appears. What happens in the first stage (progress bar), some kind of preparation to scan active memory?

Another thing I've been curious about is whether I could scan incrementally in levels. For example, if I scan Lv1, could I use the saved PTR file to continue and scan only Lv2 or Lv2+ (skipping the Lv1 pointers)? Right now I have to do a complete scan for Lv1, Lv2, etc... it runs reasonably fast up to Lv4 but Lv5+ begin to require some time.

All-in-all CE is a great piece of software, really friendly to newcomers, and has lots of fun toys/tools... once I master the pointer scan I'm going to move on to the data dissector

Edit: btw, about the offsets, my theory aligns with yours in regards to the correct offset being a lower number, the number is 16 (not 2150), and then there are sets of data (384?) bytes in length from that address