Cheat Engine

[citerkoo]

Hi

I am trying to make a simple trainer for an old strategy game - Seven Kingdoms. Currently I am trying to make a table/list of all units on map.

I have found a static address ("7kaa.exe" + 0x2A431D), that contains pointer to an array of pointers, that point to some kind of "unit" structure. This "unit" structure contains unit's health, x/y map position and some other game attributes.

Each unit in this game has also a unique name. However, this is where I am stucked. I am unable to find a connection between the name and the "unit" structure.

By doing a string search for the name of my unit, I have found it in the big string array, that contains all possible unit names. But I am unable to find anything that would point to string of my unit's name or a little bit around it.

So I have tried to use the "Find out what accesses this address" function (on the found string of my unit's name) and it works. Whenever I select the unit in game, the address is accessed. (ce_1.png)

Disassembler shows, that this address is accessed by "msvcrt.strncpy" function, which makes sense, since by selecting the active unit, the unit's name is displayed on the main panel. Thus, it first has to be copied by the strncpy function (from the array into "7kaa.exe"+2AE3A0).

Now I am not sure how to continue. From disassembler window, I have tried to use the "Find out what addresses this instruction accesses" function on start of the "msvcrt.strncpy" function. (ce_2.png)

Whenever I select the unit in game, the "count" for addresses 005FF5A0, 005FF3D0, 005FF450 increments (ce_3.png)

But I am not sure what this means. The addresses point to some constantly changing block of memory. What might that memory be? Isn't it some kind of stack of actively executed instructions? (ce_4.png)

Any ideas how to continue?

[ParkourPenguin]

[citerkoo]

Yes, the data breakpoint is what I needed. Thanks.

My assembler skills are prety basic though, so it will take some time. So far I was playing just with the data part of the memory.

However when the msvcrt.strncpy function is called, the ESI register contains source address (with name of my unit) and EDI register contains the destination address ("7kaa.exe"+2AE3A0). So I guess I need to somehow find out, what fills the ESI register and based on what.

I just have few noob questions. Feel free to just link me some material that would explain it.

1. What are the "Parameters" in the stacktrace view?
2. Why the last (most deep) instruction is missing in the stacktrace? For example in my case, the last stacktrace line is the call of "msvcrt.strncpy" (or actually the next instruction executed after call of "msvcrt.strncpy"), but I would expect it to be the actual instruction (within the strncpy function) that is accessing the memory address that the breakpoint is on.
3. This is a more specific question to my problem, but it's not letting me understand the stacktrace, so I need to crack it

This is how I understand screenshot ce_1.png: on 74kaa.exe+B630C there is a function call of 7kaa.exe+E3FF0, which eventually leads to another nested function call of 7kaa.exe+164BC0 (strncpy), which accesses the watched memory address. Then it continues with 7kaa.exe+E400E instruction. That would make sense.

However if we look on functions one level to top of stacktrace (ce_2.png), it doesn't make sense to me. On 7kaa.exe+16FFBA there is a function call of 7kaa.exe+2C089C (which is supposedly some ntdll.RtlRestoreLastWin32Error) and it's not part of the stacktrace. When I go to that address, this is what I can see: ce_3.png. It's pointing to "and" instruction, which should be start of the ntdll.RtlRestoreLastWin32Error function, right? Then I scroll up and down, it somehow rearranges and the address/instruction (7kaa.exe+2C089C) is not even there anymore: ce_4.png

Is that a bug or am I doing something wrong? The scrolling part is probably a bug, but how to interpret in human words the call of ntdll.RtlRestoreLastWin32Error? What does that mean and why it's not part of the stacktrace? (after "unbreaking", game continues to run as expected, no error is thrown)

[ParkourPenguin]

View the stacktrace as either rsp+X or rbp+X: viewing the parameters and return addresses like that is bad.

CE has absolutely no idea what the real return addresses are or what the real parameters are. CE just looks through the entire stack and checks (1) if it's an address, (2) if it's in a module, and (3) if it's executable. If so, it's probably a return address. This is obviously a heuristic and is not definitive in any way.

The "parameters" are just stack space above the return address. CE doesn't account for any calling conventions, so again, this is a heuristic.

Use the stacktrace for viewing stuff on the stack. It alone can't be used for determining where functions begin and end.

[citerkoo]

I see. So the "Full stack" are actually raw values on stack and only those are 100% correct. The other stuff is just inferred by CE.

I think I am a little bit closer now. In the stack values there is a 1 byte number that corresponds to alphabetical order of unit's name. This number actually comes from the unit structure I have mentioned in first post. (If I analysed the structure more thouroughly at the beginning, this debugging wouldn't be necessary). And who would have believed that - the number also corresponds to position of the string in the "array" I have mentioned It's probably array of some structs, not just string array because of the weird stuff around it.

So far it works like that, already done some tests with different units and civilizations and the position matches correct name.

[citerkoo]

by the way I was able to finish that. the string array is actually just a string with fixed length array - the other weird data inside of it was just some leftover from previous stuff. so by knowing the name offset (pulled out from unit structure) and knowing the pointer to start of the array (pointer to that can be found on static address), it's easy to navigate to correct name. so thanks for help.

I wonder if CE's structure spider would be able to find that. The name offset in unit structure is actually not offset from the beginning of the whole array, but just from the civilization name string, which is just another string of that array. (so the array looks like ["CIV1", "NAME1.1", "NAME1.2", ..., "CIV2", "NAME2.1"...]) and there are no other pointers to that array - just the one to the beginning.