Breakpoints

Here are the commands to use the debugger breakpoints.

Related topics:

See also Debugger submenu.

Breakpoints list

Action    name: Breakpoints

Opens the breakpoints window.

In this window, you can view information related to existing breakpoints. Breakpoints are saved in the database, and restored as soon as possible (once the memory becomes writeable).

The 'Pass count' column indicates how many times the program needs to hit the breakpoint before being suspended (0 means "always suspend").

Add breakpoint

Action    name: BreakpointAdd

This command adds a breakpoint at the current address. If an instruction exists at this address, an instruction breakpoint is created. Otherwise, IDA offers to create a hardware breakpoint and allows the user to edit breakpoint settings. Hardware breakpoints can be either real hardware breakpoints or page breakpoints.

Edit breakpoint

Action    name: BreakpointEdit

This command opens a dialog box to edit an existing breakpoint.

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. Tests like this are allowed, for example: EAX == EBX+5 or get_wide_dword(ESP+0x10) == 34 You can also use the "..." button to enter a multiline condition, or specify another scripting language to use. See here for more info.

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. More details

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, Function and Basic block level tracing types can be selected for breakpoints where enable/disable tracing have been selected. Hardware breakpoint 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!).

See also

Delete breakpoint

Action    name: BreakpointDel

This command deletes an existing breakpoint at the current address.

Page breakpoints

Page breakpoints are memory access breakpoints that can be set to detect when the application reads, writes, or executes code/data in a specific memory range. Page breakpoints are very similar to hardware breakpoints but there is no limitation on the number of page breakpoints that can be set or their size, in contrast with normal hardware breakpoints.

Memory access breakpoints are implemented by removing page permissions according to the specified type of the page breakpoint to be added (for example, for a write page breakpoint, the write permission will be removed from the page). When the access violation exception occurs because the application tries to access the specific memory region, IDA reports a breakpoint hit.

As page breakpoints can be set for a small part of a memory page but the permissions of the whole page must be changed, page breakpoints can slow down the debugger because many access violation exceptions may be generated. If the application accesses memory outside of the desired range but on the same page, the generated exception must be silently handled and the application resumed. Specifically, page breakpoints in the code segment can slow down the debugger very much.

Memory access breakpoints are supported since IDA version 6.3 for the following debuggers:

Win32

  Page breakpoints are supported for both local and remote debugging
  of 32 and 64bit applications.

WinDbg

  Page breakpoints are supported only for local debugging of 32-bit applications.

Bochs

  Page breakpoints are supported for both of 32 and 64bit applications.
  Page breakpoints in the bochs debugger are just like normal hardware
  breakpoints but with no limit on the number of breakpoints or their size.
  Please note that hardware breakpoints in the bochs debugger occur AFTER the
  instruction is executed while regular page breakpoints occur BEFORE the
  instruction is actually executed.

Find breakpoint

Action    name: BreakpointFind

Open the breakpoints window if needed, then find current breakpoint in it.

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

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)

Low level breakpoint conditions are available only for Win32, Linux, Mac, and Android debuggers.

Last updated