Neko’s Knowledge Vault
#understanding-assembly-via-examples #windbg #debugging #reverse-engineering

WinDbg Hardware Breakpoints (ba)

ba sets a hardware breakpoint that triggers on memory access rather than execution.

ba vs bp

Command Type Fires when
bp Software (INT3) Execution reaches address
ba Hardware (DR0-DR3) Address is read, written, or executed

Hardware breakpoints are essential when you need to find which instruction touches a variable or buffer, because software breakpoints can only stop on code execution.

Common forms

  • ba w1 <addr> — break on write to 1 byte
  • ba w4 <addr> — break on write to a DWORD
  • ba r1 <addr> — break on read of 1 byte
  • ba r4 <addr> — break on read of a DWORD
  • ba e1 <addr> — break on execution (similar to bp, but uses hardware register)

You can also use registers and expressions:

  • ba w1 eax
  • ba r4 poi(ebp+8)

Managing breakpoints

bl       ; list all breakpoints (bp and ba together)
bc *     ; clear all breakpoints
bc 0     ; clear breakpoint 0
bd 1     ; disable breakpoint 1
be 1     ; enable breakpoint 1

Hardware breakpoints are limited in number (typically 4) and size, since they use CPU debug registers.

IDA vs WinDbg breakpoints

  • IDA: F2 sets a software breakpoint in the disassembly view.
  • IDA breakpoints are managed in Debugger → Breakpoints (Alt+B).
  • They only take effect if IDA is driving the debugger.
  • If you attach with WinDbg manually, use WinDbg commands (bp, ba, bl, bc) instead.

Because of ASLR, addresses in IDA and WinDbg may differ. Rebase the IDA database (Edit → Segments → Rebase program) to match the live module base shown by lm.

Typical use case

You want to find the instruction that corrupts or encrypts a buffer:

ba w1 <buffer_address>

The debugger stops exactly on the writing instruction.