[原创]《0day安全...（第二版）》第3章第4节开发通用的shellcode在win10系统下测试的问题
《0day安全软件漏洞分析技术（第二版）》第3章第4节开发通用的shellcode在win10系统下测试的问题
最近耐心的重学了一遍《汇编语言第二版》，为研究0day安全这本书打下一点基础，然后静心下来时隔几年开始重新学习，
时过境迁，实验平台实验环境实验程序开发平台都变化了，
使用VS2010编译P97的shellcode装载程序，生成控制台程序，并且配置关闭数据执行保护（DEP）
直接运行测试，可以看见对话框，但是退出时候崩溃了。这不是健康的shellcode，肯定是出问题了，具体是什么问题？
基本确定是win10系统和shellcode不兼容，即这个shellcode在win10下，不再是通用的了。现在开始动手找问题的原因所在。
首先，用ollydbg加载运行，停在图1界面
图1 ollydbg加载shellcode装载程序第一步
在图1中可以直接找到xxx.main的入口地址，F2下断点，F9执行到入口地址处，F8进入装载程序代码空间，如图2所示。
图2 装载程序代码区
一路F8直到retn后，跳入shellcode代码区，如图3所示。
图3 shellcode代码
这里的代码与书本P93的代码就是相同的了。此后F8单步跟踪观察，三次push，把要搜索的API函数HASH值推入栈，如图4所示。
图4 入栈3个HASH值
因此先搜索的是最后入栈的0x0C917432也就是LoadLibraryA函数，
看图3中的第7行代码lea edi,[esi-0xc]，根据书本注释也能知道，就是图4堆栈位置再往上3个DWORD空间，用来保存三个API函数的入口地址的，edi指向这3个DWORD，因此后面只需要call [edi-0x8],call[edi-0x4]即可调用相应的API函数了，当然要注意观察，edi值在shellcode运行过程中，并不是保持不变的。可以体会确保call调用时，edi指向正确的API地址位置。
在ollydbg地址观察窗显示[edi]地址，如图5所示。
图5 Address观察窗口
对比图4和图5，依据代码，可以知道esi指向栈顶第一个API函数的HASH，edi指向比HASH值低3个DWORD的位置（目前这3个位置中的数据是无效数据），准备保存API函数入口地址，因此可以直接下内存读的断点，点击选中图5窗口的第一行地址，右击鼠标，在弹出菜单中选择Break point -> Memory,on write。
下好断点，按下F9，程序会先在kernel32.dll中根据HASH值搜索LoadLibraryA的函数名，找到之后确定函数入口地址，然后往[edi]的地址中写入入口地址，一旦写入触发我们的断点，就会停下，如图6所示。
图6 函数LoadLibraryA的入口地址保存代码
中断位置发生在书本P94倒数第二行代码，stosd这句。也就是图6中被中断的位置，F8运行这句代码。立刻可以在address观察窗口看到果然记录下了第一个API入口地址。如图7所示。
图7 第一个API函数入口地址自动确定
对比图5和图7的区别，可以看到，这里果然保存了LoadLibraryA的地址了
继续对后面两个0x0113FB1C和0x0113FB20下内存写断点，继续观察API函数入口地址是否正确，因为shellcode在退出时崩溃了。初步判断，就是ExitProcess函数入口地址应该是搜索出现问题了。这个问题是怎么出现的，是这篇文章的重点。
下好断点，按下F9，再次中断，这时候可以看到中断的代码位置还是相同的，按一下F8，发现问题了，本该保存ExitProcess入口地址的位置，变成保存的是一串字符串了，如图8所示。
图8 ExitProcess入口地址保存错误
很明显，这里保存的是ASCII字符串，看情况判断，win10可能是取消了kernel32中的ExitProcess函数了？因为系统的这个改变，所以SHELLCODE运行到这里call的不是入口地址，而是一串字符串，肯定是崩溃了。崩溃的原因找到了。要解决的话，就是要改写shellcode，在NTDLL中搜索新的ExitProcess函数了，这个就是以后能力提高后再考虑的事情了。这次实验目的查找崩溃原因的目标顺利完成。
