lixiangminghate的专栏

    今天整理ppt，突然想到一个现象：在WRK以及winddk sample源码中很少见到异常处理相关的影子(指windows结构化异常处理SEH：__try/__exception，而不是C++标准提供的try/catch，kernel不支持C++异常)。按说，内核本身具有完整的异常处理机制，驱动作为内核的一部分，如果使用了异常处理块，必然受到异常处理机制的保护。    我首先想到的是在DI...

在看WDF框架的时候，看到一段代码注释:NTSTATUS__fastcallFxPkgIo::DispatchStep2( __inout MdIrp Irp, __in_opt FxIoInCallerContext* IoInCallerCtx, __in_opt FxIoQueue* Queue ){ // ...

前面XpSp3(未开启PAE模式)内存管理之系统PTE区域 上>的结尾部分留了一个疑问:系统空闲PTE链表的结尾部分和全局变量nt!MmSystemPtesEnd中保存的值不同。这篇尝试解释是什么导致了这样的差异。    系统启动阶段时会调用nt!MiInitializeSystemPtes来初始化系统PTE区域。就如神话故事中天地是混在一起的一样，初始时，MmFirstFreeSyste

前言    几年前就已经看过wrk中关于内存管理和缓存管理的实现，由于当时对内核调试尚不熟悉，因此仅仅停留在代码层面。现在结合windbg操作，希望能有新的收获。毛德操的对理解windows内核确有裨益，但是，ReactOS对内存管理和缓存管理部分的实现与wrk相去甚远(ReactOS内存管理更接近于Linux内存管理)，因此这些的代码应以wrk为准。    正文    提到一个系统P

这几天调试系统PTE区域，在获取nt!MmFirstFreeSystemPte指向的元素时，总无法获得正确的空闲pte值。反汇编nt!MiInitializeSystemPtes函数时发现这样的代码:80544e35 8d3cf5c0975580 lea edi,nt!MmFirstFreeSystemPte (805597c0)[esi*8]80544e3c 8b5704

这篇文章实在是闲的无聊才写的，因为快过年了...文章基于xpsp3    先看看和非分页内存相关的全局变量，也好有个大局观:kd> x nt!MmNonPaged*805517d8 nt!MmNonPagedPoolEnd = 8055af84 nt!MmNonPagedPoolEnd0 = 8055af80 nt!MmNonPa

MmGetSystemRoutineAddress这个函数也是比较有用的，是得到系统导出函数的地址，不过网上都是写了一堆汇编代码在哪里，根本没有可读性，还不如用IDA看呢。下面的函数是摘自ReactOS项目的代码：PVOID  NTAPI  MmGetSystemRoutineAddress(IN PUNICODE_STRING SystemRoutineName)  

导出函数：顾名思义，出现在导出表(EAT)里面的函数，可以给外部调用的函数，验证是否为导出函数的方法，熟悉逆向的朋友可以使用LordPE之类的工具查看，当然也可以使用GetProcAddress或者MmGetSystemRoutineAddress之类的函数来获取地址，如果成功的话就是导出函数。非导出函数：这种函数是供自己调用使用的，不想提供给别人使用，当然也有方法可以获取函数地址，可以根据函

IO_STACK_LOCATION和IRP算是驱动中两个很基础的东西，为了理解这两个东西，找了一点资料。1. IRP可以看成是Win32窗口程序中的消息（Message），DEVICE_OBJECT可以看成是Win32窗口程序中的窗口（Window）2. 任何内核模式程序在创建一个IRP时，同时还创建了一个与之关联的IO_STACK_LOCATION结构数组：数组中的每个堆栈单元都

很多人拿到驱动包准备安装驱动时，往往先想到通过鼠标右键-安装这种方式来安装驱动。且不说能不能安装成功，要支持这种安装方式，对inf文件有一定的要求：inf文件中需要包含[DefaultInstall]这样的节，这个节是右键安装时的Inf入口点(MSDN的原话:"An INF file's DefaultInstall section is accessed if a user selects th

Eventdrv是MS ddk中的一个demo，演示如何在驱动中使用event view日志。本文译自src/general/tracing/evntdrv/evntdrv.htm概述Event是内核态驱动运行日志样例.该驱动并不控制任何物理硬件,仅生成日志事件.它用于演示如何在驱动中使用ETW日志.Eventdrv通过调用EtwRegister API来注册事件产生者.如果驱动加载成功,

错误难以避免，驱动安装后经常会见到YB，遇到这样的情况可以查看windows设备驱动安装日志: C:\Windows\inf\setupapi.dev.log.每次安装一个驱动，都以:>>> [Device Install (Hardwareinitiated) - STORAGE\VolumeSnapshot\HarddiskVolumeSnapshot2]>>>  Sectio

出差时发现一些大公司使用DpInst工具安装驱动，当时觉得这种方式安装驱动相当方便，出于好奇回来后自己也尝试这种安装方式。    DpInst.exe工具位于ddk目录redist\DIFx\dpinst\EngMui下，同时M$在src\setup\DPInst目录下提供了定制DpInst驱动安装包的样例。一个基本的驱动安装包至少要包含cat，sys(已签名，测试签名也可以，为cat和s

Inf2CatInf2Cat (Inf2Cat.exe) 是一个命令行工具，该工具确定驱动程序包的 INF 文件是否可以针对指定的 Windows 版本列表进行数字签名。如果可以，那么 Inf2Cat 会生成适用于指定 Windows 版本的未签名的目录文件。Inf2Cat /driver:PackagePath /os:WindowsVersionList [/nocat]

IoRegisterPlugPlayNotification函数的作用是为指定guid的设备注册一个回调函数,当进入设备驱动并调用IoSetDeviceInterfaceState使能设备访问接口后,让系统调用之前注册的回调函数,以实现通知的目的.wrk1.2源码中并没有IO管理器的实现,因此,只能退而求其次,参考ReactOS中关于IoRegisterPlugPlayNotification的实

前面toaster驱动程序的安装都是通过手动安装的方式，把sys/inf等文件安装到系统中。说实话，这么复杂的过程除了开发者，其他人能流畅的安装上驱动还真是天方夜谭了。如果读者曾在电脑城买过电脑配件，如无线网卡，蓝牙适配器，应该有印象:到手的除了这么设备本身，还会附带一张提供安装程序的小光盘和一份安装说明。安装说明一般都会要求先运行安装程序，然后重启插入设备，之后设备就可以正常使用了。这张光盘就是

最近要调试bluetooth，涉及到具体硬件因此不能用虚拟机和命名管道调试内核了，另外现在的PC追求轻便化，因此连串口都没了，不得不考虑使用网线调试。网上转了一圈发现了这篇：基于网络的内核调试 驱动调试需要用到两台机器，目前主要是通过串\口、usb或者1394接口来连接。对于软设备驱动来说就多了一种选择，通过vmware等虚拟化软件来虚拟测试机。但有些情况下必须在真实的双机环境进行

前一篇Pnp管理器(1)提到了总线上设备变化时，将产生Pnp消息并在Pnp管理器个组件间流动。消息传递的最终目的是通知某个组件加载驱动。本文看一下Pnp管理器收到消息后加载驱动的流程。    当PnpEventThread函数从等待阻塞中返回，判断如果是添加设备则创建一个DeviceInstallParams* Params变量typedef struct{#ifdef HAVE_SL

以前写过一篇Pnp管理器的文章，感觉写的有点肤浅，因此打算另起一篇写Pnp管理器。Pnp管理器是个大的组件:从内核到用户态都有涉及，因此需要分若干篇章分析。本篇立足于Pnp管理器中连接各个模块之间消息流。    系统引导过程中会初始化IO管理器，由IO管理器调用PnpInit对Pnp管理器进行初始化。跟Pnp消息相关的有两处:NTSTATUS INIT_FUNCTIONIopInitPl

用ReactOS上明确说过，Pnp管理器对每种设备都会创建一个虚拟root device用于构建设备树；同时这个新创建的root device又作为一个设备栈的栈底，往上形成完整的设备栈。用windbg调试时，可以看到这个虚拟设备属于/driver/pnpmanager驱动。    昨天出于好奇想看下设备树，结果发现只有虚拟设备attach在/driver/pnpmanger创建的设备上，而类

msddk样例中toaster是一个比较完整和值得学习的pnp驱动，包括了一个完整的设备栈(含总线驱动/功能驱动，以及设备栈中各层过滤驱动)和驱动安装程序(含驱动安装包/类安装程序/协安装程序)。本篇记录在xp下调试busenum驱动入口(关于环境的搭建网上一搜一大把，这里就省了，当然也可以参考这篇:win7 x64部署和串口调试虚拟驱动toaster)。    通过添加硬件的方式安装buse

前一篇 DDK样例toaster分析(1) 主要讨论了toaster样例中的busenum总线驱动。本篇将讨论从总线驱动过渡到功能驱动，也就是toaster.sys。    成功安装busenum.sys后，运行toaster/exe/enum目录下的enum程序模拟一个toaster设备插入:enum -p 1    前面busenum.sys!Bus_AddDevice创建Fdo的同时

系统关闭时，会向注册SHUTDOWN事件的设备驱动发送IRP_MJ_SHUTDOWN事件。NTSTATUS STDCALLNtShutdownSystem(IN SHUTDOWN_ACTION Action){ if (Action > ShutdownPowerOff) return STATUS_INVALID_PARAMETER; Status = PsCre

在windows SEH机制注释(1) 基于ReactOS 一文中，注释了try/except宏，windows的SEH机制除了这对宏，还有try/finall宏，用来执行善后处理。相比try/except，try/finall简单很多，没有绕人的长跳转，基本上属于顺序处理流程。如下：1.func(){    _SEH_TRY    {        //do st

1.SEH链表的布局:FS:[0]->因函数层层调用形成嵌套的全局SEH链表: _SEHFrame!__SEHRegistration* SER_Prev->_SEHFrame!__SEHRegistration* SER_Prev->_SEHFrame!__SEHRegistration* SER_Prev ...        |

Section/Segment/ControlArea/Subsection/MMVAD之间的关系不知道能不能这么理解:Section是内存映射的管理结构，内含Segment。当文件的内容被映射到内存后，Segment中的原型pte是指向已经被映射到内存中的文件页面。而ControlArea也是一个管理结构，其后的Subsection中有大量的原型pte这些原型pte指向即将被映射

建立内存映射，就是把文件内容映射到进程虚拟空间，这个可以通过MSDN达成共识。NtCreateSection是建立内存映射的第一步，而MmCreateSection是建立内存映射NtCreateSection的具体实现。前面 一文提到了Section/Segment等对象之间的关系，而MmCreateSection就是用来建立这些对象的关系。    MmCreateSection代码过于繁

MmCreateSection/MmMapViewOfSection个人注释及理解(一)中提到内存映射的第一步创建Section对象建立Segment与文件的关系，彼时尚未建立虚拟内存因此不能被访问。此文是内存映射的第二步，MmMapViewOfSection建立虚拟映射。

windows的过程，有如linux的软中断。以前Linux内核中自旋锁同步分析提到过，Linux通过IN_HARDIRQ/IN_SOFTIRQ来屏蔽软中断的执行，windows其实也类似，偷梁换柱的用IRQL来代替这些概念:IRQL高于DPC_LEVEL时，DPC过程无法执行，因为可能是中断过程正在执行；当通过KfLowerIrql降低IRQL请求级别到DPC_LEVEL及以下时开始执行DPC过

/* * @implemented 来看一下跟中断对象有关的两个对象: typedef struct _IO_INTERRUPT{ KINTERRUPT FirstInterrupt; PKINTERRUPT Interrupt[MAXIMUM_PROCESSORS]; KSPIN_LOCK SpinLock;} IO_INTERRUPT, *PIO_INTERR

结合前面从IRQ到IRQL(APIC版)和Windows 自旋锁分析(一) 可以知道HalBeginSystemInterrupt通过用IRQL做索引在HalpIRQLtoTPR数组中获取该IRQL对应的任务优先级，用该优先级设置任务优先级寄存器TPR，并把TPR中原先的任务优先级/16做为索引在HalpVectorToIRQL数组中获取对应的原先的IRQL然后返回。观察K

M$ddk对调用KeWaitForSingleObject接口有下面约定:Callers of KeWaitForSingleObject must be running at IRQL <= DISPATCH_LEVEL. However, if Timeout = NULL or *Timeout != 0, the caller must be running at IRQL <= A

MS上有很多关于驱动中使用IRP的守则(跟黄历中的宜忌差不多了)，比如:1.“Drivers must not attempt to reuse IRPs issued by the I/O manager. In particular, drivers should not attempt to reuse IRPs created by the IoMakeAssociatedIrp, I

一直很好奇双击ddk的Checked/free Build Environment跳出的cmd对话框能运行build编译驱动(其实App也行)，直接用cmd运行build，却提示找不到可运行的命令。开始时，怀疑环境变量Path没有包含build所在的路径导致不能工作，可是向Path追加了build的路径，虽然可以执行build但仍然不能生成sys。    于是换个思路驱动程序所在的目录下都少不

WDK7600自带的toaster驱动是个很好的学习驱动的案例，从总线驱动到App层，Class-install/Co-install都有涉及。本文主要涉及驱动部署和调试。1.先说说调试的准备工作。一般调试驱动都是在虚拟机中进行的，这里也不例外，用windbg+vmware双击联调。通常开发阶段，Wdm驱动以inf形式安装并加载，加载后依次执行DriverEntry，AddDevice并响应I