此时如果调用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调整为符合要求的结构，以下给出调试过程中笔者遇到的异常与异常的解决过程，希望为读者提供一定思路的参考
以下通过调试，尝试修改shellcode的结构。
这里遇到修改溢出数据长度之后的第一个异常：
对应文件中的内容为
当该部分内存还未被溢出淹没时，该内存处的数据为
据此修改文件中对应位置的数据后，程序的运行还是出现异常，故仔细跟踪该函数的执行过程，将需要进行特殊构造的内存内容进行记录
准备进入该函数一探究竟
内存相关指令
修改文件内容，保证[edi+8]内存位置的内容
修改完成后，加载程序进行调试直接按F9，发现程序仍然出现异常，发现还需要将地址0012a2e0处的内存进行精心布置
根据调试地址0x0012a2e处的内存数据为下图时，程序可以正常运行
根据上图，修改文件中的数据
文件数据修改后，直接f9进行调试，发现程序仍然报异常，推测是仍然存在指令使用了直接溢出的数据，需要进一步定位该数据的位置，并且在文件中精心构造对应数据。
探究问题的原因
对于能够运行成功的案例如下
相应的运行失败的案例如下
找到文件中对应的数据进行修改
解决上述问题后，出现同样的问题，需要继续解决
正常情况下的该内存中的值如下图
找到文件中对应数据的位置
修改数据
仍然存在问题，要哭了
但是问题在于，如果是正常情况，程序不会执行到该指令分支，所以需要通过出现错误时的栈回溯，分析在哪个指令处，溢出数据导致正常程序指令发生了变化
发生异常时的堆栈
在327b2e90函数中第一个内存操作
第二个内存操作
进入327b1467函数发现此时栈中数据与不正常调用时的不同，说明异常产生于327b1467函数的错误参数
在异常情况下
进入函数327b1467，发现异常产生于在指令中使用了溢出的数据
查看正常情况下该内存的值应该为0，修改文件
修改之后还是会出现问题
正常情况下
查询ecx的来源
出现异常时
修改文件内容，继续f9仍然出现异常
产生异常时堆栈数据
栈回溯，分析ecx的值来源于edi
栈回溯，发现需要继续向上追溯函数
进一步追溯
所以最终异常ecx来源于函数327ab0ed
至此，攻击文档（msfplus6.rtf）中shellcode的结构相较于原始poc（msf0.rtf）被修改的部分如下，可以看到大量微小的内存差异分布在shellcode中。
