INT3 (Breakpoint — 0xCC)

INT3 is the dedicated 1-byte software interrupt instruction encoded as 0xCC. It raises exception vector 3 (Debug Exception / Breakpoint), which the OS delivers to any attached debugger.

Encoding

CC   INT3     ; 1 byte — the only true 1-byte breakpoint
CD 03         ; INT 3  — 2-byte form; less common

Debuggers use the 1-byte form because overwriting exactly one byte of a target instruction is atomic on x86 and easy to restore.

How software breakpoints work

1. Debugger saves the original byte at target address.
2. Debugger writes 0xCC over the first byte.
3. CPU executes 0xCC → raises #BP.
4. OS notifies debugger; debugger restores original byte.
5. Debugger decrements RIP by 1 (execution stopped after the CC).

; Original
48 8B 45 F8   mov rax, [rbp-8]

; After breakpoint set (only first byte patched)
CC 8B 45 F8   INT3 ; <breakpoint>

Appearances in binaries

• Debug builds: MSVC fills uninitialised stack variables with 0xCC bytes (CC CC CC CC = int3; int3; int3; int3) to trap use-before-init bugs.
• __debugbreak() / DebugBreak(): compile to int3 — a programmatic breakpoint.
• Anti-debug tricks: a process can set a SIGTRAP / exception handler for #BP; if no debugger is present the handler runs normally; if a debugger intercepts the exception the handler is skipped, leaking debugger presence.
• Function padding: MSVC fills the gap between functions with 0xCC bytes instead of NOPs — a distinctive pattern in Windows binaries.

Reverse-engineering notes

• A 0xCC byte that is never reached by normal flow but sits at a hot-patch slot (5-byte NOP sled before a function) is a Windows hot-patch header — not a real breakpoint.
• Seeing CC CC CC CC in data is the MSVC 0xCC-fill of uninitialised heap/ stack memory — check whether you are looking at code or data.
• Some anti-tamper systems scan their own code sections for 0xCC bytes to detect debugger breakpoints at runtime.