# Debugging a Windows executable locally and remotely ## Debugging a Windows executable locally and remotely Last updated on September 01, 2020 - v0.2 This short tutorial introduces the main functionality of the IDA Debugger on Windows. IDA supports debugging of various binaries on various platforms, locally and remotely, but in this tutorial we will focus on debugging regular applications running on Windows. Let’s see how the debugger can be used to locally debug a simple buggy C console program compiled under Windows. Please use **sample.exe.idb** from samples.zip: {% file src="" %} to follow this tutorial. ## The buggy program This program 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. ```c #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: ```bash >sample.exe chars[] - average = 3 integers[] - average = -65498543 ``` Obviously, the computed average on the integer array is wrong. Let us use the IDA debugger to understand the origin of this error. ## Loading the file The debugger is completely integrated into IDA: to debug, we usually load the executable into IDA and create a database. We 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 debuggable, the Debugger menu automatically appears in main window:

Since IDA has many debugger backends, we have to select the desired backend. We will use **Local Windows debugger** in our tutorial:

## Instruction breakpoints Once we located our **int\_average()** function in the disassembly (it is at 0x40104A), we can add a breakpoint at its entry point, 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 can launch the debugger by pressing the **F9** key or by clicking the **Start** button in the debugger toolbar. IDA displays a big warning message before really starting the debugger:

Indeed, running untrusted binaries on your computer may compromise it, so you should never run them. Since in our tutorial we are playing with a toy sample, it is okay, we can accept him. However, please consider using remote debugging for untrusted binaries. Once we accept it, the program runs until it reaches our breakpoint:

## 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 **EAX**. The **\[edx+ecx\*4]** operand clearly shows us that **EDX** points to the array and **ECX** is used as an index in it. Thus, this operand will successively point to each integer from the integers array:

## Step by step and jump targets Let us 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 value of **\[esp+count]**. The ECX register (our index in the array) is compared to this register at each iteration: so, we can conclude that it is used as a counter in the loop. But, we also observe that it 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 us 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. For that jump to **EDX**, which points to the array, by clicking on a small arrow in the CPU register view:

IDA displays a sequence of bytes, so we need to create an array. Do the following: * press Alt-D, D to create a doubleword * press \* and specify the size of 5 elements

Let us add a hardware breakpoint with a size of 4 bytes (the size of an integer) in **Read/Write** mode immediately after our array. Please note that the cursor is located after the array we created:

As foreseen, if we continue the execution, the hardware breakpoint detects a read access to the first byte of the chars array.

Please note 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.

## Caller’s mistake By looking at the disassembly, we see that the value stored in **\[esp+count]** comes from the **count** argument of our **int\_average()** function. Let us try to understand why the caller gives us such a strange argument: if we go the call of **int\_average()**, we easily locate the **push 14h** instruction, passing an erroneous count value to our 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 it! As, for the **chars** array, the number of bytes was equal to the number of items, we didn’t notice the error… ## Debugging a remote process Our debuggers support debugging processes running on a remote computer. We just need to set up a remote debugging session and then we can debug the same way as in local debugging. Let us consider the following three simple steps. ### Starting the remote server Regardless of the platform where IDA itself runs (be it Windows, Mac, or Linux), we need to launch a remote debugger server on the computer where the remotely debugged application will run. For Windows, we have two different debugger servers: * for 32-bit programs, use win32\_remote.exe * for 64-bit programs, use win64\_remote64.exe So, we copy the relevant debugger server to the remote computer and launch it:

If the debugger server is accessible by others, it is a good idea to use a password for the connection (the **-P** command line option). Once this is done, we can return to the local computer, where we will run IDA, and configure it. ### Configuring IDA to connect to the remote server We have to select the Remote Windows debugger:

and specify the correct values in the **Debugger > Process options dialog**:

Please note that the **Application**, **Input file**, and **Directory** must be correct on the remote computer. We may eventully specify command line arguments for the application in the **Parameters** field. If you have specified a password when launching the remote debugger server, you must specify it in the **Password** field. ### Starting a debug session Once we have configured IDA, the rest is the same as with local debugging: press **F9** to start a debugging session. ## Attaching to a running process In some cases we cannot launch the debugged process ourselves. Instead, we need to attach to an existing process. This is possible and very easy to do: just select **Debugger > Attach to process** from the menu and select the desired process. ## Other features IDA debugger gives you access to the entire process memory, allowing you to use all powerful features: you can create structure variables in memory, draw graphs, create breakpoints in DLLs, define and decompile functions, etc. It is even possible to single step in the pseudocode window, if you have the decompiler installed!

The way the debugger reacts to exceptions is fully configurable by the user. The user can select various **Actions** to be performed when the breakpoint is hit. An **IDC** or **Python** can be executed upon hitting a breakpoint:

We invite you to play with the debugger and discover its many unique and powerful features!