Cheat Engine

[pox911]

There is a value that im editing that when edited manually causes changed in the game yet it doesnt seem to be getting accessed at all according to the debugger. Any idea on how to go about finding the function that accesess that value that causes the change?

[++METHOS]

Could be a static/constant value (what kind of value is it?). You could try attaching debugger at game start-up.

Could be anti-debugger/cheat. You could try an alternative debugger method.

Remember, you can always use an unrelated instruction for your injection point...you will just have to use pointers and forget about AOB.

[pox911]

i doubt it's anticheat. it's not the value itself i want to change but the what other values are changed/accessed during the process. I found code directly accessing the address by manually searching but the debugger just doesnt seem to pick up on it. Basicly im trying to alter the level creation settings in terraria. I've caused some funky things to happen so far.


edit: The windows debugger seems to have picked up on it. Is there a way to get the windows debugger to stop crashing steam games though?

[mgr.inz.Player]

@pox911

++METHOS +1


Another method. Example:

value1 - accessed
value2 - not accessed (according to the debugger)

But, value2 address is always 0xXXX bytes after value1 address.
You can hook instruction which access value1 and you can change value2.

[pox911]

The problem is the VEH debugger not seeing the function and the windows debugger that can causes crashes in steam ran games.

i found out the windows one picks it up by running CE on the server tool during world creation since it uses the same bit of code but doesnt need steam to run.

[mgr.inz.Player]

You can try winXP+kernelmode debugger.
Or Win7+DBVM+kernelmode debugger.

[++METHOS]

[Dark Byte]

some steam games have an annoying secondary protection (CEG) that use up the hardware breakpoints. (get startrek, all details about that security is described in the .pdb that comes with it)

windows debugger will crash the game because on attach it executes an int3 and hopes the debugger catches it, but it won't (hidden from the debugger) and thus crashes the game

The veh debugger works, but because the hardware breakpoints are in use it can not set a breakpoint (unless you use the option to override them, but expect a crash if you do)

So, try exception breakpoints with VEH debug. Those do not use hardware breakpoints (just extremely slow and don't expect them to work with execute breakpoints unless the game makes use of NX or you enable it manually)

[pox911]

[mgr.inz.Player]

You tried all combinations:
- VEH, Hardware
- VEH, int3
- VEH, page exceptions
- WinDBG, Hardware
- WinDBG, int3
- WinDBG, page exceptions
- WinDBG, Hardware, prevent detection
- WinDBG, int3, prevent detection
- WinDBG, page exceptions, prevent detection





"Worst case scenario is that i use a crack on the games i own to run it outside of steam long enough to use the windows debugger."

Well, sometimes it is the only, and fast, possibility.