Windows系统调用架构分析—也谈KiFastCallEntry函数地址的获取 + 一个hook的实现

为什么要写这篇文章

1.      因为最近在学习《软件调试》这本书，看到书中的某个调试历程中讲了Windows的系统调用的实现机制，其中讲到了从Ring3跳转到Ring0之后直接进入了KiFastCallEntry这个函数。

2.      碰巧前天又在网上看到了一篇老文章介绍xxx安全卫士对Windows系统调用的Hook，主要就是Hook到这个函数

3.      刚刚做完毕业设计，对使用中断来实现系统调用的方式记忆犹新。

 

以上原因导致我最近眼前总是出现系统调用这个词，脑海中总是出现系统调用的实现方式，所以决定写篇文章清理一下思维。本文所有举例如无明确指明，均是在Windows XP SP3系统中获得。

 

本文的目的是探索一下Windows目前的系统调用的实现架构，介绍一种中规中矩的获取KiFastCallEntry函数地址的方法，但是在介绍之前还是要把该解释的解释清除。

 

Windows API和系统调用的关系

肯定会有人说Windows API就是系统调用，系统调用就是Windwos API，是这样的么？负责任的说：不是这样的！

先从广义上来说，Windows API是对于整个Windows操作系统自身的程序代码之外的应用程序来说的，而系统调用是Windows内核对于非内核程序代码之外的Windows系统程序代码来说的。也就是说系统调用要比Windows API低一个层次。一个Windows API是一个函数，这个函数可能会使用系统调用，请注意是可能，因为并不是所有的API都需要进入内核去完成这个API的功能。

 

Windows内核实现文件和应用层文件

在一个安装完成的Windows操作系统中可见并有效的内核实现文件是

C:\Windows\System32\ntoskrnl.exe

C:\Windows\System32\ntkrnlpa.exe

请注意有两个内核文件，其中第二个比第一个的名字少了os多了个pa，省去的os没有任何意义，但是多出来的pa所代表的意思是PAE(物理地址扩展)，这是X86CPU的一个硬件特性，Windows启动之后根据当前系统设置是否开启了PAE特性会自动选择把其中一个作为内核加载到内存中。

为什么加了这么多限定词，因为ntoskrnl.exe这个文件名并不一定是这个文件的真实名称，可以从文件属性中看到

ntoskrnl.exe原始文件名为可能为ntoskrnl.exe或者ntkrnlmp.exe

ntkrnlpa.exe原始文件名为可能为ntkrnlpa.exe或者ntkrpamp.exe

可以发现其中的不同之处就是mp，mp就是Multi-processor(多处理器，也可以理解为多核，因为IA-32架构对多核处理器的编程和多处理器的编程是相似的机制)。为什么会出现这中情况呢？因为这完全是由计算机硬件的不同配置导致的。当安装Windows操作系统的时候，Windows安装程序会自动检测机器的CPU特性，根据CPU的核心数来确定使用哪一套内核。如果是单核心就只复制ntkrnlpa.exe和ntoskrnl.exe到系统目录下，如果是多核心就复制ntkrnlpamp.exe和ntoskrnlmp.exe到系统目录下，所以如果你有一台单核心CPU的机器，有一天你换了双核的CPU却没有重新安装操作系统，那么你就不会在看到熟悉的Windows启动画面了。类似这两个文件的还有一个文件C:\Windows\System32\hal.dll，这是Windows的硬件抽象层程序文件，这个就不做具体介绍了。额外补充一个不同的硬件配置所需要的文件列表：

 

Standard PC	hal.dll ntkrnlpa.exe ntoskrnl.exe
Advanced Configuration and Power Interface (ACPI) PC	halacpi.dll---->hal.dll ntkrnlpa.exe ntoskrnl.exe
ACPI Uniprocessor PC	halaacpi.dll--->hal.dll ntkrnlpa.exe ntoskrnl.exe
MPS Uniprocessor PC	halapic.dll---->hal.dll ntkrnlpa.exe ntoskrnl.exe
ACPI Multiprocessor PC	halmacpi.dll--->hal.dll ntkrpamp.exe--->ntkrnlpa.exe ntkrnlmp.exe---->ntoskrnl.exe
Compag SystemPro Multiprocessor or 100% Compatible	halsp.dll---->hal.dll ntkrpamp.exe--->ntkrnlpa.exe ntkrnlmp.exe--->ntoskrnl.exe
MPS Multiprocessor PC	halmps.dll----->hal.dll ntkrpamp.exe----->ntkrnlpa.exe ntkrnlmp.exe--->ntoskrnl.exe
Silicon Graphics Visual Workstation	halsp.dll---->hal.dll ntkrpamp.exe----->ntkrnlpa.exe ntkrnlmp.exe---->ntoskrnl.exe

 

不论什么配置，一旦系统安装完成后，对我们来说可见的内核文件就只有两个ntoskrnl.exe和ntkrnlpa.exe。这两个文件中的代码就是运行于RING0下的内核代码，他们里面所包含了真正的系统调用的代码。我们用Dependency Walker看一下：

(P1)

 

可以看到很多函数，他们之中有些是系统调用，会和RING3的程序代码有联系，有些仅仅是内核中的函数，只跟内核中其他的代码有联系。有一点需要说，在用Windbg调试内核的时候，无论系统使用的是哪个内核文件，Windbg都会把这个内核文件的符号(模块名)识别为nt。所以如果我们要查看内核中的NtOpenFile函数的反汇编，只需要输入一下命令

u nt!NtNtOpenFile

如下图：

(P2)

下面再说包含Windows API的文件，这个就非常多了，最基础的User32.dll，Ntdll.dll，Kernel.dll这三个文件包含了Windows系统相关的绝大多数API，当然还有其他函数簇比如包含socket函数簇的ws2_32.dll等等，这些dll中都导出了大量的API函数以及结构。这些函数都是运行在RING3层的代码，有些会跟内核层中的代码发生联系，有写也不会，就是上面提到的Windows API不一定会使用系统调用。比如我们举个简单的例子，拿CharNextA这个Windows API来说，这个API是在User32.dll中实现的。我们可以反汇编一下看看这个API的具体实现。

(P3)

可以看到这个函数在ret之前只有一个跳转je并且目标代码仍然在本函数内，而且没有任何中断或者快速系统调用，所以这个函数并没有离开RING3层，也就是说当你编写一个程序调用了这个API之后，这个API并没有把你的程序流程带入RING0的内核层代码。

 

Windows API使用系统调用的方法

通过中断实现系统调用

Windows API如果设涉及到系统调用就要由RING3进入RING0，这就牵扯到了X86保护模式下有特权级变化的控制转移。在早期的CPU中(Pentium II之前)，没有快速系统调用这个机制，所以能用来进行特权级变化的控制转移的机制只有通过中断实现，保护模式下的中断的实现方式是通过IDT表来实现，IDT表中存放的是一种特殊的X86段描述符——门描述符，门描述符的格式如下

(P4)

可以看到其中有一个Selector字段和一个Offset字段，并且是不连续的，这里只介绍这两个字段的含义，其他字段的含义这里不再赘述，有兴趣的话可以自己去看下保护模式相关资料。说到底这个门描述符的作用就是描述一个程序段，对我们来说重要的就是Selector和Offset字段了，因为Selector可以帮我们找到它所描述的程序的【段】，Offset就是程序在【段】内的【偏移】，有了【段】和【偏移】就可以确定程序的线性地址。那么我们来试着找一找Windows通过中断来实现系统调用时候的流程！不会用Windbg的程序员不是好的狙击手。

首先用Windbg打开一个Calc.exe或者其他的普通应用程序，然后键入命令：

u ntdll!KiIntSystemCall

(P5)

如果有疑问为什么直接来到这个函数，现在先不忙解释，后面再说。可以看到这个函数中

int 2Eh

这一句汇编代码，我们知道了系统调用了2E号中断，从而进入了系统内核，知道了中断号下面我们要做的就是找到这个中断的服务程序，也就是RING3进入到RING0之后的第一条指令在哪里。下面就进入内核调试模式。通过

!pcr

查找IDT的线性地址

(P6)

找到了IDT的线性地址：0x8003f400，前面说过IDT中存放的是门描述符，每一个门描述符占用8个字节，所以我们要找的第2e个门描述符的地址应该为0x8003f400+2e*8，然后我们通过如下命令：

dq /c 1 8003f400+2e*8

查看内存内容：

(P7)

看到第一行的八个字节就是我们要找的2e号中断所对应的门描述符。根据门描述符的格式计算，得到这个门描述符中包含的

Offset【偏移】 = 0x8053e4a1

Selector = 0x0008

【偏移】已经找到了，下面就剩【段】了，【段】可以通过Selector【选择子】找到，这里需要说下【选择子】，选择子占用2个字节，格式如下

(P8)

选择子是真正可以存放在保护模式下的段寄存器中的结构，既然它被放在段寄存器中，那么通过它必然能够找到段的信息，保护模式下的段是通过段描述符来描述的，描述符的具体分类有三种：存储段描述符，系统段描述符，门描述符，这里只介绍存储段描述符，其他的请自行查阅保护模式相关资料。存储段描述符格式如下：

(P9)

可以看到存储段描述里包含了基址，界限和属性。对我们来说只要找到基址就行了。存储段描述符是保存在GDT中的，而选择子则包含了【描述符索引】即这个选择子所指向的描述符在GDT中的索引号，比如我们刚才计算得到的选择子Selector = 0x0008，其中索引号为1，就是说我们要找的段的段描述符在GDT中的第1项。由此可知，我们要找到【段】还需要找到段描述符，这个算法跟从IDT中找门描述符是一样的，先找到GDT的地址，从刚才的!pcr命令执行结果看到GDT = 0x8003f000，一个描述符占用8个字节，我们要找第一个描述符，计算得到描述符的地址为：0x8003f000+8*1，执行命令

dq /c 1 8003f000+1*8

得到结果：

(P10)

根据上述存储段描述符的格式计算得到该段的基地址为0x000000所以费劲千辛万苦找到了【段】=0x00000，现在【段】和【偏移】都找到了，那么我们要找的一个线性地址就找到了：

【段】：【偏移】 = 0x8053e4a1

反汇编看看这个地址的代码！

u 8053e4a1

得到结果：

(P11)

是这个函数nt!KiSystemService。为了验证我们没有计算错误，可以用Windbg直接显示2E号中断所对应的中断服务程序，执行命令：

!idt 2e

(P12)

可以看到通过脑力算出的结果与Windbg dump出来的结果是一样的，证明了我们的算法是没有问题的。

这样我们先总结一下使用中断实现系统调用时候RING3和RING3的函数接续：

NtDll!KiIntSystemCall > Nt!KiSystemService

使用快速系统调用机制

从Pentium II系列开始的CPU引入了快速系统调用这一特性，增加了两条指令SYSENTER和SYSEXIT(AMD CPU中的指令为SYSCALL和SYSRET)。这一机制的实现就是专门用于解决操作系统的系统调用的性能问题的，这种机制实现的控制转移比中断系统要快很多，因为转移的目标地址是存放在MSR寄存器内，而中断实现的系统调用目标地址存放在内存中的IDT中，所以能提高执行速度。

下面看一下在应用层是在哪里调用了这条指令的：

(P13)

可以看到在ntdll!KiFastSystemCall中有这条指令。

SYSENTER指令的工作机制是在调用SYSENTER指令前，软件必须通过下面的MSR寄存器，指定0层的代码段和代码指针，0层的堆栈段和堆栈指针：

1. IA32_SYSENTER_CS：一个32位值。低16位是0层的代码段的选择子。该值同时用来计算0层的堆栈的选择子。

2. IA32_SYSENTER_EIP：包含一个32位的0层的代码指针，指向第一条指令。

3. IA32_SYSENTER_ESP：包含一个32位的0层的堆栈指针。

MSR寄存器可以通过指令RDMSR/WRMSR来进行读写。寄存器地址如下表。这些地址值在以后的intel 64和IA32处理器中是固定不变的。

MSR	地址
IA32_SYSENTER_CS	174H
IA32_SYSENTER_ESP	175H
IA32_SYSENTER_EIP	176H

当执行SYSENTER，处理器会做下面的动作：

1.从IA32_SYSENTER_CS从取出段选择子加载到CS中。

2.从IA32_SYSENTER_EIP取出指令指针放到EIP中

3.将IA32_SYSENTER_CS的值加上8，将其结果加载到SS中。

4.从IA32_SYSENTER_ESP取出堆栈指针放到ESP寄存器中

5.切换到0层。

6.若EFLAGS中VM标志已被置，则清除VM标志。

7.开始执行选择的系统过程。

 

     又看到了【选择子】，了解了执行流程，下面还可以手工一步步计算出SYSENTER指令行执行CPU取出的第一条内核指令到底在哪里。有了上面的计算过程，这次计算就不需要写的很详细了，目标还是要找到【段】和【偏移】，很明显【偏移】放在MSR的176号地址中，Windbg用如下指令读取MSR：

      rdmsr 176

(P14)

【偏移】 = 0x8053e60

下面找【段】，依然是通过选择子来计算，选择子在MSR的174号地址中存放

     rdmsr 174

(P15)

【选择子】 = 0x0008，跟之前的选择子一样，这里就不用再去计算了，从刚才的结果中知道这个选择子指向的描述符所描述的内存基址是线性地址0x0000

所以我们要找的目标线性地址为【段】:【偏移】 = 0x8053e60

下面反汇编一下这个地址：

(P16)

看到是函数Nt!KiFastCallEntry。

总结一下使用快速系统调用机制的时候RING3和RING3的函数接续：

NtDll!KiFastSystemCall > Nt!KiFastCallEntry

完整的Windows API使用系统调用的过程

在XP系统之前，Windows只实现了一种系统调用的方式，那就是通过INT 2E号中断来实现的，所以从RING3到RING0之后的第一个函数一定是nt!KiSystemService，这个函数就是核心的系统调用分派函数，但是XP开始，Windows系统开始使用快速系统调用这一机制了，但是并没有失去对中断方式的支持，所以XP之后的系统都是两种实现方式共存的。具体做法我们可以用Windbg来继续探索，下面的工作就要在RING3来做了，因为我们要分析一个完整的Windows API使用系统调用的过程。在这之前需要先说一下有关Nt*和Zw*函数的问题。在应用层的Ntdll.dll中有大量的Nt开头的函数和Zw开头的函数，并且都是配对出现，他们所指向的地址都是相同的，所以他们的实现是完全相同的，只不过是别名问题。我们可以用Depdency Walker查看他们的入口地址发现都是相同的，也可以用Windbg反汇编看，关于这一点没什么好说的了，网上很多资料都有说。那我们就可以随便选择一个Nt开头的函数来进行分析，或者Zw开头的都是一样的。内核中也存在这样的函数，但是Nt开头的函数是真正的函数实现，Zw开头的函数是通过nt!KiSystemService函数最终调用的Nt开头的函数。我们选择NtOpenFile函数，需要说明的是这个函数是未导出的，我们在编程的时候使用的是kernel32.dll中导出的OpenFile或者OpenFile，最终是要进入NtOpenFile，从KERNEL32.dll到Ntdll.dll的过程省略。先反汇编NtOpenFile看看：

(P17)

看到在NtOpenFile函数中红色标注的代码，把一个内存中的一个dwrod取到了edx中，这个内存的符号为SharedUserData!SystemCallStub，然后跳转到edx中的值，所以edx中应该是一个函数的地址，我们看一下这个地址是什么

(P18)

看到这个地址中存放的地址是0x7c92e510，反汇编这个地址

(P19)

看到SharedUserData!SystemCallStub保存的是快速系统调用的入口函数的地址，其中通过sysenter进入内核，进入内核之后的过程上面已经介绍过了。

现在就可以总结一下一个Windows API如果使用了系统调用之后的流程了：

无论在何处直接调用了RING3的API并且需要使用系统调用，最终都会通过Ntdll.dll这个模块来进入内核（此说法是错误的，因为Win32子系统就是个例外，Win32子系统也可以进入内核与Win32k.sys交互），例如一个函数OpenXXX，无论其在哪个DLL实现，最终都要进入Ntdll.dll这个函数中的NtOpenXXX，在该函数中的内容就是读取一个用户共享数据区中的一个变量SytemCallStub，这个变量的值就是包含实现特权级变化的控制转移代码的函数入口，其实就是ntdll!KiFastSystemCall的地址，在这个函数中使用了SYSENTER指令，可以直接进入内核的nt!KiFastCallEntry，这个函数会调用nt!KiSystemService这个函数，这个函数的任务是查找SSDT中对应系统调用号的系统调用的实现地址nt!NtOpenXXX。

 

本来我是想做一个推测：在XP系统中通过中断方式实现系统调用的代码仍然存在，那么我们能不能根据需要选择我们希望使用的系统调用的实现方式呢？产生这个想法的原因是Windows并没有直接把实现特权级变化的控制转移代码的函数入口硬编码到每一个API中，而是使用了一个变量—SharedUserData!SytemCallStub中，既然这样实现肯定是为了可以方便切换这个函数的地址，在现在的XP以及更新的操作系统中，这个变量中存放的是ntdll!KiFastSystemCall，就是通过快速系统调用的方式来实现系统调用，那么如果我们修改这个变量的值，使其等于ntdll!KiIntSystemCall的话，是不是就可以改变整个系统的系统调用方式为中断方式呢？关于这个猜想还我还没有做下验证，打算过几天再验证。

 

nt!KiFastCallEntry函数地址的获取

下面说一下nt!KiFastCallEntry这个函数，无论通过何种系统调用的实现方式，都会调用这个函数来进行系统调用，所以这个函数也就成了一是十分重要的领地，就相当于兵家必争之地，无论是安全软件还是恶意软件。但是这个这个函数地址的获取还是有一点技巧的。

在这里先说一下XXX安全卫士的获取nt!KiFastCallEntry这个函数地址的方式，因为网上有人分析过它的实现方式，并且被大量转载，所以这里只是简单的提一下。我们已知的信息是，Windows的凡是涉及系统调用的API在内核中的调用顺序是：

快速系统调用：nt!KiFastCallEntry->Nt*

中断方式系统调用：nt!KiSystemService-> nt!KiFastCallEntry->Nt*

所以为了过滤系统调用，只要Hook住nt!KiFastCallEntry这个函数就一定能拦截所有的系统调用。XXX安全卫士的做法是先Hook住了一个nt!NtSetEvent函数，当进入这个函数的时候利用栈回溯，找到当前函数的返回地址，这个地址一定是在上层函数内的，得到这个地址就以后，就可以根据特征码搜索需要Inline Hook的目标地址了。借助nt!ZwCreateFile函数来动态跟踪分析，如下图：

(P20)

很多人说这种方法巧妙，通过栈回溯找到目标函数地址域内的一地址，然后特征码匹配，为何不直接找到函数入口然后直接特征码匹配呢？栈回溯的方法固然看起来很巧妙，可是如果内核中对nt!KiFastCallEntry函数启用了FPO(帧指针优化)，那这种方法就完全被挫败了，所以这种方法并不能称为完美。

 

网上也有很多其他方法来获取nt!KiFastCallEntry函数入口地址，有暴力搜索的，也有通过MSR寄存器的。通过MSR寄存器读取的确是一种中规中矩的方法，但是看过不少代码，都是建立在一个假设上：nt!KiFastCallEntry的段基址一定是线性地址0x00开始。这些代码都直接忽略了对MSR 174号地址内的段选择子的处理，完整的做法应该利用本文中之前的方法计算段和偏移求得nt!KiFastCallEntry的入口地址，由于汇编语言处理这些计算相对方便，所以本人用汇编实现了一个得到nt!KiFastCallEntry函数地址的函数。代码如下：

 

[html] view plain copy

