Look at the first image:
Here what I get is var void *buf @ stack - 0x28.
But I'm watching a tutorial there his Cutter shows like this:
var void *buf @ rbp - 0x20. How can I change cutter to appear like this?
I became so confused with it. Had to spent some time to discover the discrepancy.
The two pictures probably show the same binary being analyzed. But the two Cutter versions might not be the same, and that's likely the cause for the discrepancy you see.
Cutter is a front end for Rizin, and disassembly is performed by Rizin and then reformatted by Cutter for display. There was a change in Rizin v0.5.0 (February 2023) that affects the display of stack variables: The Rizin team removed the old bp/sp related addressing for x86 family architectures, because it often caused misleading results. Instead, all variables would from then on be displayed as stack - hexoffset , as is the case in your first picture.
Before this change, Rizin users would sometimes see two different variable names/offsets, and not realize they resolved to the same address (and thus the same variable). This doubled up the number of detected variables at the top of the function, led to a lot of confusion, and also made integrating the stack variables into decompilers (such as rz-ghidra) a mess.
If you use a Cutter version released in or after February 2023 (such as Cutter v2.2.0-rc1 or later), that one likely packages a Rizin version containing the mentioned change. AFAIK, the behavior of the display of stack variables cannot be configured.
I think you might be following a tutorial such as the one linked below. If that's the case and you want to followed it closely, you can simply install the same version of Cutter. The author of the linked tutorial is using Cutter v2.1.0 from June 2022, which contains rizin v0.4.0. If you're using Linux, the AppImage of that version is still available on the releases pages.
Tutorial (not mine): 'Exploiting Return Oriented Programming (ROP) tutorial - Binary Exploitation PWN101' on YT
@feldspar's reply is 100% accurate. It was a change introduced by the Cutter team as of February 2023.
I just wanted to add that the important thing here is to understand how the addressing works, regardless of whether it is relative to the bottom of the stack or the rbp. They are equivalent.
When you have an address like stack - 0x28 it means the variable "lives" in the stack at address -0x28 from the very beginning of the stack. Where does the stack begin? At rbp+0x8 (a.k.a the saved return address).If you think about it, it is equivalent to rpb-0x20 because the rpb register is 8 bytes long.
If we draw the stack something like this:
stack+0x8 or rbp+0x10 | ... | Higher Addresses
stack or rbp+0x8 |saved @ret|
stack-0x8 or rbp |(old) rbp |
stack-0x10 or rbp-0x8 | ... |
stack-0x18 or rbp-0x10 | ... |
stack-0x20 or rbp-0x18 | ... | Lower Addresses
and so on....
it may be easier to understand why they are equivalent. Let us take as example the saved return address and the saved rbp:
stack to stack+0x7 (8 bytes) or rbp+0x8 to rbp+0xf.rbp to rbp+0x7 (or stack-0x8 to stack-0x1).Hope this helps clarifying concepts.
EDIT 2024.03.27: I've uploaded a video about this topic and Cutter's configuration and customization: https://www.youtube.com/watch?v=zrXA3AC_658.
