The build and debug cycle can be tedious especially when you are unsure whether the change you have in mind solves your problem or not. Sometimes it is good to be able to tweak the logic of your code during a debugging session. This article explains how to make minor adjustments to code without having to rebuild your application.

The article requires tweaking the assembly and dealing with opcodes. If you are not very familar with debugging in assembly, you may want to read this article first. The tips shared here are also useful while debugging libraries where you either do not have the source code or the build environment is unavailable.

Debuggers work on the common principle of launching the executable as a child program and requesting special permissions from the operating system to access and alter the state of the program. This allows it to show and/or modify the memory, registers, code, etc in a debugging session. If a debugger attaches itself to another program already loaded in memory, it requests special permission from the operating system to take control of the program for the purpose of debugging. It will now seem very obvious why the same program in memory cannot be attached by two debuggers at the same time. The operating system caters to the request on a first come first basis and refuses permissions to the second debugger.

The debugger’s access to a program’s memory and registers not only allows users to view the state of the program but also set software breakpoints. Software breakpoints are set by altering and restoring the instructions in memory and has already been covered indepth in an earlier article.

How to modify code at runtime

Altering instructions without compilation of code during debugging works on a similar logic. If one uses the debugger to alter instructions of the program which it controls, then one can essentially change the logic compiled into the executable that is currently loaded in memory. It is worth noting that altering a program in memory is temporary. When the program is restarted and reloaded in memory, all changes are lost and no real harm has been done. As this requires directly tweaking the opcodes in memory, one needs to know how to deal with assembly and this cannot be accomplished with knowledge of a high level language alone.
Independent of the operating system and debugger, the steps needed to change the logic from within the debugger are as follows -

1. Launch the program in a debugger.
2. Set a breakpoint in the code at the location which you want to alter execution.
3. Execute the program and drive the program so that your breakpoint is hit.
4. Request the debugger to display the disassembly of the code.
5. Get comfortable with the source-assembly mapping.
6. Identify the address of the assembly line you would like to alter. Altering usually means changing an if statement to if NOT or “jump if zero” to “jump if not zero”.
7. Take the address and dump the memory contents at that address. You will see opcodes corresponding to the assembly you just saw.
8. Modify the memory location with new opcodes (more on this later).
9. Cross your fingers so that your change won’t cause a crash
10. Disable the breakpoint so that execution doesn’t stop too many times at this breakpoint as it makes debugging distracting.
11. Continue execution and now the program will respond to the new logic in the program.
12. To undo the effect of change, restart the program.

Example

Let us look at the following simple snippet of code below.

bool flag = true;
if( !flag )
cout << "flag is false" ;
else
cout << "flag is true" ;

The code when compiled and run normally would print “flag is true” and this is obvious from the code above. Say we at runtime would like to alter the logic by replacing if(!flag) with if(flag) so that the statement “flag is false” is printed instead.
Let us see how to do this with the two most commonly available debuggers.

GDB

The steps below are in the same order as the generic steps explained earlier.

• gdb <myprogram>
• break <line_number_of_if_statement>
• run   Code will stop at the breakpoint set above.
• disassemble. The dump on my machine is as follows -

0×00401170 <main+32>: call 0x40f260 <_alloca>
0×00401175 <main+37>: call 0×410410 <__main>
0x0040117a <main+42>: movb $0×1,-0×1(%ebp)
0x0040117e <main+46>: cmpb $0×0,-0×1(%ebp)
0×00401182 <main+50>: jne 0x40119a <main+74>
0×00401184 <main+52>: movl $0×443000,0×4(%esp)
0x0040118c <main+60>: movl $0x4463a0,(%esp)
0×00401193 <main+67>: call 0x43e720 <_ZStlsISt11char_traitsIcEERSt13basic_ostreamIcT_ES5_PKc>
0×00401198 <main+72>: jmp 0x4011ae <main+94>
0x0040119a <main+74>: movl $0x44300e,0×4(%esp)
0x004011a2 <main+82>: movl $0x4463a0,(%esp)
0x004011a9 <main+89>: call 0x43e720 <_ZStlsISt11char_traitsIcEERSt13basic_ostreamIcT_ES5_PKc>
0x004011ae <main+94>: mov $0×0,%eax

