下面以Virtual PC 2004为例，介绍一下利用Virtual PC进行Windows内核调试的详细过程。

1，下载并安装Virtual PC 2004，从略。

2，启动Virutal PC Console（控制台），创建一台新的虚拟PC，安装向导的提示配置硬盘、内存等参数。

3，在刚才创建的虚拟PC上安装操作系统，这个操作系统应该是你要调试的Windows版本。比如你想调试你的驱动程序在Windows Server 2003上出现的问题，那么就安装Windows Server 2003。我们以Windows 2000为例。

4，配置虚拟PC的串行口，在Virtual PC的控制台中选择Windows 2000，然后点击Settings按钮弹出设置对话框，然后在左侧的列表中（如下图）选择COM1。

右侧选择Named Pipe选项，即使用命名管道来模拟串行口，然后输入管道的完整名称：\\.\pipe\com_1，com_1可以为其它名称，但是前面的部分应该保持不变。

5，启动虚拟PC中的Windows 2000，然后进入命令行窗口，执行如下命令以便在启动菜单中增加调试选项：

c:

cd\

attrib -r -h

edit boot.ini

然后将其最末一行复制，并加入调试选项，成为为如下状态：

6，在虚拟PC中选择重新启动Windows 2000，当出现启动菜单时，按方向键使其停止自动计时，等待在这里。

7，在主机（debugger）上准备启动WinDbg，考虑每次输入命令行参数太麻烦，所以建议建立一个如下内容的批处理文件，并将其放到与WinDbg.exe同位置的目录中。

windbg -k com:pipe,port=\\.\pipe\com_1

8，运行批处理文件，使其也进入等待状态：

9，切换到虚拟PC窗口，选择带有“Debug Enabled”的一项然后回车启动。

10，切换到WinDbg窗口并观察，如果一切顺利，那么会有如下类似信息输出：

Connected to Windows 2000 2195 x86 compatible target, ptr64 FALSE
Kernel Debugger connection established.
Symbol search path is: SRV*c:\symbols*http://msdl.microsoft.com/download/symbols
Executable search path is:
Windows 2000 Kernel Version 2195 UP Free x86 compatible
Kernel base = 0x80400000 PsLoadedModuleList = 0x8046a4c0
System Uptime: not available

11，见到如上信息就说明WinDbg已经与虚拟PC中运行的Windows 2000成功建立调试对话了。如果想感受一下将Windows控制于股掌之中的快感，那么就按下Ctrl+Break，随着按键发出，Windows 2000会被立刻定住。WinDbg中会显示如下信息：

*******************************************************************************
*                                                                             *
*   You are seeing this message because you pressed either                    *
*       CTRL+C (if you run kd.exe) or,                                        *
*       CTRL+BREAK (if you run WinDBG),                                       *
*   on your debugger machine's keyboard.                                      *
*                                                                             *
*                   THIS IS NOT A BUG OR A SYSTEM CRASH                       *
*                                                                             *
* If you did not intend to break into the debugger, press the "g" key, then   *
* press the "Enter" key now.  This message might immediately reappear.  If it *
* does, press "g" and "Enter" again.                                          *
*                                                                             *
*******************************************************************************
此时WinDbg的命令提示符区会显示一段时间*BUSY*（或者其它无效状态，老本本的WinDbg），这是因为WinDbg在寻找调试符号。

在你非常熟悉以上过程之后，其实可以不完全拘泥以上过程的， 比如可以先让Windows 2000以调试选项运行起来，然后再运行WinDbg。

最后再介绍几种常见的失败情况：

1）启动WinDbg，但是出现下图所示的错误信息，Win32 error 2，即指定的文件名找不到，这是因为虚拟PC还没有启动，还没有创建这个管道\\.\pipe\com_1， 系统中不存在这样的文件。应该运行虚拟PC，哪怕只到启动选项也可以，便不会再有这个错误了。

　　最近，我了解到一个叫做Sanctuary的相当有趣的安全产品。它能够阻止任何程序的运行-这些程序没有显示在软件列表中-该表中的程序被允许在一个特定的机器上运行。结果，PC用户得到保护而免于各种插件间谍软件、蠕虫和特洛伊木马的侵袭-就算能够进入他/她的计算机，它们也没有机会执行，并因此没有机会对该机器造成任何损害。当然，我觉得这个特征相当有趣；并且，在稍作思考以后，我就有了一个自己的实现。因此，本文将描述如何通过钩住本机API的方式来实现监控一个进程的创建并在系统级上对之进行控制。

