Re: Examining copied stack contents

["Martin Schröder" <gschroeder@onlinehome.de>]

Petr Hluzín wrote:
> On 3 July 2010 12:46, Martin Schröder <gschroeder@onlinehome.de>
> wrote:
>
> In general a debugger needs at least a stack pointer and an
> instruction pointer to get a backtrace. If the function containing the
> IP uses a frame pointer (a debugger should be able to tell you that)
> then debugger needs to know the FP. Which register contains the FP
> depends on the prologue type chosen by compiler (on x86 it is always
> EBP). Command "info frame <address>" may assume IP is pointed to by
> SP. So there are at least 2 arguments (FP+SP) to be provided on any
> arch.
>
> Therefore I suspect "info frame <address>" is not general enough to be
> used in your case.

Hello everyone; and thanks to Petr and Joel.

The above comment was exactly what I needed to find a working solution 
for my problem, at least as long as GDB uses Dwarf2 frame unwinding (but 
it *probably* should work with the other unwinders, too).


Due to the content of the stack being an unaltered copy, it's of course 
impossible for GDB to properly unwind it at its current location. Thus, 
you have to copy it back to its original position. But since you almost 
always want to continue your program properly later on, your first step 
has to be to save the part of the stack that's going to be overwritten.

If you assume that the convenience variable "$base" is the original 
address of the stack, "$length" its length and "$copyPos" the address of 
the copy, you have to execute the following commands:

- - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
gdb> set $stack = malloc($length)
gdb> p memcpy($stack, $base, $length);
gdb> p memcpy($base, $copyPos, $length);
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - -

Of course, you should check if malloc returns something other than 0. 
But for brevity's sake, I won't write down the sanity checks.

In any case, after you've backed-up the current stack and copied over 
the old stack, you have to set the $epb and $eip registers to allow GDB 
to understand the stack. Both should be stored within the jmp_buf struct 
that's created by the setjmp() statement.

Unfortunately, due to security reasons, glibc masks the stack pointer 
register (which is not needed by GDB, strangely enough) and the eip 
register on Linux. Their actual values are xor-ed with a fixed pattern 
and then rotated by 9 bits to the left [1]. After undoing that, you can 
get the eip and all that remains to do is to fetch the ebp frame 
pointer.

In my case that's simple, because due to the way the stack is copied, 
the ebp register is always 9 bytes less than the "base" variable. 
Otherwise, you have to dig around where the ebp is stored inside the 
jmp_buf or get it from somewhere else (like I did).

Anyway, after you have the ebp and eip values, simply back them up and 
set them with the following commands:

- - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
gdb> set $ebpsave = $ebp
gdb> set $eipsave = $eip
gdb> p $ebp = 0x<Hexadecimal-EBP-Content>
gdb> p $eip = 0x<Hexadecimal-EIP-Content>
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - -

Now, you can get a full backtrace and explore the frame details.

If you later intend to continue execution, just reset your changes:

- - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
gdb> p $ebp = $ebpsave
gdb> p $eip = $eipsave
gdb> p memcpy($base, $stack, $length)
gdb> p free($stack)
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - -


That's it. A bit crude since you can't exactly "just" look at it, need 
to learn the correct values of ebp and eip and it only works like that 
on x86, but hey, at least it *does* work. :)



Thanks again for you help!
    Martin Schröder.


[1] - http://cseweb.ucsd.edu/~hovav/dist/noret.pdf Page 14