We can view a list of variable labels in our program by entering the command:
info variables
Which outputs:
(gdb) info variables
All defined variables:
Non-debugging symbols:
0x0804a000 message
0x0804a00d hex_message
0x0804a01a __bss_start
0x0804a01a _edata
0x0804ja01c _end
(gdb)
We can see that the address for our message matches what is loaded into the ecx register.
Let's look at the actual data stored at this address. To view the data, we need to let gdb know how many bytes
we want to view. We can see that message starts at 0x0804a000, and hex_message is the next label at
0x0804a00d, which means message should be 0xd (or 13) bytes long.
To view 13 bytes starting at the message label, enter:
To view 13 bytes starting at the message label, enter:
x /13xb 0x0804a000
Which outputs:
(gdb) x /13xb 0x0804a000
0x804a000: 0x48 0x65 0x6c 0x6c 0x6f 0x20 0x57 0x6f
0x804a008: 0x72 0x6c 0x64 0x21 0x0a
This shows us the 13 bytes of data stored at 0x804a000 in hexadecimal, but since we know that the data contains
ASCII characters, let's output the data in character format.
Enter:
Enter:
x /13cb 0x0804a000
This outputs:
(gdb) x /13cb 0x0804a000
0x804a000: 72 'H' 101 'e' 108 'l' 108 'l' 111 'o' 32 ' ' 87 'W' 111 'o'
0x804a008: 114 'r' 108 'l' 100 'd' 33 '!' 10 '\n'
(gdb)
We can easily recognize our "Hello World!\n" message.
Now let's view the contents of the entire .data section of our program. To do so, wee need to find the memory range that it occupies.
To view the memory ranges for our program's sections, enter:
Now let's view the contents of the entire .data section of our program. To do so, wee need to find the memory range that it occupies.
To view the memory ranges for our program's sections, enter:
info file
This outputs:
Symbols from "/home/pete/Documents/ASM/hello_world/x86/hello_x86".
Native process:
Using the running image of child process 84922.
While running this, GDB does not access memory from...
Local exec file:
`/home/pete/Documents/ASM/hello_world/x86/hello_x86', file type elf32-i386.
Entry point: 0x8049000
0x08049000 - 0x0804903a is .text
0x0804a000 - 0x0804a01a is .data
0xf7ffc0b4 - 0xf7ffc0f4 is .hash in system-supplied DSO at 0xf7ffc000
0xf7ffc0f4 - 0xf7ffc140 is .gnu.hash in system-supplied DSO at 0xf7ffc000
0xf7ffc140 - 0xf7ffc1f0 is .dynsym in system-supplied DSO at 0xf7ffc000
0xf7ffc1f0 - 0xf7ffc2b0 is .dynstr in system-supplied DSO at 0xf7ffc000
0xf7ffc2b0 - 0xf7ffc2c6 is .gnu.version in system-supplied DSO at 0xf7ffc000
0xf7ffc2c8 - 0xf7ffc31c is .gnu.version_d in system-supplied DSO at 0xf7ffc000
0xf7ffc31c - 0xf7ffc3ac is .dynamic in system-supplied DSO at 0xf7ffc000
0xf7ffc3ac - 0xf7ffc3b8 is .rodata in system-supplied DSO at 0xf7ffc000
0xf7ffc3b8 - 0xf7ffc40c is .note in system-supplied DSO at 0xf7ffc000
0xf7ffc40c - 0xf7ffc430 is .eh_frame_hdr in system-supplied DSO at 0xf7ffc000
0xf7ffc430 - 0xf7ffc53c is .eh_frame in system-supplied DSO at 0xf7ffc000
0xf7ffc540 - 0xf7ffd262 is .text in system-supplied DSO at 0xf7ffc000
--Type <RET> for more, q to quit, c to continue without paging--
The .text and .data entries are the two entires we care about right now. The entries listed below them
are Dynamic Shared Objects (DSO) that we are not currently interested in. Looking at the entry for our .data section, we can see that
it occupies memory addresses 0x0804a000 - 0x0804a01a.
We can have gdb calculate the size of the .data section for us by entering the command:
We can have gdb calculate the size of the .data section for us by entering the command:
print (0x0804a01a - 0x0804a000)
This subtracts the starting address of .data from the ending address and prints the result, which should be 26 bytes.
To view all 26 bytes stored in the .data section, enter:
x /26xb 0x0804a000
This outputs:
(gdb) x /26xb 0x0804a000
0x804a000: 0x48 0x65 0x6c 0x6c 0x6f 0x20 0x57 0x6f
0x804a008: 0x72 0x6c 0x64 0x21 0x0a 0x48 0x65 0x6c
0x804a010: 0x6c 0x6f 0x20 0x57 0x6f 0x72 0x6c 0x64
0x804a018: 0x21 0x0a
(gdb)
Again, since we know this should contain ASCII characters, we can output it in character format with:
x /26cb 0x0804a000
Which outputs:
0x804a000: 72 'H' 101 'e' 108 'l' 108 'l' 111 'o' 32 ' ' 87 'W' 111 'o'
0x804a008: 114 'r' 108 'l' 100 'd' 33 '!' 10 '\n' 72 'H' 101 'e' 108 'l'
0x804a010: 108 'l' 111 'o' 32 ' ' 87 'W' 111 'o' 114 'r' 108 'l' 100 'd'
0x804a018: 33 '!' 10 '\n'
(gdb)
This shows the data for both our message label which starts at 0x804a000, and our hex_message label at 0x804a00d.