microsoft.com/
download/symbols
C:\grayhat>c:\debuggers\cdb.exe meet Mr Haxor
??¦output truncated for brevity??¦
(280.f60): Break instruction exception ??“ code 80000003 (first chance)
eax=77fc4c0f ebx=7ffdf000 ecx=00000006 edx=77f51340 esi=00241eb4 edi=00241eb4
eip=77f75554 esp=0012fb38 ebp=0012fc2c iopl=0 nv up ei pl nz na pe nc
cs=001b ss=0023 ds=0023 es=0023 fs=003b gs=0000 efl=00000202
ntdll!DbgBreakPoint:
77f75554 cc int 3
0:000>
As you can see from the output of cdb, at every breakpoint it displays the contents of
all registers and the assembly that caused the breakpoint. In this case, a stack trace will
show us why we are stopped at a breakpoint:
0:000> k
ChildEBP RetAddr
0012fb34 77f6462c ntdll!DbgBreakPoint
0012fc90 77f552e9 ntdll!LdrpInitializeProcess+0xda4
0012fd1c 77f75883 ntdll!LdrpInitialize+0x186
00000000 00000000 ntdll!KiUserApcDispatcher+0x7
It turns out that the Windows debugger automatically breaks in after initializing the
process before execution begins. (You can disable this breakpoint by passing -g to cdb
on the command line.) This is handy because at this initial breakpoint, your program
has loaded, and you can set any breakpoints you??™d like on your program before execution
begins.
Pages:
438
439
440
441
442
443
444
445
446
447
448
449
450
451
452
453
454
455
456
457
458
459
460
461
462