在windows下使用IDA的调试器

This small tutorial introduces the main functionalities of the IDA Debugger plugin. IDA supports debugging of x86 Windows PE files, AMD64 Windows PE files, and x86 Linux ELF files,either locally or remotely. Let's see how the debugger can be used to locally debug a simple buggy C console program compiled under Windows.

The buggy program.

This program simply computes averages of a set of values (1, 2, 3, 4 and 5). Those values are stored in two arrays: one containing 8 bit values, the other containing 32-bit values.

#include 
char char_average(char array[], int count)
{
int i;
char average;
average = 0;
for (i = 0; i < count; i++)
average += array[i];
average /= count;
return average;
}
int int_average(int array[], int count)
{
int i, average;
average = 0;
for (i = 0; i < count; i++)
average += array[i];
average /= count;
return average;
}
void main(void) {
char chars[] = { 1, 2, 3, 4, 5 };
int integers[] = { 1, 2, 3, 4, 5 };
printf("chars[] - average = %d\n",
char_average(chars, sizeof(chars)));
printf("integers[] - average = %d\n",
int_average(integers, sizeof(integers)));
}

Running this program gives us the following results:

chars[] - average = 3
integers[] - average = 1054228

Obviously, the computed average on the integer array is wrong. Let's use IDA's debugger to understand the origin of this error !

Loading the file.

The debugger is perfectly integrated with IDA: to debug, we must first load the executable in IDA, to create a database. The user can disassemble the file interactively, and all the information which he will have added to the disassembly will be available during debugging. If the disassembled file is recognized as valid (x86/ARM64 PE or x86 ELF) by the debugger, a Debugger menu automatically appears in IDA's main window.

Instruction breakpoints.

Once we located our int_average() function in the disassembly, let's add a breakpoint just after itsprolog, by selecting the Add breakpoint command in the popup menu, or by pressing the F2 key.

Program execution.

Now, we can start the execution. We simply open the debugger window by using the appropriateicon, and run the program until it reaches our breakpoint, by pressing the F9 key or clicking the Start button in the debugger toolbar.

The stack.

The IDA View-ESP window now shows us the stack frame of the interesting functions. We easily locate the array argument of our int_average() function, pointing to the integer array in the calling function (main() function).

Now, we can start the execution. We simply open the debugger window by using the appropriate icon, and run the program until it reaches our breakpoint, by pressing the F9 key or clicking the Start button in the debugger toolbar.

Watches.

Why not add a watch on this array, in order to observe the evolution of its values during the process execution ?

Address evaluation.

By analyzing the disassembled code, we can now locate the loop which computes the sum of the values, and stores the result in the EBX register. The [edx+eax*4] operand clearly shows us that the EDX register points to the start of the array, and that the EAX register is used as an index in this array. Thus, this operand will successively point to each integer from the integers array.

Step by step and jump targets.

Let's advance step by step in the loop, by clicking on the adequate button in the debugger toolbar or by pressing the F8 key. If necessary, IDA draws a green arrow to show us the target of a jump instruction.

The bug uncovered.

Now, let's have a look at ESI's value. The EAX register (our index in the array) is compared to this register at each iteration: so, we can conclude that the ESI register is used as a counter in the loop. But, we also observe that ESI contains a rather strange number of elements: 14h (= 20). Remember that our original array contains only 5 elements ! It seems we just found the source of our problem...

Hardware breakpoints.

To be sure, let's add a hardware breakpoint, just behind the last value of our integers array (in fact, on the first value of the chars array). If we reach this breakpoint during the loop, it will indeed prove that we read integers outside our array. So, we setup a hardware breakpoint with a size of 4 bytes (classical size for an integer) in Read mode.

As foreseen, if we continue the execution, the hardware breakpoint indeed detects a read access to the first byte of the chars array. Remark that EIP points to the instruction following the one which caused the hardware breakpoint ! It is in fact rather logical: to cause the hardware breakpoint, the preceding instruction has been fully executed, so EIP now points to the next one.

Stack trace.

By looking at the disassembly, we see that the value stored in ESI comes from the count argument of our int_average() function. Let's try to understand why the caller gives us such a strange argument: If we open the Stack Trace window, we see a stack of all caller functions. Simply double click on the main() function, to jump to the caller code. With the help of IDA's PIT (Parameter Identification and Tracking) technology, we easily locate the push 20 instruction, passing an erroneous count value to our int_average() function.

Now, by looking closer at the C source code, we understand our error: we used the sizeof() operator,which returns the number of bytes in the array, rather than returning the number of items in this array ! As, for the chars array, the number of bytes was equal to the number of items, we didn't notice the error...

Other features.

IDA's debugger gives you access to all the segments of a debugged process's memory space, allowing you to use all of IDA's powerful features: you can apply structures to bytes in memory, draw graphs, create breakpoints in DLLs, ...

The way the debugger reacts to exceptions is fully configurable by the user.

This debugger is thus the essential complement to IDA itself, allowing you to interactively disassemble and debug everything, everywhere.