Programming 270x080483a3 <main+31>: mov DWORD PTR [esp],0x80484d4
0x080483aa <main+38>: call 0x80482a8 <_init+56>
0x080483af <main+43>: lea eax,[ebp-4]
0x080483b2 <main+46>: inc DWORD PTR [eax]
0x080483b4 <main+48>: jmp 0x804839b <main+23>
0x080483b6 <main+50>: leave
0x080483b7 <main+51>: ret
End of assembler dump.
(gdb) break main
Breakpoint 1 at 0x8048394: file firstprog.c, line 6.
(gdb) run
Starting program: /hacking/a.out
Breakpoint 1, main() at firstprog.c:6
6 for(i=0; i < 10; i++)
(gdb) info register eip
eip 0x8048394 0x8048394
(gdb)
First, the source code is listed and the disassembly of the main() function
is displayed. Then a breakpoint is set at the start of main(), and the program is
run. This breakpoint simply tells the debugger to pause the execution of the
program when it gets to that point. Since the breakpoint has been set at the
start of the main() function, the program hits the breakpoint and pauses
before actually executing any instructions in main(). Then the value of EIP
(the Instruction Pointer) is displayed.
Notice that EIP contains a memory address that points to an instruction in
the main() function’s disassembly (shown in bold). The instructions before this
(shown in italics) are collectively known as the function prologue and are gen-
erated by the compiler to set up memory for the rest of the main() function’s
local variables. Part of the reason variables need to be declared in C is to aid
the construction of this section of code. The debugger knows this part of the
code is automatically generated and is smart enough to skip over it. We’ll talk
more about the function prologue later, but for now we can take a cue from
GDB and skip it.
The GDB debugger provides a direct method to examine memory, using
the command x, which is short for examine. Examining memory is a critical
skill for any hacker. Most hacker exploits are a lot like magic tricks—they
seem amazing and magical, unless you know about sleight of hand and
misdirection. In both magic and hacking, if you were to look in just the right
spot, the trick would be obvious. That’s one of the reasons a good magician
never does the same trick twice. But with a debugger like GDB, every aspect
of a program’s execution can be deterministically examined, paused, stepped
through, and repeated as often as needed. Since a running program is mostly
just a processor and segments of memory, examining memory is the first way
to look at what’s really going on.
The examine command in GDB can be used to look at a certain address
of memory in a variety of ways. This command expects two arguments when
it’s used: the location in memory to examine and how to display that memory.