1. #define IA32_SYSENTER_CS 174H  
2. #define IA32_SYSENTER_ESP 175H  
3. #define IA32_SYSENTER_EIP 176H  
4.   
5. ULONG GetAddressOfKiFastCallEntry()  
6. {  
7.     ULONG dwAddress = 0;  
8.     __asm  
9.     {  
10.         jmp func_main  
11. vgdtr:  
12.         _emit 0x00  
13.         _emit 0x00  
14.         _emit 0x00  
15.         _emit 0x00  
16.         _emit 0x00  
17.         _emit 0x00  
18.         _emit 0x00  
19.         _emit 0x00  
20.   
21. func_main:  
22.         push eax  
23.         push ebx  
24.         push ecx  
25.         push edx  
26.         mov ecx, 0x174  
27.         rdmsr  
28.         mov ebx, eax        //Selector offset  
29.           
30.         sgdt vgdtr  
31.         mov edx, vgdtr  
32.         add edx, 0x02  
33.         mov eax, [edx]      //GDT base  
34.         add ebx, eax        //Selector base  
35.   
36.         mov edx, ebx  
37.         add edx, 0x07  
38.         mov eax, [edx]  
39.         shl eax, 24;  
40.         mov edx, ebx  
41.         add edx, 0x02  
42.         mov ecx, [edx]  
43.         and ecx, 0x00FFFFFF  
44.         add eax, ecx        //Address CodeSegment  
45.         mov ebx, eax  
46.   
47.         mov ecx, 0x176  
48.         rdmsr  
49.         add eax, ebx  
50.   
51.         mov dwAddress, eax  
52.   
53.         pop edx  
54.         pop ecx  
55.         pop ebx  
56.         pop eax  
57.     }  
58.   
59.     return dwAddress;  
60. }   

 

测试用驱动代码及结果如下图：

(P21)

(P22)

这个结果和我们用Windbg查看得到的是一样的。

 

这篇文章写的有点长，而且知识有点砸碎希望各位看过之后能理解。

[cpp] view plain copy print ?