• Note that main+67 and main+89 are calls to cout. We have now identified the two important statements and the if check should be just above it. It usually helps to corelate the assembly with the source code in this manner.
• The if check is on lines main+42, main+46 and main+50 (if !(flag==0) ). If we change jne to je, we can negate the if condition and thus alter the logic of the code. The address of the opcode jne above is 0×00401182.
• x/6x 0×00401182 will dump the opcodes and operands in hexadecimal. In the dump below, 0×75 is the opcode for jne and the operand is 0×16. For details, refer to the Intel instruction set.

0×401182 <main+50>: 0×75 0×16 0xc7 0×44 0×24 0×04

• set *(char*)0×00401182=0×74 where 0×74 is the opcode for je. Effectively “jump if not equal” has been changed to “jump if equal” thereby inverting the logic of the if statement.
• cross your fingers.
• disable 1. Disable breakpoint set earlier.
• continue

You will observe that as we have modified the runtime code using gdb, the output of the program after the above steps would be “flag is false”.

Visual Studio

The above screen shot shows the debugger displaying the assembly after hitting the breakpoint at the if statement. Do make sure that when you right click in the assembly, “Show Code Bytes” and “Show Address” are checked.
From the screen shot above, the address of jne instruction is 0x003314B8 and its opcode is 0×75. If we modify the opcode at location 0x003314B8 and change it to 0×74 (opcode for je), we effectively negate the if statement at runtime.

To do this, open the memory window (Debug->Windows->Memory->Memory 1) and enter 0x003314B8 in the Address field. The first byte shows as 0×75. Put the cursor on 0×75 and type 74 to change the opcode. You can confirm this by seeing the effect in the disassembly window.

This modifies the code in memory and now when the program execution is continued, the output would be “flag is false”.

Conclusion

Another useful tip to keep in mind is that a lot of code can be disabled at runtime if all corresponding opcodes and operands are replaced with NOPs which has the opcode 0×90 on an Intel machine.  Similarly useful results can also be achived by altering the operands instead of the opcodes.

The ability to change code at runtime is an effective tool for quick debugging though it requires a good understanding of the code at the assembly level.   This technique is meant for small tweaks because it is faster to recompile in case complex changes in assembly are needed.   Moreover, when the program finishes execution, the modification needs to be redone as this technique does not modify the image on the disk.

I have compiled a list of my favorite features in a debugger and how to invoke them on different debuggers (Visual Studio, XCode, gdb and Windbg). 

This is not a substitute for the debugger’s documentation but helpful for quickly switching to an unfamiliar debugging environment.  Click the image below for viewing the table or download the PDF version as a ready reference.

Debugger Cheat Sheet (Download PDF)

Please note :

• The commands (especially for gdb) are not necessarily complete and the debugger’s help should be consulted for detailed usage.
• The list is not comprehensive and I have only put in my favorite commands that I use while debugging.  
• A square bracket [ ] denotes a keyboard shortcut.

Most programmer’s restrict the definition of data breakpoints to breakpoints that help halting the execution of code in the debugger when memory is written to. This is the kind of breakpoint that helps in catching most of the corruption bugs.

GDB provides data breakpoints (at least on Intel platforms) that do slightly more than that. As data breakpoints are implemented through hardware assistance, it is the hardware platform that provides the different kinds of data breakpoints and the debuggers provide the required interface.

watch

watch is gdb’s way of setting data breakpoints which will halt the execution of a program if memory changes at the specified location.

watch breakpoints can either be set on the variable name or any address location.

watch my_variable
watch *0×12345678
where 0×12345678 is a valid address.

Usually a crash because of heap corruption or invalid outcome due to buffer overruns shows up in the debugger when it is too late to figure out what went wrong. The watch or write data breakpoints can be used to find when a memory location has changed. The debugger at that very instant shows the reason for the inadvertent change.

The cause usually is double deletion of memory, writing to deleted memory, writing past the buffer boundary, etc. In order to fix such issues, it is more important to know when the corruption happens than to know what happens when the corruption has taken place.

