Ethical Hacking Learn to find vulnerabilities before the bad guys do! Gain real world hands on hacking experience in our state of the art hacking lab. Course designed and taught by expert instructors with years of penetration testing experience. 12 student maximum in every class. Certification attempt included in every package. | Computer Forensics Training at InfoSec Institute Gain the in-demand skills of a certified computer examiner, learn to recover trace data left behind by fraud, theft, and cybercrime perpetrators. Discover the source of computer crime and abuse at your organization so that it never happens again. All of our class sizes are guaranteed to be 12 students or less to facilitate one-on-one interaction with one of our expert instructors. |

| Subject: | Re: Buffer Overflow Experiment |
|---|---|
| Date: | Fri, 14 Sep 2007 03:33:54 +0100 (BST) |
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
------------------------------------------------------------------------
| <Prev in Thread] | Current Thread | [Next in Thread> |
|---|---|---|
| ||
| Previous by Date: | Re: Anonymizing Packets yet ensuring 0 % packet loss, Brett Cunningham |
|---|---|
| Next by Date: | Re: anonymous socks proxies ??, Jerome Athias |
| Previous by Thread: | Buffer Overflow Experiment, Alcides |
| Next by Thread: | Re: Buffer Overflow Experiment, Justin Ferguson |
| Indexes: | [Date] [Thread] [Top] [All Lists] |