BreakpointEdit

Description

Edit breakpoint settings. This command opens a dialog to edit an existing breakpoint.

Breakpoint settings dialog

Location

The breakpoint location: either an absolute address, a symbol name, a module+offset combination, or a source file name and a line number. The exact location syntax depends on the breakpoint kind: absolute, module relative, symbolic, or source code.

Condition

This IDC expression will be evaluated each time the breakpoint is reached. If the expression returns true (non-zero), the debugger will execute the selected actions. Please note that you can use the register names in the IDC scripts when the debugger is active.

Example conditions:

• EAX == EBX+5

• get_wide_dword(ESP+0x10) == 34

You can also use the "..." button to enter a multiline condition, or specify another scripting language to use.

Breakpoint conditions

You can use the "Condition" field of the breakpoint properties to enter an expression which is evaluated when the breakpoint is hit. It can be either an actual condition or just any valid code in IDC or another supported scripting language syntax. By using the "..." button, you can open a multi-line editor for the condition and switch the scripting language used for evaluating it.

Expressions

If you enter an expression, the result will be used to determine whether the selected actions are executed. Some examples of IDC expressions:

Check if EAX is equal to 5:

EAX==5

Check if the first argument to the function is 1:

get_wide_dword(ESP)==1

Interpret the second argument to the function as a pointer to Unicode string, print it, and return 0 (so that the execution continues immediately):

msg("Filename: %s\n", get_strlit_contents(get_wide_dword(ESP+4), -1, STRTYPE_UNICODE)), 0

Set EAX to 0 and continue:

EAX=0,0

Statements.

You can enter several statements in the multi-line editor. If the last one is a 'return' statement, it is used as the result of the condition. Otherwise the condition is assumed to return 0.

See also

• Index of IDC functions

Settings

• Enabled: If the breakpoint is enabled or disabled. Disabled breakpoints are not written to the debugged process.

• Hardware: If enabled, IDA will use a hardware breakpoint. The breakpoint mode and size must be specified for them (see below).

• Module relative: The breakpoint location is stored as a combination of a module name and an offset. This kind of breakpoint is useful for DLLs that are loaded to various addresses because their addresses cannot be calculated in advance. Example: kernel32+0x1234

• Symbolic: The breakpoint location is stored as a combination of a symbol name and a possible offset. This kind of breakpoint is useful for symbols that can be imported from different DLLs because their addresses cannot be calculated in advance. Example: myfunc+44

• Source code: The breakpoint location is stored as a combination of a source file name and a line number. Can be used only if the source code of the debugged application is available. Example: myfile.cpp:55

• Low level condition: Evaluate the condition on the remote computer. Such conditions are faster, especially during remote debugging, because there is no network traffic between IDA and the remote computer on each breakpoint hit.

Low level breakpoint conditions

Low level breakpoint conditions can be used to speed up the debugger. They are evaluated like this:

• In case of remote debugging, the condition is evaluated on the remote computer. The following actions are bypassed:

  • sending of the breakpoint event to the local computer

  • switching from debthread to the main thread

  • updating internal IDA structures and caches

  • updating the screen

• In case of local debugging, the condition is evaluated at low level. The following actions are bypassed:

  • switching from debthread to the main thread

  • updating internal IDA structures and caches

  • updating the screen

In both cases, there is a significant speed up. This improvement imposes some limitations on the breakpoint condition:

• only IDC expressions can be used for low level conditions

• only functions marked as 'thread-safe' may be called

• only entire registers can be accessed (e.g. EAX is ok but AL is not) Essentially this means that the only available functions are:

• read/write process registers

• read/write process memory

• file i/o

• auxiliary string and object functions

• msg() function (for debugging the breakpoint conditions)

Actions

• Break: Suspend the debugged application.

• Trace: Add a new entry to the trace log.

• Refresh debugger memory: By default, IDA does not refresh the memory config before evaluating a breakpoint condition. This option enables the refresh. To refresh it manually, call refresh_debugger_memory.

• Enable tracing: Enable tracing when the breakpoint hits. This is different from trace breakpoints (where only a new entry is added to the trace log).

• Disable tracing: Disable tracing when the breakpoint fires.

• Tracing type:

  • Instruction (Action ToggleTraceInstructions)

  • Function (Action ToggleTraceFunctions)

  • Basic block level (Action ToggleTraceBasicBlocks)

Tracing types can be selected for breakpoints where enable/disable tracing have been selected.

Size

Number of bytes to watch: 1, 2 or 4 bytes for normal hardware breakpoints. Any size for page breakpoints.

Hardware breakpoint mode

The access type the breakpoint will react: read/write, write, execute.

In the case of Intel hardware breakpoints, some limitations are enforced (in contrast with page breakpoints). It is impossible to create more than 4 hardware breakpoints. The address of the breakpoint must be aligned appropriately:

• 2-byte breakpoints must be word-aligned.

• 4-byte breakpoints must be dword-aligned.

Please note that hardware breakpoints occur AFTER the instruction execution while software breakpoints occur BEFORE the instruction.

Usually, it is easier to use software breakpoints, except if:

• we want to be sure the memory is not modified by the debugger (instruction breakpoints modify the debugged process memory)

• we want to detect accesses to data bytes

• the specified address is write protected (really rare!)