buffer overflow

By blackbox I meant something which you don't know about.. A blackbox approach means I know nothing about the internals and I'm just using varied inputs to see how it would respond. This is a different approach from having access to the source and being able to see the internals of the software, how it works.

The simplest is to use A (0x41) as your buffer.. If eip gets overwritten with something in your bufffer it will show up as 0x41414141. By using AAABACAD etc. you can even work out which bytes in your buffer are actually overwriting eip.

like i said before: thats what i did, but all the time the eip was overwrting by this address: 0x000012FF , so maybe its one of the defense on windows..

Then you aren't overwriting EIP..

It might be some errorhandling routine that chokes.. Look at the backtrace to see what's happening before the crash.

how can i do this backtrace ?

someone ?

Mystic-D ....Obviously ...your havent read the posts...but want someone to spoon feed you....

sorry..cant help you...but I do see alot of informatiom in the thread

you havent answered any questions...but want answers from your very vague questions....therefore you get and well deserve.. very vague answers

:rolleyes:

MLF

maybe im not clear,so i'll ask again ... (sorry if im disrupt someone, im just tring to learn) , i have a server (that i was build in C), this server is got username from the client (the username is going onto buffer of 24 bytes) and im trying to exploit this buffer and overwrite the eip...
the connection is over TCP protocol.
so i was trying to exploit this buffer by send 50 bytes of junk (AAA'..) and by send 1000bytes of this junk, and no matter how much im sending, when im watching the olldbg i saw that the eip got this address: 0x000012ff, i removed the DEP option for my server exe file.. and i know that maybe its going to this address all the time is coz the SEH..
so plz maybe someone can help me and tell me how can i overcome this or give me a cue to what can i do now..(or how can i backtrace it..) ?
if someone have any questions about the server so jusk ask.. (its a really minimal server...)
thanks alot !

Yes, you've been very clear. You've said the same things over and over again. I can read, even between the lines...

You're trying to run before you can walk my friend.. It took me 20 years of computing, learning and trying to become what I am today and I'm still learning new things every single day.. Learn the basics first, learn them well, take it step by step.. You simply cannot cut corners or you'll be lost. Despite what everyone wants you to believe, buffer overflows are far from simple. They're only simple if you know how a computer works, how compilers do their job, what makes them 'tick'. Yeah, sure, you might get there faster then me but please, don't think you can master this in a week..

Learn how to use a debugger first.. Then you would know how to backtrace.. Learning how to use debuggers and the interaction between assembly and C/C++ is essential knowledge if you want to learn about buffer overflows..

so first i`ll learn to walk... so i have another question:
did someone know how can i exploit the function "recv()" in C ?
im trying to send more than the buffer size can get..but the recv() function write only the first data into the buffer....
or maybe someone know whats happened to the last DATA that was not write to the buffer..( i mean,where the func or OS write the last data)..
thanks !

Hi

Apologies: I will be slightly off-topic regarding the initial request,
but on-topic with respect to the last questions posted by the thread
starter.
--

Quote:

---

did someone know how can i exploit the function "recv()" in C ?
im trying to send more than the buffer size can get..but the recv() function write only the first data into the buffer....
or maybe someone know whats happened to the last DATA that was not write to the buffer..( i mean,where the func or OS write the last data)..

---

These are good questions - I was asking myself the same a while ago.
You should realise that there is no magic in all that - most of the basics
are documented and ready to be studied - since at least 1981 ...


To give a short anwer:

Based on the here discussed sockets-approach, the recv-call, which is
available to the user, reads a certain amount of bytes from a receiving
buffer (often called recvQ). Since recv() allocates the needed amount of
bytes in the memory, and does not read more than that, it is not possible
to find a direct attack vector in this strict sense. However, you have to
check the specific implementation (easier if open source) - what you find
is that recv.c calls _recfrom, which itself calls kernel_recvmsg, which
again call socket_recvmsg, which uses _sock_recvmsg - so to speak
going to lower and lower layers.

Let's go back to recv() ("first step"), which reads from the receiving buffer.
The size of that receiving buffer ("second step") is being controlled by a
parameter called SO_RCFBUF (the sendQ-buffer is controlled by SO_SNDBUF),
which can be tuned: as you may know, the performance of a connection
strongly depends on this parameter and the nature of the media, the MTU resp.

Now, what happens if you send more than the recvQ-buffer can hold. At
this point, the TCP flow control kicks in: the recvQ-buffer will not receive
anymore data. However, it will be (at least partially) cleared as soon as
the next recv() is called - allowing for new data to be received in recvQ.
So, can you force the recvQ-buffer to receive more data than it can hold?
No. So can you abuse it? No, not directly.
What about the TCP flow control ("third step")?


So, what can we learn from this?

Maybe, it is not the obvious path, which leads to "success" in abusing
some protocols or implementations of them. But by learning the details,
one may recognise one or another weakness - maybe just a flaw, maybe
a vulnerability. I won't tell you that you should read the rfc's (you
won't do it anyway ;) ), however, have a look at this paper[1], which
gives a nice overview of the TCP protocol and some of its weaknesses
(congestion, handshake) - in case you want to go a bit deeper than ordinary
(but not simple) application vulnerability development. Certainly, there
are dozens of papers like these, but I liked it and it is a start - even,
if those weaknesses get obsolete.

Have in mind, that from a security perspective, flaws which can lead
to denial of services (as a while ago in setsockopt in the
bsd-implementation), also are critical, even if the flaw cannot be
misused to "spawn a shell".


Anyway: you see there is a huge pile to learn - do you want to
understand application debugging (user mode), do you want to
get a general understanding of protocols, etc.etc. choose what
you like and what gives you "the kick" - motivation is crucial.

Cheers.


[1] http://www.csc.lsu.edu/~durresi/CSC7.../3_7502_04.pdf