　　本文大胆假设，目标进程是以一种用户模式(外壳函数，CreateProcess()，用一系列的本机API调用的手工的进程创建，等等)创建的。尽管从理论上，一个进程能够以内核方式启动；不过从实际来看，如此的可能性是可以忽略不计的，因此我们不必为此担心。为什么？请逻辑地思考一下-为了以内核方式启动一个进程，用户必须装载一个驱动程序，该驱动程序反过来首先要暗示某种用户模式代码的执行。因此，为了防止未被授权程序的执行，我们可以安全地在系统级上以用户模式限制我们自己控制的进程的创建。

　　二、 定义策略

　　首先让我们明确，之所以这样做的目的是为了在系统级上监视和控制进程创建。

　　进程创建是一件相当复杂的事情-它包含相当多的工作(如果你不相信我，可以反汇编CreateProcess()，这样你就会亲眼看到这点)。为了启动一个进程，可以使用下列步骤：

　　1.可执行文件必须被以FILE_EXECUTE存取方式打开。

　　2.可执行映像必须被装载进RAM。

　　3.必须建立进程执行对象(EPROCESS，KPROCESS和PEB结构)。

　　4.必须为新建进程分配地址空间。

　　5.必须建立进程的主线程的线程执行对象(ETHREAD，KTHREAD和TEBstructures)。

　　6.必须为主线程分配堆栈。

　　7.必须建立进程的主线程的执行上下文。

　　8.必须通知Win32子系统有关该新进程的创建情况。

　　为确保这些步骤中的任何一步的成功，所有其前面的步骤必须是成功执行的(你不能够在没有一个可执行区句柄的情况下建立一个可执行进程对象；没有文件句柄的情况下你无法映射一个可执行区，等等)。因此，如果我们决定退出任何这些步骤，所有后面的步骤也会失败，以至于整个进程创建会失败。上面所有的步骤都可以通过调用某些本机API函数的方式来实现，这是可以理解的。因此，为了监视和控制进程创建，我们所有要做的就是钩住这些API函数-它们无法旁路掉要创建一新进程所要执行的代码。

　　我们应该钩住哪些本机API函数呢?尽管NtCreateProcess()似乎是问题的最显然的答案，但是，这个答案是错误的-有可能不需要调用这个函数也可以创建一个新的进程。例如，CreateProcess()可以在不调用NtCreateProcess()的情况下创建与进程相关的内核模式结构.因此，这样以来钩住NtCreateProcess()对我们毫无帮助。

　　为了监视进程的创建，我们必须钩住NtCreateFile()和NtOpenFile()，或者NtCreateSection()之中的一个,-不经调用这些API是绝对无法运行任何可执行文件的。如果我们决定监视对NtCreateFile()和NtOpenFile()的调用，那么我们必须区别开进程创建和常规的文件IO操作。这项任务并不总是那么容易。例如，如果一些可执行文件正在被以FILE_ALL_ACCESS存取方式打开，我们该怎么办？这仅是一个IO操作还是一个进程创建的一部分？在这点上，是很难判断的-我们需要了解调用线程下一步要干什么。因此，钩住NtCreateFile()和NtOpenFile()可能不是最好的选择。

　　钩住NtCreateSection()是更为合理的-如果我们在发生把可执行文件映射为映像(SEC_IMAGE 属性)的请求发生时拦截对NtCreateSection()的调用,结合允许执行页面保护的请求；那么，我们可以确信该进程将要被启动。在这一点上，我们是能够作出决定，如果我们不想该进程被创建，可以让NtCreateSection()返回STATUS_ACCESS_DENIED。因此，为了完全控制目标机器上的进程创建，所有我们要做的是在系统级上钩住NtCreateSection()。

　　象来自于ntdll.dll中的任何其它代理一样，NtCreateSection()用服务索引加载EAX，使EDX指向函数参数，并且把执行权传递到KiDispatchService()内核模式例程(这是通过Windows NT/2000中的INT 0x2E指令或者Windows XP下的SYSENTER指令实现的)。在校验完函数参数之后，KiDispatchService()把执行权传递到服务的实际实现部分-它的地址可用于服务描述表(指向这个表的指针由ntoskrnl.exe作为KeServiceDescriptorTable变量所输出，所以它对于内核模式驱动程序是可用的)中。服务描述表通过下列结构所描述：
 

