m0_68259687的博客

windows提供了API用来监控我们的线程进程的创建和销毁。主要是下面几个函数//进程线程//模块先从最简单的PsSetCreateProcessNotifyRoutine开始。

在上篇文章中我们介绍了全局句柄表，同样与之对应的还有私有句柄表。首先写一段代码来尝试打开进程句柄，我这里还是以CFF为例(什么软件其实无所谓，主要能使用OpenProcess打开就行)运行这个程序，得到结果这些返回的16进制数就是我们这次打开的句柄在我们写的代码所运行的这个程序中的私有句柄表中的位置。我这里程序名称叫做OpenReverseCollapse，这里可以看见EPROCESS的位置，当然也可以直接用 ObjectTable中的这个地址。

示意大概如下，也就是不同颜色的长条就是不同的WaitListEntry，这些长条被集中在一个DispatcherReadyListHead中，当然，应该要有32个，我这里只是示意一下。我们找到了eax是从一个edi所索引的地方取出来的，这个edi就是我们的第二个参数，它也是一个prcb，所以我们就可以知道这个0x31ec是什么，没错，就是位图。所以我们这里为了加深印象，windbg看一下，就知道，这个KiFindReadyThread所代表的函数是Prcb，这样，我们就找到了第一个参数。

StackLimit和InitialStack中间所开辟的这段栈空间就是我们线程的栈空间，其中紫色部分还要用做KTRAP，红色部分是浮点，只有绿色部分是真正线程栈的所在地。这个东西在我们调试的时候还是比较有用的，如果我们写驱动蓝屏了，就可以在查看当前线程，然后去找到这个esp的值，去看看具体蓝屏的原因。同样是用windbg来查看我们进程的具体情况,可以看到有很多的信息，我们的线程地址是 88287370。线程对应的结构也有KTHEARD和ETHREAD，dt打开看一下。继续往下看，几个重要的值。

先随便来打开一个进程，这里我就开了一个CE为例首先在windbg中用命令来遍历进程我们会看见这样的结果,一般新开的进程都在最下面87137218就是我们进程的地址了，进程空间本质上就是一块内存我们的信息都按照EPROCESS这个结构来存，乍一看，很多，但是不用担心，我们会一点点基本的解析。

先放一个成品小demo。

在经历了这么多复杂的机制后，iret返回的KTRAP_FRAME五个值也对应了我们所学习的知识,不知道大家有没有感受到系统设计之美（😀。如果翻一翻上篇，就会知道这是一个SystemcallRet的位置，我们到ntdll中去找到这个KiFastSystemCallRet。到这里，我们就基本的，初步的了解了有关win系统调用的流程，知道了几个结构，也就可以继续开始我们下一阶段的学习了。书接上文，我们继续分析，这一段主要是几个蓝屏的处理，以及对于Irql的验证，以及etw调用。接下来是性能统计和APC相关操作。

如果我们已经稍微熟悉了ntdll里面的基本结构，我们就可以知道从R3转向R0的入口大概都是一个汇编，这里以OpenProccess函数为例这里强调一下，图中红框标出的位置就是同一段汇编的两个不同的声明，所以Nt开头和Zw开头是一样的可以看到，汇编就只有短短的几行，这里注释一下这是什么意思呢？这就说明，在ntdll封装的实现中，本质上也是一个转发，在找到了不同的系统服务例程号（不同函数不同）后，去找到KiFastCallEntry这个函数，然后根据具体的调用号来进入内核调用。

本来想按照理论+实践的方式继续向下写文章，但是写来写去发现这一阶段涉及的知识实在是太多太杂，如果什么都事无巨细的去讲解，那么这样反倒会让文章变得杂乱，所以我打算直接上一个demo代码，然后根据这个demo代码来补全我们现阶段应该知道的知识（不一定理解深入，先会用经过调试，在停止服务后，任意按下一个按键就蓝屏，所以问题就在这个驱动卸载函数里面。更加精确的定位应该在这个DeAttach函数中，但是反正也不影响我们使用，就懒得搞了（菜这也是为后来的自己或者其他人指个路//设备卸载函数。

试想一下，我们未来写的某个驱动，他要发挥作用，那么处在R0的它必须要R3的程序相互通信，传输字符串，传输结果，传输数据（如果不能正常的做到这一点那么就算你随便读内存了也看不见啊是不是）第二个参数是DeviceExtensionSize，它会指定一个额外的空间来存储结构信息，比如我们创建了某个设备它有一些额外的参数，信息，就可以被存储在这个扩展出来的空间里面。上面的两个参数，一个是我们的设备对象，一个就是我们刚刚介绍的IRP。然后，在最后，我们写一个程序来和我们的设备通信。，暂时不需要了解IRP的结构特征。

