1

While doing crash analysis, I encountered bellow instructions.

74553ef7 50              push    eax
74553ef8 e81ba0ffff      call    MSVCR90!CxxThrowException (7454df18) 
74553efd cc              int     3 
74553efe cc              int     3
74553eff cc              int     3
74553f00 cc              int     3
74553f01 cc              int     3
74553f02 cc              int     3

While running windbg, I found running stoped on int 3 instruction.
As far as I know int 3 instruction is trap to debugger exception, which stands for the breakpoint.

But the thing is:

  1. I've not set any bp on windbg.

  2. So I checked debugger's default bp, and there're no enabled exception handler of windbg like below.

0:009> sx
vcpp - Visual C++ exception - second-chance break - handled
 wkd - Wake debugger - second-chance break - not handled
 wob - WOW64 breakpoint - second-chance break - handled
 wos - WOW64 single step exception - second-chance break - handled

Question:

  1. Is int 3 set by windbg? if so, why?
  2. Is int 3 originally exist on binary image? If so, why compiler inserts this instruction?

Jiwon
  • 1,074
  • 1
  • 11
  • 27
  • 0xCC is the [pattern for uninitialized memory in debug mode](https://stackoverflow.com/q/370195/995714) – phuclv Aug 09 '20 at 04:41
  • *Is int 3 originally exist on binary image?* Yes, but you could check that yourself with a disassembler, if you aren't sure you can trust your debugger not to be showing you a munged copy of the code. – Peter Cordes Aug 09 '20 at 04:45
  • I believe this q/a may answer your question https://stackoverflow.com/questions/18090317/visual-c-appends-0xcc-int3-bytes-at-the-end-of-functions – Michael Petch Aug 09 '20 at 04:48
  • Thanks @PeterCordes I found `cc` exist in disassembly ether. I also checked the links that all of you mentioned on comments. However there's a difference in my situation. This `cc` is code(NOT an uninitialized variable) and is executed during runtime(NOT a just padding being used for function alignment). So is that mean compiler insert 0xcc INTENTIONALLY to EXECUTE IT during runtime. Is that right? – Jiwon Aug 09 '20 at 05:46
  • No, MSVC uses `CC` for alignment padding *between functions*, where it won't execute. NOP for padding *inside* functions to align loops. Both of these are totally separate from its debug-mode poisoning of uninitialized stack and malloc with the same bit-pattern. @phuclv linked a Q&A about `CC` as data, but the ones I used as duplicates are about `CC` as code. – Peter Cordes Aug 09 '20 at 05:53

0 Answers0