Help File:Debugger options
This page will give you access to some options relating to how the handling of instructions works in disassembly view.
Options[edit]
Use Hardware breakpoints (Max 3): Opts to use debug registers as the method of breakpointing. This is the default choice, and is the most compatible, although you can only set a max of 4 breakpoints this way. Leave it as this unless you have a specific reason to do so.
Use int3 instructions for breakpoints (Unlimited): This is the other options available for breakpointing. int3 bytes are used extensively by standalone debuggers such as OllyDBG for breaking on code. There is no limit to how many of these BP's you can set. Although some targets may detected a debugger this way.
Replace incomplete opcodes with nops: NOP stands for No-Operation, and is an assembly command which simply does nothing. When program flow reaches a NOP it simply passes over it as if it wasn't there. NOP's are used to remove code which may, for example, reduce player health in a game. If you modify an instruction and it has a smaller/larger length than the one you replaced, then CE can replace the leftover/broken bytes with these NOP's. Should always be on just for safety purposes.
Ask for replace with nop: Also on by default. This will cause CE to ask you if you want it to replace the leftover bytes with NOP's or whether to leave the broken instruction for you to deal with. You can uncheck this option, which will cause CE to automatically clean-up leftover bytes itself, without prompt.
Debugger Methods[edit]
Use VEHdebugger: Use this debugger option to avoid debugger detection in some games that are otherwise closing/crashing if you attach the standard windows debugger to them.
- Poll for threads: The only implemented option so far.
Use windows debugger: Use the default windows debugger.
Known issue: If Debug is enabled in the boot settings of windows, VEH debug will not return any results
- Try to prevent detection of the debugger will cause CE to hook the IsDebuggerPresent API, which is commonly used as an anti-debug technique. It will cause the function to always return zero, as so as far as the debugged program is concerned, it;s not been debugged. This will take place once you have attached the debugger for the first time (attaching to a process and clicking yes). It does not guarantee success though, as there are many, many ways to detect a debugger!
Use kernelmode debugger: This will use CE kernel routines for debugging as opposed to the standard windows ones. This is good for hacking a particularly stubborn game which detects a debugger when using conventional means
- Use Global Debug routines: This will cloak the debug registers (DRs), and is therefore good if you are sure
that a target is detecting a change in these debug registers.
- Ability to step through kernel code: When stepping and entering kernel code the single stepping will usually get disabled so it continues till you're back in usermode. With this option enabled the stepping will continue. It currently doesn't seem possible to continue from stepping through kernelcode so se it like a one try only option
If you use kernelmode debugger options, you need to run the kernelmoduleunloader before you can use other type of debuggers (windows or VEHdebugger). Or you can simply restart your computer. If you use Global Debug routines, you have to restart your computer before you could use other debuggers.