　　struct SYS_SERVICE_TABLE {

　　void **ServiceTable;

　　unsigned long CounterTable;

　　unsigned long ServiceLimit;

　　void **ArgumentsTable;

　　};

　　这个结构中的ServiceTable字段指向一个数组-它拥有所有实现系统服务的函数的地址。因此，为了在系统级上钩住任何本机API函数，所有我们必须做的是把我们的代理函数的地址写入被KeServiceDescriptorTable的ServiceTable字段所指向的数组的第i个入口(i是服务索引)。

　　至此，看起来我们已了解了在系统级上监视和控制进程创建的一切。现在让我们开始实际的工作。

所谓文件是指用一个共同的符号名称作为代表，若干个逻辑记录构成的信息集合或目的，形式和内容的表示上彼此相似的一些信息项的集合。简单的说，就是具有一定名称的一组相关数据的集合。

所谓INF文件，就是以INF为扩展名的文本文件，他控制与驱动安装程序有关的大多数活动。

因为这个INF文件抽象了设备的上层建筑，含有安装驱动所有的必需的信息，所以它要由驱动开发人员随驱动一起提供，来告诉操作系统那些文件需要复制到用户的硬盘上，应添加或修改哪个注册表等。简单的说，INF文件就是机器的参考文件（Information File）。

INF文本文件与Windows 3。X的INI文件很类似，INF文件分为几节，每节包括一项或几项。每节与安装过程中的某一步相关：比如说，某一节是关于文件拷贝的。某一节是关于如何添加注册表项等等。作为一个开发者，你可以通过任何文本编辑器创建生成INF文件。Microsoft还在DDK中提供了INFEDIT工具，使拥护可以很方便的编辑INF 文件（如果实例用INFEDIT，请参阅DDK）。

INF文件可以支持很复杂的安装脚本，但是大多数的开发者只愿意使用处理一些最基本的脚本。一个基本的安装脚本应该包括：

1鉴定硬件设备

2把驱动程序从安装盘上拷贝到系统盘上去

3鉴定硬件设备资源的需求

4当硬件设备被仿真是，就在注册表中加上DevLoader一项

INF文件通常与磁盘或光盘上的硬件驱动程序一起提供。INF文件的结构和内容由驱动程序创作者决定

1.          举例说明

下面举例说明有关INF的基本特征和内容，以便更好的理解。

[Version]

Singnature=$windowsNT$                 //选择版本

Class=Unknown                          //系统定义用户指定的类名

Provider=%ABCD%                        //提供商

DirverVer=11/15/2001                    //

CatelogFile[.Ntetc]          //包含WHQL数字签名的目录说明文件。

[Strings]

ABCD=”me, the writer”       //定义宏

[SourceDisksNames]     //源代码盘或发行盘的描述，目录和打包文件

L=”Ggdriver directory”…obj\i386\

[SourceDisksFiles]      //和打包文件

Ggdriver.sys=l,obj\i386\some\

[DestinationDirs] //复制缺省文件和Filelist节中的文件，

//指定目录和子目录的ID 并指定文件的标准位置。

Ggdiver.Files.Driver=10,System32\Drivers

Ggdiver.Files.Driver=10, System32\Drivers

[Manufacturer]            //指定生产厂商和models节中相应的名称

%ABCD%=Ggdriver

[models]                  //最新的硬件ID号先出现

%USBDevice_V2%=V2Install,USB\VID_ABCD%PID_EFOL&REV_DO02

%USBDevice_V1%=V2Install,USB\VID_ABCD%PID_EFOL

[install]                         //指向添加的设备接口列表

Copyfiles=Ggdriver.Files.Driver

AddReg=Ggdriver.AddReg

LogConfig=logconfig

DirverVer=19/10/2001

ProfileItems=AB\cd

[filelist]

[addreg]

[logconfig]

[install.AddService]

ServiceTypy=l

StartType=start-code

ErrorControl=error-control-level

ServiceBinary=path-tc-driver

INF文件是一个文本文件，由不同的节组成，每一个节从括在方括号中的节名称开始，后面是节的内容。这些节也是分层的，其先后顺序与本样例基本保持一致。

在上面的样例中：

在[Verson ]节中，Signature项只能在$WindowsNT$,$Winfows95$以及$WindowsNT$中选一；

Provider项是INF文件的创造者，通常是设备的生产商；

Class项是系统定义用户指定的类名；

CatalogFile[.NTetc]则是必须包含的驱动程序包的WHQL数字签名的目录说明文件。

在[Strings ]节中定义代替字符串的宏： 

如例中：ABCD=“me,the writer”即是说%ABCD%的意思是me,the writer。而在使用时，也用“me，the writer”代替ABCD。为了适应不同的语言上下文，可以在String 的后面附加（在Winnt。H`中定义的）LangID和SubLangID，形成新的Strings节。LangID和SubLangID都是两位数，它们合作指定某语言上下文。

如定义一个英国英语（0902）的flour:

[Strings]

ABC=”Flor”

[Strings.0902]

ABC=”Flour”

[SourceDisksName]与[SourceDisksFiles]节分别是指源代码盘或发行盘的描述，目录和打包文件。如果所有文件都在根目录中，[SourceDisksFiles]节可以是在空的

在[DestinationDirs]节中，复制缺省文件和Filelist节中的文件，指定目录和子目录的ID 并指定文件的标准位置。

[Manufacture]节指定生产厂商和models节中相应的名称；

[install]节则指向添加的设备接口列表，接口键的注册表，其中：

Copyfiles=filename|filelist项，指定要复制的文件或后面列出文件的列表节的名称。

AddReg=addreg项，指定后面遗留设备节的名称。

LogConfig=logconfig项，指定后面遗留设备节的名称。

ProfileItems项，指定添加到计算机界面“开始”菜单中的文件名称项。

[filelist]指定要安装的文件列表。

[addreg]节，指定新的键和值。

[logconfig]节，指定遗留设备的I/O地址，IRQ等配置的详细信息。

[install。AddService]节，只针对Windows2000的驱动程序，指定驱动程序的详细信息。

下面我们具体介绍一下INF文件结构。

1.1INF文件结构

一个INF文件是一个被划分为节（Section）的简单的文本文件，每节由方括号（[]）内的标示符表示。某些节名字是必须的，而另一些是驱动程序专用的。每节下面的各项控制某些安装操作，或者连接或列举其它节。

文件中各节出项的顺序并不重要，因为每节都被命名和链接了。一节内容在遇到另一节或者遇到文件结尾之前继续执行。规定节的唯一的名字是区分大小写的，并且在长度上必须限制在28个字符以内，以保持与Windows 98 的兼容性。节的名字可以包括空格，但是只有在整个名字应用时。允许下划线和点字符。

节中各项的基本格式如下：

entry=value[，value….]

这里的entry是一个指令，关键字或者文件名，而value是应用于entry的属性。

下图表示了节名字链接。

Entry或value名字可以规定为一个字符串记号（string token），它是一个由百分号%包围的替换字节串，一个独立的INF节——[Strings]，给指定的语言ID提供了字符串记号值。

下面我们看一下INF文件的各个小节及小节的基本内容：（表1，表2）

下面我们详细每一节的内容：

1.2 Version节

一个有效的INF文件以一个[Version]节开始，它担当整个INF文件的头部和签名。[Version]节中允许的和要求的项都列在了下表-3

1.3 Manufacturers节

另一个必须的节是[Manufacturers]项。该节中的每个项列出INF文件安装的设备和他们的驱动程序。每个项的格式如下：

 manufacturer=model

这里的manufacturer列出要被安装的一个或多个硬件型号的制造商在INF文件中的唯一名字。Model值指向另一个INF节名字，进一步列出硬件型号驱动程序安装的方向。

1.4 Models节

对于列在[Manfacturers]节中的每个型号，必须有一个相应的节作为由model指定的节出现。每个model项的形式为：

device-description=install-section-name，hw-id[，compatible-id…]

这里的device-description表示人可以理解的设备型号列表和一个简单的描述。在一些安装过程中此字符串在一个对话框中提交给用户，因此有必要提供多种语言作为字符串记号。

 install-section-name值引用[DDInstall]节，表示值进一步安装的另一个INF节，hw-id值是硬件设备在PNP兼容的总线上声明时返回的PnP标示符。例如。USB \ VID_045E&PID_OOB   标示USB上的Microsoft HID（Human Input Device）键盘设备。能够增加任意数量的compatlible-id值，表示相同的安装脚本可以用于列表中包含的任何设备。

1.5 DDInstall节

在INF节名字链表的低部附近（但并非最低部）是[DDInstall]节，它从[Models]节中为每个制造商的每个型号规定一个唯一的名字。[DDInstall]节中允许的和要求的项目见下面表4.

       虽然在语法上只有AddReg项是必需的，但是CopyFiles项是[DDInstall]节的一个基本指令。它采取如下形式：

CopyFiles = file – list – section [，file – list – section….]或者

CopyFile = @filename

前一种形式更加常用，因为它允许一个间接指针指向包含被安装的文件列表的其他节。然而，对于简单的驱动开发程序安装，采取直接文件名方法就行了。在下面两个小节中将对AddReg和CopyFiles指令做进一步解释。

1.6  CopyFiles节

INF文件的[CopyFiles]节有一个唯一的名字，并从[DDInstall]节的CopyFiles指令引用它。该节中的每个项采用如下形式：

destination – filename[，source- filename，temp-filename，flag]

这里的destiantion-filename是最重要复制的目标文件名。如果源文件名不相同，必须规定source – filename。Temp-filename值不再适用（虽然 Windows 98仍然要求），它在系统再次引导之前规定新文件的临时文件名。对于Windows 2000，忽略此值。

 Falg 值规定对新目标文件的处理，其描述见表5。可以对falg值中的各个为进行“或”运算，以使多个操作起作用。几种操作是互斥的（例如，WARN_IF_SKIP和NOSKIP）,有疑问时应当查阅有关文档。

因为[CopyFiles]节的项的语法没有包含一个可选项来规定源文件的磁盘或路径，必须使用其他INF节——[SourceDisksNames]和[SourceDisksFiles]。然而[CopyFiles]节中各项复制的文件由另一个INF节——[DestiantionDirs]节指定。

1.7 AddReg节

一个INF文件的[AddReg]节被唯一命名，并从[DDInstall]节中的AddReg指令引用它。此节的目的是提供增加或者修改目标系统注册表中的项目。本节中每个项目采取如下形式：

 reg-root[，subkey，value- name，flags ，value]

这里的reg- root是注册表库（hive）之一的缩写，见表6所列。值表示要被修改的注册表库。Subbkey值表示库底下的键名，在层次结构中子键用反斜线（\）字符隔开。例如，software\W2KdriverBook\Driver\Seting 是HKCU或者HKLM库的一个有效子键。

Value-name指定要增加或修改的注册表值。每个注册表键包含一个或多个值，保存不同类型的数据。注册表编辑器（Registy Editor）在右边面板中列出子键的值。值名和值数据同时在该面板中出现，左边面板只列出子键。图3说明了注册表术语之间的关系。

Flags指定数据保存的类型，flages可能的位置见表7所列:

1.8  SourceDisksNames节

如果INF文件控制的驱动程序文件的分布跨越多个磁盘（软盘或光盘），则INF文件必须包含一个[SourceDisksNames]节。本节在分布集中为每个磁盘包含一项，项目采取如下形式：

Diskid=disk – descript[，tagfile，unused，path]

这里的diskid`是分布集内的一个一个唯一的编码。通常，磁盘从1开始编码。Disk – description 标签是一个供人阅读的文本串，可以保证安装过程中拥护提供正确的磁盘，在安装过程继续之前核对tagfile值是否在插入的煤体上。如果tagfile文件不存在，则提示用户插入正确的磁盘。如果tagfile值包含-CAB扩展，则该文件被认为是磁盘上驱动程序源文件的压缩文件集。

