Cheat Engine

[Kriogenic]

Hey there,

I have successfully built my own trainers in VB .net and C++ with many many older games. I recently tried with a couple of new games.

the main one being prototype.

I looked around the forum and found this
Need help with a pointer offset [ecx+eax*4]
Can't post urls yet but the topic ID is 457607

After following it I ran into an annoying issue.

(known address = 02D53010)
02D53010 = ecx+eax*4

02D53010-ecx = eax*4

(02D53010-02D53010) / 4 = eax <--- here the problem is that my ecx equals the known address

so 0/4 = 0 (if ignoring cannot divide by 0 if that even exists with hex arithmatic)

then 0*4 = 0...

But an offset of 0 does not work and I have been stumped on trying to figure this out.

Thanks,
Kriogenic

[Corruptor]

[ecx+eax*k] where k is the size of the datatype is often used to access arrays and stuff, so you can iterate through the array by increasing eax.

As for the Algebra you used to find out what's standing in eax, im not quite sure if you actually need it. In the post (the one w/ the id 457607), the problem is that line:

[Kriogenic]

First, thanks for your reply,
the whole instruction looks like this

[Corruptor]

Nice to know the pointer scan worked for you. Personally, i dont like to use it, takes ages for me (4 cores, wth me want too) and it's quite annyoing too since my cheat engine tends to crash when you attach it onto a process after closing the first one.

Difference doing it manually is that you have to think and guess. The actual way is finding out what instruction reads your variable, from the list, take the one that looks as a routine that could be possibly setting your ammo (eg, routines that are constantlly called all the time are often general instructions which dont use an actually static pointer), scan for variables holding its adress and scan for what accesses this pointer. The offsets you find out are usually there because the data is stored in a struct and accessed using a pointer to that struct. The ecx+eax*k offsets are usually arrays (e.g strings).

Now, the problem about doing it manually is that there is no real way of knowing if the instruction you took or the pointer from the search you took are the right ones. You can make guesses by looking into the functions accessing it, or when and how often it is accessed by those functions, but you of corse may always do a wrong guess.

Now, your instruction may be a result of choosing the wrong instruction from the list that "find out what accesses" gave you or the wrong variable from the search for 02D53010. Looks kinda strange to save the ammo in an array for me. Or maybe you got into some kind of temporary data. Then, again, it could be that the whole pointer chain is changed during that operation, leaving you with a dead adress which may happen if you do something "too big" (sutch as droping your weapon or even restarting the game and sutch). You also could have found and followed the number that is printed on the screen instead of the actual ammo (although i think you would have noticed).
Searching for them manually, all you can do is really estimating how the program could handle your ammo, estimating which function would do that, estimating which of the search results for you pointer could be the right one and do it over and over again if you took a wrong value. I allready did that for an 11-level pointer (pointer scan totally failed for me) and i had to retry several times.
Well, but now that you have the real pointer, you could also look into the offsets of it and compare it to the ones of the pointers you found so far. On this way you will at least be able to classify what went wrong.

[Kriogenic]

Thanks for the input, I will give it ago, as now I have the real pointer I will be able to compare my "guessed" results.

and it must definitely be the wrong address as the ammo is 4 bytes, not a string.

[Fresco]

maybe if you read this you'll understand
http://forum.cheatengine.org/viewtopic.php?p=5370193#5370193

also read the full topic if you're not convinced.

[Kriogenic]

Actually I have read over that topic many times scratching my head

[Fresco]

try pointer scanner
as for the manual way,
you're either doing something wrong or the pointer path is wrong.
or you're not writing all offsets.

can you post your procedure and results, also how many results?

[Kriogenic]

I have used the pointer scanner and found my result I am just curious to the manual way which I must be doing something wrong.

There is only one code that accesses the address.


This is the procedure I have been using.

Find the value using CE and add it to the table
right click "what accesses this address"
go into game change value and see the instructions
when the ONE instruction comes up I double click it
this will give me the "most likely pointer" and the offset mentioned above.
I then go back to CE and do a new HEX search for the "most likely pointer"
which gives me 5 addresses with the specified pointer.

I then double click the address I have in my table and check the pointer checkbox

for the address I try all 5 of those addresses while using the offset 0

This as far as i can tell should then if the address and offset is correct should make the new pointer address show in the table and be the value that was in my original found address but in all these cases when using offset 0 the value in my table becomes ?? or sometimes random values so I assume the address and offset is wrong therefor pointing to a wrong address?

This is on the first level of this 5 level pointer. so I can not continue to find the next pointers.

I know it is a 5 level pointer due to my pointer scan success, but I can get no information even close to my pointer scan.

[Corruptor]

As for the "what the heck am i doing wrong" question, im just gonna sum up a few criterias that i usually check getting such a problem.

1: Are you sure the value for your ammo you found using CE is the right one? If you eg. set it on 100, do you really have 100 ammo or such?

2: Did you pick the right instruction? (I asume you did since it seems to be the only one the CE showed you, but still) When is the instruction count increasing? Is it only increased one single time when you shoot (which would be the right one in most cases) or is it constantly called / also called in other random cases? Setting a breakpoint, does it ONLY break when you shoot? Was the first shot after activiating the find-out-function beeing shot by an npc and you might just be tracking down some random npc's ammo?

3:What about the functions name? Is it a name you know (eg. Memcpy or something like that)

4: Did you do the smallest possible thing that could make the game access the ammo? (i asume shooting is the best thing you can do though)

5: Did you acidently forgot to tick the hex-box in the search or did you search for something other then a 4-byte variable?

If you can answer all those questions correctly, then try one of those things:

6: If, after adding the pointer to you list (do NOT override the actual ammo value, just add a new list entry for that pointer), you repeat the "find out what accesses" step for the ammo value, is the value of ecx still the same? (If not, the event was "too big" and the pointer scan is mostlikely your only chance)

7: is the value in ecx near the one from esp? If yes, the pointer is mostlikely a parameter and thus useless (unless you plan on tracking it down using the debugger)

8: When you SET A BREAKPOINT to the instruction and do all the pointer search stuff WHILE THE GAME IS PAUSED, does it THEN work? Does oit suddenly stop working once you unpause the game? If so, the pointers are altered right after the shot and your chances beeing able to track them down in paused mode are small, though it might work.