那既然我们已经正确的找到这个双向链表了，剩下的事情就好办多了，使用我们之前驱动篇基础里面介绍过的API来初始化一个Unicode字符串，然后用这个字符串去对比某个目标模块，如果一致，就按照链表断链的方式将其从双向链表中删除，继续修改我们的代码。我们看见了第一个InLoadOrderLinks里面的双向链表，所以我们用它给的Flink来访问链表里面的下一个节点，由于我们的MyDriver2是最后一个加载的驱动，所以它的下一个也就是我们的第一个驱动，果不其然，是我们的内核。这是真正的断掉了吗？

首先看右边，我红圈标出来的地方默认会有inf文件，里面会标记我们驱动的信息，如果不填编译器会报错，这里我们暂时不需要，因为我们现阶段还是只是在不验证驱动签名的Win7上进行开发，等到后续介绍到Win10之后，我们会重新介绍inf，我们的驱动依次有NT（不支持即插即用功能），WDM（支持即插即用功能），WDF（以WDM为基础的框架，为了简化我们开发的流程），以及UMDF，KMDF（用户，内核）。这时候如果我们按下卸载驱动，会发现我们是卸载不掉的，这是因为我们在之前的代码中没有留下卸载驱动的函数，把它补上。

我们知道，10-10-12分页的表示范围是有极限的，1024 * 1024 * 1024 * 4 也就是4GB，但是我们现在大部分的操作系统，包括我们平时所使用的个人电脑，基本上都超过了这个内存，所以，一定是有新的分页方式代替了原有的分页。选用的进程DirBase是0670d440 ，我们的PDPTE也是8个字节，按照我们之前所学，找到了GDT表的物理地址的位置，验证了我们之前的理论知识。首先先把页切回2-9-9-12，看CR3的值像下面一样就可以了。将这个地址按照2-9-9-12的顺序拆开。

我们现在是用windbg手动去修改PTE，但是随着我们学习的深入，我们就可以使用程序来自动化这一过程，来达到我们注入shellcode的效果。

我们在之前的学习中，已经学习了相当一部分有关段的知识，CPU提供了段的机制来给我们的内存进行保护，但实际上我们在x86下的段base是0，实际上并没有偏移。

在介绍中断门之前，我们先介绍IDT表如果我们查看IDT表的解析结构，就会发现它和之前我们学习的GDT表非常类似IDT也是由段描述符组成的，既然我们之前已经介绍过了调用门，那么这个中断门我们自然是十分轻松的与调用门使用call来调用不同，中断门我们使用int指令来调用，没错，就是我们之前经常用到的int 3之流，在执行完之后会通过中断门跳入到对应的int 3函数中（int 3其实是一个函数，不只是指令怎么简单，我们马上来证明）

所以，综上所述，对于ss堆栈段来说，需要DPL和RPL保持一致，再由CS和SS必须保持一致的原则我们可以知道 对于堆栈来说，只有DPL== RPL==CPL，那么代码才能正常执行。所以我们在这里可以把ss改为R3，也就是4b，多余的过程就不截图了。CPL是当前进程的权限级别(Current Privilege Level)，是当前正在指向的代码段所在段的成绩，也就是CS段的DPL。首先还是得到现在GDT表，然后把index为4的段描述符放到index为9的地方，并且改变其DPL为0环，00cff300。

在我写的2.保护模式＋段探测这篇文章中，我们提到了S位对于段描述符的控制，之前我们已经介绍了代码段和数据段，现在我们来把目光转到系统段在这么多中结构里面，我们今天要介绍的就是编号为12的，32位调用门结合上面的图，我们先暂时只需要记住，当S = 0 ，type = C，那么这说明这个段描述符是一个调用门也就是下图所示。

其中这张表里面Read可读，Write可写，Execute可执行，accessed被访问过，expand-down表示向下扩展，conformimg表示一致位，这几个里面一致位如果是1，那么就说明这个段所指的内存是纯段没有页的，但是现在的操作系统基本上都有分页，故不再赘述。左边是正常的向上拓展，即base到Limit这一段距离的内存有效，右边是base到Limit这一段距离无效，也就是向下拓展，总的来说，向下拓展就是段所指的这部分内存无效。S位会决定是下面哪种表格，当s = 1 时，说明此时是数据段。

而base的值为 00 0000，再添加上两段分开的00，

本课程涉及的驱动，是利用驱动程序的高级权限，去做一些用户层不能做的工作，严格来说，这些写出来的东西不能算是驱动，因为它不会驱动任何设备。