Path值是磁盘上驱动程序源文件的相对于根目录的磁盘路径。与tagfile值一样，path是可选的。如果忽略它，则认为根目录是文件的源。

1.9 SourceDisksFiles节

驱动程序INF文件还必须包含一个称为[SourceDisksFiles]的节。此节列出驱动程序安装期间使用的文件名。每个文件对应于本节中的一个项，并采取如下形式：

Filename = diskid[，sbdir，size]

很自然，diskid值在[SourceDisksNames]节中指定了找到filename的一个磁盘，subdir值可选，它指定文件在磁盘上的一个路径。Size值可选，指定文件以字节为单位的未压缩大小。在开始文件复制前，安装进程可以使用此大小确定源文件是否合适目标系统。

1  DestinationDirs节

这是INF文件中必需的节，指定源文件的目标目录。没有这部分内容，安装程序或进程将没有用来拷贝文件的目标目录。[DestinatonDirs]节中的项采取如下形式：

File – list – section = dirid[，subdir]或者

DefaultDestDir = dirid[，subdir]

这里file – list – section规定了在[CopyFiles]指令中调出来的部分。它规定一个指令拷贝的所有文件安装到指定的目录。对于项目DefaultDestDir，上述规范适用于所有[CopyFiles]指令，否则不会与[DestionationDirs]节中的file- list – section项关联。

