-
-
[原创]《0day安全...（第二版）》第3章第4节开发通用的shellcode在win10系统下测试的问题
-
2018-8-29 11:26
-
《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函数了，这个就是以后能力提高后再考虑的事情了。这次实验目的查找崩溃原因的目标顺利完成。
[培训]《安卓高级研修班(网课)》月薪三万计划，掌握调试、分析还原ollvm、vmp的方法，定制art虚拟机自动化脱壳的方法
|
|
|---|---|
|
|
昨天发帖子之后，通过搜索，找到了类似问题的帖子： https://bbs.pediy.com/thread-182499.htm 翻看帖子的时候，才知道原来win7下 模块初始化链表InInitializationOrderModuleList 中按顺序存放着PE载入运行时初始化模块的信息，第二个链表节点不是kernel32.dll了，第二个是kernelbase.dll，第三个才是kernel32.dll。 那就试试改变一下shellcode的代码吧。 参考了Cryin的https://bbs.pediy.com/thread-122260.htm帖子，以其中的测试代码为核心，对0day2书本中的代码进行修改，经过耐心调试，得到新的shellcode代码，功能和书本上的一样，算是强迫症患者解决方案了。这份完整Shellcode代码起码可以跟随书本继续往下在win7以上的系统中进行实验。具体如下： char popup_general[] = "\x90"// NOP "\xFC" "\x68\x6A\x0A\x38\x1E"// PUSH 1E380A6A "\x68\x63\x89\xD1\x4F"// PUSH 4FD18963 "\x68\x32\x74\x91\x0C"// PUSH 0C917432 "\x8B\xF4"// MOV ESI,ESP "\x8D\x7E\xF4"// LEA EDI,DWORD PTR DS:[ESI-C] "\x33\xDB"// XOR EBX,EBX "\xB7\x04"// MOV BH,4 "\x2B\xE3"// SUB ESP,EBX "\x66\xBB\x33\x32"// MOV BX,3233 "\x53"// PUSH EBX "\x68\x75\x73\x65\x72"// PUSH 72657375 "\x54"// PUSH ESP "\x33\xD2"// XOR EDX,EDX "\x57" // push edi ; 新增修改支持WIN7以上系统代码 "\x64\x8B\x5A\x30"// MOV EBX,DWORD PTR FS:[EDX+30] "\x8B\x4B\x0C"// MOV ECX,DWORD PTR DS:[EBX+C] "\x8B\x49\x1C"// MOV ECX,DWORD PTR DS:[ECX+1C] "\x8B\x79\x20" // mov edi,dword ptr ds:[ecx+0x20] ; 新增修改支持WIN7以上系统代码 "\x66\x39\x57\x18" // cmp word ptr ds:[edi+0x18],dx ; 新增修改支持WIN7以上系统代码 "\x74\x04" // jnz short 3-Shellc.009F13D6 "\x8B\x09" // mov ecx,dword ptr ds:[ecx] ; 新增修改支持WIN7以上系统代码 "\xEB\xF3" // jmp short 3-Shellc.011713D6 "\x5F" // pop edi // "\x8B\x09"// MOV ECX,DWORD PTR DS:[ECX] ; 新增修改支持WIN7以上系统代码 "\x8B\x69\x08"// MOV EBP,DWORD PTR DS:[ECX+8] "\xAD"// LODS DWORD PTR DS:[ESI] "\x3D\x6A\x0A\x38\x1E"// CMP EAX,1E380A6A "\x75\x05"// JNZ SHORT popup_co.00401070 "\x95"// XCHG EAX,EBP "\xFF\x57\xF8"// CALL DWORD PTR DS:[EDI-8] "\x95"// XCHG EAX,EBP "\x60"// PUSHAD "\x8B\x45\x3C"// MOV EAX,DWORD PTR SS:[EBP+3C] "\x8B\x4C\x05\x78"// MOV ECX,DWORD PTR SS:[EBP+EAX+78] "\x03\xCD"// ADD ECX,EBP "\x8B\x59\x20"// MOV EBX,DWORD PTR DS:[ECX+20] "\x03\xDD"// ADD EBX,EBP "\x33\xFF"// XOR EDI,EDI "\x47"// INC EDI "\x8B\x34\xBB"// MOV ESI,DWORD PTR DS:[EBX+EDI*4] "\x03\xF5"// ADD ESI,EBP "\x99"// CDQ "\x0F\xBE\x06"// MOVSX EAX,BYTE PTR DS:[ESI] "\x3A\xC4"// CMP AL,AH "\x74\x08"// JE SHORT popup_co.00401097 "\xC1\xCA\x07"// ROR EDX,7 "\x03\xD0"// ADD EDX,EAX "\x46"// INC ESI "\xEB\xF1"// JMP SHORT popup_co.00401088 "\x3B\x54\x24\x1C"// CMP EDX,DWORD PTR SS:[ESP+1C] "\x75\xE4"// JNZ SHORT popup_co.00401081 "\x8B\x59\x24"// MOV EBX,DWORD PTR DS:[ECX+24] "\x03\xDD"// ADD EBX,EBP "\x66\x8B\x3C\x7B"// MOV DI,WORD PTR DS:[EBX+EDI*2] "\x8B\x59\x1C"// MOV EBX,DWORD PTR DS:[ECX+1C] "\x03\xDD"// ADD EBX,EBP "\x03\x2C\xBB"// ADD EBP,DWORD PTR DS:[EBX+EDI*4] "\x95"// XCHG EAX,EBP "\x5F"// POP EDI "\xAB"// STOS DWORD PTR ES:[EDI] "\x57"// PUSH EDI "\x61"// POPAD "\x3D\x6A\x0A\x38\x1E"// CMP EAX,1E380A6A "\x75\xA9"// JNZ SHORT popup_co.00401063 "\x33\xDB"// XOR EBX,EBX "\x53"// PUSH EBX "\x68\x77\x65\x73\x74"// PUSH 74736577 "\x68\x66\x61\x69\x6C"// PUSH 6C696166 "\x8B\xC4"// MOV EAX,ESP "\x53"// PUSH EBX "\x50"// PUSH EAX "\x50"// PUSH EAX "\x53"// PUSH EBX "\xFF\x57\xFC"// CALL DWORD PTR DS:[EDI-4] "\x53"// PUSH EBX "\xFF\x57\xF8";// CALL DWORD PTR DS:[EDI-8] ; 再次用ollydbg加载调试，下断点检查edi指向的API函数入口地址，如图9所示
图9 搜索并记录下的API函数入口地址正确了 对比图9和图8可以看见，图8其实显示的是kernelba.LoadLibraryA而不是Kernel32.LoadLibraryA了。而当时却没有注意到这点，没发现本质的问题是根本没定位到kernel32的基址导致的问题，MessageBox可以调用，只是碰巧可以。 至此，问题完美解决了。 |
|
|
|
|
|
|
|
|
|
|
|
|
