I have been a big fan of Visual Studio. It is an amazing IDE. It can be used to develop anything from a CLI to GUI and from Mobile Apps to Web Apps. But I have never really tried all that and that isn’t the reason why I liked it so much. As a starter, it can be very difficult to discover a bug in your program. You safely assume you have written what you wanted to write. But in reality that happens very rarely. Often, we miss a little small thing here and there and that creates havoc. The one thing that caught my eye as a young programmer was the Debugging features of VS. Gosh, its amazing.
In this article, I will explain how Debuggers debug!.
Firstly, we will need to learn a bit about CPU registers. We will concentrate on the x86 architecture. If you have ever written code in x86 Assembly, then you would have heard about them. But let me just walk you through the functions of these registers.
CPU registers are just memory that the CPU can use to store data. But, it is the fastest accessible memory for the CPU. Ideally you would like to keep everything in it. Unfortunately, it is damn expensive and so a trade-off is done on the pricing and performance. Though there are 32 registers, the most commonly used ones(9 to be precise) for the purpose of executing instuctions are –
EAX : Accumulator : used to store. Used during add/sub/multiplication. Mult/Div cannot be done elsewehere except in EAX. Also used to store return values.
EDX : storage register Used in conjuction to EAX. It is like a side-kick.
ECX: count register: Used in looping. However, there is an interesting thing about it. It always counts downwards and not upwards.
for ex:
int a=100;
int b=0;
while(b<a)b++;
Then ECX will begin from 100 and not 0 and move to 99,98 … !
ESI : source index for data operations and holds location of input stream.(READING)
EDI : points to location where the result is stored of a data operation destination index. (WRITING)
ESP : Stack pointer
EBP: Base pointer
EBX: not designed for anything specific . can be used for extra storage.
EIP : Current instruction being executed.
Now that we understand this, lets see how a debugger works!
Depending on the type of breakpoint, one of the following happens :
Soft Breakpoint :
Let us assume we need to execute this instruction :
mov %eax,%ebx
And this is at location 0×44332211, and the 2 byte opcode for this is 0x8BC3. Hence what we will see is :
0×44332211 0x8BC3 mov %eax,%ebx
Now when we create a soft breakpoint at this instruction what the debugger does is – it takes the first byte (8B in this case) and replaces it with 0xCC.
So now, the opcode actually looks like – 0xCCC3. This is the opcode for INT 3 interrupt. INT 3 is used to halt the execution. Now when the CPU is happily executing everything till this one and suddenly sees the 0xCC it knows it has to stop(it may not really like it but – Rules are rules 
). It then raises the INT 3 interrupt which the debugger will trap. It then checks the EIP register and sees if this intruction is actually in its list of breakpoints (just in case the program itself has a INT 3 inside it). If it is present, it will replace the first byte with the correct value (8B in this case) and then program execution can continue.
There are two kinds of soft breakpoint: One shot – Where the breakpoint occurs only once and after that the debugger removes the instruction from its list; and Persistent – where it keeps recurring. The debugger would replace the first byte with the correct byte but when execution is resumed, it will once again replace it with 0xCC and not remove it from its list.
Soft breakpoints have one caveat though.When we make a soft breakpoint it changes the software/program’s CRC (cyclic redundancy check) check sum. A CRC is a type of function which tells whether there has been any change or not. It is like a hash function and can be applied to memory/files etc.,. It compares against a known value and if the checksum fails, the CRC fails. This can be used to prevent Soft breakpoints like in malwares where if the CRC fails, the malware kills itself. To get around this we use Hardware breakpoints!
Hardware Breakpoints –
Though hardware breakpoints cannot be applied at everything, it is still very useful. Recall, the I said there are 32 registers. I introduced 9 in the previous section, let me add another 8 to that list. These eight – DR0 to DR7 are debug registers. DR0 – DR3 store the address of the breakpoints and thus we can have only 4 hardware breakpoints (Ouch!). DR4 and DR5 are reserved. DR6 is the status register which determines the type of debugging event once it is hit and DR7 is ON/OFF switch for hardware breakpoints and also stores different conditions like -
1. Break when an instruction is executed at a particular address.
2. Break when data is written to an address.
3. Break on reads or writes to an address but not execution.
As you can guess, you can only break 4 bytes of memory with hardware breakpoints but nonetheless they are very useful tools for reverse engineers. For creating hardware breakpoints, you can use hbreak command inside gdb.( More info ).
Memory breakpoints.
These arent really breakpoints. It is more like setting permissions on a section of memory or on an entire page, something similar to file permissions. When we set a particular permission, if any instruction tries to do something outside of these permissions on that memory, then a break occurs. The permissions available are – Page Execution (enables exec but throws access violation on read/write) , Page Read ( allows only read), Page Write (only write), and Guard Page (one time exception after which the page returns to its original status). Like in files, we can use combination of these to set permissions. In gdb, to break on write use watch, rwatch will break on read and awatch will break on read/write.
I hope you now have a better understanding of how debuggers work. You may feel this as being unnecessary info, but trust me it helps to know how things work for better usage.
I would like to thank all Source of knowledge – the World Wide Web. Please free to send me corrections/suggestions/criticism.
Adios!
