2

I assume you are using *nix based systems since you mentioned gdb. If you just want to print the stack/registers when you hit a break point, you can use command to set up some print statements. See here. Installing pwndbg makes it a lot less exhausting as it prints out the stack and registers every time you step, with labels on the stack identifying rbp and ...


1

After reading up on "shadow stack space" as suggested by @blabb it looks like this is an unoptimized build, so the 2 parameters RDX and RCX are being saved in the caller's scratch space, presumably to make debugging easier. I got most of this information from the following post: What is the 'shadow space' in x64 assembly?


1

Generally speaking, this is not possible with any reverse engineering tool. If the programmer created custom #define statements to associate numbers with symbolic names, this information will be destroyed by the compiler very early into the compilation process, long before the binary is ultimately created. Local variable names are also not preserved in the ...


1

Borland's Turbo Debugger also has a text-window-based UI, with the stack in its own window and showing which values in which locations. It doesn't tell you what those values represent, but at least it's always visible.


1

First, local variable allocation failures do not necessarily mean that the decompilation is incorrect. They can happen naturally when using forced variables, for example. I'd proceed trying to analyze the function as normal. If you see any weird variable manipulations that you can't reconcile, I would recommend double-checking the stack pointer all ...


Only top voted, non community-wiki answers of a minimum length are eligible