Graphics Programs Reference
In-Depth Information
0x080483a3 <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 e
x
amine 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.
