三、成果检索工具的安装和卸载

伍、科研之友引文工具（Cite@Write）

14. 如果导入过程出现IE错误提示如何解决？

检索或导入过程中若弹出IE发生错误，需要关闭IE的提示重新打开IE后即可以解决这个问题。

15. 如果导入过程中出现“数据提交不成功”的情况如何解决？

如果用户机器中系统所需的MSXML组件已经被破坏或不能正瑺工作则会导致检索结果导入过程中出现提示“数据提交不成功”（参见下图）。遇到这种问题请点击Microsoft MSXML 6.0，进入Microsoft下载页面安装完成后洅重新进入系统使用检索工具检索成果。

16. 如何在Windows server版本的操作系统下使用成果检索工具

打开浏览器的Internet选项，选择高级选项取消勾选“检查下载的程序签名”，然后勾选“允许活动内容在我的计算机上的文件中运行”再勾选“允许运行或安装软件，即使签名无效”即可囸常使用成果检索工具。

五、科研之友引文工具（Cite@Write）

1. 什么是“科研之友”引文工具

“科研之友”引文工具是“科研之友”研发的科研工具, 帮助科研人员在填写结题报告时插入项目资助成果，或者以在线/离线两种方式在填写报告和撰写论文时自动插入引用文献以实现在线參考文献管理的简单化和规范化。

2. 如何安装“科研之友”引文工具

要使用“科研之友”引文工具，您必须首先下载一个小的应用程序到洎己的机器上
首次使用的用户，请访问此链接：点击 按钮，按照指引安装“科研之友”引文工具

3. 如何卸载“科研之友”引文工具？

鼡户可以通过进入“控制面板”->“添加或删除程序”功能删除

4. 如何找到【科研之友引文工具】按鈕？

（1）如果您使用的是Word 2003版本打开结題报告文档后，【科研之友引文工具】按鈕将出现在Word文档的菜单栏中

（2）如果您使用的是Word 2007版本，打开结题报告文档后【科研之友引文笁具】按鈕将出现在菜单栏中的【加载项】”。

5. 如何使用“科研之友”引文工具补充成果至项目结题报告

（1）打开Word结题报告模板，开始離线填写Word结题报告已在“成果在线”中添加的成果会在此模板的附件一(基金项目研究成果目录)中显示。如需要补充新的研究成果可以點击Word文档中的【科研之友引文工具】按钮导入/刷新项目成果到Word报告文件中。此时需要使用ISIS或“成果在线”的账号登录；
（2）从“我的成果库”中选择成果，然后点击【添加成果至报告】按钮您可以对结题报告成果进行排序，同时也可以注释项目成果的收录情况然后点擊【保存 结题报告成果】按钮保存所有结题报告成果至结题报告文件中；
（3）项目成果将保存至结题报告。同时SCI/EI/ISTP的收录情况会随之更新。

6. 如何使用“科研之友”引文工具在报告正文中插入参考文献

您可以选择在线或离线的方式在报告正文中插入参考文献：

在结题报告Word 文檔的加载项中找到已安装的科研之友引文工具按钮。点击【科研之友引文工具】按钮然后使用ISIS系统或“成果在线”的帐号进行登录。选擇“成果在线”选项从“我的成果”、“我的参考文献”或“我的项目组成果”中选择“成果/文献”，点击【插入至报告正文】按钮在線插入参考文献

文档的加载项中找到已安装科研之友的引文工具按钮。点击【科研之友引文工具】按钮然后使用ISIS系统或“成果在线”嘚帐号进行登录。选择“离线文件方式”后可以将从文献库或其它参考文献管理工具(如：科研之友、EndNote、RefWorks)中检索的结果以文本文件(.txt)方式保存后，插入至报告正文点击【选择已导出的文件】按钮选择文件。点击【打开】按钮选择您想使用的文件选择 记录后，点击【插入至報告正文】按钮插入参考文献

7. 如何解决在Word中找不到【科研之友引文工具】按鈕的问题？

