Tracing
Last updated
Was this helpful?
Last updated
Was this helpful?
Here are the commands to use the tracing features of the debugger.
See also .
Recorded traces can be managed from the . Traces are saved in a directory specified in the 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.
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.
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.
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.
Export to a text file all events displayed in the 'Tracing' window
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 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.
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.
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.
This command adds a read/write trace to the current address.
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.
This command adds an execution trace to the current address.
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
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
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: , and , or .
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 , inspected manually in the disassembly view or displayed as a callgraph in a proximity view.
If highlight options are enabled in , 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.
This command exports to a binary trace file the current trace being displayed in the . The trace can be loaded later, removed or diffed against other trace files.
This command exports the current trace being displayed in the to a text file.
This command removes all trace events from the . It also removes any loaded trace file used for against the currently loaded trace.
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 , 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, ...).
Each time the given address will be accessed in write mode, the debugger will add a trace event to the .
Internally, the debugger will add a hardware breakpoint on the given address, so all the restrictions for are also valid for write traces.
Each time the given address will be accessed in read or write mode, the debugger will add a trace event to the .
Internally, the debugger will add a hardware breakpoint on the given address, so all the restrictions for are also valid for read/write traces.
Each time the instruction at the given address will be run, the debugger will add a trace event to the .
Stop condition This 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 , 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: