Cheat Engine

[ducspam]

I noticed that CE is able to modify a register (any of them) at a given address. I was wondering if there is a Windows API that would do this?

I have the address, the value, and I know which register I want put the value in but I just don't know how to do it.

I know that the API "WriteProcessMemory" does something similar to this by writing a value to a given address. Is there a way to use it to write a value to a register at a given address?

If you know other ways to go at this, please explain. BTW, I'm trying to write this in C++ (VB or C# ways is fine as well).

Thanks

[Dark Byte]

You need to use debugger mechanics to do that.

first start a debug session with the process (debugactiveprocess or createprocess with debug parameters, in a seperate thread preferably)

then in the waitfordebugevent/continuedebugevent loop you watch for thread creations. When a tread gets created you set one or more debug registers so it'll break at one of the positions you want.

Then when you get a breakpoint exception on one of the addresses use GeThreadContext followed by SetThreaContext and set the registers you want.

------------------------
Another method of setting breakpoints is replacing the first byte of a instruction with a int3 instruction, and on break replace the int3 with the old code and put back when continueing. But if you want to do this for a certain game that disconnects when the code gets changed (different crc) this wont work.

[ducspam]

I just have some more questions reguarding your reply. BTW, thanks a lot and your CE kick ass!!!

[Dark Byte]

No, thread creation isn't a real breakpoint, but the process will break. I use that debug event to store a list of running threads (because the only way to get the threadhandle is by linking the threadid and threadhandle together)

In that event use setthreadcontext and set the debugregisters so they break at the position you want. (Check the intel instruction manual on the exact bits to set in dr7)

then continue debugging untill a breakpoint causes the debugger to be called and then if you've checked if it's your breakpoint use setthreadcontext to change the registers to what you want)


1: yes, every thread has it's own debug registers so every thread can have up to 4 breakpoints. It's easiest to set the debugregs of all threads to the same.

2: lpContext is a pointer to a CONTEXT structure and the context.EAX=0x34C45

[ducspam]

I encounted some problems while doing this.

[Dark Byte]

before calling setthreadcontext or getthreadcontext set the ContextFlags accordingly. (set them for CONTEXT_DEBUG_REGISTERS, also note that CONTEXT_FULL doesn't include the debug registers)

I also recommend removing a threadid-threadhandle link on a terminate thread event.

Also, debug registers don't cause a EXCEPTION_BREAKPOINT event. Only int3 instructions do that. Debug registers cause a EXCEPTION_SINGLE_STEP

and if the exceptions still arnt solved keep in mind that EXCEPTION_DEBUG_EVENT is one of the cases where you DEFAULT return DBG_EXCEPTION_NOT_HANDLED instead of DBG_CONTINUE

Only return DBG_CONTINUE when it is a debug event you caused and not the game itself

e.g: a simple method used in some games to crash debuggers:

[ducspam]

I tried what you told me and I still get the same problem. CONTEXT is still empty after setting the ContextFlag to CONTEXT_DEBUG_REGISTERS. Then I tried to set it to CONTEXT_FULL and CONTEXT is also empty. I don't know if this is correct or not maybe because a new thread is created so the context for that thread is new (empty)?

Well, I got an ExceptoinCode = 0xE06D7363, which does not match anything in the Win32 Debug API. After doing a DBG_CONTINUE on that exception, I get the EXCEPTION_ACCESS_VIOLATION. If I do a DBG_EXCEPTION_NOT_HANDLED on this exception, the debugger dies automatically. If I do a DBG_CONTINUE, it would loop and keep going into EXCEPTION_ACCESS_VIOLATION.

After that, I took a step back and comment out all the Get/SetThreadContext and so on. This time I just wanted to see how many threads are created and what kind of exceptions there were.

[Dark Byte]

Did you try it on a simple process like the cheat engine tutorial ?

Perhaps there's a bug inside your own app that crashes , like writing beyond the space of a array. (and when a debugger dies the debugged process also dies)

Or otherwhise you're not handling all exceptions as you should have.
No idea where though, but when just testing and not doing anything with your debugger you should always return DBG_EXCEPTION_NOT_HANDLED for the EXCEPTION_DEBUG_EVENT)
Sure, exceptions will still show up in the debugger, but with luck the game handles those exceptions itself.

Oh yes, you might want to handle the breakpoint exceptions from 7f000000 and above

[ducspam]

Probably the game I'm debugging on is killing the debugger. I'll try it on minesweeper or something when I get home from work.

Let say that minesweeper doesn't kill the debugger, than that mean the game I'm debugging on does, how will I over come this? Is there an API for hiding the assembler from the debugger? I think you have this "check box" function in the "Settings->Assembler tab" within CE.

[ducspam]

Tested it out with Minesweeper, Freecell, and Pinball (all Microsoft's Windows games).

Minesweeper = create only 1 thread, break point exception after that thread is created (like I said before, this break point exception always happen after you attach the debugger to a process).

Freecell = same like Minesweeper.

Pinball = a lot of threads are created due to the ball rolling around hitting all kinds of things. Even flipping the flipper create new threads. But only that one exception after the dubugger attach itself to the process occur. No other exception happens.

So all 3 games works fine, that mean the previous process I tried to attach crash my dubugger on purpose. Would you know how to deal with this? Your CE attach to it fine and debug and everything fine.

[Dark Byte]

I've made a quick test app that may help you with your debugger.
See if you can get through all 4 stages without a error

[ducspam]

I ran the process, then attach to it with the debugger. Ran your tool, and ran through all 4 stages. It say it found no errors.

But the debugger dies after like 15 seconds attaching to the process. It exception with the code 0xE06D7363 (doesn't match any thing I know). AfFter doing the DBG_EXCEPTION_NOT_HANDLE, it dies.

[Dark Byte]

It even didn't say it found the debugger in step 4 ?
(I take it you havn't patched isdebuggerpresent yet, so it should have given a message about that)

[ducspam]

It say something like "no error found, or do you not have a dubugger running?" on step 4.

[Dark Byte]

did you attach your debugger to it at least before clicking the last button?
Because it looks like you're not debugging the debugger, and step 4 should have told you it detected a debugger unless you messed up the isdebugger present api