From: Justin Ferguson (jnferguson@gmail.com)
Date: Fri Sep 14 2007 - 04:34:53 EDT
one doesnt need the code at all to understand your situation, and in
fact, when he said that he overwrote one byte past, the most likely
presumption is that he hit the saved frame pointer, which in turn
begets the question, why would you be answering a question you dont
know the answer to?
As I said out-of-band to you Alcides, go lookup the documentation for
the instructions 'leave' and 'ret' or whatever equiv for your
architecture, if you still don't see your answer, think a bit harder
for a while, if you're still not getting it see if this paper rouses
any ideas http://www.phrack.org/archives/55/P55-08 , lastly if you
still don't get it perhaps you should consider a new hobby, maybe
something pen-testing web-apps.
On 9/13/07, Amit Bagree <bagree@cmu.edu> wrote:
> Hey Alcides,
>
> It would be more helpful if you can provide the actual
> code. Are you sure you are watching the EIP values
> right after the overflow happens and I mean in asm not
> C. The key to understanding BO is to notice how the
> stack, EIP and EBP are manipuated for each asm
> instruction. "Smashing the stack for fun and profit"
> is the quintessential reference for understanding BO.
> The basic stack structure is:
>
> [Buffer][EBP/Frame pointer][Return addr/saved
> Instruction Ptr][arguments]
>
> You need to account for the Frame pointer/ BP. From
> what you say in 3] and 4] either you are not looking
> at the what you need to watch for or you are not
> reaching till the ret addr. Hope that helps.
>
>
> Cheers & Chi!!
> Amit
>
>
>
> --- Alcides <alcides.hercules@gmail.com> wrote:
>
> > Hi List,
> > I was wondering if someone has already done this.
> > I'm testing a small program written in C, especially
> > coded for testing
> > buffer overflow.
> > In source code, I have assigned char buffer[512]; I
> > compile with gcc and
> > run on bash.
> >
> > As soon as I pass "512" characters as
> > argument("A"x512--being precise),
> > the program gives " Segmentation fault (core dumped
> > )" -->as desired.
> >
> > 1] Using GDB debugger, it has been verified that the
> > extended
> > instruction pointer EIP has been overwritten, as
> > expected.
> > (EIP-->0x41414141)
> > 2] But, on passing "513" chars. argument, the EIP
> > becomes 0x0 -->WHY
> > 3]On passing 520 chars. argument, EIP takes 'some'
> > value and EBP
> > becomes 0x41414141
> > 4]Thereafter, every increment by 1 --> in input
> > characters causes EIP to
> > remain the same as that 'some' value and EBP to take
> > various incremental
> > values.
> > every time, for several unit increments
> >
> > [I am using: 2.6.21-1.3194.fc7 kernel, i686,
> > Disabled VA randomization]
> >
> > Any views that help me understand why EIP becomes
> > 0, are welcome.
> >
> >
> > Thanks.
> >
> >
> ------------------------------------------------------------------------
> > This list is sponsored by: Cenzic
> >
> > Need to secure your web apps NOW?
> > Cenzic finds more, "real" vulnerabilities fast.
> > Click to try it, buy it or download a solution FREE
> > today!
> >
> > http://www.cenzic.com/downloads
> >
> ------------------------------------------------------------------------
> >
> >
>
>
>
> DELETE button is history. Unlimited mail storage is just a click away. Go to https://edit.india.yahoo.com/config/eval_register
>
> ------------------------------------------------------------------------
> This list is sponsored by: Cenzic
>
> Need to secure your web apps NOW?
> Cenzic finds more, "real" vulnerabilities fast.
> Click to try it, buy it or download a solution FREE today!
>
> http://www.cenzic.com/downloads
> ------------------------------------------------------------------------
>
>
------------------------------------------------------------------------
This list is sponsored by: Cenzic
Need to secure your web apps NOW?
Cenzic finds more, "real" vulnerabilities fast.
Click to try it, buy it or download a solution FREE today!
http://www.cenzic.com/downloads
------------------------------------------------------------------------
This archive was generated by hypermail 2.1.7 : Sat Apr 12 2008 - 10:58:07 EDT