在经典的栈溢出模型中，通过覆盖函数的返回地址来达到控制程序执行流程（EIP寄存器），通常将返回地址覆盖为0x7FFA4512，这个地址是一条JMP ESP指令，在函数返回时就会跳转到这个地址去执行，也就是执行JMP ESP，而此时ESP刚好指向我们在栈上布置的Shellcode，于是就执行了Shellcode。
之所以栈上的数据能被执行，是因为早期操作系统没有区分数据和代码，EIP指向哪里就去哪里执行。
当引入DEP（Data Execution Prevention 数据执行保护）之后，堆、栈上的内存页属性默认不再具有可执行属性，此时如果想直接在栈上执行数据，就会发生错误：
常用的绕过DEP的技术室ROP（Return Oriented Programming，早期也叫Ret2Libc），ROP由一系列的 Gadget组成。所谓ROP Gadget，就是一系列以retn结尾的指令，所有的这些Gadget组合起来就能完成特定的任务，比如调用VirtualProtect给指定的内存块添加可执行属性。
为了达到稳定利用的目的，要求选取的Gadget的地址是固定的，无论是什么时候，其指向的都是我们想要的指令。这里引入了ASLR的概念。
ASLR全称Address Space Layout Randomization，即地址空间格局随机化。ASLR使得加载程序时不再使用固定的加载基地址加载。该技术需要操作系统以及应用程序的双重支持，ASLR才能发挥正常的作用。支持ASLR的程序在PE头中会设置IMAGE_DLL_CHARACTERISTICS_DYNAMIC_BASE标识表明其支持ASLR。
通过Visual Studio对项目属性的配置，可以使二进制文件支持ASLR：
ASLR主要影响一下几个部分，分别为：
1. 模块随机化
系统将PE文件映射到内存时，对其加载基地址进行随机化处理，这个地址在系统启动时确定，系统重启后会变化。如图所示，用Ollydbg加载一个应用程序，查看模块列表：
重启操作系统后再次查看，发现基地址全改变了：
2. 堆栈随机化
每次程序加载后，其内存空间中堆、栈的基址都会发生变化。于是内存中的变量所在的地址也会发生变化。
3. PEB/TEB随机化
从Windows XP SP2开始，PEB、TEB的地址不再固定不变。
不过，几乎很少简单有人用固定的地址去获取PEB、TEB指针，而是通过fs寄存器进行定位。
TEB可以用FS : [18h]获取
PEB可以从TEB偏移30h处获取
常用的绕过ASLR的方法有：
1. 攻击未启用ASLR的模块
虽然有映像随机化，但有可能进程中存在未启用ASLR的模块。 前面提到的ROP技术要求从一个固定的地址获取Gadget，如果进程中存在未启用ASLR的模块，那么就可以从那个模块获取Gadget了。 使用OD的OllyFindAddr插件可以快速找到进程空间中未启用ASLR的模块。
2. 堆喷射（HeapSpray）技术
虽然有堆栈随机化，不过HeapSpray技术将ShellCode布局到0x0C0C0C0C（或者其他指定的地址上，通常这个地址要比较大），并不会受堆栈随机化的影响。 其实，HeapSpray中使用ROP绕过DEP的时候，就使用了前面提到的“攻击未启用ASLR的模块”。 只是，HeapSpray把ShellCode布局在堆上。
3. 覆盖部分返回地址
映像随机化中，虽然模块的加载基地址发生变化，但是各模块的入口点地址的低位字不变，只有高位字进行了随机化处理。
对于地址0×12345678，其中5678部分是固定的，如果存在缓冲区溢出，可以通过memcpy对后两个字节进行覆盖，可以将其设置为0×12340000 ~ 0x1234FFFF中的任意一个值。
如果通过strcpy进行覆盖，因为strcpy会复制末尾的结束符0×00，那么可以将0×12345678覆盖为0×12345600，或者0×12340001 ~ 0x123400FF。
部分返回地址覆盖，可以使得覆盖后的地址相对于基地址的距离是固定的，可以从基地址附近找可以利用的跳转指令。
这种方法的通用性不是很强，因为覆盖返回地址时栈上的Cookie会被破坏。不过具体问题具体分析，为了绕过操作系统的安全保护机制需要考虑各种各样的情况。
4. Java Applet Spray
Java Applet中动态申请的内存空间具有可执行属性（PAGE_EXECUTE_READWRITE），类似HeapSpray技术，可以在固定的地址上分配滑板指令(如NOP)和ShellCode，然后跳转到那个地址上面去执行。 和常规的HeapSpray不同，Applet申请空间的上限为100MB，而常规的HeapSpray可以达到1GB。
5. JIT Spray
JIT (Just In Time Compilation) 即时编译，也就是解释器（比如Python解释器）。
主要思想是将 ActionScript代码中进行大量的XOR操作。然后编译成字节码，并且多次更新到Flash VM中，这样它会建立很多带有恶意Xor操作的内存块。例如，一个序列为：
var y=(0×11223344^0×44332211^0×4433221);
正常情况下被解释器解释为：
如果非常规的跳转到中间某一个字节开始执行代码，结果就是另一番景象了：
关于JIT的详细介绍，可以参考Pointer Inference and JIT Spraying以及Writing JIT-Spray shellcode for fun and profit，文章末尾会给出链接。
6. Tombkeeper在CanSecWest 2013上提出的基于SharedUserData的方法
从Windows NT 4到Windows 8，SharedUserData的位置一直固定在地址0x7ffe0000上。 从WRK源代码中nti386.h以及ntamd64.h可以看出：
#define MM_SHARED_USER_DATA_VA 0x7FFE0000
在x86 Windows上，通过Windbg，可以看到：
0:001> dt _KUSER_SHARED_DATA SystemCall 0x7ffe0000
ntdll!_KUSER_SHARED_DATA
+0×300 SystemCall : 0x774364f0
0x7ffe0300总是指向KiFastSystemCall
0:001> uf poi(0x7ffe0300)
ntdll!KiFastSystemCall:
774364f0 8bd4 mov edx,esp
774364f2 0f34 sysenter
774364f4 c3 ret
反汇编NtUserLockWorkStation函数，发现其就是通过7ffe0300进入内核的：
0:001> uf USER32!NtUserLockWorkStation
USER32!NtUserLockWorkStation:
75f70fad b8e6110000 mov eax,11E6h
75f70fb2 ba0003fe7f mov edx,offset SharedUserData!SystemCallStub (7ffe0300)
75f70fb7 ff12 call dword ptr [edx]
75f70fb9 c3 ret
其中11E6是NtUserLockWorkStation的服务号（ShadowSSDT中0x01E6的服务），通过Xuetr可以看到：
这样，在触发漏洞前合理布局寄存器内容，用函数在系统服务(SSDT / Shadow SSDT)中服务号填充EAX寄存器，然后让EIP跳转到对应的地方去执行，就可以调用指定的函数了。但是也存在很大的局限性：仅仅工作于x86 Windows上；几乎无法调用有参数的函数。
64位Windows系统上0x7ffe0350总是指向函数ntdll!LdrHotPatchRoutine。
HotPatchBuffer结构体的定义如下：
struct HotPatchBuffer {
ULONG NotSoSure01; // & 0×20000000 != 0
ULONG NotSoSure02;
USHORT PatcherNameOffset; // 结构体相对偏移地址
USHORT PatcherNameLen;
USHORT PatcheeNameOffset;
USHORT PatcheeNameLen;
USHORT UnknownNameOffset;
USHORT UnknownNameLen
};
LdrHotPatchRoutine调用方式：
void LdrHotPatchRoutine (struct *HotPatchBuffer);
在触发漏洞前合理布局寄存器内容，合理填充HotPatchBuffer 结构体的内容，然后调用LdrHotPatchRoutine。
如果是网页挂马，可以指定从远程地址加载一个DLL文件；
如果已经经过其他方法把DLL打包发送给受害者，执行本地加载DLL即可。
此方法通常需要HeapSpray协助布局内存数据；且需要文件共享服务器存放恶意DLL；只工作于64位系统上的32位应用程序；不适用于Windows 8（已经被修补）。