反病毒引擎设计之实时监控篇
反病毒引擎设计之实时监控篇
from: http://tech.ccidnet.com/pub/article/c1247_a81772_p1.html
编者按：绪论《反病毒引擎设计之虚拟机查毒篇》我们重点对虚拟机查毒进行了阐述。下面看看如何对病毒实时监控。
目录
3.1实时监控概论
3.2病毒实时监控实现技术概论
3.3WIN9X下的病毒实时监控
3.3.1实现技术详解
3.3.2程序结构与流程
3.3.3HOOKSYS.VXD逆向工程代码剖析
3.3.3.1钩子函数入口代码
3.3.3.2取得当前进程名称代码
3.3.3.3通信部分代码
3.4 WINNT/2000下的病毒实时监控
3.4.1实现技术详解
3.4.2程序结构与流程
3.4.3HOOKSYS.SYS逆向工程代码剖析
3.4.3.1取得当前进程名称代码
3.4.3.2启动钩子函数工作代码
3.4.3.3映射系统内存至用户空间代码
3．病毒实时监控
3.1实时监控概论
实时监控技术其实并非什么新技术，早在DOS编程时代就有之。只不过那时人们没有给这项技术冠以这样专业的名字而已。早期在各大专院校机房中普遍使用的硬盘写保护软件正是利用了实时监控技术。硬盘写保护软件一般会将自身写入硬盘零磁头开始的几个扇区（由0磁头0柱面1扇最开始的64个扇区是保留的，DOS访问不到）并修改原来的主引导记录以使启动时硬盘写保护程序可以取得控制权。引导时取得控制权的硬盘写保护程序会修改INT13H的中断向量指向自身已驻留于内存中的钩子代码以便随时拦截所有对磁盘的操作。钩子代码的作用当然是很明显的，它主要负责由判断中断入口参数，包括功能号，磁盘目标地址等来决定该类型操作是否被允许，这样就可以实现对某一特定区域的写操作保护。后来又诞生了在此基础之上进行改进了的磁盘恢复卡之类的产品，其利用将写操作重定向至目标区域外的临时分区并保存磁盘先前状态等技术来实现允许写入并可随时恢复之功能。不管怎么改进，这类产品的核心技术还是对磁盘操作的实时监控。对此有兴趣的朋友可参看高云庆著《硬盘保护技术手册》。DOS下还有许多通过驻留并截获一些有用的中断来实现某种特定目的的程序，我们通常称之为 TSR（终止并等待驻留terminate-and-stay-resident，此种程序不容易编好，需要大量的关于硬件和Dos中断的知识，还要解决 Dos重入，tsr程序重入等问题，搞不好就会当机）。在WINDOWS下要实现实时监控决非易事，普通用户态程序是不可能监控系统的活动的，这也是出于系统安全的考虑。HPS病毒能在用户态下直接监控系统中的文件操作其实是由于WIN9X在设计上存在漏洞。而我们下面要讨论的两个病毒实时监控（For WIN9X&WINNT/2000）都使用了驱动编程技术，让工作于系统核心态的驱动程序去拦截所有的文件访问。当然由于工作系统的不同，这两个驱动程序无论从结构还是工作原理都不尽相同的，当然程序写法和编译环境更是千差万别了，所以我们决定将其各自分成独立的一节来详细地加以讨论。上面提到的病毒实时监控其实就是对文件的监控，说成是文件监控应该更为合理一些。除了文件监控外，还有各种各样的实时监控工具，它们也都具有各自不同的特点和功用。这里向大家推荐一个关于WINDOWS系统内核编程的站点:www.sysinternals.com。在其上可以找到很多实时监控小工具，比如能够监视注册表访问的Regmon（通过修改系统调用表中注册表相关服务入口），可以实时地观察TCP和UDP活动的Tdimon（通过hook系统协议驱动 Tcpip.sys中的dispatch函数来截获tdi clinet向其发送的请求），这些工具对于了解系统内部运作细节是很有裨益的。介绍完有关的背景情况后，我们来看看关于病毒实时监控的具体实现技术的情况。
3.2病毒实时监控实现技术概论
正如上面提到的病毒实时监控其实就是一个文件监视器，它会在文件打开，关闭，清除，写入等操作时检查文件是否是病毒携带者，如果是则根据用户的决定选择不同的处理方案，如清除病毒，禁止访问该文件，删除该文件或简单地忽略。这样就可以有效地避免病毒在本地机器上的感染传播，因为可执行文件装入器在装入一个文件执行时首先会要求打开该文件，而这个请求又一定会被实时监控在第一时间截获到，它确保了每次执行的都是干净的不带毒的文件从而不给病毒以任何执行和发作的机会。以上说的仅是病毒实时监控一个粗略的工作过程，详细的说明将留到后面相应的章节中。病毒实时监控的设计主要存在以下几个难点：
其一是驱动程序的编写不同于普通用户态程序的写作，其难度很大。写用户态程序时你需要的仅仅就是调用一些熟知的API函数来完成特定的目的，比如打开文件你只需调用CreateFile就可以了；但在驱动程序中你将无法使用熟悉的CreateFile。在NT/2000下你可以使用 ZwCreateFile或NtCreateFile（native API），但这些函数通常会要求运行在某个IRQL（中断请求级）上，如果你对如中断请求级，延迟/异步过程调用，非分页/分页内存等概念不是特别清楚，那么你写的驱动将很容易导致蓝屏死机（BSOD），Ring0下的异常将往往导致系统崩溃，因为它对于系统总是被信任的，所以没有相应处理代码去捕获这个异常。在NT下对KeBugCheckEx的调用将导致蓝屏的出现，接着系统将进行转储并随后重启。另外驱动程序的调试不如用户态程序那样方便，用象VC ++那样的调试器是不行的，你必须使用系统级调试器，如softice,kd,trw等。
其二是驱动程序与ring3下客户程序的通信问题。这个问题的提出是很自然的，试想当驱动程序截获到某个文件打开请求时，它必须通知位于ring3下的查毒模块检查被打开的文件，随后查毒模块还需将查毒的结果通过某种方式传给ring0下的监控程序，最后驱动程序根据返回的结果决定请求是否被允许。这里面显然存在一个双向的通信过程。写过驱动程序的人都知道一个可以用来向驱动程序发送设备I/O控制信息的API调用 DeviceIoControl，它的接口在MSDN中可以找到，但它是单向的，即ring3下客户程序可以通过调用DeviceIoControl将某些信息传给ring0下的监控程序但反过来不行。既然无法找到一个现成的函数实现从ring0下的监控程序到ring3下客户程序的通信，则我们必须采用迂回的办法来间接做到这一点。为此我们必须引入异步过程调用（APC）和事件对象的概念，它们就是实现特权级间唤醒的关键所在。现在先简单介绍一下这两个概念，具体的用法请参看后面的每子章中的技术实现细节。异步过程调用是一种系统用来当条件合适时在某个特定线程的上下文中执行一个过程的机制。当向一个线程的APC队列排队一个APC时，系统将发出一个软件中断，当下一次线程被调度时，APC函数将得以运行。APC分成两种：系统创建的APC称为内核模式 APC，由应用程序创建的APC称为用户模式APC。另外只有当线程处于可报警（alertable）状态时才能运行一个APC。比如调用一个异步模式的 ReadFileEx时可以指定一个用户自定义的回调函数FileIOCompletionRoutine，当异步的I/O操作完成或被取消并且线程处于可报警状态时函数被调用，这就是APC的典型用法。Kernel32.dll中导出的QueueUserAPC函数可以向指定线程的队列中增加一个APC 对象，因为我们写的是驱动程序，这并不是我们要的那个函数。很幸运的是在Vwin32.vxd中导出了一个同名函数QueueUserAPC，监控程序拦截到一个文件打开请求后，它马上调用这个服务排队一个ring3下客户程序中需要被唤醒的函数的APC，这个函数将在不久客户程序被调度时被调用。这种 APC唤醒法适用于WIN9X，在WINNT/2000下我们将使用全局共享的事件和信号量对象来解决互相唤醒问题。有关WINNT/2000下的对象组织结构我将在3.4.2节中详细说明。NT/2000版监控程序中我们将利用KeReleaseSemaphore来唤醒一个在ring3下客户程序中等待的线程。目前不少反病毒软件已将驱动使用的查毒模块移到ring0，即如其所宣传的“主动与操作系统无缝连接”，这样做省却了通信的消耗，但把查毒模块写成驱动形式也同时会带来一些麻烦，如不能调用大量熟知的API，不能与用户实时交互，所以我们还是选择剖析传统的反病毒软件的监控程序。
其三是驱动程序所占用资源问题。如果由于监控程序频繁地拦截文件操作而使系统性能下降过多，则这样的程序是没有其存在的价值的。本论文将对一个成功的反病毒软件的监控程序做彻底的剖析，其中就包含有分析其用以提高自身性能的技巧的部分，如设置历史记录，内置文件类型过滤，设置等待超时等。
3.3WIN9X下的病毒实时监控
3.3.1实现技术详解
WIN9X下病毒实时监控的实现主要依赖于虚拟设备驱动（VXD）编程，可安装文件系统钩挂（IFSHook），VXD与ring3下客户程序的通信（APC/EVENT）三项技术。
我们曾经提到过只有工作于系统核心态的驱动程序才具有有效地完成拦截系统范围文件操作的能力，VXD就是适用于WIN9X下的虚拟设备驱动程序，所以正可当此重任。当然，VXD的功能远不止由IFSMGR.vxd提供的拦截文件操作这一项，系统的VXDs几乎提供了所有的底层操作的接口- -可以把VXD看成ring0下的DLL。虚拟机管理器本身就是一个VXD，它导出的底层操作接口一般称为VMM服务，而其他VXD的调用接口则称为 VXD服务。
二者ring0调用方法均相同，即在INT20（CD 20）后面紧跟着一个服务识别码，VMM会利用服务识别码的前半部分设备标识--Device Id找到对应的VXD，然后再利用服务识别码的后半部分在VXD的服务表（Service Table）中定位服务函数的指针并调用之：
CD 20 INT 20H
01 00 0D 00 DD VKD_Define_HotKey
这条指令第一次执行后，VMM将以一个同样6字节间接调用指令替换之（并不都是修正为CALL指令，有时会利用JMP指令），从而省却了查询服务表的工作：
FF 15 XX XX XX XX CALL [$VKD_Define_HotKey]
必须注意，上述调用方法只适用于ring0，即只是一个从VXD中调用VXD/VMM服务的ring0接口。VXD还提供了V86（虚拟8086模式），Win16保护模式，Win32保护模式调用接口。其中V86和Win16保护模式的调用接口比较奇怪：
XOR DI DI
MOV ES,DI
MOV AX,1684 ；INT 2FH,AX = 1684H-->取得设备入口
MOV BX,002A ；002AH = VWIN32.VXD的设备标识
INT 2F
MOV AX,ES ；现在ES:DI中应该包含着入口
OR AX,AX
JE failure
MOV AH,00 ；VWIN32 服务 0 = VWIN32_Get_Version
PUSH DS
MOV DS,WORD PTR CS:[0002]
MOV WORD PTR [lpfnVMIN32],DI
MOV WORD PTR [lpfnVMIN32+2],ES ；保存ES和DI
CALL FAR [lpfnVMIN32] ；call gate（调用门）
ES:DI指向了3B段的一个保护模式回调：
003B：000003D0 INT 30 ；#0028:C025DB52 VWIN32（04）+0742
INT30强迫CPU从ring3提升到ring0，然后WIN95的INT30处理函数先检查调用是否发自3B段，如是则利用引发回调的CS:IP索引一个保护模式回调表以求得一个ring0地址。本例中是0028:C025DB52 ，即所需服务VWIN32_Get_Version的入口地址。
VXD的Win32保护模式调用接口我们在前面已经提到过。一个是DeviceIoControl，我们的ring3客户程序利用它来和监控驱动进行单向通信；另一个是VxdCall，它是Kernel32.dll的一个未公开的调用，被系统频繁使用，对我们则没有多大用处。
你可以参看WIN95DDK的帮助，其中对每个系统VXD提供的调用接口均有详细说明，可按照需要选择相应的服务。
可安装文件系统钩挂（IFSHook）就源自IFSMGR.VXD提供的一个服务 IFSMgr_InstallFileSystemApiHook，利用这个服务驱动程序可以向系统注册一个钩子函数。以后系统中所有文件操作都会经过这个钩子的过滤，WIN9X下文件读写具体流程如下：
在读写操作进行时，首先通过未公开函数EnterMustComplete来增加MUSTCOMPLETECOUNT变量的记数，告诉操作系统本操作必须完成。该函数设置了KERNEL32模块里的内部变量来显示现在有个关键操作正在进行。有句题外话，在VMM里同样有个函数，函数名也是EnterMustComplete。那个函数同样告诉VMM，有个关键操作正在进行。防止线程被杀掉或者被挂起。
接下来，WIN9X进行了一个_MapHandleWithContext(又是一个未公开函数)操作。该操作本身的具体意义尚不清楚，但是其操作却是得到HANDLE所指对象的指针，并且增加了引用计数。
随后，进行的乃是根本性的操作：KERNEL32发出了一个调用VWIN32_Int21Dispatch的VxdCall。陷入 VWIN32后，其检查调用是否是读写操作。若是，则根据文件句柄切换成一个FSD能识别的句柄，并调用IFSMgr_Ring0_FileIO。接下来任务就转到了IFS MANAGER。
IFS MANAGER生成一个IOREQ，并跳转到Ring0ReadWrite内部例程。Ring0ReadWrite检查句柄有效性，并且获取FSD在创建文件句柄时返回的CONTEXT，一起传入到CallIoFunc内部例程。CallIoFunc检查IFSHOOK的存在，如果不存在，IFS MANAGER生成一个缺省的IFS HOOK，并且调用相应的VFatReadFile/VFatWriteFile例程(因为目前 MS本身仅提供了VFAT驱动)；如果IFSHOOK存在，则IFSHOOK函数得到控制权，而IFS MANAGER本身就脱离了文件读写处理。然后，调用被层层返回。KERNEL32调用未公开函数LeaveMustComplete，减少 MUSTCOMPLETECOUNT计数，最终回到调用者。
由此可见通过IFSHook拦截本地文件操作是万无一失的，而通过ApiHook或VxdCall拦截文件则多有遗漏。著名的CIH病毒正是利用了这一技术，实现其驻留感染的，其中的代码片段如下：
lea eax, FileSystemApiHook-@6[edi] ；取得欲安装的钩子函数的地址
push eax
int 20h ；调用IFSMgr_InstallFileSystemApiHook
IFSMgr_InstallFileSystemApiHook = $
dd 00400067h
mov dr0, eax ；保存前一个钩子的地址
pop eax
正如我们看到的，系统中安装的所有钩子函数呈链状排列。最后安装的钩子，最先被系统调用。我们在安装钩子的同时必须将调用返回的前一个钩子的地址暂存以便在完成处理后向下传递该请求：
mov eax, dr0 ；取得前一个钩子的地址
jmp [eax] ； 跳到那里继续执行
对于病毒实时监控来说，我们在安装钩子时同样需要保存前一个钩子的地址。如果文件操作的对象携带了病毒，则我们可以通过不调用前一个钩子来简单的取消该文件请求；反之，我们则需及时向下传递该请求，若在钩子中滞留的时间过长--用于等待ring3级查毒模块的处理反馈--则会使用户明显感觉系统变慢。
至于钩子函数入口参数结构和怎样从参数中取得操作类型（如IFSFN_OPEN）和文件名（以UNICODE形式存储）请参看相应的代码剖析部分。
我们所需的另一项技术--APC/EVENT也是源自一个VXD导出的服务，这便是著名的VWIN32.vxd。这个奇怪的VXD导出了许多与WIN32 API对应的服务：如_VWIN32_QueueUserApc，_VWIN32_WaitSingleObject， _VWIN32_ResetWin32Event，_VWIN32_Get_Thread_Context， _VWIN32_Set_Thread_Context 等。这个VXD叫虚拟WIN32，大概名称即是由此而来的。虽然服务的名称与WIN32 API一样，但调用规则却大相径庭，千万不可用错。_VWIN32_QueueUserApc用来注册一个用户态的APC，这里的APC函数当然是指我们在ring3下以可告警状态睡眠的待查毒线程。ring3客户程序首先通过IOCTL把待查毒线程的地址传给驱动程序，然后当钩子函数拦截到待查文件时调用此服务排队一个APC，当ring3客户程序下一次被调度时，APC例程得以执行。_VWIN32_WaitSingleObject则用来在某个对象上等待，从而使当前ring0线程暂时挂起。我们的ring3客户程序先调用WIN32 API--CreateEvent创建一组事件对象，然后通过一个未公开的API--OpenVxdHandle将事件句柄转化为VXD可辩识的句柄（其实应是指向对象的指针）并用IOCTL发给ring0端VXD，钩子函数在排队APC后调用_VWIN32_WaitSingleObject在事件的 VXD句柄上等待查毒的完成，最后由ring3客户程序在查毒完毕后调用WIN32 API--SetEvent来解除钩子函数的等待。
当然，这里面存在着一个很可怕的问题：如果你按照的我说的那样去做，你会发现它会在一端时间内工作正常，但时间一长，系统就被挂起了。就连驱动编程大师Walter Oney在其著作《System Programming For Windows 95》的配套源码的说明中也称其APC例程在某些时候工作会不正常。而微软的工程师声称文件操作请求是不能被中断掉的，你不能在驱动中阻断文件操作并依赖于ring3的反馈来做出响应。网上关于这个问题也有一些讨论，意见不一：有人认为当系统DLL--KERNEL32在其调用ring0处理文件请求时拥有一个互斥量（MUTEX），而在某些情况下为了处理APC要拥有同样的互斥量，所以死锁发生了；还有人认为尽管在WIN9X下32位线程是抢先多任务的，但Win16子系统是以协作多任务来运行的。为了能平滑的运行老的16位程序，它引入了一个全局的互斥量--Win16Mutex。任何一个16位线程在其整个生命周期中都拥有Win16Mutex而32位线程当它转化成16位代码也要攫取此互斥量，因为WIN9X内核是16位的,如 Knrl386.exe,gdi.exe。如果来自于拥有Win16Mutex的线程的文件请求被阻塞，系统将陷入死锁状态。这个问题的正确答案似乎在没有得到WIN9X源码的之前永远不可能被证实，但这是我们实时监控的关键，所以必须解决。
我通过跟踪WIN95文件操作的流程，并反复做实验验证，终于找到了一个比较好的解决办法：在拦截到文件请求还没有排队APC之前我们通过Get_Cur_Thread_Handle取得当前线程的ring0tcb，从中找到TDBX，再在TDBX中取得ring3tcb根据其结构，我们从偏移44H处得到Flags域值，我发现如果它等于10H和20H时容易导致死锁，这只是一个实验结果，理由我也说不清楚，大概是这样的文件请求多来自于拥有Win16Mutex的线程，所以不能阻塞；另外一个根本的解决方法是在调用_VWIN32_WaitSingleObject时指定超时，如果在指定时间里没有收到ring3的唤醒信号，则自动解除等待以防止死锁的发生。
以上对WIN9X下的实时监控的主要技术都做了详细的阐述。当然，还有一部分关于VXD的结构，编写和编译的方法由于篇幅的关系不可能在此一一说明。需要了解更详细内容的，请参看Walter Oney的著作《System Programming For Windows 95》，此书尚有台湾候俊杰翻译版《Windows 95系统程式设计》。
3.3.2程序结构与流程
以下的程序结构与流程分析来自一著名反病毒软件的WIN9X实时监控虚拟设备驱动程序Hooksys.vxd：
1.当VXD收到来自VMM的ON_SYS_DYNAMIC_DEVICE_INIT消息--需要注意这是个动态VXD，它不会收到系统虚拟机初始化时发送的Sys_Critical_Init, Device_Init和Init_Complete控制消息--时，它开始初始化一些全局变量和数据结构，包括在堆上分配内存（HeapAllocate），创建备用，历史记录，打开文件，等待操作，关闭文件5个双向循环链表及用于链表操作互斥的5个信号量（调用 Create_Semaphore），同时将全局变量_gNumOfFilters即文件名过滤项个数设置为0。
2.当VXD收到来自VMM的ON_W32_DEVICEIOCONTROL消息时，它会从入口参数中取得用户程序利用 DeviceIoControl传送进来的IO控制代码（IOCtlCode），以此判断用户程序的意图。和Hooksys.vxd协同工作的ring3 级客户程序guidll.dll会依次向Hooksys.vxd发送IO控制请求来完成一系列工作，具体次序和代码含义如下：
83003C2B：将guidll取得的操作系统版本传给驱动（保存在iOSversion变量中），根据此变量值的不同，从ring0tcb结构中提取某些域时将采用不同的偏移，因为操作系统版本不同会影响内核数据结构。
83003C1B：初始化后备链表，将guidll传入的用OpenVxdHandle转换过的一组事件指针保存在每个链表元素中。
83003C2F：将guidll取得的驱动器类型值传给驱动（保存在DriverType变量中），根据此变量值的不同，调用VWIN32_WaitSingleObject设置不同的等待超时值，因为非固定驱动器的读写时间可能会稍长些。
83003C0F：保存guidll传送的用户指定的拦截文件的类型，其实这个类型过滤器在查毒模块中已存在，这里再设置显然是为了提高处理效率：它确保不会将非指定类型文件送到ring3级查毒模块，节省了通信的开销。经过解析的各文件类型过滤块指针将保存在 _gaFileNameFilterArra数组中，同时更新过滤项个数_gNumOfFilters 变量的值。
83003C23：保存guidll中等待查杀打开文件的APC函数地址和当前线程KTHREAD指针。
83003C13：安装系统文件钩子，启动拦截文件操作的钩子函数FilemonHookProc的工作。
83003C27：保存guidll中等待查杀关闭文件的APC函数地址和当前线程KTHREAD指针。
83003C17：卸载系统文件钩子，停止拦截文件操作的钩子函数FilemonHookProc的工作。
以上列出的IO控制代码的发出是固定，而当钩子函数启动后，还会发出一些随机的控制代码：
83003C07：驱动将打开文件链表的头元素即最先的请求打开的文件删除并插入到等待链表尾部，同时将元素的用户空间地址传送至ring3级等待查杀打开文件的APC函数中处理。
83003C0B：驱动将关闭文件链表的头元素即最先的请求关闭的文件删除并插入到备用链表尾部，同时将元素中的文件名串传送至ring3级等待查杀关闭文件的APC函数中处理
83003C1F：当查得关闭文件是病毒时，更新历史记录链表。
下面介绍钩子函数和guidll中等待查杀打开文件的APC函数协同工作流程，写文件和关闭文件的处理与之类似：
当文件请求进入钩子函数FilemonHookProc后，它先从入口参数中取得被执行的函数的代号并判断其是否为打开操作（IFSFN_OPEN 24H），若非则马上将这个IRQ向下传递，即构造入口参数并调用保存在PrevIFSHookProc中前一个钩子函数；若是则程序流程转向打开文件请求的处理分支。分支入口处首先要判断当前进程是否是我们自己，若是则必须放过去，因为查毒模块中要频繁的进行文件操作，所以拦截来自自身的文件请求将导致严重的系统死锁。接下来是从堆栈参数中取得完整的文件路径名并通过保存的文件类型过滤阵列检查其是否在拦截类型之列，如通过则进一步检查文件是否是以下几个须放过的文件之一：SYSTEM.DAT，USER.DAT，\PIPE\。然后查找历史记录链表以确定该文件是否最近曾被检查并记录过，若在历史记录链表中找到关于该文件的记录并且记录未失效即其时间戳和当前系统时间之差不得大于1F4h，则可直接从记录中读取查毒结果。至此才进入真正的检查打开文件函数_RAVCheckOpenFile，此函数入口处先从备用，等待或关闭链表头部摘得一空闲元素（_GetFreeEntry）并填充之（文件路径名域等）。接着通过一内核未公开的数据结构中的值（ring3tcb->Flags）判断可否对该文件请求排队APC。如可则将空闲元素加入打开文件链表尾部并排队一个ring3级检查打开文件函数的APC。然后调用_VWIN32_WaitSingleObject在空闲元素中保存的一个事件对象上等待ring3查毒的完成。当钩子函数挂起不久后，ring3的APC函数得到执行：它会向驱动发出一IO控制码为83003C07的请求以取得打开文件链表头元素即保存最先提交而未决的文件请求，驱动可以将内核空间中元素的虚拟地址直接传给它而不必考虑将之重新映射。实际上由于WIN9X内核空间没有页保护因而ring3级程序可以直接读写之。接着它调用RsEngine.dll中的fnScanOneFile函数进行查毒并在元素中设置查毒结果位，完毕后再对元素中保存的事件对象调用SetEvent唤醒在此事件上等待的钩子函数。被唤醒的钩子函数检查被ring3查毒代码设置的结果位以此决定该文件请求是被采纳即继续向下传递还是被取消即在EAX中放入-1后直接返回，同时增加历史记录。
以上只是钩子函数与APC函数流程的一个简单介绍，其中省略了诸如判断固定驱动器，超时等内容，具体细节请参看guidll.dll和hooksys.vxd的反汇编代码注释。
3.当VXD收到来自VMM的ON_SYS_DYNAMIC_DEVICE_EXIT消息时，它释放初始化时分配的堆内存（HeapFree），并清除5个用于互斥的信号量（Destroy_Semaphore）。
3.3.3HOOKSYS.VXD逆向工程代码剖析
在剖析代码之前有必要介绍一下逆向工程的概念。逆向工程（Reverse Engineering）是指在没有源代码的情况下对可执行文件进行反汇编试图理解机器码本身的含义。逆向工程的用途很多，如摘掉软件保护，窥视其设计和编写技术，发掘操作系统内部奥秘等。本文中我们用到的不少未公开数据结构和服务就是利用逆向的方法得到的。逆向工程的难度可想而知：一个1K大小的exe 文件反汇编后就有1000行左右，而我们要逆向的3个文件加起来有80多K，总代码量是8万多行。所以必须掌握一定的逆向技巧，否则工作起来将是非常困难的。
首先要完成逆向工作，必须选择优秀的反汇编及调试跟踪工具。IDA（The Interactive Disassembler）是一款功能强大的反汇编工具：它以交互能力强而著称，允许使用者增加标签，注释及定义变量，函数名称；另外不少反汇编工具对于特殊处理的反逆向文件，如导入节损坏等显得无能为力，但IDA仍可胜任之。当文件被加过壳或插入了干扰指令时就需要使用调试工具进行动态跟踪。Numega公司的Softice是调试工具中的佼佼者：它支持所有类型的可执行文件，包括vxd和sys驱动程序，能够用热键实时呼出，可对代码执行，内存和端口访问设置断点，总之功能非常之强大以至于连微软总裁比尔盖茨对此都惊叹不已。
其次需要对编译器常用的编译结构有一定了解，这样有助于我们理解代码的含义。
如下代码是MS编译器常用的一种编译高级语言函数的形式：
0001224A push ebp ；保存基址寄存器
0001224B mov ebp, esp
0001224D sub esp, 5Ch ；在堆栈留出局部变量空间
00012250 push ebx
00012251 push esi
00012252 push edi
......
0001225B lea edi, [ebp-34h] ；引用局部变量
......
0001238D mov esi, [ebp+08h] ；引用参数
......
00012424 pop edi
00012425 pop esi
00012426 pop ebx
00012427 leave
00012428 retn 8 ；函数返回
如下代码是MS编译器常用的一种编译高级语言取串长度的形式：
0001170D lea edi, [eax+1Ch] ；串首地址指针
00011710 or ecx, 0FFFFFFFFh ；将ecx置为-1
00011713 xor eax, eax ；扫描串结束符号（NULL）
00011715 push offset 00012C04h ；编译器优化
0001171A repne scasb ；扫描串结束符号位置
0001171C not ecx ；取反后得到串长度
0001171E sub edi, ecx ；恢复串首地址指针
最后一点是必须要有坚忍的毅力和清晰的头脑。逆向工程本身是件痛苦的工作：高级语言源代码中使用的变量和函数名字在这里仅是一个地址，需要反复调试琢磨才能确定其含义；另外编译器优化更为我们理解代码增加了不少障碍，如上例中那句压栈指令是将后面函数调用时参数入栈提前放置。所以毅力和头脑二者缺一不可。
以下进入hooksys.vxd代码剖析，由于代码过于庞大，我只选择有代表性且精彩的部分进行介绍。代码中的变量和函数及标签名是我分析后自己添加的，可能会与原作者的意图有些出入。
3.3.3.1钩子函数入口代码
C00012E0 push ebp
C00012E1 mov ebp, esp
C00012E3 sub esp, 11Ch
C00012E9 push ebx
C00012EA push esi
C00012EB push edi
C00012EC mov eax, [ebp+arg_4] ； 被执行的函数的代号
C00012EF mov [ebp+var_11C], eax
C00012F5 cmp [ebp+var_11C], 1 ； IFSFN_WRITE
C00012FC jz writefile
C0001302 cmp [ebp+var_11C], 0Bh ； IFSFN_CLOSE
C0001309 jz closefile
C000130F cmp [ebp+var_11C], 24h ； IFSFN_OPEN
C0001316 jz short openfile
C0001318 jmp irqpassdown
钩子函数入口处，堆栈参数分布如下：
ebp+00h -> 保存的EBP值.
ebp+04h -> 返回地址.
ebp+08h -> 提供这个API要调用的FSD函数的的地址
ebp+0Ch -> 提供被执行的函数的代号
ebp+10h -> 提供了操作在其上执行的以1为基准的驱动器代号（如果UNC为-1)
ebp+14h -> 提供了操作在其上执行的资源的种类。
ebp+18h -> 提供了用户串传递其上的代码页
ebp+1Ch -> 提供IOREQ结构的指针。
钩子函数利用[ebp+0Ch]中保存的被执行的函数的代号来判断该请求的类型。同时它利用[ebp+0Ch]中保存的IOREQ结构的指针从该结构中偏移0ch处path_t ir_ppath域取得完整的文件路径名称。
3.3.3.2取得当前进程名称代码
C0000870 push ebx
C0000871 push esi
C0000872 push edi
C0000873 call VWIN32_GetCurrentProcessHandle ；在eax中返回ring0 PDB（进程数据库）
C0000878 mov eax, [eax+38h] ；HTASK W16TDB
；偏移38h处是Win16任务数据库选择子
C000087B push 0 ；DWORD Flags
C000087D or al,
C000087F push eax ；DWORD Selector
C0000880 call Get_Sys_VM_Handle@0
C0000885 push eax ；取得系统VM的句柄 VMHANDLE hVM
C0000886 call _SelectorMapFlat ；将选择子基址映射为平坦模式的线形地址
C000088B add esp, 0Ch
C000088E cmp eax, 0FFFFFFFFh ；映射错误
C0000891 jnz short loc_C0000899
......
C0000899 lea edi, [eax+0F2h] ；从偏移0F2h取得模块名称
；char TDB_ModName[8]
3.3.3.3通信部分代码
hooksys.vxd中代码：
C00011BC push ecx ；客户程序的ring0线程句柄
C00011BD push ebx ；传入APC的参数
C00011BE push edx ；ring3级APC函数的平坦模式地址
C00011BF call _VWIN32_QueueUserApc ；排队APC
C00011C4 mov eax, [ebp+0Ch] ；事件对象的ring0句柄
C00011C7 push eax
C00011C8 call _VWIN32_ResetWin32Event；设置事件对象为无信号态
......
C00011E7 mov eax, [ebp+0Ch]
C00011EA push 3E8h ；超时设置
C00011EF push eax ；事件对象的ring0句柄
C00011F0 call _VWIN32_WaitSingleObject ；等待ring3查毒的完成
guidll.dll中代码：APC函数入口：
10001AD1 mov eax, hDevice ；取得设备句柄
10001AD6 lea ecx, [esp+4]
10001ADA push 0
10001ADC push ecx ；返回字节数
10001ADD lea edx, [esp+8]
10001AE1 push 4 ；输出缓冲区大小
10001AE3 push edx ；输出缓冲区指针
10001AE4 push 0 ；输入缓冲区大小
10001AE6 push 0 ；输入缓冲区指针
10001AE8 push 83003C07h ；IO控制代码
10001AED push eax ；设备句柄
10001AEE call ds:DeviceIoControl
10001AF4 test eax, eax
10001AF6 jz short loc_10001B05
10001AF8 mov ecx, [esp+0] ；得到打开文件链表头元素
10001AFC push ecx
10001AFD call ScanOpenFile ；调用查毒函数
ScanOpenFile函数中：1000185D call ds:fnScanOneFile ；调用真正查毒库导出函数
10001863 mov edx, hMutex
10001869 add esp, 8
1000186C mov esi, eax ；查毒结果
1000186E push edx
1000186F call ds:ReleaseMutex
10001875 test esi, esi ；检查结果
10001877 jnz short OpenFileIsVirus ；如发现病毒则跳到OpenFileIsViru进一步处理
10001879 mov eax, [ebp+10h] ；事件对象的ring3句柄
1000187C mov byte ptr [ebp+16h], 0 ；设置元素中的结果位为无病毒
10001880 push eax
10001881 call ds:SetEvent ；设置事件对象为有信号态唤醒钩子函数
3.4 WINNT/2000下的病毒实时监控
3.4.1实现技术详解
WINNT/2000下病毒实时监控的实现主要依赖于NT内核模式驱动编程，拦截IRP，驱动与ring3下客户程序的通信（命名的事件与信号量对象）三项技术。程序的设计思路和大体流程与前面介绍的WIN9X下病毒实时监控非常相似，只是在实现技术由于运行环境的不同将呈现很大的区别。
WINNT/2000下不再支持VXD，我将在后面剖析的hooksys.sys其实是一种称为NT内核模式设备驱动的驱动程序。这种驱动程序无论从其结构还是工作方式都与VXD有很大不同。比较而言，NT内核模式设备驱动的编写比VXD难度更大：因为它要求编程者熟悉 WINNT/2000的整体架构和运行机制，NT/2000是纯32位微内核操作系统，与WIN9X有很大区别；能灵活使用内核数据结构，如驱动程序对象，设备对象，文件对象，IO请求包，执行体进程/线程块，系统服务调度表等。另外编程者在编程时还需注意许多重要事项，如当前系统运行的IO请求级，分页/非分页内存等。
这里首先介绍几个重要的内核数据结构，它们在NT内核模式设备驱动的编程中经常被用到，包括文件对象，驱动程序对象，设备对象，IO请求包（IRP），IO堆栈单元（IO_STACK_LOCATION）：
文件明显符合NT中的对象标准：它们是两个或两个以上用户态进程的线程可以共享的系统资源；它们可以有名称；它们被基于对象的安全性所保护；并且它们支持同步。对于用户态受保护的子系统，文件对象通常代表一个文件，设备目录，或卷的打开实例；而对于设备和中间型驱动，文件对象通常代表一个设备。文件对象结构中的域大部分是透明的驱动可以访问的域包括：
PDEVICE_OBJECT DeviceObject：指向文件于其上被打开的设备对象的指针。
UNICODE_STRING FileName：在设备上被打开的文件的名字，如果当由DeviceObject代表的设备被打开时此串长度（FileName.Length）为0。
驱动程序对象代表可装载的内核模式驱动的映象，当驱动被加载至系统中时，有I/O管理器负责创建。指向驱动程序对象的指针将作为一个输入参数传送到驱动的初始化例程（DriverEntry），再初始化例程（Reinitialize routines）和卸载例程（Unload routine）。驱动程序对象结构中的域大部分是透明的，驱动可以访问的域包括：
PDEVICE_OBJECT DeviceObject：指向驱动创建的设备对象的指针。当在初始化例程中成功调用IoCreateDevice后这个域将被自动更新。当驱动卸载时，它的卸载例程将使用此域和设备对象中NextDevice域调用IoDeleteDevice来清除驱动创建的每个设备对象。
PDRIVER_INITIALIZE DriverInit：由I/O管理器设置的初始化例程（DriverEntry）入口地址。该例程负责创建驱动程序操作的每个设备的设备对象，需要的话还可以在设备名称和设备对用户态可见名称间创建符号链接。同时它还把驱动程序各例程入口点填入驱动程序对象相应的域中。
PDRIVER_UNLOAD DriverUnload：驱动程序的卸载例程入口地址。
PDRIVER_DISPATCH MajorFunction[IRP_MJ_MAXIMUM_FUNCTION+1]：一个或多个驱动程序调度例程入口地址数组。每个驱动必须在此数组中为驱动处理的IRP_MJ_XXX请求集设置至少一个调度入口，这样所有的IRP_MJ_XXX请求都会被I/O管理器导入同一个调度例程。当然，驱动程序也可以为每个IRP_MJ_XXX请求设置独立的调度入口。
当然，驱动程序中可能包含的例程将远不止以上列出的。比如启动I/O例程，中断服务例程（ISR），中断服务DPC例程，一个或多个完成例程，取消I/O例程，系统关闭通知例程，错误记录例程。只不过我们将要剖析的hooksys.sys中只用到例程中很少一部分，故其余的不予详细介绍。
设备对象代表已装载的驱动程序为之处理I/O请求的一个逻辑，虚拟或物理设备。每个NT内核模式驱动程序必须在它的初始化例程中一次或多次调用IoCreateDevice来创建它支持的设备对象。例如tcpip.sys在其DriverEntry中就创建了3个共用此驱动的设备对象： Tcp，Udp，Ip。目前有一种比较流行的称为WDM（Windows Driver Model）的驱动程序，在大多数情况下，其二进制映像可以兼容WIN98和WIN2000(32位版本)。WDM与NT内核模式驱动程序的主要区别在于如何创建设备：在WDM驱动程序中，即插即用（PnP）管理器告知何时向系统中添加一个设备，或者从系统中删除设备。WDM驱动程序有一个特殊的 AddDevice例程，PnP管理器为共用该驱动的每个设备实例调用该函数；而NT内核模式驱动程序需要做大量额外的工作，它们必须探测自己的硬件，为硬件创建设备对象(通常在DriverEntry中)，配置并初始化硬件使其正常工作。设备程序对象结中的域大部分是透明的，驱动可以访问的域包括：
PDRIVER_OBJECT DriverObject：指向代表驱动程序装载映象的驱动程序对象的指针。
所有I/O都是通过I/O请求包（IRP）驱动的。所谓IRP驱动，是指I/O管理器负责在系统的非分页内存中分配一定的空间，当接受用户发出的命令或由事件引发后，将工作指令按一定的数据结构置于其中并传递到驱动程序的服务例程。换言之，IRP中包含了驱动程序的服务例程所需的信息指令。IRP有两部分组成：固定部分（称为标题）和一个或多个堆栈单元。固定部分信息包括：请求的类型和大小，是同步请求还是异步请求，用于缓冲I/O的指向缓冲区的指针和由于请求的进展而变化的状态信息。
PMDL MdlAddress：指向一个内存描述符表(MDL)，该表描述了一个与该请求关联的用户模式缓冲区。如果顶级设备对象的Flags域为 DO_DIRECT_IO，则I/O管理器为IRP_MJ_READ或IRP_MJ_WRITE请求创建这个MDL。如果一个 IRP_MJ_DEVICE_CONTROL请求的控制代码指定METHOD_IN_DIRECT或METHOD_OUT_DIRECT操作方式，则 I/O管理器为该请求使用的输出缓冲区创建一个MDL。MDL本身用于描述用户模式虚拟缓冲区，但它同时也含有该缓冲区锁定内存页的物理地址。
PVOID AssociatedIrp.SystemBuffer：SystemBuffer指针指向一个数据缓冲区，该缓冲区位于内核模式的非分页内存中于 IRP_MJ_READ和IRP_MJ_WRITE操作，如果顶级设备指定DO_BUFFERED_IO标志I/O管理器就创建这个数据缓冲区。对于 IRP_MJ_DEVICE_CONTROL操作，如果I/O控制功能代码指出需要缓冲区，则I/O管理器就创建这个数据缓冲区。I/O管理器把用户模式程序发送给驱动程序的数据复制到这个缓冲区，这也是创建IRP过程的一部分。这些数据可以是与WriteFile调用有关的数据，或者是 DeviceIoControl调用中所谓的输入数据。对于读请求，设备驱动程序把读出的数据填到这个缓冲区，然后I/O管理器再把缓冲区的内容复制到用户模式缓冲区。对于指定了METHOD_BUFFERED的I/O控制操作，驱动程序把所谓的输出数据放到这个缓冲区，然后I/O管理器再把数据复制到用户模式的输出缓冲区。
IO_STATUS_BLOCK IoStatus：IoStatus(IO_STATUS_BLOCK)是一个仅包含两个域的结构，驱动程序在最终完成请求时设置这个结构。IoStatus.Status域将收到一个NTSTATUS代码。
PVOID UserBuffer：对于METHOD_NEITHER方式的IRP_MJ_DEVICE_CONTROL请求，该域包含输出缓冲区的用户模式虚拟地址。该域还用于保存读写请求缓冲区的用户模式虚拟地址，但指定了DO_BUFFERED_IO或DO_DIRECT_IO标志的驱动程序，其读写例程通常不需要访问这个域。当处理一个METHOD_NEITHER控制操作时，驱动程序能用这个地址创建自己的MDL。
任何内核模式程序在创建一个IRP时，同时还创建了一个与之关联的IO_STACK_LOCATION结构数组：数组中的每个堆栈单元都对应一个将处理该IRP的驱动程序，另外还有一个堆栈单元供IRP的创建者使用。堆栈单元中包含该IRP的类型代码和参数信息以及完成函数的地址。
UCHAR MajorFunction：该IRP的主功能码。这个代码应该为类似IRP_MJ_READ一样的值，并与驱动程序对象中MajorFunction表的某个派遣函数指针相对应。
UCHAR MinorFunction：该IRP的副功能码。它进一步指出该IRP属于哪个主功能类。
PDEVICE_OBJECT DeviceObject：与该堆栈单元对应的设备对象的地址。该域由IoCallDriver函数负责填写。
PFILE_OBJECT FileObject：内核文件对象的地址，IRP的目标就是这个文件对象。
下面简要介绍一下WINNT/2000下I/O请求处理流程。先看对单层驱动程序的同步的I/O请求：I/O请求经过子系统DLL子系统 DLL调用I/O管理器中相应的服务。I/O管理器以IRP的形式给设备驱动程序发送请求。驱动程序启动I/O操作。在设备完成了操作并且中断CPU时，设备驱动程序服务于中断。最后I/O管理器完成I/O请求。以上六步只是一个非常粗略的描述，其中的中断处理和I/O完成阶段比较复杂。
当设备完成了I/O操作后，它将发出中断请求服务。设备中断发生时，处理器将控制权交给内核陷阱处理程序，内核陷阱处理程序将在它的中断调度表（IDT）中定位用于设备的ISR。驱动程序的ISR例程获得控制权后，它通常只在设备IRQL上停留获得设备状态所必需的一段时间，然后停止设备中断，接着它排队一个DPC并清除中断退出操作。IRQL降低至Dispatch/DPC级之前，所有中间优先级中断因而可以得到服务。当DPC例程得到控制时，它将启动设备队列中下一个I/O请求，然后完成中断服务。
当驱动的DPC例程执行完后，在I/O请求可以考虑结束之前还有一些工作要做。如某些情况下，I/O系统必须将存储在系统内存中的数据复制到调用者的虚拟地址空间中，如将操作结果记录在调用者提供的I/O状态块中或执行缓冲I/O的服务将数据返回给调用线程。这样当DPC例程调用I/O 管理器完成原始I/O请求后，I/O管理器会为调用线程调用线程排队一个核心态APC。当线程被调度执行时，挂起的APC被交付。它将把数据和返回状态复制到调用者的地址空间，释放代表I/O操作的IRP，并将调用者的文件句柄或调用者提供的事件或I/O完成端口设置为有信号状态。如果调用者用异步I/O 函数ReadFileEx和WriteFileEx指定了用户态APC，则此时还需要将用户态APC排队。最后可以考虑完成I/O。在文件或其它对象句柄上等待的线程将被释放。
基于文件系统设备的I/O请求处理过程与此是基本相同的，主要区别在于增加一个或多个附加的处理层。例如读文件操作，用户应用程序调用子系统库Kernel32.dll中的API函数ReadFile，ReadFile接着调用系统库Ntdll.dll中的NtReadFile， NtReadFile通过一个陷入指令（INT2E）将处理器模式提升至ring0。然后Ntoskrnl.exe中的系统服务调度程序 KiSystemService将在系统服务调度表中定位Ntoskrnl.exe中的NtWReadFile并调用之，同时解除中断。此服务例程是 I/O管理器的一部分。它首先检查传递给它们的参数以保护系统安全或防止用户模式程序非法存取数据，然后创建一个主功能代码为IRP_MJ_READ的 IRP，并将之送到文件系统驱动程序的入口点。以下的工作会由文件系统驱动程序与磁盘驱动程序分层来完成。文件系统驱动程序可以重用一个IRP或是针对单一的I/O请求创建一组并行工作的关联（associated）IRP。执行IRP的磁盘驱动程序最后可能会访问硬件。对于PIO方式的设备，一个 IRP_MJ_READ操作将导致直接读取设备的端口或者是设备实现的内存寄存器。尽管运行在内核模式中的驱动程序可以直接与其硬件会话，但它们通常都使用硬件抽象层(HAL)访问硬件：读操作最终会调用Hal.dll中的READ_PORT_UCHAR例程来从某个I/O口读取单字节数据。
WINNT/2000下设备和驱动程序的有着明显堆栈式层次结构：处于堆栈最底层的设备对象称为物理设备对象，或简称为PDO，与其对应的驱动程序称为总线驱动程序。在设备对象堆栈的中间某处有一个对象称为功能设备对象，或简称FDO，其对应的驱动程序称为功能驱动程序。在FDO的上面和下面还会有一些过滤器设备对象。位于FDO上面的过滤器设备对象称为上层过滤器，其对应的驱动程序称为上层过滤器驱动程序；位于FDO下面(但仍在 PDO之上)的过滤器设备对象称为下层过滤器，其对应的驱动程序称为下层过滤器驱动程序。这种栈式结构可以使I/O请求过程更加明了。每个影响到设备的操作都使用IRP。通常IRP先被送到设备堆栈的最上层驱动程序，然后逐渐过滤到下面的驱动程序。每一层驱动程序都可以决定如何处理IRP。有时，驱动程序不做任何事，仅仅是向下层传递该IRP。有时，驱动程序直接处理完该IRP，不再向下传递。还有时，驱动程序既处理了IRP，又把IRP传递下去。这取决于设备以及IRP所携带的内容。
通过上面的介绍可得知：如果我们想拦截系统的文件操作，就必须拦截I/O管理器发向文件系统驱动程序的IRP。而拦截IRP最简单的方法莫过于创建一个上层过滤器设备对象并将之加入文件系统设备所在的设备堆栈中。具体方法如下：首先通过IoCreateDevice创建自己的设备对象，然后调用IoGetDeviceObjectPointer来得到文件系统设备（Ntfs，Fastfat，Rdr或Mrxsmb，Cdfs）对象的指针，最后通过IoAttachDeviceToDeviceStack将自己的设备放到设备堆栈上成为一个过滤器。
这是拦截IRP最常用也是最保险的方法，Art Baker的《Windows NT设备驱动程序设计指南》中有详细介绍，但用它实现病毒实时监控却存在两个问题：其一这种方法是将过滤器放到堆栈的最上层，当存在其它上层过滤器时就不能保证过滤器正好在文件系统设备之上；其二由于过滤器设备需要表现的和文件系统设备一样，这样其所有特性都需从文件系统设备中复制。另外文件系统驱动对象中调度例程过滤器驱动必须都支持，这就意味着我们无法使过滤器驱动中的调度例程供自己的ring3级客户程序所专用，因为原本发往文件系统驱动调度例程的 IRP现在都会先从过滤器驱动的调度例程中经过。
所以Hooksys.sys没有使用上述方法。它的方法更简单且更为直接：它先通过ObReferenceObjectByName得到文件系统驱动对象的指针。然后将驱动对象中MajorFunction数组中的打开，关闭，清除，设置文件信息，和写入调度例程入口地址改为 Hooksys.sys中相应钩子函数的入口地址来达到拦截IRP的目的。具体操作细节请参看代码剖析一节。
下面介绍驱动与ring3下客户程序的通信技术。与WIN9X下驱动与ring3下客户程序通信技术相同，NT/2000仍然支持使用 DeviceIoControl实现从ring3到ring0的单向通信，但从ring0通过排队APC来唤醒ring3线程的方法却无法使用了。原因是我没有找到一个公开的函数来实现（Walter Oney的书中说存在一个未公开的函数实现从ring0排队APC）。其实不通过APC我们也可以通过命名的事件/信号量对象来实现双向唤醒，而且这可能比APC更为可靠些。
对象管理器在Windows NT/2000内核中占了极其重要的位置，其一个最主要职能是组织管理系统内核对象。在Windows NT/2000中，内核对象管理器大量引入了C++面向对象的思想，即所有内核对象都封装在对象管理器内部，除对象管理器自己以外，对其他所有想引用内核对象结构成员的子系统都是不透明的，也即都需通过对象管理器访问这些结构。Microsoft极力推荐内核驱动代码遵循这一原则（用户态代码根本不能直接访问这些数据），它提供了一系列以Ob开头的例程供我们使用。
内核已命名对象存于系统全局命名内核区，与传统的DOS目录和文件组织方式相似，对象管理器也采用树状结构管理这些对象，这样可以快速检索内核对象。当然使用这种树状结构组织内核已命名对象，还有另一个优点，那就是使所有已命名对象组织的十分有条理，如设备对象处于\Device下，而对象类型名称处于\ObjectTypes下等等。再者这样也能达到使用户态进程仅能访问\??与\BaseNamedObjects下的对象，而内核态代码则没有任何限制的目的。至于系统内部如何组织管理这些已命名对象，其实Windows NT/2000内部由内核变量ObpRootDirectoryObject指向的Directory对象代表根目录，使用哈希表(HashTable) 来组织管理这些命名内核对象。
Hooksys.sys中使用命名的信号量来唤醒ring3级线程。具体做法如下：首先在guidll.dll中调用 CreateSemaphore创建一个命名信号量Hookopen并设为无信号状态，同时调用CreateThread创建一个线程。线程代码的入口处通过调用WaitForSingleObject在此信号量上等待被ring0钩子函数唤醒查毒。驱动程序这边则在初始化过程中通过未公开的例程 ObReferenceObjectByName（\BaseNamedObjects\Hookopen）得到命名信号量对象Hookopen的指针，当它拦截到文件打开请求时调用KeReleaseSemaphore将Hookopen置为有信号状态唤醒ring3级等待检查打开文件的线程。其实 guidll.dll共创建了两个命名信号量，还有一个Hookclose用于唤醒ring3级等待检查关闭文件的线程。
guidll.dll中使用命名的事件来唤醒暂时挂起等待查毒完毕的ring0钩子函数。具体做法如下：Hooksys.sys在其初始化过程中通过ZwCreateEvent函数创建一组命名事件对象（此处必须合理设置安全描述符，否则ring3线程将无法使用事件句柄）并得到其句柄，同时通过ObReferenceObjectByHandle得到句柄引用的事件对象的指针。然后Hooksys.sys将这一组事件句柄和指针对以及事件名保存在备用链表的每个元素中：ring3使用句柄，ring0使用指针。当钩子函数拦截到文件请求时它首先唤醒ring3查毒线程，然后马上调用 KeWaitForSingleObject在一个事件\BaseNamedObjects\Hookxxxx上等待查毒的完成。而被唤醒的ring3查毒线程通过OpenEventA函数由事件名字得到其句柄，在结束查毒后发出一个SetEvent调用将事件置为有信号状态从而唤醒ring0挂起的钩子函数。当然，以上讨论仅限于打开文件操作，钩子函数在拦截到其它文件请求时并不调用KeWaitForSingleObject等待查毒的完成，而是唤醒 ring3查毒线程后直接返回；相应的ring3查毒线程也就不必在查毒完成后调用SetEvent进行远程唤醒。
另外在编写NT内核模式驱动程序时还必须注意一些事项。首先是中断请求级（IRQL），这是在进行NT驱动编程时特别值得注意的问题。每个内核例程都要求在一定的IRQL上运行，如果在调用时不能确定当前IRQL在哪个级别，则可调用KeGetCurrentIrql获取当前的IRQL 值并进行判断。例如欲获得指向当前进程Eprocess的指针可以考虑先判断当前的IRQL，如大于等于DISPATCH_LEVEL时可调用 IoGetCurrentProcess；而当IRQL小于调度/延迟过程调用级别时（DISPATCH_LEVEL/DPC）则可使用 PsGetCurrentProcessId和PsLookupProcessByProcessId。其次要注意的问题是分页/非分页内存。由于执行在提升的IRQL级上时系统将不能处理页故障，因为系统在APC级处理页故障，因而这里总的原则是：执行在高于或等于DISPATCH_LEVEL级上的代码绝对不能造成页故障。这也意味着执行在高于或等于DISPATCH_LEVEL级上的代码必须存在于非分页内存中。此外，所有这些代码要访问的数据也必须存在于非分页内存中。最后是同步互斥问题，这对于如病毒实时监控等系统范围共享的驱动程序尤显重要。虽然在Hooksys中没有创建多线程（PsCreateSystemThread），但由于它挂接了系统文件钩子，系统中所有线程的文件请求都会从Hooksys中经过。当一个线程的文件请求被处理过程中Hooksys会去访问一些全局共享的数据，如过滤器，历史记录等，有可能在访问进行到一半时该线程由于某种原因被抢占了，结果是其它线程的文件请求经过时Hooksys访问的共享数据将是错误的。为此驱动程序必须合理使用自旋锁，互斥量，资源等内核同步对象对共享全局数据的所有线程进行同步。
3.4.2程序结构与流程
以下的程序结构与流程分析来自一著名反病毒软件的WINNT/2000实时监控NT内核模式设备驱动程序Hooksys.sys：
1.初始化例程（DriverEntry）：调用_GetProcessNameOffset取得进程名在Eprocess中的偏移。初始化备用，打开文件等待操作，关闭文件，历史记录5个双向循环链表及用于链表操作互斥的4把自旋锁和1个快速互斥量。将全局变量_IrqCount （IRP记数）设置为0。创建卸载保护用事件对象。为文件名过滤数组初始化同步用资源变量。在系统全局命名内核区中检索Hookopen和 Hookclose两个命名信号量（ _CreateSemaphore）。为备用（_AllocateBuffer）和历史记录（_AllocatHistoryBuf）链表在系统非分页池中分配空间，同时创建一组命名事件对象Hookxxxx并保存至备用链表的每个元素中（_CreateOneEvent）。创建设备，设置驱动例程入口，为设备建立符号连接。创建磁盘驱动器设备对象指针（_QuerySymbolicLink）和文件系统驱动程序对象指针（_HookSys）列表。
2.打开例程（IRP_MJ_CREATE）：将备用链表用系统非分页内存（首地址保存在_SysBufAddr中）映射到用户空间中（保存在_UserBufAddr）以便从用户态可以直接访问这段内存（_MapMemory）。
3.设备控制例程（IRP_MJ_DEVICE_CONTROL）：它会从入口IRP当前堆栈单元中取得用户程序利用 DeviceIoControl传送进来的IO控制代码（IoControlCode），以此判断用户程序的意图。和Hooksys.sys协同工作的 ring3级客户程序guidll.dll会依次向Hooksys.sys发送IO控制请求来完成一系列工作，具体次序和代码含义如下：
83003C2F：将guidll取得的驱动器类型值传给驱动（保存在DriverType变量中），根据此变量值的不同，设置不同的等待（KeWaitForSingleObject）超时值，因为非固定驱动器的读写时间会稍长些。
83003C0F：保存guidll传送的用户指定的拦截文件的类型，其实这个类型过滤器在查毒模块中已存在，这里再设置显然是为了提高处理效率：它确保不会将非指定类型文件送到ring3级查毒模块，节省了通信的开销。经过解析的各文件类型过滤块指针将保存在 _gaFileNameFilterArra数组中，同时更新过滤项个数_gNumOfFilters变量的值。
83003C13：修改文件系统驱动程序对象调度例程入口，启动拦截文件操作的钩子函数的工作。
83003C17：恢复文件系统驱动程序原调度例程入口，停止拦截文件操作的钩子函数工作。
以上列出的IO控制代码的发出是固定，而当钩子函数启动后，还会发出一些随机的控制代码：
83003C07：驱动将打开文件链表的头元素即最先的请求打开的文件删除并插入到等待链表尾部，同时将元素的用户空间地址传送至ring3级等待查杀打开文件的线程中处理。
83003C0B：驱动将关闭文件链表的头元素即最先的请求关闭的文件删除并插入到备用链表尾部，同时将元素中的文件名串传送至ring3级等待查杀关闭文件的线程中处理
83003C1F：当查得关闭文件是病毒时，更新历史记录链表。
下面介绍钩子函数_HookCreateDispatch和guidll中等待查杀打开文件的线程协同工作流程，而关闭，清除，设置文件信息，和写入操作的处理与此大同小异：
当文件请求进入钩子函数_HookCreateDispatch后，它首先从入口IRP中定位当前的堆栈单元并从中取得代表此次请求的文件对象。然后判断当前进程是否为我们自己，若是则必须放过去，因为查毒模块中要频繁的进行文件操作，所以拦截来自ravmon的文件请求将导致严重的系统死锁。接下来利用堆栈单元中的文件对象取得完整的文件路径名并确保文件不是：\PIPE\，\IPC。之后查找历史记录链表以确定该文件是否最近曾被检查并记录过，若在历史记录链表中找到关于该文件的记录并且记录未失效即其时间戳和当前系统时间之差不得大于1F4h，则可直接从记录中读取查毒结果。如历史链表中没有该文件的记录则利用保存的文件类型过滤阵列检查文件是否在被拦截的文件类型之列。至此才进入真正的检查打开文件函数 _RAVCheckOpenFile，此函数入口处先从备用，等待或关闭链表头部摘得一空闲元素（_GetFreeEntry）并填充之，如文件路径名域等。接着将空闲元素加入打开文件链表尾部并释放Hookopen信号量唤醒ring3下等待检查打开文件的线程。然后调用 KeWaitForSingleObject在空闲元素中保存的一个事件对象上等待ring3查毒的完成。当钩子函数挂起后，ring3查毒线程得到执行：它会向驱动发出一IO控制码为83003C07的请求以取得打开文件链表头元素即保存最先提交而未决的文件请求，驱动会将元素映射到用户空间中的偏移地址直接传给它。接着它调用RsEngine.dll中的fnScanOneFile函数进行查毒并在元素中设置查毒结果位，完毕后再对元素中保存的事件对象调用SetEvent唤醒在此事件上等待的钩子函数。被唤醒的钩子函数检查被ring3查毒代码设置的结果位以此决定该文件请求是被采纳即调用保存的原调度例程还是被取消即调用IofCompleteRequest直接返回，同时增加历史记录。
以上只是钩子函数与ring3线程流程的一个简单介绍，其中省略了诸如判断固定驱动器，超时等内容，具体细节请参看guidll.dll和hooksys.sys的反汇编代码注释。
4.关闭例程（IRP_MJ_CLOSE）：停止钩子函数工作，恢复文件系统驱动程序原调度入口（_StopFilter）。解除到用户空间的内存映射。
5.卸载例程（DriverUnload）：停止钩子函数工作，恢复文件系统驱动程序原调度入口。删除设备和符号连接。删除初始化时创建的一组命名事件对象Hookxxxx，包括解除指针引用，关闭打开的句柄。释放为MDL（_pMdl），备用链表（_SysBufAddr），历史记录链表（_HistoryBuf）和过滤器分配的内存空间。删除为文件名过滤数组访问同步设置的资源变量（_FilterResource）。解除对系统全局命名内核区中Hookopen和Hookclose两个命名信号量的指针引用。
3.4.3HOOKSYS.SYS逆向工程代码剖析
3.4.3.1取得当前进程名称代码
初始化例程中取得进程名在Eprocess中偏移
00011889 call ds:__imp__IoGetCurrentProcess@0 ；
得到当前进程System的Eprocess指针
0001188F mov edi, eax ；Eprocess基地址
00011891 xor esi, esi ；初始化偏移为0
00011893 lea eax, [esi+edi] ；扫描指针
00011896 push 6 ；进程名长度
00011898 push eax ；扫描指针
00011899 push offset $SG8452 ; "System" ；进程名串
0001189E call ds:__imp__strncmp ；比较扫描指针处是否为进程名
000118A4 add esp, 0Ch ；恢复堆栈
000118A7 test eax, eax ；测试比较结果
000118A9 jz short loc_118B9 ；找到则跳出循环
000118AB inc esi ；增加偏移量
000118AC cmp esi, 3000h ；在12K范围中扫描
000118B2 jb short loc_11893 ；在范围之内则继续比较
钩子函数开始处取得当前进程名
00010D1E call ds:__imp__IoGetCurrentProcess@0 ；得到当前进程System的Eprocess指针
00010D24 mov ecx, _ProcessNameOffset ；取得保存的进程名偏移量
00010D2A add eax, ecx ；得到指向进程名的指针
3.4.3.2启动钩子函数工作代码
000114F4 push 4 ；预先将文件系统驱动对象个数压栈
000114F6 mov esi, offset FsDriverObjectPtrList ；
取得文件系统驱动对象指针列表偏移地址
000114FB pop edi ；用EDI做记数器，初始值为4
000114FC mov eax, [esi] ；取得第一个驱动对象的指针
000114FE test eax, eax ；测试是否合法
00011500 jz short loc_11548 ；不合法则继续下一个修改驱动对象
00011502 mov edx, offset _HookCreateDispatch@8 ；
取得自己的钩子函数的偏移地址
00011507 lea ecx, [eax+38h] ；取得对象中打开调度例程（IRP_MJ_CREATE）偏移
0001150A call @InterlockedExchange@8 ；
原子操作，替换驱动对象中打开调度例程的入口为钩子函数的偏移地址
0001150F mov [esi-10h], eax ；保存原打开调度例程的入口
3.4.3.3映射系统内存至用户空间代码
0001068E push esi ；系统内存大小
0001068F push _SysBufAddr ；系统内存基地址
00010695 call ds:__imp__MmSizeOfMdl@8 ；计算描述系统内存所需内存描述符表（MDL）大小
0001069B push 206B6444h ；调试用标签
000106A0 push eax ；MDL大小
000106A1 push 0 ；在系统非分页内存池中分配
000106A3 call ds:__imp__ExAllocatePoolWithTag@12 ；为MDL分配内存
000106A9 push esi ；系统内存大小
000106AA mov _pMdl, eax ；保存MDL指针
000106AF push _SysBufAddr ；系统内存基地址
000106B5 push eax ；MDL指针
000106B6 call ds:__imp__MmCreateMdl@12 ；初始化MDL
000106BC push eax ；MDL指针
000106BD mov _pMdl, eax ；保存MDL指针
000106C2 call ds:__imp__MmBuildMdlForNonPagedPool@4
；填写MDL后物理页面数组
000106C8 push 1 ；访问模式
000106CA push _pMdl ；MDL指针
000106D0 call ds:__imp__MmMapLockedPages@8 ；映射MDL描述的物理内存页面
......
000106DB mov _UserBufAddr, eax ；保存映射后的用户空间地址
_UserBufAddr 和_SysBufAddr映射到相同的物理地址。
主要参考文献
David A. Solomon, Mark Russinovich 《Inside Microsoft Windows 2000》September 2000
David A. Solomon 《Inside Windows NT》 May 1998
Prasad Dabak，Sandeep Phadke，Milind Borate 《Undocumented Windows NT》October 1999
Matt Pietrek 《Windows 95 System Programming Secrets》 March 1996
Walter Oney 《System Programming for Windows 95》 March 1996
Walter Oney 《Programming the Windows Driver Model》 1999
陆麟 《WINDOWS9X文件读写Internal》2001