Metasploit mailing list archives

Nop sled problem


From: mmiller at hick.org (mmiller at hick.org)
Date: Thu, 3 Nov 2005 09:17:06 -0600

On Thu, Nov 03, 2005 at 02:29:31PM +0100, shells angel wrote:
The problem I'm experiencing is somehow related to the nop sled. Whenever I
change the line:

my $payload = $nop_sled . $shellcode . $ret . "\0";

to:

my $payload = $shellcode . $nop_sled . $ret . "\0";

the shellcode will get executed correctly. But as for as I understand, this
renders the entire nop sled useless because the RET address will jump
directly to the beginning of the shellcode. Otherwise(placing the shellcode
behing the nop sled) the program crashes due to a Segmentation Fault. The
odd thing is that the nopsled will get executed along with a part of the
shellcode(checked it with GDB). Does anyone know what the the problem could
be?

Depending on where the stack pointer is at when the payload starts
executing, you could end up overwriting part of the shellcode when it
pushes values to the stack.  Try prepending a sub/add instruction to the
front of the payload that shifts the stack pointer to a lower address so
that push operations don't risk corrupting the payload.  If you want to
verify that this is the cause before going this route, simply breakpoint
on the first instruction of the nop sled and do an i reg $eip $esp.  If
$esp is at a higher address, corruption may be an issue (depending on
the location of code that does the push operations in relation to the
stack pointer).  In this case, the last few instructions are probably
being overwritten by values pushed by the payload.

You'll notice that a number of metasploit exploits make use of this
convention to avoid corruption via the 'Prepend' payload directive.
Here's the equivalent of an add esp, -3500:

"\x81\xc4\x54\xf2\xff\xff"

In your case, however, since the buffer you are exploiting is so small,
you can probably get away with a sub esp, 0x7f:

"\x83\xec\x7f"

Hope that helps.  If this doesn't fix your problem, the next step is to
single step through the payload and try to determine when/where
corruption occurs (since that seems to be what is happening).



Current thread: