Windows内核中的内存管理 内存管理的要点内核内存是在虚拟地址空间的高2GB位置，且由所有进程所共享，进程进行切换时改变的只是进程的用户分区的内存驱动程序就像一个特殊的DLL，这个DLL被加载到内核的地址空间中，DriverEntry和AddDevice例程在系统的system进程中运行，派遣函数会运行在应用程序的进程上下文中所能访问的地址空间是这个进程的虚拟地址空间利用_EPROCESS结构可以查看该进程的相关信息当程序的中断级别在DISPATCH_LEVEL之上时，必须使用非分页内存，否则会造成系统蓝屏，在编译WDK相关例程时，可以使用如下的宏指定某个例程或者某个全局变量是位于分页内存还是运行于非分页内存#define PAGEDCODE code_seg("PAGE") //分页内存 #define LOCKEDCODE code_seg() //非分页内存 #define INITCODE code_seg("INIT") //指定在相关函数执行完成后就从内存中卸载下来 #define PAGEDDATA data_seg("PAGE") #define LOCKEDDATA data_seg() #define INITDATA data_seg("INIT")在使用时直接使用#pragma直接加载这些宏即可比如:#pragma PAGEDCODE VOID DoSomething() { PAGED_CODE() //函数体 }其中PAGED_CODE是一个WDK中提供的一个宏，只在debug版本中生效，用于判断当前的中断请求级别，当级别高于DISPATCH_LEVEL(包含这个级别)时会产生一个断言内核中的堆申请函数PVOID ExAllocatePool( IN POOL_TYPE PoolType, IN SIZE_T NumberOfBytes ); PVOID ExAllocatePoolWithTag( IN POOL_TYPE PoolType, IN SIZE_T NumberOfBytes, IN ULONG Tag ); PVOID ExAllocatePoolWithQuota( IN POOL_TYPE PoolType, IN SIZE_T NumberOfBytes ); PVOID ExAllocatePoolWithQuotaTag( IN POOL_TYPE PoolType, IN SIZE_T NumberOfBytes, IN ULONG Tag );PoolType:这是一个枚举变量，用来表示分配内存的种类，如果为PagedPool表示分配的是分页内存，如果是NonPagedPool表示分配的是非分页内存NumberOfBytes：分配内存的大小，为了效率最好分配4的倍数上面这些函数主要分为带有标记和不带标记的两种，其中有Quota的是按配额分配，带有标记的函数可以通过这个标记来判断这块内存最后有没有被分配,标记是一个字符串，但是这个字符串是用单引号引起来的。一般给4个字符,由于IntelCPU采用的是高位优先的存储方式，所以为了阅读方便，一般将这个字符串倒着写这些函数分配的内存一般使用下面的函数来释放VOID ExFreePool( IN PVOID P ); NTKERNELAPI VOID ExFreePoolWithTag( IN PVOID P, IN ULONG Tag ); 在驱动中使用链表WDK给程序员提供了两种基本的链表结构，分别是单向链表和双向链表双向链表的结构体定义如下:typedef struct _LIST_ENTRY { struct _LIST_ENTRY *Flink; //指向下一个节点 struct _LIST_ENTRY *Blink; //指向上一个节点 } LIST_ENTRY, *PLIST_ENTRY;初始化链表使用宏InitializeListHead，它需要传入一个链表的头节点指针它的定义如下VOID InitializeListHead( IN PLIST_ENTRY ListHead );这个宏只是简单的将链表头的Flink和Blink指针指向它本身。利用宏IsListEmpty可以检查一个链表是否为空，它也是只简单的检查这两个指针是否指向其自身在定义自己的数据结构的时候需要将这个结构体放到自定义结构体中，比如typedef struct _MYSTRUCT { LIST_ENTRY listEntry; ULONG i; ULONG j; }MYSTRUCT, *PMYSTRUCT一般插入链表有两种方法，头插法和尾插法，DDK根据这两种方法都给出了具体的函数可供操作：//头插法，采用头插法只改变链表数据的顺序，链表头仍然是链表中的第一个元素 VOID InsertHeadList( IN PLIST_ENTRY ListHead, //链表头指针 IN PLIST_ENTRY Entry //对应节点中的LIST_ENTRY指针 ); //尾插法 VOID InsertTailList( IN PLIST_ENTRY ListHead, IN PLIST_ENTRY Entry );删除节点使用的是这样两个函数，同样采用的是从头部开始删除和从尾部开始删除，就是查找链表中节点的方向不同。//从头部开始删除 PLIST_ENTRY RemoveHeadList( IN PLIST_ENTRY ListHead ); //从尾部开始删除 PLIST_ENTRY RemoveTailList( IN PLIST_ENTRY ListHead );这两个函数都是传入头节点的指针，返回被删除那个节点的指针，这里有一个问题，我们如何根据返回PLIST_ENTRY结构找到对应的用户定义的数据，如果我们将LIST_ENTRY，这个节点放在自定义结构体的首部的时候，返回的地址就是结构体的地址，如果是放在其他位置，则需要根据结构体的定义来进行转化，对此WDK提供了这样一个宏来帮我们完成这个工作：PCHAR CONTAINING_RECORD( IN PCHAR Address, IN TYPE Type, IN PCHAR Field );这个宏返回自定义结构体的首地址，传入的是第一个参数是结构体中某个成员的地址，第二个参数是结构体名，第三个参数是我们传入第一个指针的类型在结构体中对应的成员变量值，比如对于上面那个MYSTRUCT结构体可以这样使用typedef struct _MY_LIST_DATA { LIST_ENTRY list; ULONG i; }MY_LIST_DATA, *PMY_LIST_DATA; PLIST_ENTRY pListData = RemoveHeadList(&head);//head是链表的头节点 PMYSTRUCT pData = CONTAINING_RECORD(pListData, MYSTRUCT, list);Lookaside结构频繁的申请和释放内存将造成内存空洞，即出现大量小块的不连续的内存片段，这个时候即使内存仍有剩余，但是我们也申请不了内存，一般在操作系统空闲的时候会进行内存整理，将空洞内存进行合并，如果驱动需要频繁的从内存中申请释放相同大小的内存块，DDK提供了Lookaside内存容器，在初始时它先向系统申请了一块比较大的内存，以后程序每次申请内存的时候不是直接在Windows堆中进行分配，而是在这个容器中，Lookaside结构会智能的避免产生内存空洞，如果申请的内存过多，lookaside结构中的内存不够时，他会自动向操作系统申请更多的内存，如果lookaside内部有大量未使用的内存时，他会自动释放一部分，总之它是一个智能的自动调整内存大小的一个容器。一般应用于以下几个方面：程序每次申请固定大小的内存申请和回收的操作十分频繁使用时首先初始化Lookaside对象，调用函数VOID ExInitializeNPagedLookasideList( IN PNPAGED_LOOKASIDE_LIST Lookaside, IN PALLOCATE_FUNCTION Allocate OPTIONAL, IN PFREE_FUNCTION Free OPTIONAL, IN ULONG Flags, IN SIZE_T Size, IN ULONG Tag, IN USHORT Depth );或者VOID ExInitializePagedLookasideList( IN PPAGED_LOOKASIDE_LIST Lookaside, IN PALLOCATE_FUNCTION Allocate OPTIONAL, IN PFREE_FUNCTION Free OPTIONAL, IN ULONG Flags, IN SIZE_T Size, IN ULONG Tag, IN USHORT Depth );这两个函数一个是操作的是非分页内存，一个是分页内存。Lookaside：这个参数是一个NPAGED_LOOKASIDE_LIST的指针，在初始化前需要创建这样一个结构体的变量，但是不用填写其中的数据。Allocate：这个参数是一个分配内存的回调函数，一般这个值填NULLFree：这是一个释放的函数，一般也填NULL这两个函数有点类似于C++中的构造与析构函数，如果我们对申请的内存没有特殊的初始化的操作，一般这个两个都给NULLFlags：这是一个保留字节，必须为NULLSize：指明明我们每次在lookaside容器中申请的内存块的大小每次申请的内存块的标志，这个标志与上面的WithTag函Tag：数申请内存时填写的标志相同Depth：系统保留，必须填0创建容器之后，可以用下面两个函数来分配内存PVOID ExAllocateFromNPagedLookasideList( IN PNPAGED_LOOKASIDE_LIST Lookaside ); PVOID ExAllocateFromPagedLookasideList( IN PPAGED_LOOKASIDE_LIST Lookaside );用下面两个函数来释放内存VOID ExFreeToNPagedLookasideList( IN PNPAGED_LOOKASIDE_LIST Lookaside, IN PVOID Entry ); VOID ExFreeToPagedLookasideList( IN PPAGED_LOOKASIDE_LIST Lookaside, IN PVOID Entry );最后可以使用下面两个函数来释放Lookaside对象VOID ExDeleteNPagedLookasideList( IN PNPAGED_LOOKASIDE_LIST Lookaside ); VOID ExDeletePagedLookasideList( IN PPAGED_LOOKASIDE_LIST Lookaside );其他内存函数内存拷贝函数VOID RtlCopyMemory( IN VOID UNALIGNED *Destination, IN CONST VOID UNALIGNED *Source, IN SIZE_T Length );需要注意的是这个函数没有考虑到内存重叠的情况，假如内存发生重叠例如这样：这个时候AC内存块和BD内存块有部分重叠，如果将AC拷贝到BD那么会改变AC的值，这样在拷贝到BD中的值也会发生变化，有可能造成错误，为了保证重叠也可以正常拷贝，可以使用函数void MoveMemory( __in PVOID Destination, __in const VOID* Source, __in SIZE_T Length );填充内存一般使用函数void FillMemory( [out] PVOID Destination, [in] SIZE_T Length, [in] BYTE Fill );另外DDK另外提供了一个将内存清零的函数VOID RtlZeroMemory( IN VOID UNALIGNED *Destination, IN SIZE_T Length );内存比较函数ULONG RtlEqualMemory( CONST VOID *Source1, CONST VOID *Source2, SIZE_T Length );这个函数返回的是两块内存中相同的字节数，如果要比较两块内存是否完全相同，可以将返回值与Length相比较，如果相等则说明两块内存相同，否则不相同，另外为了实现这个功能DDK提供了一个与该函数同名的宏来判断，具体在编写代码时可以根据情况判断调用的是函数还是宏。在内核中，对于内存的读写要相当的谨慎，稍不注意就可能产生一个新漏洞或者造成系统的蓝屏崩溃，有时在读写内存前需要判断该内存是否合法可供读写，DDK提供了两个函数来判断内存是否可读可写VOID ProbeForRead( IN CONST VOID *Address, IN SIZE_T Length, IN ULONG Alignment//当前内存是以多少字节对齐的 ); VOID ProbeForWrite( IN CONST VOID *Address, IN SIZE_T Length, IN ULONG Alignment );这两个函数在内存不可读写的时候引发一个异常，需要用结构化异常进行处理，这里使用结构化异常的方式与在应用层的使用方式相同其他数据结构typedef union _LARGE_INTEGER { struct { DWORD LowPart; LONG HighPart; }; struct { DWORD LowPart; LONG HighPart; } u; LONGLONG QuadPart; } LARGE_INTEGER, *PLARGE_INTEGER;这个结构用来表示64位二进制的整形数据，它是一个共用体，占内存大小是64位8个字节，从定义上来看可以看做一个LONGLONG型数据，也可以看做两个4字节的数据。

