《漏洞战争》-CVE-2010-3333（下）

此时如果调用32e5941b函数的参数符合要求，则此时ebp-8就可以为0，不需要专门构造。

此时ebp-1地址处的内存必须可读，此时该地址处内存内容已经被精心构造过，满足正常执行要求，不需要重新构造，之后执行jmp 32e59579，程序准备返回，执行流程被劫持到溢出的返回地址。

对比原始poc文件（msf0.rtf）和复制0x90字节数据的攻击文件（msfplus4.rtf）

通过复制0x90字节数据的攻击文件，可以向内存中溢出更多的数据用于保存shellcode

关于在文件中布置以字母表示的数据，然后将对应数据保存在内存中的问题

上图是原始的poc文件msf0.rtf，通过上图可以看出，0xc8ac被作为复制数据的大小在数据复制的过程中被使用，所以我们推测，如果要在内存中使用以字母表示的数据，需要文件中对应位置存储该字母小写形式的ascii，之前实验中以字母表示的数据在文件中以该字母大写形式的ascii保存，所以对应数据在内存中被保存为0。

在攻击文件msfplus4.rtf中，我们发现部分用于保证程序能够正常返回的填充数据仍然使用对应字母大写形式的ascii，这是因为，在实际实验过程中，这部分如果为0，程序才能够正常返回，如果使用字母小写形式的ascii（即与正常运行时内存布局一模一样），程序反而不能正常返回。，

那么在这种内存布局情况下，能不能在保证溢出数据不影响进程劫持的条件下，尽量将更多的数据溢出到内存中，从而为shellcode提供更多的内存空间呢？通过二分法增大文件中复制数据的长度，发现此种溢出数据的内存布局最多能够支持0x1c4（十进制的452）字节数据溢出到进程中，这个数据长度足够容纳简单的shellcode。

溢出更多的数据到栈空间中

那么更进一步，如果使用了非常复杂的shellcode，导致shellcode很长，需要向栈中溢出更多数据，但是同时需要保证在memcoy进行栈溢出之后，返回地址被覆盖的函数返回之前，所有指令的执行能够正常执行，不会受到溢出到栈中的数据的影响。

如果需要达到以上目的，需要对更多的溢出数据进行特殊构造，并且保证此类数据不会影响shellcode的执行（数据对应得指令执行后不会对shellcode产生影响，或者在shellocde中使用短跳指令跳过此类数据）。

需要构造溢出数据中得哪些部分，需要构造为何值，可以先将文件中溢出数据的长度修改为较大值，然后使用word打开，使用od进行调试，找到出现异常的位置，然后对比函数正常返回过程中，相同位置的的执行过程与操作数，从而获得函数正常返回过程中内存的数据结构，以此为依据，修改文件中的对应数据。

以上调试过程可能会经历多轮，直到将溢出数据的结构修改为能够保证程序正常返回，并且包含要执行的shellcode内容，理论上，因为从溢出到返回执行的指令是有限且确定的，只要将所有出现的异常都进行修正，就可以得到符合要求的shellcode结构。笔者在这个过程中花费了大量精力，随着调试的深入，出现的异常也越来越麻烦，考虑到时间、精力与此过程中能够得到的收获，最后未能完全将shellcode调整为符合要求的结构，以下给出调试过程中笔者遇到的异常与异常的解决过程，希望为读者提供一定思路的参考