DRIVER_OBJECT，DEVICE_OBJECT 结构体分析

最新推荐文章于 2024-04-12 10:39:47 发布
原创 最新推荐文章于 2024-04-12 10:39:47 发布 · 803 阅读 · 3 ·
CC 4.0 BY-SA版权
版权声明：本文为博主原创文章，遵循 CC 4.0 BY-SA 版权协议，转载请附上原文出处链接和本声明。

本文分析了WDK中的DRIVER_OBJECT和DEVICE_OBJECT结构体，详细探讨了这两个结构体在驱动程序中的作用和关键成员，为理解驱动开发提供基础。

摘要生成于 C知道 ，由 DeepSeek-R1 满血版支持， 前往体验 >


在wdm.h这个头文件中可以看到这两个结构体的定义，下面简单的分析一下结构体中的内容。

DRIVER_OBJECT

typedef struct _DRIVER_OBJECT {
    CSHORT Type;
    CSHORT Size;

     //这个驱动生成的设备对象，形成一个链，DeviceObject指向这个链
    PDEVICE_OBJECT DeviceObject;

    //驱动对象是否可以扩展的标记
    ULONG Flags;
    //这部分描述的就是驱动从哪儿被加载。记数字段用来记录驱动注册的重新初始化程序一共被调用了多少次
    PVOID DriverStart;
    ULONG DriverSize;
    PVOID DriverSection;
    //指向driver extension.他唯一可以访问的成员就是 DriverExtension->AddDevice，,我们也是利用这个方法在 DriverEntry 程序中存储驱动程序的AddDevice程序  
     PDRIVER_EXTENSION DriverExtension;

    // 驱动程序的名字被错误日志线程用来决定I/O请求所绑定的驱动的名字
    UNICODE_STRING DriverName;


     //这个字段是用来进行注册用的。这个指针指向在注册表中硬件信息的路径。
    PUNICODE_STRING HardwareDatabase;


   //这是一个指向支持快速I/O的备用驱动入口的数组的可选择指针，快速I/O通过传入独立参数直接调用驱动程序来实现，而不是利用标准的IRP呼叫机制。
  //注意这些方法只能被用于同步的I/O处理，而且是在文件已经被缓存了的情况下

    PFAST_IO_DISPATCH FastIoDispatch;

   //是Driver
最低0.47元/天 解锁文章

200万优质内容无限畅学
驱动程序数据结构--DRIVER_OBJECT
KOOKNUT的博客
03-31 534
我们先来看一下微软对这个结构体的定义： typedef struct _DRIVER_OBJECT { CSHORT Type; CSHORT Size; PDEVICE_OBJECT DeviceObject;//该驱动程序挂载的设备对象 ULONG Flags; PVOID DriverStart; ULONG DriverSize; ...
rockchip3399的DRM架构中drm_device解析
多年芯片设计领域从业经验，负责芯片bringup以及kernel驱动开发。
12-17 1884
基于DRM架构的图显系统软件架构中，DRM世界中的设备主体由struct drm_device描述。
DRIVER_OBJECT & DEVICE_OBJECT
Iqian1314的专栏
06-03 2558
驱动对象结构 DRIVER_OBJECT ，定义如下:(左侧为相对于结构体起始地址的偏移量)　　struct _DRIVER_OBJECT (sizeof=168)　　+00 int16 Type　　+02 int16 Size　　+04 struct _DEVICE_OBJECT *DeviceObject　　+08 uint32 Flags　　+0c void *DriverStart　　+10 uint32 DriverSize　　+14 void *DriverSection（即为PsLoadedM
设备对象(DEVICE_OBJECT)-----------------主要成员
weixin_30342827的博客
06-26 193
一、设备对象(DEVICE_OBJECT) kd> dt _device_objectntdll!_DEVICE_OBJECT +0x000 Type : Int2B +0x002 Size : Uint2B +0x004 ReferenceCount : Int4B +0x008 DriverObject : P...
DRIVER_OBJECT结构体
07-23 884
个驱动程序对象代表了一个加载了的内核模式驱动程序映像.这个驱动对象就是以DRIVER_OBJECT结构体的形式存在的.这个驱动对象的指针从驱动程序的DriverEntry函数或AddDevice函数的参数传入的.typedef struct 　　{ 　　PDEVICE_OBJECT DeviceObject; 　　PUNICODE_STRING HardwareData
设备对象（DEVICE_OBJECT)
门没锁的专栏
05-16 5979
DEVICE_OBJECT结构体是操作系统用来表示某个具体的设备对象,一个设备对象是一个逻辑上的，或者虚拟的，或者物理上的设备的具体抽象，驱动通过设备对象来处理I/O请求。 typedef struct _DEVICE_OBJECT { CSHORT Type; USHORT Size; LONG
driver_register分析
wwbbxx的博客
04-18 1581
在上一篇文章中分析了，i2c设备和i2c驱动的向总线注册过程。在总线-设备-驱动这种模型中，无论是先进行driver_register还是后进行device_register，总线驱动都会对进行匹配，只有匹配工程后，才会执行驱动的probe函数； 首先分析driver_register函数，先看此函数源码（driver/base/driver.c）: int driver_register...
Device_driver_model 设备驱动模型
atrouble的博客
08-28 1438
设备驱动模型 相关介绍 kobject/kset bus、device和driver的数据类型 sysfs文件/目录 sysfs和Kobject的关系 sysfs和kobj_type的关系 attribute的创建 sysfs设备目录层次结构 设备模型框架下驱动开发的基本步骤 设备驱动probe时机 probe函数的调用 Device注册过程—-device_register() ...
Windows驱动开发(7) - DEVICE_OBJECT结构体
Vinx Blog
05-07 2372
Windows驱动开发(7) - DEVICE_OBJECT结构体typedef struct _DEVICE_OBJECT { CSHORT Type; USHORT Size; LONG ReferenceCount; struct _DRIVER_OBJECT
windows内核开发笔记十四：DRIVER_OBJECT和DEVICE_OBJECT的关系
jyl_sh的专栏
03-30 1645
DRIVER_OBJECT和DEVICE_OBJECT的关系 DRIVER_OBJECT是驱动程序在内核中的数据结构，每个驱动程序有唯一DRIVER_OBJECT，IO管理器使用驱动程序对象代表每个设备驱动程序，驱动程序描述了驱动程序的载入到内存什么地方，驱动程序的大小和它的主要入口点（MajorFunction数组）；驱动程序对象有一个DeviceObject域指向一个设备对象链表，每个设备对象代表一个设备。 DEVICE_OBJECT是物理设备或逻辑设备在内核中的数据结构...
设备对象(DEVICE_OBJECT)-----------------设备名称
weixin_30834019的博客
06-26 536
通常设备对象都把自己的名字放到\Device目录中。在Windows 2000中，设备的名称有两个用途。第一个用途，设备命名后，其它内核模式部件可以通过调用IoGetDeviceObjectPointer函数找到该设备，找到设备对象后，就可以向该设备的驱动程序发送IRP。 另一个用途，允许应用程序打开命名设备的句柄，这样它们就可以向驱动程序发送IRP。应用程序可以使用标准的CreateFile ...
typedef struct _DRIVER_OBJECT
autumn20080101的专栏
05-20 746
typedef struct _DRIVER_OBJECT { CSHORT Type; CSHORT Size; // // The following links all of the devices created by a single driver // together on a list, and the Flags word provide
DEVICE_OBJECT结构参数
dengjiatao9832的博客
09-21 164
typedef struct DECLSPEC_ALIGN(MEMORY_ALLOCATION_ALIGNMENT) _DEVICE_OBJECT { CSHORT Type; USHORT Size; LONG ReferenceCount; /*指向驱动程序中驱动对象的指针*/ struct _DRIVER_OBJECT *Dr...
设备对象(DEVICE_OBJECT)
BpLife
12-03 1669
1.每个驱动程序会创建一个或多个设备对象(下文称DO)，用DEVICE_OBJECT数据结构表示。每个DO都会有个指针指向下一个DO，因此就形成了一个DO链。DO链的第一个DO是由DRIVER_OBJECT 结构体中的 PDRIVER_EXTENSION 指明的.DO保存DO特征和状态信息，以下是字段信息： typedef struct _DEVICE_OBJECT { CSHORT
DriverObject与DeviceObject关系
cshcmqcsh的专栏
05-26 1175
二者是一个不太严格的双向链表关系：1、DriverObject--------------->DeviceObject1------------------>DeviceObject2-->....DeviceObjectN-->NULL           (DriverObject.DeviceObject域)        (DeviceObject.NextDevice域)2、DeviceObject----------->DriverObject                (DeviceObj
DRIVER_OBJECT和DEVICE_OBJECT的关系
XinhuaSoft
01-14 2159
从开始接触驱动以来，一直对DRIVER_OBJECT和DEVICE_OBJECT之间的关系很是困惑，经过一段时间的学习，大概了解了两者之间的关系。DRIVER_OBJECT是驱动程序在内核中的数据结构，每个驱动程序有唯一DRIVER_OBJECT，IO管理器使用驱动程序对象代表每个设备驱动程序，驱动程序描述了驱动程序的载入到内存什么地方，驱动程序的大小和它的主要入口点（MajorFunction数
PDEVICE_OBJECT 的定义
01-03 2352
 PDEVICE_OBJECT 定义在 ntddk.h中 typedef struct _DRIVER_EXTENSION {    //    // Back pointer to Driver Object    //    struct _DRIVER_OBJECT *DriverObject;    //    // The AddDevice entry point
驱动开发：探索DRIVER_OBJECT驱动对象
支持一对一答疑的编程作家朱文伟的博客！
04-12 625
入口处都会存在这样一个驱动对象，该对象内所包含的就是当前所加载驱动自身的一些详细参数，例如驱动大小，驱动标志，驱动名，驱动节等等，每一个驱动程序都会存在这样的一个结构。这一系列则是微软的调用号，不同的RIP代表着不同的涵义，但一般驱动也就会用到如下这几种调用号。编译这段程序，签名并运行，我们即可看到如下输出信息，此时当前自身驱动的详细参数都可以被输出；编译这段程序，签名并运行，我们即可看到如下输出信息，此时当前自身驱动的详细参数都可以被输出；即可得到全部的数据，这段代码可以写成如下样子，其中的。
/* File Kmd.h By WzrterFX */ #pragma once #ifndef KMD_H #define KMD_H #include <cstdint> #include <ntifs.h> namespace Kmd { namespace _NtifsApi { extern “C” __declspec(dllimport) NTSTATUS __stdcall IoCreateDriver( IN PUNICODE_STRING DriverName, IN PDRIVER_INITIALIZE InitializationFunction ); extern "C" __declspec(dllimport) NTSTATUS __stdcall PsLookupProcessByProcessId( IN HANDLE ProcessId, OUT PEPROCESS* Process ); extern "C" __declspec(dllimport) NTSTATUS __stdcall MmCopyVirtualMemory( IN PEPROCESS FromProcess, IN PVOID FromAddress, IN PEPROCESS ToProcess, IN PVOID ToAddress, IN SIZE_T BufferSize, IN KPROCESSOR_MODE PreviousMode, OUT PSIZE_T NumberOfBytesCopied ); } namespace _IoCtls { constexpr std::uint32_t attach = CTL_CODE(FILE_DEVICE_UNKNOWN, 0x01, METHOD_BUFFERED, FILE_SPECIAL_ACCESS ); constexpr std::uint32_t read = CTL_CODE(FILE_DEVICE_UNKNOWN, 0x02, METHOD_BUFFERED, FILE_SPECIAL_ACCESS ); constexpr std::uint32_t write = CTL_CODE(FILE_DEVICE_UNKNOWN, 0x03, METHOD_BUFFERED, FILE_SPECIAL_ACCESS ); } class Kmd { private: PDEVICE_OBJECT _deviceObject; typedef struct __AttachRequest { HANDLE process; } AttachRequest, * PAttachRequest; typedef struct __CopyMemoryRequest { PVOID from; PVOID to; SIZE_T requested; } CopyMemoryRequest, * PCopyMemoryRequest; typedef struct _KmdRequest { AttachRequest attachRequest; CopyMemoryRequest copyMemoryRequest; } KmdRequest, * PKmdRequest; static NTSTATUS KmdControl(PDEVICE_OBJECT deviceObject, PIRP io); public: NTSTATUS Create(PDRIVER_OBJECT driverObject); }; } #endif /* !KMD_H */这个可以单独加载使用吗
最新发布
03-24
<think>好的，我现在需要分析用户提供的C++头文件Kmd.h，并回答这个内核模式驱动程序（KMD）是否可以单独加载使用。首先，我应该仔细阅读代码，理解其结构和各部分的功能。 首先，文件开头是版权和作者信息，然后是标准的头文件保护宏#ifndef KMD_H。接着包含了<cstdint>和<ntifs.h>，后者是Windows内核驱动开发的重要头文件，包含了许多内核API的定义。接下来是命名空间Kmd，里面分为_NtifsApi和_IoCtls两个子命名空间。 在_NtifsApi中，导入了三个内核API：IoCreateDriver、PsLookupProcessByProcessId和MmCopyVirtualMemory。这些函数都是通过extern "C"和__declspec(dllimport)声明的，说明是从NTOSKRNL.EXE动态链接导入的。这些API用于创建驱动、查找进程和复制虚拟内存，属于内核模式下的基本操作。 _IoCtls命名空间定义了三个IO控制码：attach、read和write，使用CTL_CODE宏生成。这些控制码用于设备IO通信，METHOD_BUFFERED表示使用缓冲IO方式，FILE_SPECIAL_ACCESS可能需要特定权限。 接下来是Kmd类，包含私有成员_deviceObject，几个结构体定义用于请求处理，以及一个公共的Create方法和静态的KmdControl函数。看起来Create方法用于创建设备对象，而KmdControl是设备控制处理函数，处理来自用户层的IO请求。 现在，用户的问题是，这个头文件对应的驱动程序是否可以单独加载使用。我需要分析代码是否完整，是否具备驱动加载的必要结构。 首先，驱动程序入口点通常是DriverEntry函数，但在这里，Kmd类的Create方法可能被用作初始化函数，通过IoCreateDriver注册。不过头文件中没有显示DriverEntry的实现，也没有提供驱动对象的主要回调函数如Unload例程或其他必要的IRP处理函数。例如，KmdControl处理IO控制请求，但可能没有处理创建设备请求或其他必要的IRP_MJ_XXX分发函数。 另外，单独加载驱动需要一个.sys文件，并且需要正确的入口点和必要的设备创建、符号链接等步骤。头文件中虽然定义了部分结构，但缺少具体的实现，比如Kmd::Create和Kmd::KmdControl的具体代码。头文件只声明了这些函数，但没有实现，因此无法直接编译成可加载的驱动。 此外，IO控制码的定义和请求结构体可能用于与用户层通信，但如果没有实现对应的处理逻辑，比如读取和写入内存的具体操作，驱动也无法正常工作。例如，PsLookupProcessByProcessId和MmCopyVirtualMemory的使用需要正确的调用上下文和参数处理，否则可能导致系统不稳定或蓝屏。 总结来看，这个头文件只是一个框架，缺少实际的实现代码和驱动入口点。因此，仅凭这个头文件无法单独编译和加载为一个有效的内核驱动程序。用户需要提供更多的实现细节，如DriverEntry函数、Kmd::Create和KmdControl的具体实现，以及正确处理IRP的方法，才能使得驱动程序可以加载和使用。</think>这个头文件 $Kmd.h$ 是一个内核模式驱动程序的框架，但**不能直接单独加载使用**。以下是逐步分析原因： --- ### 一、关键结构分析 #### 1. 驱动入口点缺失 - 内核驱动必须实现 `DriverEntry` 函数作为入口点，但代码中只有 `Kmd::Create` 方法，且未展示其具体实现。 - 若要通过 `IoCreateDriver` 动态创建驱动，需要定义初始化函数（如 `DriverEntry`），但此处未体现。 #### 2. 设备对象未完整配置 - 虽然定义了 `_deviceObject` 成员，但未展示如何通过 `IoCreateDevice` 创建设备对象。 - 缺少符号链接（Symbolic Link）创建步骤，用户层无法通过设备名访问驱动。 #### 3. IRP 分发不完整 - 仅实现了 `KmdControl` 处理控制请求（`IRP_MJ_DEVICE_CONTROL`），但未注册其他必须的 IRP 处理函数（如 `IRP_MJ_CREATE`, `IRP_MJ_CLOSE`）。 - 实际驱动需处理至少以下 IRP 类型： ```cpp DriverObject->MajorFunction[IRP_MJ_CREATE] = DispatchCreate; DriverObject->MajorFunction[IRP_MJ_CLOSE] = DispatchClose; ``` --- ### 二、关键功能缺失 #### 1. 内存操作未实现 - 虽然声明了 `MmCopyVirtualMemory`，但未展示如何在 `KmdControl` 中处理读写请求的具体逻辑。 - 缺少对进程附加（`attach`）操作的实现，如通过 `PsLookupProcessByProcessId` 获取目标进程的 `EPROCESS`。 #### 2. 安全性问题 - 未对用户层传入参数进行验证（如地址范围、缓冲区大小），直接操作可能导致系统崩溃（BSOD）。 - 未使用 `ProbeForRead`/`ProbeForWrite` 检查用户层缓冲区可访问性。 --- ### 三、编译与加载依赖 #### 1. 代码不完整 - 头文件仅包含声明，缺少 `.cpp` 文件中的具体实现（如 `Kmd::Create` 和 `KmdControl` 函数体）。 - 未定义驱动卸载例程（`DriverUnload`），无法安全卸载驱动。 #### 2. 依赖内核模式配置 - 需使用 WDK（Windows Driver Kit）编译为 `.sys` 文件。 - 需签名才能在 64 位系统加载（测试模式下可绕过，但不安全）。 --- ### 四、改进方向 若要使其可加载，需补充以下内容： 1. **实现 `DriverEntry` 函数**： ```cpp extern "C" NTSTATUS DriverEntry(PDRIVER_OBJECT DriverObject, PUNICODE_STRING RegistryPath) { DriverObject->DriverUnload = DriverUnload; return Kmd::Kmd::Create(DriverObject); } ``` 2. **完善 IRP 分发函数**： ```cpp DriverObject->MajorFunction[IRP_MJ_DEVICE_CONTROL] = Kmd::Kmd::KmdControl; ``` 3. **创建设备与符号链接**： ```cpp UNICODE_STRING devName = RTL_CONSTANT_STRING(L"\\Device\\KmdDevice"); IoCreateDevice(DriverObject, 0, &devName, FILE_DEVICE_UNKNOWN, 0, FALSE, &_deviceObject); UNICODE_STRING symLink = RTL_CONSTANT_STRING(L"\\DosDevices\\KmdDriver"); IoCreateSymbolicLink(&symLink, &devName); ``` 4. **补充内存操作逻辑**（示例片段）： ```cpp NTSTATUS status = PsLookupProcessByProcessId(ProcessId, &TargetProcess); if (NT_SUCCESS(status)) { MmCopyVirtualMemory(CurrentProcess, SourceAddress, TargetProcess, TargetAddress, Size, KernelMode, &BytesCopied); } ``` --- ### 结论 当前代码仅为**框架性头文件**，缺少关键实现和配置，无法直接编译或加载。需要补充完整的驱动入口点、IRP 处理逻辑和设备管理代码，并解决安全性问题，才能作为有效内核驱动运行。
评论
添加红包

请填写红包祝福语或标题

个

红包个数最小为10个

元

红包金额最低5元

当前余额3.43元 前往充值 >
需支付：10.00元
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付元
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明：

1.余额是钱包充值的虚拟货币，按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载，可以购买VIP、付费专栏及课程。

余额充值