I've written a minimalistic implementation of the backtrace command
for x86. It's buggy and needs more work, but at least it give you
a minimal idea how do you arrive to the current eip :)
for(i=0; i<10; i++) {
debug_read_at(ps.pid, &ebp2, 4, regs.ebp); /* read previous ebp */
debug_read_at(ps.pid, &ptr, 4, regs.ebp+4); /* read previous eip */
printf("#%d 0x%08x\n", i, ptr);
regs.ebp = ebp2;
}
Obviously this only works after the push %ebp is called (the first opcode
after entering a subroutine), and it's unable to find the deepest level
of stack frames.
Any idea about how to enhace this? I think that an address resolution tool
must be written to reverse lookup the sym+off by a given offset. It can
be easily achieved with an external perl script, but this is not very
optimal, but stills fine for me, because i don't usually reverse lookup
everything all the time. and this gives a rawest view to the end user that
is always good :)
> You can walk the backtrace if you compiled the code without
> -fomit-framepointers.
> The frame pointers are set at the beginning of each function:
> push %ebp
> mov %esp, %ebp
i was thinking on read the bytes in %EIP and if they are "push %ebp, mov
%esp, %ebp", just bypass the +4 offset using the current %ebp instead of
the stored in the stack.
Just a minimal check and it should be ok.
I'll take a look this night for this.
> Thus, in any function, %ebp points to the current frame pointer, and
> %bp to the previous.
> You know that at -4(%ebp) there is the return address. Then, you know
> that at -4((%ebp)) (double indirection :), there is the other return
> address. And so on.
>
> Well, that's the idea. Maybe I gave the wrong offsets. :)
> gcc guarantees that %bp is only used for frame pointers. Otherwise the
> backtrace doesn't work. :)
The problem comes when the program doesn't follows the 'standards' ;)
About the 'core' lib I told you yesterday I've noticed that's written
by Zodiac :) Good to know about him.
--pancake
_______________________________________________
radare mailing list
[email protected]
https://lists.nopcode.org/mailman/listinfo/radare