Another interesting use of write data breakpoints is to find out the cause of memory leaks in reference counted objects by monitoring the increase and decrease in the reference count of the objects.

rwatch

rwatch (read-watch) breakpoints break the execution of code when the program tries to read from a variable or memory location.

rwatch iWasAccessed
rwatch *0×12345678
where 0×12345678 is a valid address.

For example, say you are new to your project and would like to figure out where exactly are your encryption routines in code. As a start, you can first search your codebase but you may hit a few false positives. If you know the memory location of your password and you set your rwatch breakpoints correctly, it would not be long before the debugger breaks execution right in your encryption algorithms which have to read the password in order to perform their function. Getting evil ideas already?

Another use of read data breakpoints is finding out the code that is reading from memory that has already been deleted and is using this corrupt information later.

awatch

awatch or access watches break execution of the program if a variable or memory location is written to or read from. In summary, awatches are watches and rwatches all in one. It is a handy way of creating one breakpoint than two separate ones.

awatch *0×12345678
where 0×12345678 is a valid address.

The problem with data breakpoints like any other breakpoint is that they can be triggered far too many times and the programmer may lose track of the problem being debugged. To ensure the breakpoints are hit the least number of times, the data being worked upon should be minimal and the breakpoint should be set as late as possible.

]]> http://www.technochakra.com/debugging-types-of-data-breakpoints-in-gdb/feed/ 2 http://www.technochakra.com/software-breakpoints/ http://www.technochakra.com/software-breakpoints/#comments Wed, 13 May 2009 19:05:53 +0000 tc http://www.technochakra.com/?p=192 Line breakpoints can be implemented either in hardware or software.  This article discusses the latter in detail.

It is very useful to be able to break execution of code at a line number of your choice.  Breakpoints are provided in debuggers to do exactly that.  It is fun getting to the root of the problem by setting breakpoints in a debug session.  It is even more fun to know how do breakpoints work in the first place.

Software breakpoints work by  inserting a special instruction in the program being debugged.  This special instruction on the Intel platform is “int 3″.  When executed it calls the debugger’s exception handler.

Example

Let us look at a very simple example that inserts a breakpoint in a program at compile time and not through a debugger.  The code uses the Intel instruction “int 3″ and you may need to figure out the equivalent instruction for a non-Intel platform.

// The code below works well with Visual Studio.
int main()
{
__asm int 3;
printf("Hello World\n");
return 0;
}

// The code below works well with gcc + gdb
int main()
{
asm("int $3");
printf("Hello World\n");
return 0;
}

If you run this program in Visual Studio, you get a dialog saying “helloworld.exe has triggered a breakpoint“.

In gdb you get the message “Program received signal SIGTRAP, Trace/breakpoint trap.”

In the example above, a call to “int 3″ invokes the debugger’s exception handler.

It is also interesting to note the assembly instructions generated for the program above.

In Visual Studio, right click on the code and click on “Show Disassembly”. Also ensure that “Show Code Bytes” is on in the same context menu.

In gdb type disassemble at the gdb command.

0x0040107a <main+42>:   int3

Now obtain the opcode of the int3 instruction using the x (examine memory) command

(gdb) x/x main+42

0x40107a <main+42>:     0xcc

As seen above, the breakpoint opcode we inserted during compilation is 0xCC .

How Do Debuggers Insert Breakpoints?

For practical reasons, it is unwise to ask for a recompilation whenever a breakpoint is added or deleted.  Debuggers change the loaded image of the executable in memory and insert the “int 3″ instruction at runtime.  The common steps a debugger performs to provide the functionality of a line breakpoint to a user are as follows -

1. When a user inserts a breakpoint in a line of code, the debugger saves the opcode at that given location and replaces it with 0xCC (int 3).
2. When the program is run and it executes the “int 3″ instruction, control is passed to the debugger’s exception handler.
3. The debugger notifies the user that a breakpoint has been hit. Say that the user instructs the debugger to resume execution of the program.
4. The debugger replaces the opcode 0xCC with the one it had saved earlier.  This is done to restore the instructions to their original state.
5. The debugger then single steps the program.
6. It then resaves the original instruction and re-inserts the opcode 0xCC.  If this step were not done, the breakpoint would have been lost.  Temporary breakpoints on the other hand skip this step.
7. The debugger then resumes execution of the program.

