小菜的一次Shellcode跟踪实例

shellcode实例：上篇blog文，4楼的网友提供的毒网，晚上上来看到了，心想顺便看一下，结果欲罢不能，居然真的把shellcode的动作都discover出来了。作为之前完全不懂这些的我来说，这实在是一个不大不小的里程碑，值得纪念一下，特别是这个shellcode还是新鲜的。现在把对shellcode代码的分析发上来。

AlphaEncode的代码，xor的代码，都在前面的blog文里提过了，这一个shellcode的相关手法也基本一样，故不再谈（这次是xor 66H），直接从解密后的真正原貌开始。

讲解之前，先说一下我所知的，毒网里的shellcode要在别人的计算机里正常运行，需要注意的关键：
1. 所有shellcode都难以保证自己的代码被加载到哪个内存地址。shellcode要运转，特别是要读取自身代码里的数据（如病毒URL地址，要调用的函数名等常量和变量），就必须要自我定位，即获取自身在内存中的虚拟地址。
一般来说，只要在执行shellcode过程中，能获取到程序当前的入口点EIP值，就能以此定位自己的代码。但是EIP值是不能直接用mov等方法获取的。为此，shellcode编写者利用了一个典型的办法，你在下面的shellcode中将会看到。
2.shellcode必须在所在进程的空间里，调用系统API函数，来完成远程下载文件并运行的目的。那么，怎么获取函数地址？这也就是远程注入代码的又一关键：函数地址重定位问题。
只要API所在的dll被进程所加载，就可以通过由kernel32.dll导出的GetProcAddress来得到函数地址，进而Call之。但是，GetProcAddress本身也是一个函数，我们首先要得到它的地址啊！看起来好像进入死循环了。
既然如此，shellcode作者就必须模拟程序加载dll的方式，为自己的shellcode代码创建一个类似的“输入表”。要得到kernel32.dll中的GetProcAddress函数的地址，也就要读取kernel32.dll的输出表。那么，问题变成了如何定位kernel32.dll的输出表。
问题转变成了一个PE文件结构读取的问题。只要得到kernel32.dll在进程虚拟空间中的基址（DOS文件头，即MZ的位置），就可以在03CH偏移处读到PE文件头（"PE"字样地址）相对这个DOS文件头的偏移，并计算出PE文件头地址。PE文件头结构中的78H处，就是输出表的地址了。通过检索输出表，就可以得到GetProcAddress函数的地址的偏移量，进一步变为在虚拟空间中的入口点地址。
问题逐层深入，变成怎么得到“kernel32.dll文件在进程空间中的基址”。硬编码？那你干脆连函数地址都硬编码，不是更省？！shellcode作者们有更好的作法。
讲到dll的基址，一个结构呼之欲出了——PEB！fs:[0x30]！
OK了，shellcode终于从一片“不确定”中抓到了这根可以一条指令就得到的“救命稻草”。

其他的，看代码注释吧。不知道PEB的（我也是前两天碰巧刚知道），不知道PE文件结构的（我一直看着它看得头昏脑胀），看前面的部分可能会有些吃力……

代码在记事本里很整齐，copy上来就乱了，想详细看的同样copy回记事本看吧……

调试环境：XP sp2 VC++6.0 将shellcode内容作为main函数里的局部变量，之后嵌入两行汇编，将其地址lea入eax后jmp eax进入了shellcode，所以下面的地址是在堆栈里。代码从解密后真正执行开始：

……………………………………………………………………………………………………………………………………………………
下面是紧接着的一段，相当于子程序，获得所需函数的地址，函数名字符串从0012FF0E开始。每次取到地址后，同样会依次覆盖0012FF0E开始的空间。

………………………………………………………………………………………………………………………………………………………
0012FF09 E8 26 FF FF FF       call        0012FE34

从在内存中存储的顺序上，这是“代码”的最后一行，这个欺骗性的call是程序为了定位自身代码的入口点而使用的典型办法。其实同样是跳回原代码的下一句执行，但是由于系统执行call时会先把EIP入栈，所以只要在下一句代码里pop，就可以得到被压入堆栈的EIP值，也就可以定位代码自身的位置了。这里得到的值恰好指向这行代码紧接的“数据区”的开始。
………………………………………………………………………………………………………………………………………………………
紧接着这里是“数据区”。可以看到这里保存着需要的多个函数名（包括urlmon的dll名），以及“万恶的病毒URL”。对照shellcode代码，你可以发现函数地址是怎么一个一个被找到的。
值得一提的有两点：
1.找到函数地址后，会把地址一个个依次写在此区的开始，也就是从0012FF0E开始的14H个字节内容将被五个函数地址所代替。
2.在所有代码执行之前的解密函数代码执行过程中（我这里省掉了，是xor 66H），从0012FE2F到0012FF6A的内容被xor解密。但是最后一个病毒URL地址，其本身没有加密，也就没有被解密。这跟之前的一次xor FEH不一样，原因不言而喻……

