介绍
多阶段加载是基于如下这种想法:如果一个小片段的shellcode可以在目标上执行，理论上可以通过网络连接、传输和执行其他的shellcode,或者甚至是一个完整的二进制可执行文件。
关键的想法是对加载的最终程序进行分级。这样子，只有严格大小的代码会在第一阶段加载。这种想法在一篇优秀的文章<<Understanding Windows Shellcode>>中有详细介绍。
第一阶段:shellcode加载
这是在加载链中至关重要的一步。代码必须够小，没有NULLs值并且必须能够在各种平台上执行。它的主要功能是找到用于连接的套接字描述符，并通过它读取额外的数据。
当完成时，加载器跳至数据部分并且CPU开始执行它
第二阶段:二进制加载
如果额外的shellcode可以取得预期的结果，那么第一阶段加载器可能是足够的。但也可能需要在目标机上运行更复杂的代码和譬如像C这种在各种环境中更能使用的高级语言。不幸的
是，通过C/C++/Java/其他语言不可能编写像汇编代码的大小的和效率。对这个问题的解决方案之一是使用通过第一阶段加载器执行的另一个加载器。第二阶段
加载器负责加载和执行实际可执行的二进制。这一切都发生在单一的TCP(或者UDP)会话中，这也是取得相关目标的好方法之一。它可以过滤几乎任何数据包。当然，可执行的payload和
加载shellcode的payload可能会陷入一些内容检查设备，但是这是另外一些情况了。
应当指出，在第一阶段加载二进制理论上没有问题的。但因为增加的payload的大小可能不切实际。这就是为什么选择这两个阶段的处理方法的原因。
POC: nload
nload是一个具有上述两种阶段能力的程序。这是一个C程序，负责协调加载的各个阶段。该软件包包括nload的源码和加载器使用的asm源码。它还包括一个演示服务端"srv.exe"，这个程序仅仅是从TCP
socket读取代码并且执行它，其他的事情都不做。nload工作unix/win32环境下，但是加载器只对Windows NT/2000/XP有效。
不继续说了，我们开始一个会话的例子。这里我们有一台Linux主机，它的目标是一台IP地址为10.10.10.10的Windows主机。
$ ./nload 10.10.10.10 1111 -s example.s
nload v1.0 - load staged shellcode over network connection
Copyright (c) Jarkko Turkulainen 2004. All rights reserved.
Sending loader... 230 bytes sent
Sending shellcode... 204 bytes sent
Microsoft Windows XP [Version 5.1.2600]
(C) Copyright 1985-2001 Microsoft Corp.
C:\>
在目标机器，运行着演示用的服务端"srv.exe"，如下所示:
C:\>srv 1111
Oops.. I'm 0wned.
现在，这里发生如下过程:
1.在第一阶段，nload发送第一阶段加载器到目标主机并执行它(Sending loader... 222 bytes sent)
2.在第二季端，nload执行实际的shellcode(example.s)并执行它(Sending shellcode... 204 bytes sent)
在此之后，nload就在等待弹出shell(这是example.s做的事---执行cmd.exe和重定向IO到已经建立的TCP连接)
这个例子是非常简单的，因为服务端"srv.exe"并没有真正被利用。它需要是一个工作的shellcode和包含一对NOP指令的用于对齐的头部文件"head.s"。在一个真实的情况下
，它没有那么容易实现。还应该指出的是，example.s只有当宿主进程调用WSASocket winsock API调用打开socket下才能运行(这也是它在"srv.exe"下如何运行的原因)
另一个例子:
$ ./nload 10.10.10.10 1111 -b backdoor.exe exp_head.s exp_tail.s
nload v1.0 - load staged shellcode over network connection
Copyright (c) Jarkko Turkulainen 2004. All rights reserved.
Sending loader... 222 bytes sent
Sending 2nd loader... 328 bytes sent
Sending payload...
这个例子看起来有一些复杂:
"exp_head.s"和"exp_tail.s"代替"head.s"和"tail.s"用于第一阶段shellcode的对齐
在第一阶段中，nload发送第一阶段加载器到目标机并执行它(Sending loader... 222 bytes sent)
在第二阶段中，nload发送第二阶段加载器并执行它(Sending 2nd loader... 328 bytes sent)
第二阶段加载器读取可执行负载"backdoor.exe"并执行它
一些注意事项
在nload的当前实现中，scoket文件描述符通过比较当前的TCP连接的源端口进行搜索，这些源端口从getpeername()返回的每一个有效的文件描述符得到。此搜索可能会失败，如果客户端发起的连接在NAT设备后面。
为了更准确些，NAT设备可能会改变源端口和客户端的IP地址。大多数NAT的实现都是这样子，它被称为源NAT，PAT的，隐藏NAT，或其他。
因为原来的源端口在加载器的shellcode很难硬编码实现，因此正确的文件描述符很难发现。这种NAT问题的解决方案之一是实现一个的简单的协议。
这个协议大致是客户端发送一些认证数据到第一阶段加载器，加载器循环通过遍历所有文件描述符去试图找到数据。
如果成功的话，找到正确的描述，不管多少原有网络头部被改变。
另一个当前nload中恼人的限制是在二进制模式下可执行负载在执行前被保存在disk中。
nload试图删除二进制文件，但它仍然存在。
更新：nload2不会在磁盘上保存二进制，它在内存中执行它！
在第2阶段，nload执行一个可执行的二进制文件(.exe)，这显然有一定的局限性（nload2仍然需要读取访问主机应用程序，主机应用程序是可见的，等等）。
还有另一种非常复杂的可执行文件加载的方法，被称为 Library Injection，这是更加灵活和隐身。
下载nload
链接
Metasploit http://www.metasploit.com/
Remote Library Injection http://www.nologin.org/Downloads/Papers/remote-library-injection.pdf
MOSDEF http://www.immunitysec.com/
LSD's wasm http://lsd-pl.net/projects.html#windowsassembly
InlineEgg http://community.corest.com/~gera/ProgrammingPearls/InlineEgg.html
Impurity 1.0 http://archives.neohapsis.com/archives/vuln-dev/2003-q4/0006.html
Understanding Windows Shellcode http://www.hick.org/code/skape/papers/win32-shellcode.pdf
备注：
复用当前的socket
1.IIS的ECB结构
2.getpeername
3.fcntl设置socket状态
4.ioctl(Linux/Unix)和ioctlsocket(Win32)
5.使用OOB特性
6.Hook系统的recv调用
复用当前连接的技术相对较隐蔽，而且对于Win32的用管道绑定cmd.exe后，和服务器交互的数据可以用xor的办法进行编码，进一步躲避IDS的检测
单单查找SOCKET的shellcode可以写的相对比较短，在找到socket后，可以再继续接收一段功能更复杂的shellcode到缓冲区，然后跳入执行。对于该后续shellcode就没有任何字
符和长度的限制。甚至接收一个dll文件，实现更复杂的功能。
摘自xcon2004-san
getsockname和getpeername在有NAT网络环境里是会出现查找socket失败的
参考链接:
http://seclists.org/dailydave/2004/q3/48
http://www.klake.org/~jt/asmcode/
http://www.klake.org/~jt/mstage/
http://hi.baidu.com/yuange1975/blog/item/618800542ebc730e3a293508.html
http://www.hick.org/code/skape/shellcode/win32/
http://hi.baidu.com/erenfei/blog/item/0a9298f389559ac80b46e024.html