Hardware breakpoints are limited in number but debuggers are able to provide unlimited breakpoints by implementing them through software.

Knowing what goes behind the scenes makes debugging a bit easier.  A debugger may defer setting a breakpoint if the module is not loaded in memory yet.  It needs to replace some opcode with 0xCC and that can happen only when the module is in memory.  Likewise, a mismatch between a binary, its sources and its debug symbols (or the lack of it) may cause breakpoints to be hit at unexpected locations because the debugger is not able to correctly map the source line to the opcode that it needs to replace with 0xCC.  At times debuggers complain about the mismatch and refuse to set the breakpoints.

Many of the setup issues with breakpoints become obvious once we know how they work internally.  And when all else fails and release build breakpoints  adamantly refuse to work, you always have the option of compiling an “int 3″ breakpoint right into your code.

A useful feature in a debugger is a temporary breakpoint that automagically gets deleted when hit thereby reducing the clutter of unnecessary breakpoints.  These breakpoints are useful when you wish to stop at a code location only once and do not require the execution to stop at that location ever again. 

For example, say you are trying to determine whether a particular test scenario invokes a specific line of code or not, in that case a temporary breakpoint can be used as the breakpoint is not useful once it has been hit alteast once.

Below are steps on how to set temporary breakpoints in various debuggers.

gdb

Use the tb command to set a temporary breakpoint in gdb.  It is similar to the break command but the breakpoint will automatically be deleted when hit.

(gdb)help tb
Set a temporary breakpoint.
Like “break” except the breakpoint is only temporary,
so it will be deleted when hit.  Equivalent to “break” followed
by using “enable delete” on the breakpoint number.
    

Windbg

In Windbg, breakpoints set in the Command window using the bl /1 command can be used to create temporary breakpoints.  The /1 tells Windbg that the breakpoint should be deleted when hit.

In Windbg temporary breakpoints are also known as “one shot breakpoints”.

Visual Studio

I found it a bit painful to create temporary breakpoints in Visual Studio.  The only way I could create one was by setting a breakpoint and then setting the hit count for the breakpoint to be equal to 1.   The  article here explains how to set a hit count in Visual Studio.

The amount of work involved to do this sometimes doesn’t make temporary breakpoints worthwhile to set.  Moreover the breakpoint lingers on and doesn’t actually get deleted when hit.

A normal debugging session involving assembly language consists of the following steps -

1. Launch the program in gdb and set the required breakpoint(s).
2. When the breakpoint is hit, use the disassemble command to view the assembly language of the current frame.
3. Use the frame command and figure out the program counter and thus your location in the assembly that gdb produced in the last step.
4. Use the si and ni commands to step in and step over the instructions in assembly language.

The problem is that this may require a bit of scrolling to do if the disassembled function is very long.  The display command can be used to solve this problem.

The display command in gdb allows a user to configure the variables that should show up each time the program is suspended.

(gdb) help display
Print value of expression EXP each time the program stops.
/FMT may be used before EXP as in the “print” command.
/FMT “i” or “s” or including a size-letter is allowed,
as in the “x” command, and then EXP is used to get the address to examine
and examining is done as in the “x” command.

With no argument, display all currently requested auto-display expressions.
Use “undisplay” to cancel display requests previously made.

One can use the display command to view the next instruction that is about to be executed.  The pointer to the instruction yet to be executed is stored in the computer’s program counter (also known as the instruction pointer).   The following command will show the next 3 instructions that are pointed to by the program counter.

display /3i $pc

The /3i above causes three instructions to be printed and $pc references the program counter register.  A sample output is shown below.

1: x/3i $pc
0×401175 <main+37>:     call   0x4103f0 <__main>
0x40117a <main+42>:     lea    0xffffffe8(%ebp),%eax
0x40117d <main+45>:     mov    %eax,(%esp)
(gdb)

]]> http://www.technochakra.com/gdb-debugging-in-assembly/feed/ 0