Metasploit mailing list archives

What we mean by NOPs generator and payload encoders


From: patrick at aushack.com (Patrick Webster)
Date: Tue, 14 Apr 2009 14:33:06 +1000

A NOP sled is simply the processor architecture 'no operation' instruction.
In buffer overflows it is used to allocate a lot of space before the payload
itself, to allow for a reliable return address in memory (instead of knowing
the exact location of the start of the payload, just hit the NOP sled
instead and it will return)... or to align the registers.

E.g.

"\x90" * 20000 + payload.encoded

However IDS will check for packets which contain many NOP instructions in
sequence (0x90 is Intel x86).

Here is an example IDS signature from Juniper:

("SHELLCODE:X86:NOOP-TCP"
                :id (1613759292)
                :supercedes (
                    : ("DNS:OVERFLOW:TOO-LONG-TCP-MSG")
                )
                :recommended-action (none)
                :severity (5)
                :service ("tcp/0")
                :rectype (signature)
                :signature (
                    :pattern (".*\x90 90 90 90 90 90 90 90 90 90 90 90 90
90\x.*")
                    :negate (false)
                    :type (stream)
                )

So to get around this, Metasploit and others create non-0x90 "NOP"
instructions using different commands.

One example is

INC EAX, DEC EAX, INC ECX, DEC ECX etc.... basically the traffic over the
wire is not 0x90, but the commands increase a register by 1 then decrease it
by 1, effectively creating a NOP sled without using the NOP instruction.

The encoders vary. It can be to bypass IDS, but more commonly because the
software targetted does not support certain characters, e.g. non printable
ASCII.. So the Decoder reads an ASCII encoded payload into memory (as
ASCII), then decodes the ASCII into the correct architecture instructions,
and jumps into the decoded payload.

-Patrick
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.metasploit.com/pipermail/framework/attachments/20090414/63de633f/attachment.htm>


Current thread: