0:000> db 0x00320e10
00320e10 6d 65 65 74 00 4d 72 00-48 61 78 6f 72 00 fd fd meet.Mr.Haxor...
Let??™s continue on until we hit our second breakpoint at the greeting function.
0:000> g
Breakpoint 2 hit
...
meet!greeting:
00401020 55 push ebp
0:000> kP
ChildEBP RetAddr
0012fecc 00401076 meet!greeting(
char * temp1 = 0x00320e15 "Mr",
char * temp2 = 0x00320e18 "Haxor")
0012fedc 004013a0 meet!main(
int argc = 3,
char ** argv = 0x00320e00)+0x16
0012ffc0 77e7eb69 meet!mainCRTStartup(void)+0x170
0012fff0 00000000 kernel32!BaseProcessStart+0x23
You can see from the stack trace (or the code) that greeting is passed the two arguments
we passed into the program as char *. So you might be wondering, ???how is the
stack currently laid out???? Let??™s look at the local variables and map it out.
0:000> dv /V
0012fed4 @ebp+0x08 temp1 = 0x00320e15 "Mr"
0012fed8 @ebp+0x0c temp2 = 0x00320e18 "Haxor"
0012fd3c @ebp-0x190 name = char [400] "???"
The variable name is 0x190 above ebp. Unless you think in hex, you need to convert
that to decimal to put together a picture of the stack. You can use calc.exe to compute
that or just ask the debugger to show the value 190 in different formats, like this:
0:000> .formats 190
Evaluate expression:
Hex: 00000190
Decimal: 400
So it appears that our variable name is 0x190 (400) bytes above ebp.
Pages:
443
444
445
446
447
448
449
450
451
452
453
454
455
456
457
458
459
460
461
462
463
464
465
466
467