Cheat Engine

[lailei009]

[Dark Byte]

DebugProcess is for "Find what accesses and find what writes"
The only one you need is ChangeRegOnBp

As for why it's not working, that's because you have to manually set the debug registers in the threads of the target process.
ChangeRegOnBP just sets a watch in the kernel, for when such a breakpoint occurs on what to do

so,
enumerate all threads in the target process (createtoolhelp32snapshot, thread32first/thread32next)
and set the debug registers to break on execution of 00873236 (openthread,suspendthread,get/setthreadcontext, resumethread)

[lailei009]

thanks,could i sets breakpoint to all thread or find the call thread and set breakpoint?

[Dark Byte]

It's easiest to set it on all threads, then you can be pretty sure that the thread that executes that particular piece of code is captured when it executes it

Of course, it will usually always be the same thread, but probloem would be pinpointing it, so thats why I just pick all

[lailei009]

oh that's right . let me try it .
finnally,you mean the Processid:dword is a thread id??

[Dark Byte]

no, that processid is the processid of the process
It's used by the kernelroutine to check if the generated breakpoint belongs to the process being debugged.

You just have to set the debug registers to an execute bp at the specified eip on every thread of that particular process, the kernel routine will do the rest (dr0=eip, dr7=3)

[dnsi0]

[Dark Byte]

FF only when DR 1, dr2 and dr3 are used

FF=11111111= 11 11 11 11

Meaning enable g0,g1,g2,g3 and l0,l1,l2,l3
So, if you only use dr0 and don't fill in dr1 to 3 then any access to 0 will generate a breakpoint. (e.g a access check by using a try/except instead of checking if something is really 0)

as for dr2 and dr3 not working properly, not really sure. It does work in ce ? (setting more then 2 change reg on bp, something I never tested since max I ever needed was 2 )
Or perhaps you're not filling in the proper debug registers
Or perhaps the game itself is using dr2 or dr3 (e.g ce's standalone trainer with protect on makes use of a debug register to jump over useless code)

[lailei009]

I also found some mistake, I set a breakpoints and breakpoints should be work but the application is automatically exit ?why

here is my source:

[Dark Byte]

I recommend calling ChangeRegOnBP before setting the debug context. If a breakpoint fires and it's not handled and just passed on to the game, most of the times it will then terminate because an unhandled exception occurred. (And that can happen thanks to taskswitching and multicore cpu's)

Also, your thread enumeration is broken, you're not setting the breakpoint on the first thread (you skip the result of Thread32first)

Actually, you're only doing it on the last thread. (The suspendthread-SetThreadContext-ResumeThread code is outside the whole loop)


Also, make sure dbk32.sys is in the same location as the dll
You might want to use dbgview to make sure everything is being set as expected. Just noticed that if the driver failed to load, ChangeRegOnBP can randomly return true or false

[lailei009]

i tryed what you said ,but it alway auto exit.

when I call setthreadcontext the application is aoto exit whether I calling ChangeRigsterOnBP

Whether I call RetivedebugData?

how changerigsteronbp work?

can you give me a sample?

[Dark Byte]

First make sure you're not using some uce's driver (they tend to strip out the debugging part completly)

Also, get dbgview, so you know it's working or not

Retrievedebugdata is only needed when using the option to fuind out what accesses an address

changerigsteronbp will first hook interrupt 1 in the idt and then tell the driver to watch for interrupts that happen in the specified process on the given eip address.
Then when such a breakpoint occurs it will handle it itself, instead of telling windows that the interrupt occured. (If it doesn't handle it and just tells windows about it, 99% chance the game will terminate on such a breakpoint)

And with application terminating you mean tyhe target app right? Not your own

and agin, get dbgview from sysinternals. It'll tell you if the driver loaded, what it's going to do, and when an interrupt got fired and if it got handled or not, including the register states in some cases

[dnsi0]

It works perfect with cheatengine. And Im using my own program to test the registers.

[lailei009]

I know the reasons for the error

The application has np and hooked KiResumeThread and KiSuspendThread

could I use dbkResumeThread and dbkSuspendThread to instead?

[Dark Byte]

It could work, but it's hardly tested

But what you are describing sounds a lot that you're actually setting the debug registers just fine (I don't know if the suspend is really needed for setting the debugregs alone) and that the game is crashing because of the unhandled breakpoint.

Whats more likely going on here is that the IDT is being unhooked by nprotect.(Game crashes after setting the debug registers) Also, since you say the game is running nprotect, and you're not getting a hack detect message, means you either made your own driver undetected but didn't put in a working bypass for the interrupt 1 unhook by nprotect. Or you reused another driver, e.g moon light engine's driver, which I know has stripped the interrupt1 handler

If you made it yourself, try booting up with dbvm. The driver will then use dbvm for interrupt hooking. (Check if your system supports it by opening ce and rightclick on the ce logo)



But, if you intend on thinking it's the setting of debug registers and not the unhooking of int1(again, I really really doubt it), then fix the global debug routine where it keeps on setting the breakpoint as a read/write breakpoint of a 4 byte length to an execute breakpoint.
Then enable the globaldebug flag and go threadsurfing. The globaldebug method will break on EVERY thread, allowing you to set the debug register you like if you enter in a thread owned by the target process