………………………………………………………………………………………………………………………………

在VC里看太痛苦了，注释完全是我自己把代码copy到记事本后，自己添加上去的。连字符串也是自己译过来的，VC它根本不认它们为字符，我都不知道怎么调，要是在OD里我还知道……

经过以上分析，该代码的行为是：
1. 利用一个call来使得系统将EIP入栈，并马上pop出来，从而解决了自身代码定位问题，而且由于shellcode编排得巧妙，得到的地址正是指向“数据区”的开头。
2.利用fs:[0x30]这个地址，得到PEB头部的地址。然后读取PEB中的PLDR_DATA指针，再找LDR_DATA结构中的InInitializationOrderModuleList的Flink，从而得到指向kernel32.dll的LDR_MODULE结构的地址。通过读取LDR_MODULE结构中的BaseAddress，从而得到了kernel32.dll在进程空间中的基址。由于PEB属于Undocument的内容，以上名字可能不同的人命名有所不同，但是意义是一样的。
3.通过读取kernel32.dll在进程空间中的映像的PE文件结构，找到其输出表，通过循环比对，在AddressOfNames数组中找到指向GetProcAddress这个函数名的指针位置，定位其索引号位置。
4.通过索引查AddressOfFunctions数组，找到GetProcAddress的函数入口偏移量，加上kernel32.dll的基址，终于得到了GetProcAddress函数的确切入口。
5.通过调用GetProcAddress函数，配合kernel32.dll的基址这个句柄，找到GetSystemDirectoryA、Winexec、ExitThread、LoadLibraryA这四个由kernel32.dll导出的函数的入口点，并将之依次保存到“数据区”开头以备调用。
6.通过刚刚得到的LoadLibraryA函数入口，加载urlmon.dll，用GetProcAddress得到重要的函数URLDownloadToFileA的入口点，同样保存备用。
7.通过调用GetSystemDirectoryA，得到系统文件夹路径（即XP里默认为C:\WINDOWS\system32，注意得到的路径最后没有"\"），在路径后面加入\a.exe，作为下载保存的本地地址。
8.调用URLDownloadToFileA，将由挂马者指定的URL地址对应的病毒文件（这里是http://99.vc/s.exe），下载到本机（默认是C:\WINDOWS\system32\a.exe），并调用Winexec运行。
9.完成以上所有任务，调用ExitThread，退出自身线程。

补充：
进入了shellcode之后，shellcode的运行代码，与利用漏洞本身无关。也就是说，这串代码你可以copy到其他ActiveX插件漏洞的利用网页里。对于不同的漏洞来说，不同点只在于如何触发漏洞，从而使得程序的EIP能够跳到shellcode的入口点，使得shellcode能够运行。编写可以运行的shellcode有学问，如以上shellcode代码就涉及PEB结构的读取，PE文件结构的读取，以及Win32汇编语言代码的实现等。而如何找到并利用漏洞（通常是产生溢出），如何巧妙地编排，使得EIP跳到shellcode内，使shellcode代码得到运行的机会，则更是需要真才实学的，而这一部分，我还完全摸不着门道。

另外，得到kernel32.dll的基址，是不是只能PEB？想想PEB好像是比较通用的方式，程序自身重定向的时候，也要用到它的，所以正常程序一般不会随便去“伪造”它。

不过，对于一个改节表和入口点的感染型病毒而言，在被感染的文件中，那段在程序初始化后，就被抢先执行的病毒代码，由于其执行的特殊时机（在程序刚初始化跳到入口点时），它可以轻松地从堆栈中找到一个位于kernel32.dll空间内的地址，然后用它来找kernel32.dll的基址。
事实上，这正是Worm.Win32.Delf病毒使用的方式。最近由于新变种logogogo.exe的出现，瑞星把以前的变种的病毒名也改成了Win32.logogo。最近的变种我没拿到，过两天找阳光等人拿一下。但是今天下午，我分析了被以前的变种感染的文件，其中的病毒代码，从它如何定位自身代码，得到GetProcAddress函数地址，得到其他函数地址，调用CreateFileA和WriteFile将用Upack加壳的病毒主体代码写入新文件，最后得到已保存的原文件基址和入口点，并跳转到原入口点处，将控制权交还给原程序，都看了一遍。

当我分析完Delf的代码，吃完饭再跑上blog，看到4楼的回复，再看到这段shellcode的时候，我实在是喜出望外，Delf（或者logogo）病毒感染后文件中的那段代码，跟以上这段shellcode，两者的机理非常非常地相像！