I am debugging a binary file in gdb. It was C code compiled by gcc on an Intel IA-32. I retrieved this output from objdump. I am most interested in the last line here:
08048d9e <func_1>
8048d9e: 55 push %ebp
8048d9f: 89 e5 mov %esp,%ebp
8048da1: 83 ec 18 sub $0x18,%esp
8048da4: c7 44 24 04 88 99 04 movl $0x8049988,0x4(%esp)
8048dab: 08
8048dac: 8b 45 08 mov 0x8(%ebp),%eax
8048daf: 89 04 24 mov %eax,(%esp)
8048db2: e8 54 01 00 00 call 8048f0b <strings_not_equal>
I believe this last line will compare the value found at the indicated address: 8048f0b. I attempt:
(gdb) x 0x8048f0b
and receive:
0x8048f0b <strings_not_equal>: 0x57e58955
Am I interpreting the assembly incorrectly? Is this the correct way to read the value of an address in gdb? I was kind of expecting to find a more ascii friendly hex value. I am interested in finding the stored string value that is compared against.
Also do you have a favorite gui tool that you like to use for this type of debugging? I have been thinking about trying ddd. I want to find an easier way to debug.
1 Answer
You are correctly reading the value at memory address 0x8048f0b, but the line call 8048f0b <strings_not_equal> indicates that this address is the start of a function (called strings_not_equal()). You wouldn't expect that to be ASCII - you'd expect it to be more machine code.
If you're looking for the function arguments to strings_not_equal(), those are being pushed onto the stack. The first argument is being copied from 0x8(%ebp), which is the first argument of func1(). The second argument is $0x8049988, which is presumably the address of a string.
If you want to print the contents of the address as a string, you can do that with x/s:
x/s 0x8049988
