Here are the commands to use the tracing features of the debugger.
See also Debugger submenu.
Recorded traces can be managed from the Tracing window. Traces are saved in a directory specified in the tracing options dialog.
Saved binary trace files can be loaded, saved and replayed with the new replayer debugger module, diffed against other traces (to spot differences between executions) or displayed in a proximity view (displaying the execution call graph).
Opens the 'Tracing' window.
In this window, you can view some information related to all traced events. The tracing events are the information saved during the execution of a program. Different type of trace events are available: instruction tracing events , function tracing events and write, read/write or execution tracing events.
During the execution, the list of traced events is disabled, as it couldn't be continuously synchronized with the execution without rendering the whole tracing very slow.
If a '=' character is displayed in the 'Thread' and 'Address' columns, it indicates that the trace event occurred in the same thread and at the same address as the previous trace event.
Load a binary trace file in the 'Tracing' window.
This command displays all the saved trace files that correspond to the MD5 of the current IDB and allows the user to load one of them. The traces can be replayed with the replayer debugger, inspected manually in the disassembly view or displayed as a callgraph in a proximity view.
Show a dialog with additional options for managing trace files.
This command displays a window with all the available commands to manage trace files.
Show the description of a binary trace file.
This command displays a window with the description of a selected binary trace file and allows to edit it.
Diff the currently loaded trace against a recorded trace.
This command displays a window to select a trace file to diff against the currently loaded trace, displayed in the 'Tracing' window.
If highlight options are enabled in Tracing Options, instructions from the currently loaded trace will be displayed with the background "main color" and instructions from the diff trace file will be displayed with the "diff color". Common instructions will be highlighted with an average of the two.
Delete a binary trace file from disk.
This command displays a window to select a recorded trace file to delete from disk.
Import a binary trace file from a different IDB.
This command allows to import binary trace files recorded for an IDB with a different MD5. For example, it can be used to load recorded traces from a malware sample which is practically the same, but differs in a few bytes.
Export to a binary trace file all events displayed in the 'Tracing' window.
This command exports to a binary trace file the current trace being displayed in the Tracing window. The trace can be loaded later, removed or diffed against other trace files.
Export to a text file all events displayed in the 'Tracing' window
This command exports the current trace being displayed in the Tracing window to a text file.
Show the callgraph of the loaded trace in a proximity view.
This command displays the callgraph of the currently loaded trace in a proximity view.
This command removes all trace events from the Tracing window. It also removes any loaded trace file used for diffing against the currently loaded trace.
This command starts instruction tracing. You can then use all the debugger commands as usual: the debugger will save all the modified register values for each instruction.
When you click on an instruction trace event in the 'Tracing' window, IDA displays the corresponding register values preceding the execution of this instruction. In the 'Result' column of the Tracing window, you can also see which registers were modified by this instruction. By using this information, you can for example quickly determine which instruction modified a specific register, or you can even backtrace the execution flow. Note that the IP register is never printed in the 'Result' column, although it is usually modified by almost any instruction (except perhaps some prefixed instructions like REP MOVSB, ...).
Internally, the debugger runs the current thread step by step to properly obtain all the required register values. This explains why instruction tracing is slower than a normal execution.
This command starts function tracing. You can then use all debugger commands as usual: the debugger will save all addresses where a call to a function or a return from a function occurred.
Internally, the debugger runs the current thread step by step to properly detect all function calls and returns. This explains why functions tracing is slower than a normal execution.
This command starts basic block tracing. You can then use all debugger commands as usual: the debugger will save all addresses where a temporary basic block breakpoint was reached.
Internally, the debugger runs the current thread normally, setting temporary breakpoints in the last instruction of every basic block of every function referenced from the current function and also at any call instruction in the middle of the traced basic blocks.
Basic block tracing is slower than normal execution but faster than instruction or function tracing.
This command adds a write trace to the current address.
Each time the given address will be accessed in write mode, the debugger will add a trace event to the Tracing window.
In fact, write traces are nothing more than breakpoints with special properties: they don't stop and they simply add a trace event when the breakpoints are reached.
Internally, the debugger will add a hardware breakpoint on the given address, so all the restrictions for hardware breakpoints are also valid for write traces.
This command adds a read/write trace to the current address.
Each time the given address will be accessed in read or write mode, the debugger will add a trace event to the Tracing window.
In fact, read/write traces are nothing more than breakpoints with special properties: they don't stop and they simply add a trace event when the breakpoints are reached.
Internally, the debugger will add a hardware breakpoint on the given address, so all the restrictions for hardware breakpoints are also valid for read/write traces.
This command adds an execution trace to the current address.
Each time the instruction at the given address will be run, the debugger will add a trace event to the Tracing window.
In fact, execution traces are nothing more than breakpoints with special properties: they don't stop and they simply add a trace event when the breakpoints are reached.
Internally, the debugger will add a breakpoint instruction at the given address.
Opens the stack trace window.
This window displays the function calls that brought the current instruction.
The top of the Stack Trace window lists the last function called by the program. Below this is the listing for the previously called functions. Each line indicates the name of the function which called the function represented by the previous line.
Double clicking on a line jumps to the exact address of the instruction realizing this call.
Currently, IDA uses the EBP frame pointer values to gather the stack trace information. It will fail for functions using other methods for the frame.
This dialog box allows you to specify different settings related to the tracing features.
Trace buffer size
Trace file
Trace directory
Stop condition This IDC expression will be evaluated before the execution of each instruction. If the expression returns true, the debugger will suspend the execution. Please note that you can use register names in the condition. Tracing
Enabling these options will speed up the execution, as many instructions (from debugger segments and/or library functions) will not be traced. Disabling these options can quickly fill the Tracing window, as all instructions in DLLs and system functions will be executed step by step. Notice that both options influence the way instruction and function tracings will work. Internally, the debugger proceeds like this:
memorize the return address associated with the last executed call instruction in database segments (the previously saved one is overwritten).
setup a temporary breakpoint on this address once the IP is in a debugger segment or library function, disable step by step, and run the thread.
reenable step by step once this temporary breakpoint is reached.
Highlight
Instruction tracing
Function tracing
Basic block tracing