Dirid值根据表8规定了目标的一个列举值。如果提供了值subdir，它指定diid调处的目录下面的一个相对路径。

2. DDInstall.Services节

为了真正的使复制的文件成为目标系统上的驱动程序，必须通知服务器管理程序（SCM）。安装在Windows 2000下的每个驱动程序在HKLM\System\Current-ControlSet\Services下的注册表中有一项。ServiceType值为1表示一个内核模式设备驱动程序。StartType指定在引导过程中的什么点上驱动程序装入（3表示按需或手动启动）。在驱动程序装入过程中遇到错误时，ErrorControl值确定发生了什么情况。ServiceBinary值指向驱动程序文件（。SYS文件）的位置，但是，如果二进制值位于%windir%\system32\drivers目录，并且与HKLM\…\Services下的子键有相同的名字，则可以忽略ServiceBinary值。

DDInstall.Services节项目中包括一个形式如下的项目：

AddService = ServiceName，[flags]，service – install – section[，eventlog – install – section]

这里的ServiceName表示设备的名字，通常是驱动程序的名字，没有。SYS扩展名。Flags值的描述见表9

Service – install – section和可选的eventlog- install – section值调出控制服务值项目（诸如ServiceType和StartType）的新增的INF节名字。

3. ServiceInstall 节

[ServiceInstall]节名字实际上由DDInstall.Services节中每个AddService项唯一规定，它控制把驱动程序安装到服务控制管理程序。[ServiceInstall]节允许的项见表10所列。

4 .验证INF语法

DDK包含一个基本的工具CHKINF，在DDK的Tools目录中。它依赖于Perl脚本引擎，该引擎可以从www.perl.com上下载。虽然工具没有什么优点，但它在检查标准Microsoft INF文件时能报告许多错误。工具以HTML文件形式输出。

DDK Tools目录还包括一个用语简化INF文件构造的实用程序CENINF。EXE 。 必须把该工具区分为基本工具，它对入门者是有用的。

最后，DDK提供了STAMPINF。EXE这一简单工具，它提供了快速增加或修改INF中版本信息的机制。

				;**************************************************************************************************
;Author:dge/D哥
;Date  :2006.7.20
;**************************************************************************************************
;f:\masm32\bin\ml /nologo /c /coff HookAPI.asm
;C:\>f:\masm32\bin\link /nologo /driver /base:0x10000 /align:32 /out:HookAPI.sys /subsystem:native HookAPI.obj


.386

.
model flat
,
 stdcall
option casemap
:
none

;**************************************************************************************************

include f:\masm32\include\w2k\ntstatus.inc
include f:\masm32\include\w2k\ntddk.inc
include f:\masm32\include\w2k\ntoskrnl.inc
includelib f:\masm32\lib\w2k\ntoskrnl.lib
include f:\masm32\Macros\Strings.mac
;**************************************************************************************************
.data
;保存地址
dwOldNtLoadDriver   dd            ?
dwAddr              dd            ?
dwDriverName        ANSI_STRING  <?>
.const
CCOUNTED_UNICODE_STRING "\\Device\\devHookApi", g_usDeviceName, 4
CCOUNTED_UNICODE_STRING "\\??\\slHookApi", g_usSymbolicLinkName, 4
CCOUNTED_UNICODE_STRING "ZwLoadDriver", g_usRoutineAddr, 4
;**************************************************************************************************
.code
;让这个函数在NtLoadDriver的调用时被执行以实现监视
NewNtLoadDriver     proc  lpDriverName:PUNICODE_STRING
pushad
;      int 3
;                   invoke DbgPrint, $CTA0("\nEntry into NEW\n")
      invoke RtlUnicodeStringToAnsiString, addr dwDriverName, lpDriverName,TRUE