windbg蓝屏调试 一般在写Windows内核程序的时候，经常会出现蓝屏的问题，这个时候一般是采用记录下dump文件然后用windbg查看得方式，具体的过程就不说了，网上一大堆的内容。现在我主要记录自己当初按照网上的方案出现windbg的open crashdump项呈现灰色的情况。就像下面这样这个问题曾今百思不得其解，曾今一度以为是自己的win10不能很好的兼容这个，后来发现自己想多了( ^_^ )，现在公布这个问题的解决方案。主要是确保下面的工作完成1）首先需要在虚拟机上确保我们打开了抓取dump文件的功能，怎么打开百度上有一大堆。2）接着就是真实机上也要打开这个功能3）然后最重要的就是关闭虚拟机，不要让windbg连上了虚拟机，它连上了虚拟机就会呈现选项变灰的情况，查看dump文件是我们在真实机里面进行的，之前一直不知道这点，结果怎么试都不行。如果还是不行，可以考虑关了虚拟机之后重启windbg。然后可以看到已经能使用这个选项了。在调试dump文件时要确保自己已经下载了Windows内核的符号表，然后打开dump文件就可以分析出错的位置了

Minfilter过滤框架 Minfilter过滤框架优势与传统的Sfilter过滤驱动相比，有这样几个优势Minfilter加载顺序更易控制，Sfilter加载是随意的，也就是说它在IO设备栈上的顺序是根据其创建的顺序决定的，越晚创建的，越排在设备栈的顶部，而Minfilter根据它的一个全局变量——altitude规定了它在设备栈上的顺序具有可卸载能力，一般的hook或者过滤框架在卸载时可能仍然有程序在访问它们的代码，所以如果在有程序访问其代码，而它又被卸载时容易导致蓝屏，这样就不具备可卸载能力。而Minfilter则不会导致蓝屏Minfilter是通过注册回调函数到Minfilter管理器中，由Minfilter管理器来负责调度这些函数，不直接与IO管理器接触，同时我们只需要注册我们感兴趣的回调函数，而不像Sfilter那样，需要提供一个统一的处理函数。所以相对来说更简单兼容性更好，由IO管理器下发的IRP 请求既可以交给Sfilter框架处理，也可以交给Minfilter处理，也可以给下层的设备驱动处理。名字处理处理更加容易，相对与Sfilter中需要另外顶一个一个NAME_CONTROL结构，还需要注意长短名来说，Minfilter更加简单，只需要一个简单的函数就可以获取文件的卷设备名称，文件全名，流名等信息Minfilter的基本框架应用层下发的IO请求首先交由IO管理器处理，IO管理器将请求封装为一个IRP请求包接着网下层分发，当分发到Minfilter管理器时，由Minfilter将IRP封装为一个CALLBACK_DATA结构，并根据不同的请求调用不同的回调函数，由回调函数处理并决定是否分发到下层。Altitude 变量这个变量是Minfilter提供的全局变量，用来规定这个Minfilter管理器在IO栈中的高度，值越大越位于上方，它们在IO管理器中的位置如下图在栈中的位置既不是越低越好也不是越高越好，而是根据其具体需求，比如杀毒操作应该放到加解密操作之前，加解密应该放到真实的读写操作之前，所以它们在栈中从上到下的顺序应该是杀毒、加解密、IO设备对象。所以微软为每个功能的Minfilter中的Altitude都提供了大致的位置值，杀毒的过滤驱动是在320000-329999，而加解密的是140000-149999Minfilter框架详解注册结构FLT_REGISTRATIONMinfilter中最主要的是各个回调函数，向其中注册回调函数实际是在填写一个叫做FLT_REGISTRATION的结构体，在Minfilter中定义了这样一个结构体的变量：const FLT_REGISTRATION fileMonitorRegistration = { sizeof( FLT_REGISTRATION ), // Size FLT_REGISTRATION_VERSION, // Version 0, // Flags ContextRegistration, // ContextRegistration fileMonitorCallbacks, // Operation callbacks fileMonUnload, // FilterUnload fileMonInstanceSetup, // InstanceSetup NULL, // InstanceQueryTeardown fileMonInstanceTeardownStart, // InstanceTeardownStart NULL, // InstanceTeardownComplete NULL, // GenerateFileName NULL, // GenerateDestinationFileName NULL // NormalizeNameComponent };fileMonitorCallbacks是一个函数的指针数组，保存了处理各种事件的回调函数，框架会根据具体的事件来调用这些函数。它的定义如下：const FLT_OPERATION_REGISTRATION fileMonitorCallbacks[] = { { IRP_MJ_CREATE, FLTFL_OPERATION_REGISTRATION_SKIP_PAGING_IO, HOOK_PreNtCreateFile, HOOK_PostNtCreateFile }, { IRP_MJ_CLEANUP, 0, HOOK_PreNtCleanup, NULL }, { IRP_MJ_WRITE, 0, HOOK_PreNtWriteFile, HOOK_PostNtWriteFile }, { IRP_MJ_SET_INFORMATION, 0, HOOK_PreNtSetInformationFile, HOOK_PostNtSetInformationFile }, { IRP_MJ_OPERATION_END } };利用这个结构体将各种IRP请求与处理它的回调函数绑定起来，每组请求都有两个两个处理它的回调函数，一个Pre表示具体设备处理这个请求之前，Post表示系统处理这个请求之后。拿Sfilter中的sfCreate举例来说，HOOK_PreNtCreateFile处理的是在它调用IoCallDriver之前的操作，而HOOK_PostNtCreateFile表示的是在sfCreate在等到底层设备完成文件创建之后的操作。fileMonUnload 这个函数相当于驱动中的DriverUnload函数，在进行驱动开发时由于很多时候不能进行安全的卸载所以很多驱动不提供DriverUnload函数，防止由于卸载时产生蓝屏，要卸载只能重启机器fileMonInstanceSetup ：Minfilter像Sfilter一样，会遍历计算机中的所有卷设备，每当有一个被遍历到，就会绑定一个过滤驱动设备在卷设备上，这个过滤设备就是Minfilter中的Instance，这个函数会在绑定过滤设备对象时触发fileMonInstanceTeardownStart 在卸载这个过滤设备时调用它们的关系如下图所示Minfilter过滤驱动的注册启动与销毁在我们自己写的驱动中可以使用函数FltRegisterFilter来向Minfilter管理器注册这个驱动的相关信息，以便Minfilter管理器将我们的程序放入到IO设备栈的合适位置中，该函数的原型如下：NTSTATUS FltRegisterFilter( IN PDRIVER_OBJECT Driver, IN CONST FLT_REGISTRATION *Registration, OUT PFLT_FILTER *RetFilter ); 第一个参数就是驱动的驱动对象指针，这个可以从DriverEntry中获得。第二个参数是是我们定义的那个装有各种事件回调函数的一个结构体的指针，通过传入这个参数，将这组回调函数注册到Minfilter管理器中第三个参数是一个输出参数，如果注册成功，则会返回这个参数用来唯一标识这个过滤驱动，这个参数一般是保存在NULL_FILTER_DATA结构中的FilterHandle中注册完成后，就是启动这个过滤驱动，进行文件系统的过滤，启动使用函数FltStartFiltering，这个函数需要传入之前注册函数返回的那个过滤驱动的句柄当我们不需要使用这个过滤驱动时使用函数FltUnregisterFilter卸载，它同样需要传入这个过滤驱动句柄。下面是一个具体的例子NTSTATUS DriverEntry ( __in PDRIVER_OBJECT DriverObject, __in PUNICODE_STRING RegistryPath ) { NTSTATUS status; UNREFERENCED_PARAMETER( RegistryPath ); //注册回调函数 status = FltRegisterFilter( DriverObject, &FilterRegistration, &NullFilterData.FilterHandle ); ASSERT( NT_SUCCESS( status ) ); if (NT_SUCCESS( status )) { //如果注册成功则开启minfilter监控 status = FltStartFiltering( NullFilterData.FilterHandle ); if (!NT_SUCCESS( status )) { //如果失败则卸载注册的回调 FltUnregisterFilter( NullFilterData.FilterHandle ); } } DbgPrint("Minifilter started\n"); return status; }对于卸载来说，需要注意的是很多驱动本身是不支持卸载的也就是不提供DriverUnload函数，因为系统中的驱动是被所有进程调用的，如果某个进程正在调用而另外一个进程正在卸载这个驱动，那么很可能会产生蓝屏。回调函数Minfilter过滤驱动中处理各个请求的回调函数一般都有两个：一个在IO设备处理之前，一个在IO设备处理之后。下面将称它们问Pre函数和Post函数Pre函数typedef FLT_PREOP_CALLBACK_STATUS (*PFLT_PRE_OPERATION_CALLBACK) ( IN OUT PFLT_CALLBACK_DATA Data, IN PCFLT_RELATED_OBJECTS FltObjects, OUT PVOID *CompletionContext );这个函数中的Data是对IRP的一个封装，与操作IRP相似，Minfilter向R3层返回结果使用的代码与普通的NT模型中的相同Data->IoStatus.Status = STATUS_SUCCESS; Data->IoStatus.Information = 0;另外过滤函数返回的值时直接返回给Minfilter管理器进行处理，而Sfilter返回的值是直接交给IO管理器，回调函数的返回值一般有这样几个常用的：FLT_PREOP_SUCCESS_WITH_CALLBACK：表示处理请求成功，接着往下发这个请求，下层驱动处理完这个请求后可以触发POST函数的调用FLT_PREOP_SUCCESS_NO_CALLBACK：与上述返回值类似，只是下层驱动处理完这个请求后不会触发POST函数FLT_PREOP_COMPLETE：请求处理完成，返回这个值，Minfilter将不会将请求继续往下发Post函数Post函数的原型如下：typedef FLT_POSTOP_CALLBACK_STATUS (FLTAPI *PFLT_POST_OPERATION_CALLBACK) ( __inout PFLT_CALLBACK_DATA Data, __in PCFLT_RELATED_OBJECTS FltObjects, __in_opt PVOID CompletionContext, __in FLT_POST_OPERATION_FLAGS Flags );在该函数中的返回值一般有如下几个：FLT_POSTOP_FINISHED_PROCESSING：向Minfilter管理器返回成功FLT_POSTOP_MORE_PROCESSING_REQUIRED：需要Minfilter管理器另外开一个线程，用来作为工作者线程，处理需要在低IRQL请求中完成的工作判断DATA的操作类型的宏FLT_IS_IRP_OPERATION：判断这个是否是一个IRP请求FLT_IS_FASTIO_OPERATION：判断这个是否是一个FASTIO请求FLT_IS_FS_FILTER_OPERATION:判断这个是否是一个文件系统过滤的请求Minfilter的安装以inf文件安装inf文件是一个安装信息的配置文件，指明了安装的.sys文件路径，安装到哪个位置，以及写到注册表中的何种位置，下面是一个具体的例子,在这只列举了比较重要的部分：[Version] Signature = "$Windows NT$" Class = "ActivityMonitor" ;This is determined by the work this filter driver does ClassGuid = {b86dff51-a31e-4bac-b3cf-e8cfe75c9fc2} ;This value is determined by the Class Provider = %Msft% DriverVer = 06/16/2007,1.0.0.0 CatalogFile = nullfilter.cat [DestinationDirs] DefaultDestDir = 12 NullFilter.DriverFiles = 12 ;%windir%\system32\drivers ;; ;; Default install sections ;; [DefaultInstall] OptionDesc = %ServiceDescription% CopyFiles = NullFilter.DriverFiles [DefaultInstall.Services] AddService = %ServiceName%,,NullFilter.Service [DefaultUninstall] DelFiles = NullFilter.DriverFiles [DefaultUninstall.Services] DelService = %ServiceName%,0x200 ;Ensure service is stopped before deleting [NullFilter.Service] DisplayName = %ServiceName% Description = %ServiceDescription% ServiceBinary = %12%\%DriverName%.sys ;%windir%\system32\drivers\ Dependencies = "FltMgr" ServiceType = 2 ;SERVICE_FILE_SYSTEM_DRIVER StartType = 3 ;SERVICE_DEMAND_START ErrorControl = 1 ;SERVICE_ERROR_NORMAL LoadOrderGroup = "FSFilter Activity Monitor" AddReg = NullFilter.AddRegistry [NullFilter.AddRegistry] HKR,"Instances","DefaultInstance",0x00000000,%DefaultInstance% HKR,"Instances\"%Instance1.Name%,"Altitude",0x00000000,%Instance1.Altitude% HKR,"Instances\"%Instance1.Name%,"Flags",0x00010001,%Instance1.Flags% [NullFilter.DriverFiles] %DriverName%.sys [SourceDisksFiles] nullfilter.sys = 1,, [SourceDisksNames] 1 = %DiskId1%,,, [Strings] Msft = "Microsoft Corporation" ServiceDescription = "NullFilter mini-filter driver" ServiceName = "NullFilter" DriverName = "NullFilter" DiskId1 = "NullFilter Device Installation Disk" ;Instances specific information. DefaultInstance = "Null Instance" Instance1.Name = "Null Instance" Instance1.Altitude = "370020" Instance1.Flags = 0x1 ; Suppress automatic attachments下面对这些部分进行说明：以[]括起来的部分是一个节，inf文件就是由不同的节组成version节规定了程序的版本信息2.1 Class是程序的类，这个值是由驱动具体的功能决定的，这个值其实规定了Altitude的值，也就是驱动在IO栈上的位置。微软提供了不同用途的具体的class值，只需要去对应的网站查询，然后根据具体情况填写即可，点击这里查看2.2 ClassGuid：是上述Class所对应的GUID值，这个值在上面的链接中可以查到DestinationDirs 规定目标文件的路径，就是你希望将驱动文件安装到哪个目录下，填入的12表示是在C:\Windows\System32\Drivers目录DefaultInstall.Services节表示了要将这个驱动以服务的形式启动起来，AddService 表示添加一个服务，后面是服务的名称，标志，以及安装详细信息的节名称，这里指定安装详细信息在节NullFilter.Service中DefaultUninstall 表示卸载的节点，DelFiles值表名卸载的信息在节点NullFilter.DriverFiles中NullFilter.Service节点中规定了安装的详细信息：6.1 DisplayName表示的是服务的显示名称6.2 ServiceDescription 服务的描述信息6.3 ServiceBinary服务程序所在的路径6.4 Dependencies该服务的依赖项，就是这个服务要运行必须提前启动他的依赖项服务，Minfilter的驱动是依赖与"FltMgr"服务6.5 ServiceType 表示服务程序的类型，2 是表示文件系统的服务，这些值可以在MSDN中查到，只需要搜索关于Service的函数 即可，比如CreateService6.6 StartType 启动类型，3表示手动启动，这个信息也可以通过查询MSDN，方法与ServiceType值的查询相同6.7 ErrorControl，错误码，当驱动出错时系统怎么处理，1表示一个常规的处理方式6.8 LoadOrderGroup 加载这个驱动的用户组6.9 AddReg加入注册表信息所在的节点NullFilter.AddRegistry 加入注册表信息的节点，其中的每一项都是一个注册表的项String节中的内容可以看作是一组变量值的定义，当某些字符串过长或者需要反复使用，可以为它定义一个变量，为了以后使用时的方便。在使用时按照%变量名%的形式，最终在解析时会将其进行替换这份文件是一个通用的模板，以后在使用inf进行Minfilter驱动程序的安装时，只需要修改其中的名称，另外需要修改的可能就是服务启动的那部分内容了inf文件编写完成后，只需要点击右键-->安装即可，安装完成后在cmd下使用命令net start 驱动名 即可启动命令，卸载则使用net stop 驱动名用编程的方法动态加载安装驱动驱动安装主要的工作是将驱动加载到服务程序并填写相关注册表项，大致需要这样几步：调用OpenSCManager 打开服务控制管理器的句柄调用CreateService函数，为驱动创建一个服务设置注册表的值，其中打开注册表键使用函数RegCreateKeyEx,设置注册表的值用函数RegSetValueEx。BOOL InstallDriver(const char* lpszDriverName,const char* lpszDriverPath,const char* lpszAltitude) { char szTempStr[MAX_PATH]; HKEY hKey; DWORD dwData; char szDriverImagePath[MAX_PATH]; if( NULL==lpszDriverName || NULL==lpszDriverPath ) { return FALSE; } //得到完整的驱动路径 GetFullPathName(lpszDriverPath, MAX_PATH, szDriverImagePath, NULL); SC_HANDLE hServiceMgr=NULL;// SCM管理器的句柄 SC_HANDLE hService=NULL;// NT驱动程序的服务句柄 //打开服务控制管理器 hServiceMgr = OpenSCManager( NULL, NULL, SC_MANAGER_ALL_ACCESS ); if( hServiceMgr == NULL ) { // OpenSCManager失败 CloseServiceHandle(hServiceMgr); return FALSE; } // OpenSCManager成功 //创建驱动所对应的服务 hService = CreateService( hServiceMgr, lpszDriverName, // 驱动程序的在注册表中的名字 lpszDriverName, // 注册表驱动程序的DisplayName 值 SERVICE_ALL_ACCESS, // 加载驱动程序的访问权限 SERVICE_FILE_SYSTEM_DRIVER, // 表示加载的服务是文件系统驱动程序 SERVICE_DEMAND_START, // 注册表驱动程序的Start 值 SERVICE_ERROR_IGNORE, // 注册表驱动程序的ErrorControl 值 szDriverImagePath, // 注册表驱动程序的ImagePath 值 "FSFilter Activity Monitor",// 注册表驱动程序的Group 值 NULL, "FltMgr", // 注册表驱动程序的DependOnService 值 NULL, NULL); if( hService == NULL ) { if( GetLastError() == ERROR_SERVICE_EXISTS ) { //服务创建失败，是由于服务已经创立过 CloseServiceHandle(hService); // 服务句柄 CloseServiceHandle(hServiceMgr); // SCM句柄 return TRUE; } else { CloseServiceHandle(hService); // 服务句柄 CloseServiceHandle(hServiceMgr); // SCM句柄 return FALSE; } } CloseServiceHandle(hService); // 服务句柄 CloseServiceHandle(hServiceMgr); // SCM句柄 //------------------------------------------------------------------------------------------------------- // SYSTEM\\CurrentControlSet\\Services\\DriverName\\Instances子健下的键值项 //------------------------------------------------------------------------------------------------------- strcpy(szTempStr,"SYSTEM\\CurrentControlSet\\Services\\"); strcat(szTempStr,lpszDriverName); strcat(szTempStr,"\\Instances"); if(RegCreateKeyEx(HKEY_LOCAL_MACHINE,szTempStr,0,"",REG_OPTION_NON_VOLATILE,KEY_ALL_ACCESS,NULL,&hKey,(LPDWORD)&dwData)!=ERROR_SUCCESS) { return FALSE; } // 注册表驱动程序的DefaultInstance 值 strcpy(szTempStr,lpszDriverName); strcat(szTempStr," Instance"); if(RegSetValueEx(hKey,"DefaultInstance",0,REG_SZ,(CONST BYTE*)szTempStr,(DWORD)strlen(szTempStr))!=ERROR_SUCCESS) { return FALSE; } RegFlushKey(hKey);//刷新注册表 RegCloseKey(hKey); //------------------------------------------------------------------------------------------------------- // SYSTEM\\CurrentControlSet\\Services\\DriverName\\Instances\\DriverName Instance子健下的键值项 //------------------------------------------------------------------------------------------------------- strcpy(szTempStr,"SYSTEM\\CurrentControlSet\\Services\\"); strcat(szTempStr,lpszDriverName); strcat(szTempStr,"\\Instances\\"); strcat(szTempStr,lpszDriverName); strcat(szTempStr," Instance"); if(RegCreateKeyEx(HKEY_LOCAL_MACHINE,szTempStr,0,"",REG_OPTION_NON_VOLATILE,KEY_ALL_ACCESS,NULL,&hKey,(LPDWORD)&dwData)!=ERROR_SUCCESS) { return FALSE; } // 注册表驱动程序的Altitude 值 strcpy(szTempStr,lpszAltitude); if(RegSetValueEx(hKey,"Altitude",0,REG_SZ,(CONST BYTE*)szTempStr,(DWORD)strlen(szTempStr))!=ERROR_SUCCESS) { return FALSE; } // 注册表驱动程序的Flags 值 dwData=0x0; if(RegSetValueEx(hKey,"Flags",0,REG_DWORD,(CONST BYTE*)&dwData,sizeof(DWORD))!=ERROR_SUCCESS) { return FALSE; } RegFlushKey(hKey);//刷新注册表 RegCloseKey(hKey); return TRUE; }这里提供一个安装驱动的函数，在这个函数中将某些信息写入了注册表，注册表中变化的信息如下：HKEY_LOCAL_MACHINE中的SYSTEM\CurrentControlSet\Services\Nullfilter\Instances 中键 DefaultInstance = "nullfilter Instance"HKEY_LOCAL_MACHINE中的SYSTEM\CurrentControlSet\Services\Nullfilter\ nullfilter Instances 中键 altitude = “370020”,键Flags = 0启动驱动驱动的启动与普通的服务程序的启动方法一样，这里直接贴上代码：BOOL StartDriver(const char* lpszDriverName) { SC_HANDLE schManager; SC_HANDLE schService; if(NULL==lpszDriverName) { return FALSE; } schManager=OpenSCManager(NULL,NULL,SC_MANAGER_ALL_ACCESS); if(NULL==schManager) { CloseServiceHandle(schManager); return FALSE; } schService=OpenService(schManager,lpszDriverName,SERVICE_ALL_ACCESS); if(NULL==schService) { CloseServiceHandle(schService); CloseServiceHandle(schManager); return FALSE; } if(!StartService(schService,0,NULL)) { CloseServiceHandle(schService); CloseServiceHandle(schManager); if( GetLastError() == ERROR_SERVICE_ALREADY_RUNNING ) { // 服务已经开启 return TRUE; } return FALSE; } CloseServiceHandle(schService); CloseServiceHandle(schManager); return TRUE; }停止驱动的运行BOOL StopDriver(const char* lpszDriverName) { SC_HANDLE schManager; SC_HANDLE schService; SERVICE_STATUS svcStatus; bool bStopped=false; schManager=OpenSCManager(NULL,NULL,SC_MANAGER_ALL_ACCESS); if(NULL==schManager) { return FALSE; } schService=OpenService(schManager,lpszDriverName,SERVICE_ALL_ACCESS); if(NULL==schService) { CloseServiceHandle(schManager); return FALSE; } if(!ControlService(schService,SERVICE_CONTROL_STOP,&svcStatus) && (svcStatus.dwCurrentState!=SERVICE_STOPPED)) { CloseServiceHandle(schService); CloseServiceHandle(schManager); return FALSE; } CloseServiceHandle(schService); CloseServiceHandle(schManager); return TRUE; }删除驱动BOOL DeleteDriver(const char* lpszDriverName) { SC_HANDLE schManager; SC_HANDLE schService; SERVICE_STATUS svcStatus; schManager=OpenSCManager(NULL,NULL,SC_MANAGER_ALL_ACCESS); if(NULL==schManager) { return FALSE; } schService=OpenService(schManager,lpszDriverName,SERVICE_ALL_ACCESS); if(NULL==schService) { CloseServiceHandle(schManager); return FALSE; } ControlService(schService,SERVICE_CONTROL_STOP,&svcStatus); if(!DeleteService(schService)) { CloseServiceHandle(schService); CloseServiceHandle(schManager); return FALSE; } CloseServiceHandle(schService); CloseServiceHandle(schManager); return TRUE; }Minfilter中如何获取各种信息的值Minfilter中将IRP进行了封装，但是在获取各种值时基本上变化不大，而且相对于之前的Sfilter简单了许多，下面假定在函数中有了它的CALL_BACK_DATA结构，有这样一条语句PFLT_CALLBACK_DATA Data获取当前进程的EPROCESS结构/*如果当前线程的ETHREAD结构不为NULL则根据线程ETHREAD来获取进程否则调用函数PsGetCurrentProcess()获取当前进程的EPROCESS结构*/ PEPROCESS processObject = Data->Thread ? IoThreadToProcess(Data->Thread) : PsGetCurrentProcess();向R3层返回数据Data->IoStatus.Status = ntStatus; Data->IoStatus.Information = 0;与使用IRP相似，在DATA中仍然使用IoStatus成员向R3返回，上述两句的意思与使用IRP时完全相同文件路径的获取文件路径的获取与Sfilter相比，简单了许多，只需要调用一个函数FltGetFileNameInformation，这个函数的定义在MSDN中可以查到，所以就不再这里做过多的说明，该函数会返回一个FLT_FILE_NAME_INFORMATION结构体用来保存文件名信息，结构体FLT_FILE_NAME_INFORMATION的定义如下所示typedef struct _FLT_FILE_NAME_INFORMATION { USHORT Size; FLT_FILE_NAME_PARSED_FLAGS NamesParsed; FLT_FILE_NAME_OPTIONS Format; UNICODE_STRING Name; UNICODE_STRING Volume; UNICODE_STRING Share; UNICODE_STRING Extension; UNICODE_STRING Stream; UNICODE_STRING FinalComponent; UNICODE_STRING ParentDir; } FLT_FILE_NAME_INFORMATION, *PFLT_FILE_NAME_INFORMATION;这个结构体记录了文件路径的各种信息，其中各个字符串都是根据Format的值来进行格式化得到的，需要注意的是在上述位置得到的文件名是类似与“\Device\HarddiskVolume1\Documents and Settings\MyUser\My Documents\Test Results.txt:stream1”的而不是我们之前熟悉的"C:\Documents and Settings\MyUser\My Documents\Test Results.txt:stream1",这就需要进行转化。需要注意的是在获取文件名时要在PostCreate函数中获取，因为当调用这个函数时说明根据传进来的文件路径已经正确打开了文件，这个时候的路径名一定是可靠的。 NTSTATUS ntStatus; PFLT_FILE_NAME_INFORMATION pNameInfo = NULL; UNREFERENCED_PARAMETER( Data ); UNREFERENCED_PARAMETER( FltObjects ); UNREFERENCED_PARAMETER( CompletionContext ); UNREFERENCED_PARAMETER( Flags ); //获取文件路径信息 ntStatus = FltGetFileNameInformation(Data, FLT_FILE_NAME_NORMALIZED| FLT_FILE_NAME_QUERY_DEFAULT, &pNameInfo); if (NT_SUCCESS(ntStatus)) { //解析获取到的信息 FltParseFileNameInformation(pNameInfo); DbgPrint("FileName:%wZ\n", &pNameInfo->Name); //使用完成后释放这个空间 FltReleaseFileNameInformation(pNameInfo); }函数FltGetFileNameInformation会自动为我们分配一个缓冲区来存储文件的信息，所以最后需要调用Release函数释放。另外通过调试的情况来看，FltGetFileNameInformation函数并不能获取文件路径的所有信息，一些扩展信息像Extension或者Parent这样的信息开始是没有的，只有通过FltParseFileNameInformation在已有信息的基础之上进行解析才会有。至于重命名的文件路径的获取使用下面的语句：PFILE_RENAME_INFORMATION pFileRenameInfomation = (PFILE_RENAME_INFORMATION)Data->Iopb->Parameters.SetFileInformation.InfoBuffer;在MInfilter中进行文件操作尽量使用以Flt开头的函数，不要使用Zw开头的那一组，以Zw开头的函数最终会触发Minfilter的回调函数，最终会造成无限递归Minfilter上下文在编程中，我们经常会遇到上下文这个概念，比如说进程上下文，线程上下文等等，在这里上下文表示某些代码执行的具体环境，系统一般位于进程上下文和中断上下文。当系统处理进程上下文时，系统在代替R3层做某些事，此时系统在调用系统API，执行系统功能，当系统处于进程上下文时是可以被挂起的。而当系统响应中断与具体硬件进行交互时处于中断上下文，此时的数据都位于非分页内存，而且不能睡眠而Minfilter上下文指的并不是代码运行的环境，而是一组数据，这组数据是附加到具体的设备对象上的，由用户自己定义。在使用时先利用函数AllocateContext分配一段内存空间，然后使用一组Set和Get函数来设置和获取设备上下文。具体的函数由不同的上下文来决定，下面是不同的上下文与他们对应的Set函数之间的关系Context TypeSet-Context RoutineFLT_FILE_CONTEXTWindows Vista and later only.) FltSetFileContextFLT_INSTANCE_CONTEXTFltSetInstanceContextFLT_STREAM_CONTEXTFltSetStreamContextFLT_STREAMHANDLE_CONTEXTFltSetStreamHandleContextFLT_TRANSACTION_CONTEXT(Windows Vista and later only.) FltSetTransactionContextFLT_VOLUME_CONTEXTFltSetVolumeContextGet函数的使用与上述相同。最后使用完成后需要使用FltReleaseContext来释放这个上下文。下面是一个使用的具体例子typedef struct _INSTANCE_CONTEXT { … } INSTANCE_CONTEXT, *PINSTANCE_CONTEXT; PINSTANCE_CONTEXT pContext = NULL; //从设备对象上获取上下文 ntStatus = FltGetInstanceContext(FltObjects->Instance, & pContext); if(NT_SUCCESS(Status) == FALSE) { //设备上没有上下文则分配上下文的内存 ntStatus = FltAllocateContext(g_pFilter,FLT_INSTANCE_CONTEXT, sizeof(INSTANCE_CONTEXT), PagedPool,& pContext); if(NT_SUCCESS(Status) == FALSE) { //返回资源不足 return STATUS_INSUFFICIENT_RESOURCES; } RtlZeroMemory(pContext, sizeof(INSTANCE_CONTEXT)); } pContext ->m_DeviceType = VolumeDeviceType; pContext->m_FSType = VolumeFilesystemType; FltSetInstanceContext(FltObjects->Instance, FLT_SET_CONTEXT_REPLACE_IF_EXISTS,pContext,NULL); if (pContext) { FltReleaseContext(pContext); } //获取访问 PINSTANCE_CONTEXT pContext = NULL; Status = FltGetInstanceContext(FltObjects->Instance,&pContext); //下面是使用这个上下文，和一些其他的操作 pContext->xxx = xxx;回调函数运行的中断请求级别（IRQL）pre回调函数可以运行在APC_LEVEL或者PASSIVE_LEVEL 级别，但是一般是运行在PASSIVE_LEVEL级别如果一个Pre函数返回的是FLT_PREOP_SYNCHRONIZE，那么相对的，在同一个线程内部，它对应的POST函数将在IRQL <= APC_LEVEL级别运行。与对应的Pre在一个线程内时，fast IO请求对应的Post函数运行在PASSIVE_LEVEL级别Create回调的Post函数运行在PASSIVE_LEVEL级别当我们不确定当前代码所处的IRQL时可以使用函数KeCurrentIrql获取当前执行环境所在的IRQL。R3 与R0的通信R3在调用Minfilter中的相关函数时需要包含相关的库文件，与Lib文件，具体怎么包含这个我不太清楚，只需要在库项目属性的VC++目录下面这几项包含具体的路径即可包含目录 :“$(VC\_IncludePath);$(WindowsSDK_IncludePath);”库路径: "$(VC\_LibraryPath_x86);$(WindowsSDK\_LibraryPath\_x86);$(NETFXKitsDir)Lib\um\x86"之前R3与R0进行通信是通过R3调用DeviceIoControl函数将数据下发到R0层，然后R3等待一个事件，在R0处理完成R3的请求并准备好往上发的数据后将事件的对象设置为有信号，这样R3再从缓冲区中取数据，完成双方的通信，但是在Minfilter中准备了专门的函数用于双方通信。R3向R0下发数据R3层通过函数FilterSendMessage向R0下发数据，而R0通过fnMessageFromClient接收从R3发下来的数据。在Minfilter中R3与R0是通过各自的端口进行通讯的，这个端口与传统意义上的网络的通信端口不同，是一个抽象的概念，不需要太过于关注。在与R3进行通讯之前需要设置这个端口，端口的设置使用函数FltCreateComunicationPort，在这个函数调用时需要提供这样几个回调函数ConnectNotifyCallback：这个函数在R3层链接到R0的这个通讯端口时调用，在这个函数中可以拿到R3的进程句柄和R3的端口DisconnectNotifyCallback：当R3层与R0层断开时调用这个回调函数MessageNotifyCallback：当R3有数据下发下来调用这个回调，在这个函数中取R3发下来的数据R0向R3上报数据R0向R3上报数据时是一个双向的过程，R0既要上报数据，又要等待R3的返回，就好像之前的弹窗一样，当R0上报数据后就等待40s，在接收到R3的进一步指示时进行下一步，R0向R3上报大致经历这样的几个过程：R0通过函数FltSengMesage将数据发送到R3R3通过函数FilterGetMessage函数接收到R0的数据，并进行相应的处理处理完成后，调用函数FilterReplyMessage将处理结果返回给R0。另外需要注意一点，在进行通讯时需要两套数据结构，这两套分别运用在R3和R0两层，每一层都有两个数据结构，用来表示接收和返回的数据，拿R3来说，它需要一个MESSAGE结构体来接收从R0层发过来的数据，另外需要一个REPLY用于向R0返回数据。R3上报和下发的数据相比于R0需要多加一个FILTER_MESSAGE_HEADER的头，便于Minfilter分辨是哪个客户端下发的数据，Minfilter 根据这个头做相关的处理后将其于的数据发送到R0，所以R0能够正确知道是哪个进程在进行相关请求，而不需要添加额外的结构体下面是一个例子NTSTATUS ScannerpScanFileInUserMode ( __in PFLT_INSTANCE Instance, __in PFILE_OBJECT FileObject, __out PBOOLEAN SafeToOpen ) /*读取文件中的部分数据，然后交由R3处理，并根据R3返回的结果判断R3是否安全*/ { NTSTATUS status = STATUS_SUCCESS; PVOID buffer = NULL; ULONG bytesRead; PSCANNER_NOTIFICATION notification = NULL; FLT_VOLUME_PROPERTIES volumeProps; LARGE_INTEGER offset; ULONG replyLength, length; PFLT_VOLUME volume = NULL; *SafeToOpen = TRUE; if (ScannerData.ClientPort == NULL) { return STATUS_SUCCESS; } try { status = FltGetVolumeFromInstance( Instance, &volume ); if (!NT_SUCCESS( status )) { leave; } status = FltGetVolumeProperties( volume, &volumeProps, sizeof( volumeProps ), &length ); if (NT_ERROR( status )) { leave; } //取1024和扇区的最大值，保证读取的数据至少有一个扇区的大小 length = max( SCANNER_READ_BUFFER_SIZE, volumeProps.SectorSize ); /*分配一块内存用于从文件中读取数据，在minfilter中进行文件操作时申请缓冲区最好使用flt开头的一组函数，因为它不是简单的分配一块内存，还能保证在有程序使用这段内存时不会出现内存已被释放的情况，内部可能也用了引用计数*/ buffer = FltAllocatePoolAlignedWithTag( Instance, NonPagedPool, length, 'nacS' ); if (NULL == buffer) { status = STATUS_INSUFFICIENT_RESOURCES; leave; } //构建发送给R3层的结构体的内存 notification = ExAllocatePoolWithTag( NonPagedPool, sizeof( SCANNER_NOTIFICATION ), 'nacS' ); if(NULL == notification) { status = STATUS_INSUFFICIENT_RESOURCES; leave; } offset.QuadPart = bytesRead = 0; status = FltReadFile( Instance, FileObject, &offset, length, buffer, FLTFL_IO_OPERATION_NON_CACHED | FLTFL_IO_OPERATION_DO_NOT_UPDATE_BYTE_OFFSET, &bytesRead, NULL, NULL ); if (NT_SUCCESS( status ) && (0 != bytesRead)) { notification->BytesToScan = (ULONG) bytesRead; /*将这段信息发送到R3，这个函数是一个阻塞的函数，只有当超时值过了或者R3返回了数据才会返回，在这设置超时值为NULL表示会一直等待，在这返回值也是使用notification做为接受返回值的缓冲，在这不会出现覆盖的情况，因为这个函数在调用后首先是R3接受数据，然后进行处理，处理完成后R3才会主动调用另一个API返回数据，所以这里有一个时间差，当获取到返回值时之前传入的数据已经没有用了，这里将发送的缓冲与返回的缓冲定义为同一个只是为了节省内存*/ RtlCopyMemory( &notification->Contents, buffer, min( notification->BytesToScan, SCANNER_READ_BUFFER_SIZE ) ); replyLength = sizeof( SCANNER_REPLY ); //在这我们将 status = FltSendMessage( ScannerData.Filter, &ScannerData.ClientPort, notification, sizeof(SCANNER_NOTIFICATION), notification, &replyLength, NULL ); if (STATUS_SUCCESS == status) { *SafeToOpen = ((PSCANNER_REPLY) notification)->SafeToOpen; } else { DbgPrint( "!!! scanner.sys --- couldn't send message to user-mode to scan file, status 0x%X\n", status ); } } } finally { //最后清理内存 if (NULL != buffer) { FltFreePoolAlignedWithTag( Instance, buffer, 'nacS' ); } if (NULL != notification) { ExFreePoolWithTag( notification, 'nacS' ); } if (NULL != volume) { FltObjectDereference( volume ); } } return status; }这个例子演示了R0层如何从磁盘中读取文件内容，然后发送到R3，并从R3层上接受返回。下面这个例子将演示R3如何读取R0发上来的数据 while (TRUE) { //这是一个阻塞函数，当能从R0接受到数据的时候返回 result = GetQueuedCompletionStatus( Context->Completion, &outSize, &key, &pOvlp, INFINITE ); message = CONTAINING_RECORD( pOvlp, SCANNER_MESSAGE, Ovlp ); if (!result) { hr = HRESULT_FROM_WIN32( GetLastError() ); break; } printf( "Received message, size %d\n", pOvlp->InternalHigh ); notification = &message->Notification; assert(notification->BytesToScan <= SCANNER_READ_BUFFER_SIZE); /*R3层定义的这个SCANNER_MESSAGE结构体是在notification这个结构体的基础之上加了一个头，所以大小会大于这个notification*/ __analysis_assume(notification->BytesToScan <= SCANNER_READ_BUFFER_SIZE); //这个函数是一个自定义函数，用来扫描R0传上来的数据有没有特定的字符 result = ScanBuffer( notification->Contents, notification->BytesToScan ); replyMessage.ReplyHeader.Status = 0; replyMessage.ReplyHeader.MessageId = message->MessageHeader.MessageId; replyMessage.Reply.SafeToOpen = !result; printf( "Replying message, SafeToOpen: %d\n", replyMessage.Reply.SafeToOpen ); //向R0返回数据 hr = FilterReplyMessage( Context->Port, (PFILTER_REPLY_HEADER) &replyMessage, sizeof( replyMessage ) ); if (SUCCEEDED( hr )) { printf( "Replied message\n" ); } else { printf( "Scanner: Error replying message. Error = 0x%X\n", hr ); break; } memset( &message->Ovlp, 0, sizeof( OVERLAPPED ) ); //再次等待从R0下发的数据 hr = FilterGetMessage( Context->Port, &message->MessageHeader, FIELD_OFFSET( SCANNER_MESSAGE, Ovlp ), &message->Ovlp ); if (hr != HRESULT_FROM_WIN32( ERROR_IO_PENDING )) { break; } }

驱动开发入门——NTModel 上一篇博文中主要说明了驱动开发中基本的数据类型，认识这些数据类型算是驱动开发中的入门吧，这次主要说明驱动开发中最基本的模型——NTModel。介绍这个模型首先要了解R3层是如何通过应用层API进入到内核，内核又是如何将信息返回给R3，另外会介绍R3是如何直接向R0层下命令。API调用的基本流程一般在某些平台上进行程序开发，都需要使用系统提供的统一接口，linux平台直接提供系统调用，而windows上提供API，这两个并不是同一个概念（之前我一直分不清楚），虽然它们都是系统提供的实现某种功能的接口，但是它们有着本质的区别，系统调用在调用时会陷入到内核态，而API则不是这样，例如对于CreateFile这个我们不能说它是一个系统调用，在这个函数中并没有立即陷入到内核态，而是先进行参数检查，然后通过其他的一系列操作之后调用系统调用而进入到内核，所以它并不是系统调用。windows在应用层提供了3个重要的动态库，分别是kernel.dll uer32.dll gdi.dll （现在基本上将所有的API都封装到kernell.dll中）当用户程序调用一个API函数时，在这个API内部会调用用封装到ntdll.dll中以Zw或者Nt开头的同名函数，这些函数主要负责从用户态切换到内核态，这些函数叫做Native API，Native API进入到内核的方式是产生一个中断（XP及以前的版本）和调用sysenter（XP以上的版本），Native API在进入到内核中时会带上一个服务号，系统根据这个服务号在SSDT表中查找到相关的服务函数，最后调用这些服务函数完成相关功能，这个过程可以用下面的图来说明：下面以CreateFile为例说明具体的调用过程：应用层调用CreateFile函数这个函数实际上被封装到了kernel32.dll中，在这个函数中调用NtCreateFile，这就是调用ntdll.dll中的native api ，ntdll.dll中一般又两组函数——以Nt开头，以Zw开头的，这两组函数本身没有什么太大的区别。native api中通过中断 int 2eh（windows 2000 及以下），或者通过sysenter指令（windows xp及以上）进入内核，这种方式称为软中断，在产生中断时会带上一个服务号，根据服务号在ssdt表中以服务号进行查找（类似与8086中的中断机制）根据SSDT表中记录的服务函数地址，调用相关的服务函数。然后进入到执行组件中，对于CreateFile的操作，这个时候会调用IO管理器，IO管理器负责发起IO操作请求，并管理这些请求，主要时生成一个IRP结构，系统中有不同的管理器，主要有这样几个——虚拟内存管理器，IO管理器，对象管理器，进程管理器，线程管理器，配置管理器。管理器生成一个IRP请求，并调用内核中的驱动，来相应这个操作，对于CreateFile来说会调用NtCreateFile函数。最后调用内核实现部分，也就是硬件抽象层。最后由硬件抽象层操作硬件，完成打开或者创建文件的操作。NTModel详解R3与R0互相通信在驱动程序中，入口是DriverEntry，函数会带入一个DriverObject指针。这个对象中有许多回调函数，它会根据R3层下发的操作调用对应的回调函数，比如应用层调用CreatFile时在驱动层会调用DispatchCreate。这样我们只要写好DispatchCreate就可以处理由R3层下发的CreateFile命令。上述的一些函数只适用于一般的操作，对于一些特殊的，比如R3层要R0层产生一个输出语句等等，这个特殊的操作是通过DeviceIoControl向R0下发一个控制命令，在R0层根据这个控制码来识别具体是哪种控制，需要R0做哪种操作，函数原型如下：BOOL DeviceIoControl( HANDLE hDevice, //驱动的设备对象句柄 DWORD dwIoControlCode, //控制码 LPVOID lpInBuffer, //发往R0层的数据 DWORD nInBufferSize, //数据大小 LPVOID lpOutBuffer, //提供一个缓冲区，接受R0返回的数据 DWORD nOutBufferSize, //缓冲区的大小 LPDWORD lpBytesReturned, //R0实际返回数据的大小 LPOVERLAPPED lpOverlapped //完成例程 );IRP的简介R3与R0的通信是通过IRP进行数据的交换，IRP的定义如下：typedef struct DECLSPEC_ALIGN(MEMORY_ALLOCATION_ALIGNMENT) _IRP { CSHORT Type; USHORT Size; PMDL MdlAddress; ULONG Flags; union { struct _IRP *MasterIrp; PVOID SystemBuffer; } AssociatedIrp; ... IO_STATUS_BLOCK IoStatus; CHAR StackCount; CHAR CurrentLocation; ... PVOID UserBuffer; ... struct { union { struct _IO_STACK_LOCATION *CurrentStackLocation; ... }; } IRP;IRP主要分为两部分，一部分是头，另一部分是IRP栈，在上一篇分析驱动中的数据结构时，说过驱动设备时分层的，上层驱动设备完成后，需要发到下层驱动设备，所有驱动设备公用IRP的栈顶，但是每个驱动都各自有自己的IRP栈，它们的关系如下如所示：_IO_STACK_LOCATION 的结构如下：typedef struct _IO_STACK_LOCATION { UCHAR MajorFunction; UCHAR MinorFunction; UCHAR Flags; UCHAR Control; union { struct { PIO_SECURITY_CONTEXT SecurityContext; ULONG Options; USHORT POINTER_ALIGNMENT FileAttributes; USHORT ShareAccess; ULONG POINTER_ALIGNMENT EaLength; } Create; ... struct { ULONG Length; ULONG POINTER_ALIGNMENT Key; LARGE_INTEGER ByteOffset; } Read; struct { ULONG Length; ULONG POINTER_ALIGNMENT Key; LARGE_INTEGER ByteOffset; } Write; ... struct { ULONG OutputBufferLength; ULONG POINTER_ALIGNMENT InputBufferLength; ULONG POINTER_ALIGNMENT IoControlCode; PVOID Type3InputBuffer; } DeviceIoControl; ... struct { PVOID Argument1; PVOID Argument2; PVOID Argument3; PVOID Argument4; } Others; } Parameters; PDEVICE_OBJECT DeviceObject; PFILE_OBJECT FileObject; PIO_COMPLETION_ROUTINE CompletionRoutine; PVOID Context; } IO_STACK_LOCATION, *PIO_STACK_LOCATION;这个结构中有一个共用体，当处理不同的R3层请求时系统会填充对应的共用体。源代码分析//设备名 #define DEVICE_NAME L"\\device\\NtDevice" #define LINK_NAME L"\\??\\NtDevice" //DriverEntry NTSTATUS DriverEntry(PDRIVER_OBJECT pDriverObject, PUNICODE_STRING pRegisterPath) { PDEVICE_OBJECT pDeviceObject = NULL; UNICODE_STRING uDeviceName = { 0 }; UNICODE_STRING uLinkName = { 0 }; NTSTATUS status = 0; UNREFERENCED_PARAMETER(pRegisterPath); DbgPrint("Start Driver......\n"); pDriverObject->DriverUnload = UnloadDriver; //创建设备对象 RtlInitUnicodeString(&uDeviceName, DEVICE_NAME); status = IoCreateDevice(pDriverObject, 0, &uDeviceName, FILE_DEVICE_UNKNOWN, 0, FALSE, &pDeviceObject); if (!NT_SUCCESS(status)) { DbgPrint("create device error!\n"); return status; } pDeviceObject->Flags |= DO_BUFFERED_IO; //创建符号连接 RtlInitUnicodeString(&uLinkName, LINK_NAME); status = IoCreateSymbolicLink(&uLinkName, &uDeviceName); if (!NT_SUCCESS(status)) { DbgPrint("create link name error!\n"); return status; } //注册分发函数 for (ULONG i = 0; i < IRP_MJ_MAXIMUM_FUNCTION + 1; i++) { pDriverObject->MajorFunction[i] = IoDispatchCommon; } pDriverObject->MajorFunction[IRP_MJ_CREATE] = IoDispatchCreate; pDriverObject->MajorFunction[IRP_MJ_READ] = IoDispatchRead; pDriverObject->MajorFunction[IRP_MJ_WRITE] = IoDispatchWrite; pDriverObject->MajorFunction[IRP_MJ_DEVICE_CONTROL] = IoDispatchControl; pDriverObject->MajorFunction[IRP_MJ_CLOSE] = IoDispatchClose; pDriverObject->MajorFunction[IRP_MJ_CLEANUP] = IoDispatchClean; return STATUS_SUCCESS; }这个函数是驱动的入口函数，类似与main函数或者WinMain函数。在该函数中首先创建一个控制设备对象，并为它创建一个符号链接，因为R3层不能直接通过设备的名称来访问设备，必须通过其符号链接。需要注意，设备名称必须以“\\device”开头，而符号链接需要以“\\??”开头，否则创建设备和符号链接会失败。然后为这个驱动程序注册分发函数，分发函数保存在DriverObject结构中MajorFunction中，这个时一个数组，元素个数为IRP_MJ_MAXIMUM_FUNCTION，系统为每个位置定义一个宏，我们根据这个宏，在数据中填入对应 的函数指针，系统会根据R3层的操作来调用具体的函数。另外DriverObject中的DriverUnload 保存的是卸载驱动时系统回调用的函数，在这个函数中主要完成资源的释放工作//UnloadDriver VOID UnloadDriver(PDRIVER_OBJECT pDriverObject) { UNICODE_STRING uLinkName = { 0 }; UNREFERENCED_PARAMETER(pDriverObject); RtlInitUnicodeString(&uLinkName, LINK_NAME); IoDeleteSymbolicLink(&uLinkName); IoDeleteDevice(pDriverObject->DeviceObject); DbgPrint("Unload Driver......\n"); }在这个函数中主要释放了之前创建的符号链接和控制设备对象。NTSTATUS IoDispatchCommon(PDEVICE_OBJECT DeviceObject, PIRP pIrp) { UNREFERENCED_PARAMETER(DeviceObject); //向R3返回成功 pIrp->IoStatus.Status = STATUS_SUCCESS; //向R3返回的数据长度为0，不向R3返回数据 pIrp->IoStatus.Information = 0; //默认直接返回 IoCompleteRequest(pIrp, IO_NO_INCREMENT); return STATUS_SUCCESS; }这个函数是我们注册的默认处理函数，它每步的操作在注释中也写了，需要注意的是在pIrp->IoStatus.Status = STATUS_SUCCESS;语句是向R3返回执行的状态，而最后返回成功是给驱动程序看的。//IoDispatchRead NTSTATUS IoDispatchRead(PDEVICE_OBJECT DeviceObject, PIRP pIrp) { //处理R3层的读命令,将数据返回给R3层 WCHAR wHello[] = L"hello world"; ULONG uReadLength = 0; WCHAR *pBuffer = pIrp->AssociatedIrp.SystemBuffer; ULONG uBufferLen = 0; ULONG uMin = 0; PIO_STACK_LOCATION pCurrStack = IoGetCurrentIrpStackLocation(pIrp); UNREFERENCED_PARAMETER(DeviceObject); uBufferLen = pCurrStack->Parameters.Read.Length; uReadLength = sizeof(wHello); uMin = (uReadLength < uBufferLen) ? uReadLength : uBufferLen; RtlCopyMemory(pBuffer, wHello, uMin); pIrp->IoStatus.Status = STATUS_SUCCESS; pIrp->IoStatus.Information = uMin; IoCompleteRequest(pIrp, IO_NO_INCREMENT); return STATUS_SUCCESS; }这个函数主要用来处理应用层的ReadFile请求，这个函数主要是将一段字符串拷贝到通信用的缓冲区中，模拟读的操作。，需要注意的是这个地址要根据不同的设备类型来不同的对待，对于DO_BUFFERED_IO类型的设备，是保存在pIrp->AssociatedIrp.SystemBuffer中，对于DO_DIRECT_IO类型的设备，这个缓冲区的地址是MdlAddress。而对于ReadFile这个API来说，应用层在调用这个函数时会给一个缓冲区的大小，为了获取这个大小，首先得到当前的IRP栈，这个操作用函数IoGetCurrentIrpStackLocation可以得到，然后在当前栈的Parameters共用体中，调用Read部分的Length。当得到这个缓冲区大小后，取缓冲区大小和对应字符串的大小的最小值，为什么要这样做？我们不妨考虑如果用缓冲区的长度的话，当这个长度比字符串的长度长，那么在拷贝时就会将字符串后面的一些无用内存给拷贝进去了，一来效率不高，二来这样应用层得到了内核层中内存的部分数据，存在安全隐患，如果我们采用字符串的长度，可能会出现用户提供的缓冲区不够的情况，这样会造成越界。所以采用它们的最小值是最合理的。完成之后返回，这个时候要注意返回的长度这一项需要填上真实拷贝的大小，不然R3是得不到数据的，或者得到的数据不完整。NTSTATUS IoDispatchWrite(PDEVICE_OBJECT DeviceObject, PIRP pIrp) { //接受R3的写命令 UNICODE_STRING uWriteString = { 0 }; WCHAR *pBuffer = NULL; ULONG uWriteLength = 0; PIO_STACK_LOCATION pStackIrp = IoGetCurrentIrpStackLocation(pIrp); UNREFERENCED_PARAMETER(DeviceObject); uWriteLength = pStackIrp->Parameters.Write.Length; uWriteString.MaximumLength = uWriteLength; uWriteString.Length = uWriteLength - 1 * sizeof(WCHAR); uWriteString.Buffer = ExAllocatePoolWithTag(PagedPool, uWriteLength, 'TSET'); pBuffer = pIrp->AssociatedIrp.SystemBuffer; if (NULL == uWriteString.Buffer) { DbgPrint("Allocate Memory Error!\n"); pIrp->IoStatus.Status = STATUS_INSUFFICIENT_RESOURCES; pIrp->IoStatus.Information = 0; IoCompleteRequest(pIrp, IO_NO_INCREMENT); return STATUS_INSUFFICIENT_RESOURCES; } RtlCopyMemory(uWriteString.Buffer, pBuffer, uWriteLength); DbgPrint("Write Date: %wZ\n", &uWriteString); pIrp->IoStatus.Status = STATUS_SUCCESS; pIrp->IoStatus.Information = 0; IoCompleteRequest(pIrp, IO_NO_INCREMENT); return STATUS_SUCCESS; }这个函数用来处理WriteFile的请求，首先通过IRP中传进来的缓冲区的地址得到这个数据，然后将数据打印出来，通过这种方式来模拟向R3文件中写入数据。//定义的控制码 #define IOCTL_BASE 0x800 #define MYIOCTRL_CODE(i) CTL_CODE(FILE_DEVICE_UNKNOWN, (IOCTL_BASE + i), METHOD_BUFFERED, FILE_ANY_ACCESS) #define CTL_PRINT MYIOCTRL_CODE(1) #define CTL_HELLO MYIOCTRL_CODE(2) #define CTL_BYE MYIOCTRL_CODE(3) //IoDispatchControl函数 NTSTATUS IoDispatchControl(PDEVICE_OBJECT DeviceObject, PIRP pIrp) { UNREFERENCED_PARAMETER(DeviceObject); ULONG uBufferLength = 0; WCHAR *pBuffer = NULL; ULONG uIOCtrlCode = 0; PIO_STACK_LOCATION pStack = IoGetCurrentIrpStackLocation(pIrp); uBufferLength = pStack->Parameters.DeviceIoControl.InputBufferLength; uIOCtrlCode = pStack->Parameters.DeviceIoControl.IoControlCode; pBuffer = pIrp->AssociatedIrp.SystemBuffer; switch (uIOCtrlCode) { case CTL_BYE: DbgPrint("Good Bye"); break; case CTL_HELLO: DbgPrint("Hello World\n"); break; case CTL_PRINT: DbgPrint("%S", pBuffer); break; default: DbgPrint("unknow command\n"); } pIrp->IoStatus.Information = 0; pIrp->IoStatus.Status = STATUS_SUCCESS; IoCompleteRequest(pIrp, IO_NO_INCREMENT); return STATUS_SUCCESS; }这个宏CTL_CODE是微软官方定义的，主要用来将控制码和对应类型的设备进行绑定，主要传入4个参数，第一个是设备的类型，第二个是具体的控制码，需要注意的是：为了与微软官方的控制码区分，自定义的控制码需要在0x800以上。第三个参数是对应控制码传递参数的方式，主要的几种方式与设备对象和R3层传递数据的方式类似，我们在这传入的是METHOD_BUFFERED，表示的是通过内存拷贝的方式将R3的数据传入到R0。最后一个是操作权限，我们给它所有的权限。在函数中我们根据R3传入的控制码来进行不同的操作。R3部分的代码R3部分主要完成的是驱动程序的加载、卸载、以及向驱动程序发送命令。驱动的加载和卸载是通过注册并启动服务和关闭并删除服务的方式进行的，至于怎么操作一个服务，请看本人另外一篇关于服务操作的博客。需要注意的是在创建服务时需要填入服务程序所在的路径，这个时候需要填生成的.sys文件的路径，不要写之前定义的设备名或者符号链接名。在这主要贴出控制部分的代码：//打开设备，获取它的设备句柄 HANDLE hDevice = CreateFileA("\\\\.\\NtDevice", GENERIC_WRITE | GENERIC_READ, 0, NULL, OPEN_EXISTING, FILE_ATTRIBUTE_NORMAL, NULL); if (NULL == hDevice) { printf("打开设备失败\n"); return; } //读 CHAR szBuf[255] = ""; ULONG uLength = 0; ReadFile(hDevice, szBuf, 255, &uLength, NULL); printf("Read Date:%s\n", szBuf); //写 WCHAR wHello[] = L"Hello world"; WriteFile(hDevice, wHello, (wcslen(wHello) + 1) * sizeof(WCHAR), &uLength, NULL); printf("写操作完成"); //向其发送控制命令 WCHAR wCtlString[] = L"C:\\test.txt"; DeviceIoControl(hDevice, CTL_PRINT, wCtlString, (wcslen(wCtlString) + 1) * sizeof(WCHAR), NULL, 0, NULL, NULL); DeviceIoControl(hDevice, CTL_HELLO, NULL, 0, NULL, 0, NULL, NULL); DeviceIoControl(hDevice, CTL_BYE, NULL, 0, NULL, 0, NULL, NULL); printf("控制操作完成"); CloseHandle(hDevice);要控制一个设备对象，必须先得到设备对象的句柄，获得这个句柄，我们是通过函数CreateFile来得到的，这个时候填入的文件名应该是之前注册的符号链接的名字，在R3中这个名字以“\\\\ .”开头并加上我们为它提供的符号链接名。在调用CreateFile时会触发之前定义的DispatchCreate函数。然后我们通过调用ReadFile和WriteFile分别触发读写操作，最后调用DeviceIoControl函数，发送控制命令，在R3层中也要定义一份与R0中一模一样的控制码。这样就基本实现了R3与R0通信。有的时候在加载驱动的时候，系统会报错，返回码为2，表示系统找不到驱动对应的文件，这个时候可能是文件的路径的问题，这个时候可以在系统的注册表HKEY_LOCAL_MACHINE\SYSTEM\ControlSet001\services\下，找到我们的驱动（还有可能是在ControlSet002）对应的路径，然后将R3程序拷贝到这个路径下，基本就可以解决这个问题

windows 驱动开发入门——驱动中的数据结构 最近在学习驱动编程方面的内容，在这将自己的一些心得分享出来，供大家参考，与大家共同进步，本人学习驱动主要是通过两本书——《独钓寒江 windows安全编程》 和 《windows驱动开发技术详解》。驱动开发过程中，主要使用的C语言，虽说C中定义了许多数据类型，但是一般来说在编码上还是习惯与使用WDK的规范，虽说这个不是必须的，比如有这样一句unsigned long ul = 0;这个数据的大小根据不同的机器不同的编译器环境略有不同，这样代码就产生了不可控的行为，但是WDK上专门定义了相关的宏，环境不同，只需要修改一下宏定义，这样就避免了这个问题。在这列举一些常用的数据类型，以免以后在编写代码或者查看例子代码时犯迷糊：普通数据类型#define ULONG unsigned long #define UCHAR unsigned char #define UINT unsigned int #define VOID void #define PULONG unsigned * #define PUCHAR unsigned char* #define PUINT unsigned int* #define PVOID void* 字符串类型在驱动的编程中，为字符串操作专门定义了一个数据类型UNICODE_STRING ANSI_STRING，他们的定义大致相同，只是一个是表示UNICODE字符串，一个表示ANSI字符串，下面主要来说明一下UNICODE_STRINGtypedef struct _UNICODE_STRING { USHORT Length; // 字符串的中字符所占的内存大小 USHORT MaximumLength;//用来存储字符串缓冲的大小 PWCHAR Buffer;//缓冲的地址 } UNICODE_STRING;这个结构体在使用是需要注意的是上述两个大小单位是字节数而不是字符个数，另外在操作UNICODE_STRING 的时候只是简单的操作Buffer指向的内存，并不会特意的为其分配另外的空间，字符串处理函数主要有这样几个：RtlInitUnicodeString(&uStr1, str1); RtlCopyUnicodeString(&uStr1, &uStr2); RtlAppendUnicodeToString(&uStr1, str1); RtlAppendUnicodeStringToString(&uStr1, &uStr2); RtlCompareUnicodeString(&uStr1, &uStr2, TRUE/FALSE); RtlAnsiStringToUnicodeString(&uStr1, &aStr1, TRUE/FALSE); RtlFreeUnicodeString(&uStr1);这些函数从字面上就可以知道它们是干什么用的，需要注意的是，除了Init，这些函数只是简单的操作Buffer已指向的内存，并不会改变指针的指向。所以在使用时要特别注意不要试图改变静态常量区的内容，也要特别注意指向的内存是在栈中还是在堆中。下面是一个简单的例子： UNICODE_STRING uStr1 = { 0 }; UNICODE_STRING uStr2 = { 0 }; UNICODE_STRING uStr3 = { 0 }; ANSI_STRING aStr = { 0 }; RtlInitUnicodeString(&uStr1, L"Hello"); RtlInitUnicodeString(&uStr2, L"Goodbye"); //打印字符串结构用%Z表示%wZ表示是宽字符 DbgPrint("uStr1 = %wZ\n", &uStr1); DbgPrint("uStr2 = %wZ\n", &uStr2); RtlInitAnsiString(&aStr, "Hello World"); DbgPrint("aStr = %Z\n", &aStr); /*这个操作是由于uStr3中的Buffer指向NULL，所以会失败*/ RtlCopyUnicodeString(&uStr3, &uStr1); DbgPrint("uStr3 = %wZ\n", &uStr3); //失败 /*下面两个失败是由于Str1 Str2 指向的是字符串常量区，不可修改*/ RtlAppendUnicodeToString(&uStr1, &uStr2); DbgPrint("uStr1 = %wZ\n", &uStr1); //失败 RtlAppendUnicodeStringToString(&uStr1, L"World"); DbgPrint("uStr1 = %wZ\n", &uStr1); //失败LARGE_INTEGER这个结构就像它的名字一样，用来表示一个比较大的整数，它的定义如下：typedef union _LARGE_INTEGER { struct { DWORD LowPart; LONG HighPart; }; struct { DWORD LowPart; LONG HighPart; } u; LONGLONG QuadPart; } LARGE_INTEGER, *PLARGE_INTEGER;这是一个公用体，可以认为它是由两部分组成高32位的HighPart和低32位的LowPart，它分了高位优先和低位优先两种情况，也可以认为它是一个64位的整形。在使用时根据需求来决定NTSTATUS绝大多数驱动函数都返回这个值，用来表示当前处理的状态，一般STATUS_SUCCESS表示成功，其余的都表示失败。微软根据不同情况定义了它的状态值，一般常用的有下面几个值含义STATUS_SUCCESS函数执行成功STATUS_UNSUCCESSFUL函数执行不成功STATUS_NOT_IMPLEMENTED函数违背实现STATUS_INVALID_INFO_CLASS输入参数是无效的类别STATUS_ACCESS_VIOLATION不允许访问STATUS_IN_PAGE_ERROR发生页面故障STATUS_INVALID_HANDLE输入的是无效的句柄STATUS_INVALID_PARAMETER输入的是无效的参数STATUS_NO_SUCH_DEVICE指定的设备不存在STATUS_NO_SUCH_FILE指定的文件不存在STATUS_INVALID_DEVICE_REQUEST无效的设备请求STATUS_END_OF_FILE文件已到结尾STATUS_INVALID_SYSTEM_SERVICE无效的系统调用STATUS_ACCESS_DENIED访问被拒绝STATUS_BUFFER_TOO_SMALL输入的缓冲区过小STATUS_OBJECT_TYPE_MISMATCH输入的对象类型不匹配STATUS_OBJECT_NAME_INVALIE输入的对象名无效STATUS_OBJECT_NAME_NOT_FOUND输入的对象没有找到STATUS_PORT_DISCONNNECTED需要连接的端口没有被连接STATUS_OBJECT_PATH_INVALID输入的对象路径无效另外在使用WinDbg进行调试的时候，一般都会得到函数调用的错误码，根据错误码可以找到对应的错误信息，微软提供了一种解决方案：LPVOID lpMessageBuffer; HMODULE Hand = LoadLibrary(_T("NTDLL.DLL")); DWORD dwErrCode = 0; //获取错误码 FormatMessage( FORMAT_MESSAGE_ALLOCATE_BUFFER | FORMAT_MESSAGE_FROM_SYSTEM | FORMAT_MESSAGE_FROM_HMODULE, Hand, dwErrCode, MAKELANGID(LANG_NEUTRAL, SUBLANG_DEFAULT), (LPTSTR) &lpMessageBuffer, 0, NULL ); // Now display the string. // Free the buffer allocated by the system. LocalFree( lpMessageBuffer ); FreeLibrary(Hand);驱动对象驱动程序的入口函数是DriverEntry，函数会传入一个驱动对象的指针——PDRIVER_OBJECT，每个驱动都有一个唯一的驱动对象，就好像每个Win32应用程序有一个唯一的实例句柄。它的定义如下：typedef struct _DRIVER_OBJECT { CSHORT Type; CSHORT Size; PDEVICE_OBJECT DeviceObject; ULONG Flags; PVOID DriverStart; ULONG DriverSize; PVOID DriverSection; PDRIVER_EXTENSION DriverExtension; UNICODE_STRING DriverName; PUNICODE_STRING HardwareDatabase; PFAST_IO_DISPATCH FastIoDispatch; PDRIVER_INITIALIZE DriverInit; PDRIVER_STARTIO DriverStartIo; PDRIVER_UNLOAD DriverUnload; PDRIVER_DISPATCH MajorFunction[IRP_MJ_MAXIMUM_FUNCTION + 1]; } DRIVER_OBJECT;下面主要对几个重要的部分做介绍：DeviceObject：保存的是驱动中设备对象的指针，另外每个设备对象又有一个指向下一个设备对象的指针，这样同一个驱动程序中的不同设备对象就构成了一个链表DriverName：这个里面存储的是驱动程序的名称，该字符串一般为“\Driver\驱动名称”HardwareDatabase：这里记录的是设备的硬件数据库键名，这个数据库一般是注册表，字符串一般为“REGISTRY\MACHINE\HARDWARE\DESCRIPTION\SYSTEM”DriverStartIo：记录StartIo这个例程回调函数的地址DriverUnload：当驱动卸载时会调用这个指针所指向的函数MajorFunction，这是一个回调函数的指针数组，处理IRP包的不同请求，就好像应用层里面的消息处理函数，根据不同的请求，调用不同的函数。设备对象在windows平台将每个设备抽象为一个设备对象，驱动层一般通过设备对象来操作具体的设备，每个驱动可以有多个设备对象。typedef struct DECLSPEC_ALIGN(MEMORY_ALLOCATION_ALIGNMENT) _DEVICE_OBJECT { ... struct _DRIVER_OBJECT *DriverObject; struct _DEVICE_OBJECT *NextDevice; struct _DEVICE_OBJECT *AttachedDevice; struct _IRP *CurrentIrp; ULONG Flags; PVOID DeviceExtension; DEVICE_TYPE DeviceType; CCHAR StackSize; ... } DEVICE_OBJECT;设备对象本身定义是十分复杂的，在这我们只列举出部分，以后写程序会经常使用的部分，下面是对这些部分的说明：DriverObject： 指向所属驱动的驱动对象的指针NextDevice：指向下一个设备驱动的指针AttachedDevice：指向它被附加的驱动的指针，设备对象之上还可以在附加上其他的设备对象，这样每当有消息传来时总会由附加在它之上的设备对象处理，然后才会交由它自身处理，这个指针就是指向附加在它之上的设备对象的指针CurrentIrp：指向当前IRP域的指针Flags：表名该设备的一些标志信息，主要有下面几个值：标志描述DO_BUFFERED_IO读写使用缓冲方式，内核层在使用用户缓冲区时会将用户分区中的数据拷贝到内核分区中DO_EXCLUSIVE一次只允许一个线程使用这个设备对象DO_DIRECT_IO读写直接方式，应用层将某块内存锁定在内存，然后将内存映射到内核空间中，这种方式是最快的方式DO_DEVICE_INITIALIZING设备正在初始化DO_POWER_PAGABLE设备必须在PASSIVE_LEVEL上处理IRP_MJ_PNP请求DO_POWER_INRUSH设备上电期间需要大电流DeviceExtension：指向一块扩展的内存，系统允许用户在创建设备对象时自定义一块区域用来保存结构体中没有但是用户自己感兴趣的内容。在驱动程序中需要尽量避免使用全局变量，所以可以通过使用这块扩展内存来传输全局变量DeviceType：驱动的类型，主要有下面几个值设备类型描述FILE_DEVICE_BEEP该设备是一个蜂鸣器FILE_DEVICE_CD_ROM该设备时一个CD光驱FILE_DEVICE_CD_ROM_FILE_SYSTEMCD光驱文件系统设备FILE_DEVICE_CONTROLLER控制器设备FILE_DEVICE_DATALINK数据链设备FILE_DEVICE_DFSDFS设备对象FILE_DEVICE_DISK磁盘设备对象FILE_DEVICE_DISK_FILE_SYSTEM磁盘文件系统设备对象FILE_DEVICE_FILE_SYSTEM文件系统设备对象FILE_DEVICE_INPORT_PORT输入端口设备对象FILE_DEVICE_KEYBOARD键盘设备对象FILE_DEVICE_MAILSLOT邮件曹设备对象FILE_DEVICE_MIDI_INMIDI输入设备对象FILE_DEVICE_MIDI_OUTMIDI输出设备对象FILE_DEVICE_MOUSE鼠标设备对象FILE_DEVICE_MULTI_UNC_PROVIDER多UNC设备对象FILE_DEVICE_NAMED_PIPE命名管道设备对象FILE_DEVICE_NETWORK网络设备对象FILE_DEVICE_NETWORK_BROWSER网络浏览器设备对象FILE_DEVICE_NETWORK_FILE_SYSTEM网络文件系统设备对象FILE_DEVICE_NULL空设备对象FILE_DEVICE_PARALLEL_PORT并口设备对象FILE_DEVICE_PHYSICAL_NETCARD物理网卡设备对象FILE_DEVICE_PRINTER打印机设备对象FILE_DEVICE_SCANNER扫描仪设备对象FILE_DEVICE_SERIAL_MOUSE_PORT串口鼠标设备对象LE_DEVICE_SERIAL_PORT串口设备对象FILE_DEVICE_SCREEN屏幕设备对象FILE_DEVICE_SOUND声音设备对象FILE_DEVICE_STREAMS流设备对象LE_DEVICE_TAPE磁带设备对象FILE_DEVICE_TAPE_FILE_SYSTEM磁带文件系统设备对象FILE_DEVICE_TRANSPORT传输设备对象FILE_DEVICE_UNKNOWN未知设备对象FILE_DEVICE_VIDEO视频设备对象FILE_DEVICE_VIRTUAL_DISK虚拟磁盘设备对象FILE_DEVICE_WAVE_IN声音输入设备对象FILE_DEVICE_WAVE_OUT声音输出设备对象在创建设备对象时如果不知道这个设备对象是何种类型，可以直接给FILE_DEVICE_UNKNOWN；StackSize：之前说到过，设备对象存在附加的情况，附加时每个设备对象会存储它上层的设备对象的指针，这样就形成了类似堆栈的结构，而这个值就表示从该设备对象到栈底还有多少个设备对象为了便于理解我们做了这样一个示意图：