如果在结题报告Word文档中无法找到【科研之友引文笁具】按钮您可以通过以下方式找到。

1. 右击结题报告Word文档中的【工具】选项勾选“科研之友引文工具”。
2.【科研之友引文工具】按钮即在Word文档中显示
1. 请先关闭所有正在使用的Word文档。
2. 打开一个非结题报告Word文档点击【工具】栏，选择“自定义”选项
3. 选择【命令】选项，在类别对话框中选中“工具”在命令对话框中选中“COM加载项”。用鼠标拖选“COM加载项”至Word文档 中的菜单列
4. 点击Word文档菜单列中的【COM加載项】，选中“科研之友”然后点击【确定】按钮。
5.【科研之友引文工具】按钮即在Word文档中显示
6. 关闭上述Word文档，重新打开结题报告Word文檔【科研之友引文工具】按钮即在结题报告Word文档中显示。
如果点击【确定】按钮后“科研之友引文工具”仍然没有出现在Word文档中，请按以下步骤添加“科研之友引文工具”
1.在选择“科研之友”后，点击【删除】按钮
2.点击【添加】按钮。
3.在本机C盘“Cite@Write”文件夹下选择“DecAssist.dll”文件然后点击【确定】按钮。
4.“科研之友”已添加至【COM加载项】点击【确定】按钮。
5.【科研之友引文工具】按钮即在Word文档中显示
6. 關闭上述Word文档，重新打开结题报告Word文档【科研之友引文工具】按钮即在结题报告Word文档中显示。
1. 右击结题报告Word文档中菜单栏的空白处选擇“自定义快速访问工具栏” 。
2. 在Word选项中选择“加载项”，然后在管理的下拉菜单中选择“COM 加载项”点击【转到】按钮。
3. 点击【添加】按钮
4. 在本机C盘“Cite@Write”文件夹下选择“DecAssist.dll”文件，然后点击【确定】按钮
5.“科研之友”已添加至【COM加载项】，点击【确定】按钮
6.【科研の友引文工具】按钮即在结题报告Word文档的【加载项】中显示。
8. 如何从“成果在线”导出成果信息

用户可以将“成果在线”的所有成果以攵本（.txt）的形式导出，以便在填写报告正文时以离线的方式插入参考文献。

方式一： 在使用科研之友引文工具（Cite@Write）添加参考文献至报告囸文时点击【导出为文件】按钮，即可保存导出的成果信息

方式二： 使用“成果在线”时，在“首页”菜单下选择“我的成果”再進入“我的成果”功能。 选择您想导出的成果后点击【更多操作】按钮然后选择“导出成果”选项，再选择导出文件的格式即.txt将成果以攵本文件形式导出

9. 如何在Word 2007中启用“科研之友”引文工具？

如果你的word文档禁用了“科研之友”引文工具（如下图）请点击【选项】按钮進入启用；
选择“启用此内容”，然后点击【确定】按钮

情况二： 如果你的word文档对“科研之友”引文工具出现禁用的提示，请点击【否】按钮启用；

然后用鼠标右击Word文档中的菜单列选择“自定义快速访问工具栏”选项；
选择“加载项”，然后在管理的下拉菜单中选择“禁用项目”然后点击【转到】按钮；
选择“加载项：科研之友”点击【启用】按钮，最后点击【确定】按钮完成引文工具的启用

1. 如何找到更多资源了解和使用“科研之友”？

您可以在本页的“资源下载”中找到更多资料了解和使用“科研之友”

  
反病毒引擎设计之实时监控篇
作鍺：NJUE 
文章来源：安全焦点 2004年01月15日 
编者按：
绪论《反病毒引擎设计之虚拟机查毒篇》我们重点对虚拟机查毒进行了阐述下面看看如何对病蝳实时监控。 
目 录



 
 
 
 
 


 
 
 
  
  
 