invoke DbgPrint, $CTA0("\nDriverName: %s.sys\n"), dwDriverName.Buffer
popad
;调用原函数
      push   lpDriverName
call   dwOldNtLoadDriver
ret
NewNtLoadDriver     endp
;**************************************************************************************************
HookFunction        proc

                    pushad
;      int 3
;      invoke DbgPrint, $CTA0("\nEntry into hoookfunction\n")
;下面是用KeServiceDescriptorTabled导出符号获得数组的基地址，这个数组中包含有NtXXXX函数的入口地址。
      mov eax, KeServiceDescriptorTable
mov esi, [eax]
mov esi, [esi]
;用MmGetSystemRoutineAddress来获得函数ZwLoadDriver的地址。并从这个函数地址后面的第2个字节中取得服务号。从而
;获得以服务号为下标的数组元素。
             invoke MmGetSystemRoutineAddress,addr g_usRoutineAddr
inc eax
movzx ecx,byte ptr[eax]
sal ecx,2
      add esi,ecx
mov dwAddr,esi
      mov edi,dword ptr[esi]
;保存旧的函数地址。
      mov dwOldNtLoadDriver,edi
mov edi,offset NewNtLoadDriver
;修改入口地址
      cli
      mov dword ptr[esi],edi
sti
popad
mov eax, STATUS_SUCCESS
ret
HookFunction     endp
;**************************************************************************************************
DispatchCreateClose proc pDeviceObject:PDEVICE_OBJECT, pIrp:PIRP
mov eax, pIrp
assume eax:ptr _IRP
mov [eax].IoStatus.Status, STATUS_SUCCESS
and [eax].IoStatus.Information, 0
assume eax:nothing 

             invoke  IoCompleteRequest, pIrp, IO_NO_INCREMENT
mov eax, STATUS_SUCCESS
ret
DispatchCreateClose endp
;**************************************************************************************************
DriverUnload        proc pDriverObject:PDRIVER_OBJECT
;必须保存环境，否则后果很严重。在这个函数中恢复被修改的地址。

                   pushad
;             int 3
;                   invoke DbgPrint, $CTA0("\nEntry into DriverUnload \n")
                    mov esi,dwAddr
mov eax,dwOldNtLoadDriver
cli
mov dword ptr[esi],eax
sti
invoke IoDeleteSymbolicLink, addr g_usSymbolicLinkName
mov eax,pDriverObject
invoke IoDeleteDevice, (DRIVER_OBJECT PTR [eax]).DeviceObject
             popad

             ret
DriverUnload endp
;**************************************************************************************************
DriverEntry         proc pDriverObject:PDRIVER_OBJECT, pusRegistryPath:PUNICODE_STRING
local status:NTSTATUS
local pDeviceObject:PDEVICE_OBJECT
;                   int 3
;             invoke DbgPrint, $CTA0("\nEntry into DriverEntry\n")
             mov status, STATUS_DEVICE_CONFIGURATION_ERROR
invoke IoCreateDevice, pDriverObject, 0, addr g_usDeviceName, FILE_DEVICE_UNKNOWN, 0, FALSE, addr pDeviceObject
.if eax == STATUS_SUCCESS
invoke IoCreateSymbolicLink, addr g_usSymbolicLinkName, addr g_usDeviceName
.if eax == STATUS_SUCCESS
mov eax, pDriverObject
assume eax:ptr DRIVER_OBJECT
mov [eax].DriverUnload,            offset DriverUnload
mov [eax].MajorFunction[IRP_MJ_CREATE*(sizeof PVOID)],        offset DispatchCreateClose
mov [eax].MajorFunction[IRP_MJ_CLOSE*(sizeof PVOID)],         offset DispatchCreateClose
assume eax:nothing
                                          invoke HookFunction
mov status, STATUS_SUCCESS
.else
invoke IoDeleteDevice, pDeviceObject
.endif
.endif
             mov eax, status
ret
DriverEntry         endp

end DriverEntry
;**************************************************************************************************