1. //从hookport.sys学到的hook方法，主要是KiFastCallEntry地址的获取及hook的地方思路  
2.   
3. //DRIVER.CPP  
4.   
5.   
6.   
7. #include "Driver.h"  
8. #define  MAX_POOL_EXA 0x1000  
9.   
10. /************************************************************************ 
11.     全局结构变量 
12. *************************************************************************/  
13.   
14. #define  FUNCINDEX 0xDB  
15. extern "C"  typedef struct _SERVICE_DESCRIPTOR_TABLE  
16. {  
17.  PVOID   ServiceTableBase;  
18.  PULONG  ServiceCounterTableBase;  
19.  ULONG   NumberOfService;  
20.  ULONG   ParamTableBase;  
21. }SERVICE_DESCRIPTOR_TABLE,*PSERVICE_DESCRIPTOR_TABLE;  
22.   
23. extern "C" PSERVICE_DESCRIPTOR_TABLE    KeServiceDescriptorTable;  
24.   
25. #define Unprotect() /  
26.  __asm cli /  
27.  __asm mov eax,cr0 /  
28.  __asm and eax,0x0FFFEFFFF /  
29. __asm mov cr0,eax  
30.   
31. #define Protect() /  
32.  __asm mov eax,cr0 /  
33.  __asm or  eax, not 0FFFEFFFFh /  
34.  __asm mov cr0,eax  /  
35.   __asm sti  
36.   
37. ULONG g_OldServiceAddress=0;  
38. ULONG g_hookkifasthandle=0x680286449;  
39. PVOID g_pJmpBuff=NULL;  
40. ULONG g_KiFaseCallEntryEntryAddress=0;  
41. ULONG g_OldKiFastCallEntryAddress=0;  
42. CHAR TagsToHookKiFastCallEntry[]={0x2b,0xe1,0xc1,0xe9,0x02};  
43. CHAR g_jmp[]={0xe9,0x90,0x90,0x90,0x90};  
44. /************************************************************************ 
45.     函数声明 
46. *************************************************************************/  
47.   
48. extern "C"  
49. NTSTATUS  
50. ZwSetEvent(  
51.      __in HANDLE  EventHandle,  
52.      __out_opt PLONG  PreviousState   
53.      );  
54.   
55. /************************************************************************ 
56. * 函数名称:MySleep 
57. * 功能描述:传入时间，暂停指定时间 
58. * 参数列表: 
59.        
60. * 返回 值:无 
61. *************************************************************************/  
62. VOID MySleep(ULONG dwMilliseconds)  
63. {  
64.  KTIMER Timer;  
65.  LARGE_INTEGER DueTime;  
66.  DueTime.QuadPart=dwMilliseconds*(-1000);  
67.  KeInitializeTimerEx(&Timer, SynchronizationTimer);  
68.  KeSetTimer(&Timer,DueTime,0);  
69.  KeWaitForSingleObject(&Timer,UserRequest,0,TRUE,0);  
70.    
71. }  
72.   
73. /************************************************************************ 
74. * 函数名称:RealKiFastCallEntry 
75. * 功能描述:这里添加各种过滤规则,暂未添加规则，只是简单打印 
76. * 参数列表:这3个参数暂且不知道什么意思，需要看wrk 
77.        
78. * 返回 值:NTSTATUS 
79. *************************************************************************/  
80. ULONG RealKiFastCallEntry(ULONG arg1,ULONG arg2,ULONG arg3)  
81. {  
82.  KdPrint(("i'am running in kifastcallentry,%.8X,%.8X,%.8X",arg1,arg2,arg3));   
83.  return arg1;   
84. }  
85. /************************************************************************ 
86. * 函数名称:MyZwSetEvent 
87. * 功能描述:挂钩ZwSetEvent的挂钩函数 
88. * 参数列表: 
89.        
90. * 返回 值:NTSTATUS 
91. *************************************************************************/  
92. __declspec(naked)  __stdcall MyKiFastCallEntry()  
93. {  
94.   
95.    
96.  __asm  
97.  {  
98.    mov     edi,edi  
99.      
100.    push ebp  
101.    pushfd  
102.    pushad  
103.      
104.    push edi  
105.    push edx  
106.    push eax  
107.    call RealKiFastCallEntry  
108.    mov [esp+10],eax  
109.    popad  
110.    popfd  
111.    pop ebp  
112.      
113.    //KiFastCallEntry原处的指令  
114.    sub esp,ecx  
115.    shr ecx,2  
116.    //  
117.    push [g_OldKiFastCallEntryAddress]  
118.    retn  
119.      
120.      
121.  }  
122.    
123. }  
124.   
125. /************************************************************************ 
126. * 函数名称:MyZwSetEvent 
127. * 功能描述:挂钩ZwSetEvent的挂钩函数,在这里面得到kIfastcallentry地址并inine hook 
128. * 参数列表:EventHandle PreviousState都是原ZwSetEvent的参数 
129.        
130. * 返回 值:NTSTATUS 
131. *************************************************************************/  
132. NTSTATUS  
133. MyZwSetEvent(  
134.      __in HANDLE  EventHandle,  
135.      __out_opt PLONG  PreviousState   
136.      )  
137. {  
138.  BOOLEAN bFlags=FALSE;  
139.  KSPIN_LOCK Spinlock;  
140.  KIRQL  Irql;  
141.  NTSTATUS Status=STATUS_SUCCESS;  
142.  ULONG MyJmpAddress=(ULONG)MyKiFastCallEntry;  
143.  //获取KFastCallEntry地址  
144.  if (EventHandle==(HANDLE)g_hookkifasthandle)  
145.  {  
146.   if (ExGetPreviousMode()==0)//先前模式是内核的才行  
147.   {  
148.    g_pJmpBuff=ExAllocatePoolWithTag(NonPagedPool,5,'jmp');  
149.    if (g_pJmpBuff==NULL)  
150.    {  
151.     //  
152.     goto Retu;  
153.    }  
154.    else  
155.    {  
156.     //开始获取地址并hook  
157.     __asm  
158.     {   
159.      push eax  
160.       push ebx  
161.      mov eax,g_pJmpBuff//构造好buffer，形成jmp XXXXXXXX  
162.      mov byte ptr [eax],0xe9   //这个jmp XxxXXXX是跳到我们上面的MyKiFastCallEntry的  
163.      mov ebx,MyJmpAddress  
164.      sub ebx,eax  
165.      sub ebx,5  
166.      mov dword ptr [eax+1],ebx  
167.      pop ebx  
168.      pop eax  
169.     }  
170.     KeAcquireSpinLock(&Spinlock,&Irql);  
171.     Unprotect();  
172.       
173.     //取ebp+4  
174.     __asm  
175.     {  
176.      mov eax,[ebp+4]///*********************关键点  
177.      mov edx,eax  
178.      mov g_KiFaseCallEntryEntryAddress,eax  
179. agains:  
180.      mov edi,eax  
181.      lea esi,TagsToHookKiFastCallEntry  
182.      mov ecx,5  
183.      repe cmpsb  
184.      push eax  
185.      setz al  
186.      test al,al  
187.      pop eax  
188.      jnz Find  
189.      dec eax       //从后往前找  
190.      push edx  
191.      sub edx,eax  
192.      cmp edx,64h  
193.      pop edx  
194.      ja ReadyExit  
195.      jmp agains      //循环，找到改写的地址  
196.   
197. Find:  
198.      add eax,5       
199.      mov g_OldKiFastCallEntryAddress,eax//g_ OldKiFastCallEntryAddress在MyKiFastCallEntry调回的  
200.      mov edx,g_pJmpBuff          //在这里填入的JMp  
201.      sub edx,eax            //是jmp XXXXX到上面分配的buffer中的  
202.      lea eax,g_jmp  
203.      mov [eax+1],edx  
204.      mov edi,g_OldKiFastCallEntryAddress  
205.      sub edi,5       //开始hook的地方  
206.      lea esi,g_jmp  
207.      mov ecx,5  
208.      rep movsb  
209.        
210.        
211.      
212.     }  
213. ReadyExit:  
214.     Protect();   
215.     KeReleaseSpinLock(&Spinlock,Irql);  
216.    }  
217.   }  
218.   
219.  }  
220.  //调用原来的  
221.  __asm  
222.  {  
223.    pushad  
224.    mov eax,EventHandle  
225.    mov ebx,PreviousState;  
226.    push ebx  
227.    push eax  
228.    call g_OldServiceAddress  
229.    mov Status,eax  
230.   
231.    popad  
232.  }  
233. Retu:  
234.  return Status;  
235.    
236. }  
237. /************************************************************************  
238. * 函数名称:HookTableFunc  
239. * 功能描述:传入要hook的某个表的地址和表中的函数索引，和函数地址  
240. * 参数列表:  
241.   
242. * 返回 值:无   
243. *************************************************************************/  
244. VOID HookTableFunc(ULONG TableAddress,ULONG Index,ULONG MyFuncAddress)  
245. {  
246.  KSPIN_LOCK Spinlock;  
247.  KIRQL  Irql;  
248.  ULONG HookAddress=TableAddress+Index*4;  
249.  KdPrint(("HookAddress=%.8X/n",HookAddress));  
250.  g_OldServiceAddress=*(ULONG *)HookAddress;   
251.  KeInitializeSpinLock(&Spinlock);  
252.  KeAcquireSpinLock(&Spinlock,&Irql);  
253.  Unprotect();  
254.     
255. // *(ULONG *)HookAddress=MyFuncAddress;  
256.  InterlockedExchange((volatile LONG *)HookAddress,MyFuncAddress);  
257.   
258.  Protect();  
259.  KeReleaseSpinLock(&Spinlock,Irql);  
260. }  
261. /************************************************************************ 
262. * 函数名称:HookSdtFunc 
263. * 功能描述:传入要unhook的某个表的地址和表中的函数索引，和填入函数地址 
264. * 参数列表: 
265.  
266. * 返回 值:无  
267. *************************************************************************/  
268. VOID UnHookTableFunc(ULONG TableAddress,ULONG Index,ULONG OldFuncAddress)  
269. {  
270.   
271.  KSPIN_LOCK Spinlock;  
272.  KIRQL  Irql;  
273.  ULONG HookAddress=TableAddress+Index*4;  
274.  KdPrint(("HookAddress=%.8X/n",HookAddress));  
275.  KeInitializeSpinLock(&Spinlock);  
276.  KeAcquireSpinLock(&Spinlock,&Irql);  
277.  Unprotect();  
278.    
279.  // *(ULONG *)HookAddress=MyFuncAddress;  
280.  InterlockedExchange((volatile LONG *)HookAddress,OldFuncAddress);  
281.    
282.  Protect();  
283.  KeReleaseSpinLock(&Spinlock,Irql);  
284. }  
285. /************************************************************************ 
286. * 函数名称:DriverEntry 
287. * 功能描述:驱动入口 
288. * 参数列表: 
289.        
290. * 返回 值:NTSTATUS 
291. *************************************************************************/  
292. #pragma INITCODE  
293. extern "C" NTSTATUS DriverEntry(  
294.    IN PDRIVER_OBJECT pDriverObject,  
295.    IN PUNICODE_STRING pRegistryPath )   
296. {  
297.  NTSTATUS status;  
298.  KdPrint(("Enter DriverEntry/n"));  
299.   
300.  //注册其他驱动调用函数入口  
301.  pDriverObject->DriverUnload = HelloDDKUnload;  
302.  pDriverObject->MajorFunction[IRP_MJ_CREATE] = HelloDDKDispatchRoutine;  
303.  pDriverObject->MajorFunction[IRP_MJ_CLOSE] = HelloDDKDispatchRoutine;  
304.  pDriverObject->MajorFunction[IRP_MJ_WRITE] = HelloDDKDispatchRoutine;  
305.  pDriverObject->MajorFunction[IRP_MJ_READ] = HelloDDKDispatchRoutine;  
306.    
307.  //创建驱动设备对象  
308.  status = CreateDevice(pDriverObject);  
309.  //hook zwsetevent  
310.  HookTableFunc((ULONG) KeServiceDescriptorTable->ServiceTableBase,FUNCINDEX,(ULONG)MyZwSetEvent);  
311.  //调用zwSetevent  
312.  ZwSetEvent((HANDLE)g_hookkifasthandle,0);  
313.  //取消hook  
314.  UnHookTableFunc((ULONG) KeServiceDescriptorTable->ServiceTableBase,FUNCINDEX,(ULONG)g_OldServiceAddress);  
315.  KdPrint(("DriverEntry end/n"));  
316.  return status;  
317. }  
318. /************************************************************************ 
319. * 函数名称:CreateDevice 
320. * 功能描述:初始化设备对象 
321. * 参数列表: 
322.       pDriverObject:从I/O管理器中传进来的驱动对象 
323. * 返回 值:返回初始化状态 
324. *************************************************************************/  
325. #pragma INITCODE  
326. NTSTATUS CreateDevice (  
327.   IN PDRIVER_OBJECT pDriverObject)   
328. {  
329.  NTSTATUS status;  
330.  PDEVICE_OBJECT pDevObj;  
331.  PDEVICE_EXTENSION pDevExt;  
332.    
333.  //创建设备名称  
334.  UNICODE_STRING devName;  
335.  RtlInitUnicodeString(&devName,L"//Device//MyRookit");  
336.    
337.  //创建设备  
338.  status = IoCreateDevice( pDriverObject,  
339.       sizeof(DEVICE_EXTENSION),  
340.       &(UNICODE_STRING)devName,  
341.       FILE_DEVICE_UNKNOWN,  
342.       0, TRUE,  
343.       &pDevObj );  
344.  if (!NT_SUCCESS(status))  
345.   return status;  
346.   
347.  pDevObj->Flags |= DO_BUFFERED_IO;  
348.  pDevExt = (PDEVICE_EXTENSION)pDevObj->DeviceExtension;  
349.  pDevExt->pDevice = pDevObj;  
350.  pDevExt->ustrDeviceName = devName;  
351.  //创建符号链接  
352.  UNICODE_STRING symLinkName;  
353.  RtlInitUnicodeString(&symLinkName,L"//??//MyRookit");  
354.  pDevExt->ustrSymLinkName = symLinkName;  
355.  status = IoCreateSymbolicLink( &symLinkName,&devName );  
356.  if (!NT_SUCCESS(status))   
357.  {  
358.   IoDeleteDevice( pDevObj );  
359.   return status;  
360.  }  
361.   
362.  return STATUS_SUCCESS;  
363. }  
364. /************************************************************************ 
365. * 函数名称:HelloDDKUnload 
366. * 功能描述:负责驱动程序的卸载操作 
367. * 参数列表: 
368.       pDriverObject:驱动对象 
369. * 返回 值:返回状态 
370. *************************************************************************/  
371. #pragma PAGEDCODE  
372. VOID HelloDDKUnload (IN PDRIVER_OBJECT pDriverObject)   
373. {  
374.  PDEVICE_OBJECT pNextObj;  
375.  KdPrint(("Enter DriverUnload/n"));  
376.  pNextObj = pDriverObject->DeviceObject;  
377.  while (pNextObj != NULL)   
378.  {  
379.   PDEVICE_EXTENSION pDevExt = (PDEVICE_EXTENSION)  
380.    pNextObj->DeviceExtension;  
381.   
382.   //删除符号链接  
383.   UNICODE_STRING pLinkName = pDevExt->ustrSymLinkName;  
384.   IoDeleteSymbolicLink(&pLinkName);  
385.   pNextObj = pNextObj->NextDevice;  
386.   IoDeleteDevice( pDevExt->pDevice );  
387.  }  
388. }  
389.   
390. #pragma PAGEDCODE  
391. NTSTATUS HelloDDKDispatchRoutine(IN PDEVICE_OBJECT pDevObj,  
392.          IN PIRP pIrp)   
393. {  
394.  KdPrint(("Enter HelloDDKDispatchRoutine/n"));  
395.  NTSTATUS status = STATUS_SUCCESS;  
396.  // 完成IRP  
397.  pIrp->IoStatus.Status = status;  
398.  pIrp->IoStatus.Information = 0; // bytes xfered  
399.  IoCompleteRequest( pIrp, IO_NO_INCREMENT );  
400.  KdPrint(("Leave HelloDDKDispatchRoutine/n"));  
401.  return status;  
402. }  
403.   
404.   
405.   
406.   
407.   
408.   
409.   
410.   
411.   
412. //Driver.h  
413.   
414. #pragma once  
415.   
416. #ifdef __cplusplus  
417. extern "C"  
418. {  
419. #endif  
420. #include <NTDDK.h>  
421. #ifdef __cplusplus  
422. }  
423. #endif   
424.   
425. #define PAGEDCODE code_seg("PAGE")  
426. #define LOCKEDCODE code_seg()  
427. #define INITCODE code_seg("INIT")  
428.   
429. #define PAGEDDATA data_seg("PAGE")  
430. #define LOCKEDDATA data_seg()  
431. #define INITDATA data_seg("INIT")  
432.   
433. #define arraysize(p) (sizeof(p)/sizeof((p)[0]))  
434.   
435. typedef struct _DEVICE_EXTENSION {  
436.  PDEVICE_OBJECT pDevice;  
437.  UNICODE_STRING ustrDeviceName; //设备名称  
438.  UNICODE_STRING ustrSymLinkName; //符号链接名  
439. } DEVICE_EXTENSION, *PDEVICE_EXTENSION;  
440.   
441. // 函数声明  
442.   
443. NTSTATUS CreateDevice (IN PDRIVER_OBJECT pDriverObject);  
444. VOID HelloDDKUnload (IN PDRIVER_OBJECT pDriverObject);  
445. NTSTATUS HelloDDKDispatchRoutine(IN PDEVICE_OBJECT pDevObj,  
446.          IN PIRP pIrp);  

 

 

 

只是个框架，并未实现什么，简单的打印了下字符，并且未作卸载驱动hook的恢复(几句搞定)