Cheat Engine

[Caliber]

DarkByte or anyone who may know.

there seems to be a trend in newer games that allow you to attach a debugger to the game but when you attempt to set a breakpoint on a memory address, the game then crashes.

for instance, i just downloaded the bioshock demo. lets pick bullets, for instance.

you can attach Cheat Engine to the game (or OllyDbg, for that matter) and then do you searches until you narrow down the bullets.

HOWEVER, once you select that address and then enable "Find out what accesses this address" the game will immediately shut down/crash, without error report or anything. This will also occur with TSearch and with OllyDbg during the same moment where you try to breakpoint the memory address.

Is there a way around this sort of thing? I have noticed it with Halo 2 when I trained that game, although in that game you had a small amount of time before the game crashed. Also, with ShadowRun this occurs (instant shut down of game). Bioshock is not a ONLY VISTA title like the other two, but I see this trend increasing in games. Your CheatEngine program will be less useful if these anti-debugging techniques continue and we don't find a way around them. I have tried several plug-ins with OllyDbg and also selected various options in CE to try to hide the debugger. I don't think hiding the debugger is the answer, since I think it is actually detecting the actual breakpoint itself.

At any rate, this should be a very useful and lively discussion and hopefully will come to some useful information. Obviously there must be some way around all this since the "crackers" of games who produce the No-DVD versions of many games many times are able to be breakpointed and debugged without problems. So there must be a way. However, my searches have revealed nothing and so I hope to gain some info here.

General Settings:
- [X]Show undo button
- [X]Show advanced options
- [X]Update the list of found addresses even after scanning
- [X]Center Cheat Engine when bringing to front
- [X]Hide some/all windows instead of trying to bring ce to front

- [X]Show values as if they are signed
- [ ]Show and work wirth binaries as if the arer decimals
- [ ]Simple copy/paste

Scan Settings:
- [ ]Fast scan on by default
- [ ]Enable Hyperscan when possible
- [ ]Don't scan memory that is protected with the No Cache option
- [ ]Keep low memory usage when doing an "Unknown Initial Value scan" with Hyper Scan
- [X]MEM_PRIVATE
- [X]MEM_IMAGE
- [ ]MEM_MAPPED

Code Finder:
- [X]Use Debug Registers
- [ ]Memory Access Exceptions
- [X]Try to prevent detection of debugger
- [ ]Handle breakpoints not caused by CE

Assembler:
- [X]Show disassembler
- [X]Show debugger options
- [X]Replace incomplete opcodes with nops
- [X]Ask for replace woth nop
- [X]Try to prevent detection of the debugger

Extra:
- [ ]Query memory region routines
- [X]Read/Write Process Memory
- [ ]Undo changes to CE
- [ ]Enable use of the Process Watcher
- [ ]Use kernelmode debugger options when possible
- [ ]Stealth mode (Usermode)
- [ ]Stealth mode (Kernelmode)


Thanks,
Cal

[Dark Byte]

try ticking " [ ]Use kernelmode debugger options when possible "
and then use find out what accesses or writes
do not attach! (and make sure you're not in vista)

[Caliber]

[Dark Byte]

You can just open a process. Doubleclick. (so don't clikc on the attach to process button)
When you have enabled the kernel debug option, and choose the option to find out what writes or accesses a certain address it will not popup a question if you want to attach, but immeadiatly start the debug option

so, lets say you found the address of health, then do a "find out what writes"to find the code that writes to it and go from there. Of course, single stepping through the code isn't possible yet, but it's a start

[Caliber]

[Dark Byte]

if you're able to edit the memory you can make use of code injection. Inject a script and there save the important registers to a buffer of some sort you can read out later with the mem viewer

and about why: It could be both olly and ce have been configured to use int3 breakpoints instead of hardware breakpoints. That combined with a integrity check on the memory can cause such a problem.

I do doubt it's that since the way the game instantly crashes (just like an unhandled exception occured)
It could be that the debug api is being hooked.
Also, one question, when you attach ce, does ce freeze for several seconds and the game crashes, or does ce immediately continue and the game crashes (a tiny bit) later.

[DABhand]

I thought I put a post here for my old buddy Cal, welcoming him

Im interested DB will you be allowing a bit more support for 64bit kernels with future releases Save me having to use Sice all the time and losing me net conn O_o

[Caliber]

[Dark Byte]

what happens if you clicmk the 'attach to process' button intread of open ?

does it also crash then ?
What you're describing could be the eprocess's debugport gets rewritten to 0 so debug exceptions raises a exception in the game itself instead of the debugger. (can explain why it works a few seconds and then crashes if the interval that the debugger is removed is several seconds)
And unhandled exceptions generally tend to terminate the whole program

If that is the case no idea how to bypass it with the normal windows api except removing the code that detaches the debugger from the process.
I could probably improve the kernel debugger to add more functionality. (e.g on a debug exception redirecting to a injected piece of code where it goes into a sleep till it receives a event, and a single step sets the single step bit, lets it execute one instruction, which then causes a debug exception and again to that loop etc...)

[Caliber]