Cheat Engine

maxmakki · How do I cheat? Reputation: 0 Joined: 29 Jun 2012 Posts: 7

Hello everyone,

I'm running Cheat Engine version 6.2 on 64-bit windows 7. I ran into a rather unusual problem recently with static pointers. When I run a game, the static pointer works great, it keeps up with the changing addresses during map changes, through cut scenes, etc. When I exit a game, then start it back up, the static pointer has a value of "??" and is not pointing to the right address.

Now here is where it gets strange. I run through the steps of getting to that pointer again (without deleting the original pointer), do an action in game, check for a change until I see the right addresses pop up. After I find the right dynamic address I choose, "Find out what writes to this address". As soon as I select that, my original pointer (which was untouched) becomes active again. It points to the right dynamic address and has a value. It seems like the pointer can't find the right address until I attach the debugger to the game.

It gets even stranger. I made a C++ console trainer to access the static pointer and change the value. Like the pointers in Cheat Engine, my trainer can not read or write to the address. However, as soon as I find the dynamic address and select "Find out what writes to this address", my trainer works, it once again is capable of reading and writing to the static address. Now, I can't simply attach the debugger to any address, it has to be to the current dynamic address that I find for the value I want to change, once I attach the debugger to this dynamic address, my pointer and my trainer start working again.

Has anyone experienced this before? If so, how did you work around this?

Dark Byte · Posted: Fri Jun 29, 2012 6:07 pm Post subject:

Well, in ce I'd say, rightclick and choose "Recheck symbols" in case the symbolhandler still has the old symbollist, but as you stated it also acts strange in your own process

Try following the path and sees where it goes wrong. Then attach the debugger and check the value that gets written.
Perhaps your pointerpath goes through the process info block and takes the debugflag as a pointer ?

Does this happen with every debugger interface? VEH, windows, kernel ?

maxmakki · How do I cheat? Reputation: 0 Joined: 29 Jun 2012 Posts: 7

Hi Dark Byte,

Thank you for responding, and thanks for this great software!

I am using the VEH and the kernal debuggers. The windows debugger crashes the game.

Both debuggers illicit the same results. The pointer value changes to ?? when the game is restarted. I just tried "Recheck Symbols" with no luck.

By 'following the path', are you referring to the multi level pointer retrieval process? If so, the path is always exactly the same, the pointer is one level deep with the same offset and the same base address.

Would you be so kind as to provide me with a resource about 'process info blocks'? It is possible that is responsible for the results I'm getting. Perhaps there is a quick workaround to get past this?

Thanks

Max

Dark Byte · Posted: Fri Jun 29, 2012 6:41 pm Post subject:

Really? Kernel debugger makes the pointer work?
With veh I can understand as it probably contains the address of last break in the stack, that a pointerpath might come though, but the kernelmode breakpoint should have it's only trace in a kernelmode stack that is unreadable by the usermode part

Can you read the base pointer without attaching the debugger ?

Also, is the base pointer really a base pointer? Is it located inside a module ?

maxmakki · How do I cheat? Reputation: 0 Joined: 29 Jun 2012 Posts: 7

Hi Dark Byte,

I will have to reboot to test out the kernel debugger again, power went out for a split second and by force of habit I started windows normally. Until I reboot and test it out, I will continue under the assumption that the kernel debugger does [i:a677035489]not[/i:a677035489] affect the pointer per your response (you know your program better than I!).

By 'read the base pointer' do you mean read the address it points to? If so it's always something like:

p->10000001E - and yes, that's 9 characters and not 8. When I attach the VEH debugger it points to the correct 8 character dynamic address.

I'll need a little more information to answer your last question. Manipulating a process's memory is something I only recently started doing. What does it mean for a pointer to be 'inside a module'? Perhaps it's not really a base pointer after all! In which case it would be a noob mistake (which I'm hoping for).

Thank you!

Max

Dark Byte · Posted: Fri Jun 29, 2012 7:14 pm Post subject:

Is the target process 64-bit ?

What I meant is are the 4 (or Cool

bytes of the base address readable? And what are they?
Is it a static address located inside a module (green memory) or is it dynamically allocated memory.
If it's only working with VEH then it's likely it's picking part of the VEH's dll/memory as a path of the pointer.

Try finding a different path to the value you're looking for. Perhaps a pointerscanner scan, or pick another address after doing a hexadecimal scan when doing the manual route with debugging

maxmakki · How do I cheat? Reputation: 0 Joined: 29 Jun 2012 Posts: 7

Hi Dark Byte,

I did some reading up on modules. If I understand what I read correctly, then the module will be something like "game.exe"+000253C.

If so, then the pointer does not point to a module, it points to an address. However, the address it points to is an address that was highlighted green. Perhaps this is the issue.

Rather than pointing to the address, I had the pointer point to the 'module', the text I get from double clicking the base address in my address list. The issue remains the same, the pointer is not valid until I debug with VEH.

Thank you!

Max

----

Edit: I can't double post yet!

Hi Dark Byte,

When I "Browse this memory region", the bytes column simply reads '90' with opcode nop.

I will try the pointerscanner scan and get back to you.

Thanks

Max

----------

Edit: Still can't double post!

Hi Dark Byte,

I ran the pointer scan. I must say, that was quite the arduous process. The list returned over 3million results.

I was able to narrow down the results to 171. I ran into different issue following this route, the pointers survived the test of the game restart - but to a limited extent. Each game restart made some of the pointers have the ?? value. After 3 game restarts, all of the pointers I received from the pointer scan had a value of ??.

To limit the results I selected the "Stop traversing a path when a static has been found". I also limited the number of offsets to 3.

I am hesitant to repeat the process with the "Stop traversing a path when a static has been found" unticked and an offset of 5 (default) as the narrowing process would take many hours.

The way I narrowed the addresses:

I ran the pointer scan for the address, then I'd scan for the value I'm looking for. When the rescan no longer lowers the result count, I exit the game, restart it, then rescan again - this time for the new dynamic address. I repeat this process until the number becomes manageable.

Is there a better way?

Thank you

Max

--------

Can't double post!!

I ran the pointer scanner again with "Stop traversing a path when a static has been found" unchecked. To my surprise, it returned LESS results. These results seem to be stable.

There are many pointers though, all of them change the same memory value. Change one, the rest change. These pointers have remained the same through multiple game restarts.

For anyone who is having a similar problem, the issue here was that although I ran the steps outlined in the tutorial to find a static address, the address I found still wasn't the right one. The pointer scanning feature of CE helped me find the correct unchanging addresses.

Thank you.

Max