作者: SoBeIt    来自:https://www.xfocus.net

没实现非安全返回法一，因为里面的技术要点都包括在安全返回法和非安全返回法二里了。主要就是那个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里，系统检测到当前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)进行环境切换，但在这个漏洞溢出里我们第一步就是进行环境切换:)。所以突破系统对

[1] [2] [3] [4] [5] [6] [7] [8] 下一页