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
------------------------------------------------------------------------
