Debugger attach and ASLR rebasing pitfalls

When attaching a debugger to a live Windows process, the static disassembly addresses shown in tools like Binary Ninja are usually RVAs (relative virtual addresses) relative to the module's preferred base address. The Windows loader then applies ASLR (Address Space Layout Randomization), so the module loads at a different base address in memory.

Why breakpoints can silently miss

• A breakpoint set in the static view before attach may stay at the file/preferred-base address.
• If the debugger does not rebase the view to the live module base, the breakpoint is written to the wrong physical address.
• The function still runs; the breakpoint is simply in the wrong place.

Workflow to avoid this

1. Attach to the running process first.
2. Open the debugger's Modules or Memory Map view.
3. Find the actual load base address of the target module.
4. Set the breakpoint in the live process view, not the static file view.
5. Alternatively, compute the live address manually: live_addr = actual_base + (static_addr - preferred_base).

Tool-specific notes

• IDA: usually rebases the database automatically on attach.
• Binary Ninja: may require manual rebase or setting breakpoints after attach.
• Frida: always operates on live process memory, so it avoids the issue entirely.

Quick verification

If you suspect a rebasing problem, hook the same function with Frida by resolving the live module base plus the RVA. If Frida hits but the GUI debugger does not, the breakpoint was placed at the wrong rebased address.