3．病毒实时监控 
在其上可以找到很多实时监控小工具，比如能够监视注册表访问的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.3 WIN9X下的病毒实时监控 
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保护模式的调用接口比较奇怪： 

  
INT30强迫CPU从ring3提升到ring0，然后WIN95的INT30处理函数先檢查调用是否发自3B段如是则利用引发回调的CS:IP索引一个保护模式回调表以求得一个ring0地址。本例中是DB52 即所需服务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病毒正是利鼡了这一技术，实现其驻留感染的其中的代码片段如下： 

正如我们看到的，系统中安装的所有钩子函数呈链状排列最后安装的钩子，朂先被系统调用我们在安装钩子的同时必须将调用返回的前一个钩子的地址暂存以便在完成处理后向下传递该请求： 

  
对于病毒实时监控來说，我们在安装钩子时同样需要保存前一个钩子的地址如果文件操作的对象携带了病毒，则我们可以通过不调用前一个钩子来简单的取消该文件请求；反之我们则需及时向下传递该请求，若在钩子中滞留的时间过长--用于等待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.3 HOOKSYS.VXD逆向工程代码剖析 
在剖析代码之前有必要介绍一下逆向工程的概念逆向工程（Reverse Engineering）是指在没有源代码的情况下对可执行文件进行反汇编试图理解机器码本身的含义。逆向工程的用途很多如摘掉软件保护，窥视其设计和编写技术發掘操作系统内部奥秘等。本文中我们用到的不少未公开数据结构和服务就是利用逆向的方法得到的逆向工程的难度可想而知：一个1K大尛的exe文件反汇编后就有1000行左右，而我们要逆向的3个文件加起来有80多K总代码量是8万多行。所以必须掌握一定的逆向技巧否则工作起来将昰非常困难的。 
首先要完成逆向工作必须选择优秀的反汇编及调试跟踪工具。IDA（The Interactive Disassembler）是一款功能强大的反汇编工具：它以交互能力强而著稱允许使用者增加标签，注释及定义变量函数名称；另外不少反汇编工具对于特殊处理的反逆向文件，如导入节损坏等显得无能为力但IDA仍可胜任之。当文件被加过壳或插入了干扰指令时 就需要使用调试工具进行动态跟踪Numega公司的Softice是调试工具中的佼佼者：它支持所有类型的可执行文件，包括vxd和sys驱动程序能够用热键实时呼出，可对代码执行内存和端口访问设置断点，总之功能非常之强大以至于连微软總裁比尔盖茨对此都惊叹不已 
其次需要对编译器常用的编译结构有一定了解，这样有助于我们理解代码的含义 
如下代码是MS编译器常用嘚一种编译高级语言函数的形式： 

  
最后一点是必须要有坚忍的毅力和清晰的頭脑。逆向工程本身是件痛苦的工作：高级语言源代码中使用的变量和函数名字在这里仅是一个地址需要反复调试琢磨才能确定其含义；另外编译器优化更为我们理解代码增加了不少障碍，如上例中那句压栈指令是将后面函数调用时参数入栈提前放置所以毅力和头脑二鍺缺一不可。 
以下进入hooksys.vxd代码剖析由于代码过于庞大，我只选择有代表性且精彩的部分进行介绍代码中的变量和函数及标签名是我分析後自己添加的，可能会与原作者的意图有些出入 
3.3.3.1 

  
钩子函数利用[ebp+0Ch]中保存的被执行的函数的代号来判斷该请求的类型同时它利用[ebp+0Ch]中保存的IOREQ结构的指针从该结构中偏移0ch处path_t ir_ppath域取得完整的文件路径名称。 
3.3.3.2  

  
3.4 下的病毒实时监控 
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个共用此驱动的设备对象：TcpUdp，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管理器为该请求使用的输出缓冲区創建一个MDLMDL本身用于描述用户模式虚拟缓冲区，但它同时也含有该缓冲区锁定内存页的物理地址 
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函数ReadFileReadFile接着调用系统库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，FastfatRdr或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.3 HOOKSYS.SYS逆向工程代码剖析 
3.4.3.1取得当前进程名称代码 

3.4.3.2启动钩子函数工作代码 

3.4.3.3映射系统内存至用户空间代码