Different RSP register value between Radare2 and GDB

Question

the question is, as the title states, I'm getting a different rsp value when I try to read the rsp register after hitting the breakpoint of a particular function.

I think from my research, commands between Radare2 and GDB are equivalent, but it seems they are not since Radare2 is giving me the wrong value. I'm trying to understand the cause of this difference, so if anyone can give me an idea, I would appreciate it.

---

Since GDB is giving me the right values, I will first show how I work with GDB:

» gdb ./test
pwndbg> b *&(fun)
Breakpoint 1 at 0x40117d: file src/test.c, line 10.
pwndbg> r
pwndbg> i r $rsp
rsp            0x7fffffffcd28      0x7fffffffcd28
pwndbg> p &buffer[0]
$1 = 0x7fffffffcca0 ""

---

Now, here is my attempt at trying to do equivalent commands of the above with Radare2 (I'm trying to learn how to use Radare2 better)

» r2 -d ./test
[0x7ffff7fd3090]> aaa
INFO: Analyze all flags starting with sym. and entry0 (aa)
INFO: Analyze imports (af@@@i)
INFO: Analyze entrypoint (af@ entry0)
INFO: Analyze symbols (af@@@s)
INFO: Recovering variables
INFO: Analyze all functions arguments/locals (afva@@@F)
...
[0x7ffff7fd3090]> afl | grep fun
0x0040117d    1     63 dbg.fun
[0x7ffff7fd3090]> db dbg.fun
[0x7ffff7fd3090]> s 0x40117d
[0x0040117d]> dc
INFO: hit breakpoint at: 0x40117d
[0x0040117d]> afv
var char[128] buffer @ rbp-0x80
[0x0040117d]> dr rsp
0x7fffffffcdc8 <---- this should be 0x7fffffffcd28 
[0x0040117d]> x/16x @rbp-0x80
- offset -      6061 6263 6465 6667 6869 6A6B 6C6D 6E6F  0123456789ABCDEF
0x7fffffffcd60  0000 0000 0000 0000 0000 0000 0000 0000  

# 0x7fffffffcd60 should be 0x7fffffffcca0
................

---

In summary,

0x7fffffffcdc8 (R2) != 0x7fffffffcd28 (GDB)

and

0x7fffffffcd60 (R2) != 0x7fffffffcca0 (GDB)

Could someone let me know what I am doing wrong in the Radare2? Thank you in advance.

Answer 1

Radare2 is giving me the wrong value.

What makes you think one value is right and the other is wrong?

When a Linux process starts, the kernel places a bunch of data at the top of the stack (which in turn affects the value of RSP when _start is invoked), and that data can vary in size.

One of the things placed on the stack is the argv[] vector, and GDB has a tendency to invoke the program being debugged as /absolute/path/to/./test.

If Radare2 doesn't do that, this could easily explain the difference of 160 bytes.