|
Cheat Engine The Official Site of Cheat Engine
|
View previous topic :: View next topic |
Author |
Message |
SadrienHatesU Newbie cheater Reputation: 0
Joined: 08 May 2017 Posts: 14 Location: I don't exist... Unfortunately
|
Posted: Sat Jan 20, 2018 10:34 pm Post subject: Guides on Using breakpoints and the CE debugger? |
|
|
There are none stickied but i'm hoping someone either knows where one is or that someone can make one. Even if you have to refer me to a youtube name or smth. Thanks in advance
_________________
Um... Hello... Thanks for taking the time to read my pointless signature |
|
Back to top |
|
|
OldCheatEngineUser Whateven rank Reputation: 20
Joined: 01 Feb 2016 Posts: 1587
|
Posted: Sun Jan 21, 2018 4:31 am Post subject: |
|
|
understand the concept of the debugger, then you will automatically understand how to use CE's debugger.
refer to wikipedia.
_________________
About Me;
I Use CE Since Version 1.X, And Still Learning How To Use It Well!
Jul 26, 2020
STN wrote: | i am a sweetheart. |
|
|
Back to top |
|
|
FreeER Grandmaster Cheater Supreme Reputation: 53
Joined: 09 Aug 2013 Posts: 1091
|
Posted: Sun Jan 21, 2018 10:24 am Post subject: |
|
|
"breakpoints" are points in the code where the cpu will stop executing the code, aka "break", to let a debugger do stuff, which will generally let the user do stuff like check/change values or step through the code one instruction at a time in order to figure out how something is working (and why it's not what was expected lol).
(disclaimer: not an expert but I believe I understand the general idea)
hardware breakpoints- are limited (4 I believe) because they are offered by the cpu itself, these can not be detected by the program because only the CPU knows about them and there's nothing to detect. Though a program can detect that it took way more time to go through that code path that it had before...
software breakpoints- work by changing the first byte of the instruction to 0xCC which is the opcode for the assembly mnemonic INT 3 aka "interrupt type 3". When the cpu loads an int 3 instruction it will stop and raise an exception which a debugger can catch and then change the code back and allow the user to debug stuff before letting the code continue running. Due to multi-threading and how this implementation works it is theoretically possible for one thread to hit the breakpoint and between when the first byte is replaced so it can be executed and the int 3/breakpoint is replaced another thread could run the code....
There's a bit more technical info here: http://forum.cheatengine.org/viewtopic.php?p=5734790
When at a breakpoint you can:
1. execute a single instruction (generally labeled "step into")
2. step to the next instruction ("step over", if on a call this will run all the instructions inside that call until it returns to the instruction after the call)
3. continue execution until another breakpoint is hit ("run")
4. continue execution until a return statement is reached, useful to get out of a function you accidentally stepped into ("execute until return", "step out")
4. inspect values of registers, flags, and memory
5. change values of registers, flags, and memory
Some debuggers (including CE) support "conditional breakpoints" which let you set a condition, such as EAX equal to 5, in which it will break for the user and if that condition is not matched then it will automatically continue execution. CE supports this by opening the breakpoint list and then right clicking one of the breakpoints, conditions are lua code so make sure that registers are capitalized (EAX not eax) and numbers are prefixed with 0x if you want them to be read as hexadecimal.
Right clicking an instruction in the disassembler view of CE will give you an option to change registers and flags at that point, essentially setting a breakpoint and automatically changing the values for you.
Alternatively you can do a "break and trace" which sets a breakpoint and then CE's debugger will automatically step through each instruction and record register values and the stack (depending on options) up to some n instructions (or a "stop condition" is reached).
Right clicking a memory record in the address list will allow you to use a breakpoints to find out what accesses (reads or writes) or just writes to that address. This works because breakpoints can be triggered not just by the cpu executing code but also be reading or writing to an address (I do not know the specifics of how it's setup but I know it's possible).
If you really need more than that then go watch videos of people using a debugger and you'll pick it up pretty quickly eg. https://www.youtube.com/watch?v=oMran8kEvyA (this is not CE's debugger but it is a debugger that's somewhat similar. There are certainly videos using CE's debugger but I doubt there are any covering just the debugger like this and I didn't feel like taking the time to find a decent one, if you do feel free to share it!), even better go take a programming course that introduces a debugger at some point, like http://cs50.edx.org
|
|
Back to top |
|
|
|
|
You cannot post new topics in this forum You cannot reply to topics in this forum You cannot edit your posts in this forum You cannot delete your posts in this forum You cannot vote in polls in this forum You cannot attach files in this forum You can download files in this forum
|
|