Difference between revisions of "Duby/Breakpoint"
m (→Code Modification) |
(→See Also) |
||
| Line 18: | Line 18: | ||
The downside of this approach is the need of single-stepping operation, in order to restore the break-point back. | The downside of this approach is the need of single-stepping operation, in order to restore the break-point back. | ||
| − | |||
| − | |||
| − | |||
==See Also== | ==See Also== | ||
*[[duby]] | *[[duby]] | ||
[[Category:duby]] | [[Category:duby]] | ||
Revision as of 21:39, 27 October 2017
Setting Breakpoint
Code Modification
In the force case scenario, breakpoints are set by changing the existing code and setting debugging code (for x86) interruption.
The code has a length of 1 byte, thus it's safe to modify an existing instruction (of any length).
However, it's necessary to know, where an instruction actually begins. (Without debugging information, the only way to know where an instruction begins is through careful disassembling)
- Save the existing instruction
- Write the interruption code
- Proceed with execution
- On breakpoint event, restore the original code
- Move the execution register to point to the instruction
- Execute a single-step instruction
- Once single-step is completed, restore the debugging break point code
The downside of this approach is the need of single-stepping operation, in order to restore the break-point back.
