Is there any way to find the original buffer limit, in the case of buffer overflows

[pusscat at metasploit.com (Pusscat)]

Send AAAA for buf1 and BBBB for buf2, then locate both and subtract the
pointers, that'll show you the distance from the start of buf 1 to the start
of buf2, which may be different than the code indicates due to crazy ass
compilers. 

 

~ Puss

 

From: M.P.Sairam [mailto:msairam at intoto.com] 
Sent: Wednesday, May 30, 2007 9:08 AM
To: framework at metasploit.com
Subject: Re: [framework] Is there any way to find the original buffer limit,
in the case of buffer overflows

 

Can we know the size only for buf1

At 03:23 PM 5/30/2007, you wrote:



You can often indirectly estimate it.
 
Lets say you have in pseudo-code:
 
function do_stuff(attacker_controlled)
{
  buf1[256]
  buf2[128]
  strcpy(buf1,attacker_controlled)
}
 
Then depending on your architecture, the stack will assign space for buf1,
followed by buf2, followed by EBP, followed by saved return address (EIP).
If the program has been compile with /GS support you'll see a further 4 byte
record for the stack canary if all went as planned. 
 
So if you calculate empirically that you need 392 bytes to align with EIP in
this example you know you have ~384 bytes of buffer to fill up, followed by
the prologue, before the saved return address. This is the reason why we use
slightly more than a power of 2 bytes when overflowing a buffer on the
stack, as there are a few bytes after the buffer allocations have finished
(and programmers like to use nice powers of 2). 
 
I don't have my TAoSSA reference in front of me, but from memory that's how
the stack will be laid out from the MS compiler.
 
Rhys

Thanks,
   --
Sairam 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.metasploit.com/pipermail/framework/attachments/20070530/f25aa03b/attachment.htm>