Windows系统调用中的系统服务表描述符

 Windows内核分析索引目录:https://www.cnblogs.com/onetrainee/p/11675224.html

Windows系统调用中的系统服务表描述符

  在前面,我们将解过 系统服务表。可是,我们有个疑问,系统服务表存储在哪里呢?

  答案就是:系统服务表 存储在 系统服务描述符表中。(其又称为 SSDT Service Descriptor Table)

  

 一、使用PELord函数从ntoskrnl.exe文件中查看SSDT导出函数

  如图,可以看出KeServiceDescriptorTable导出函数。

  通过该函数可以查找SSDT表的位置。

  

二、通过Windbg来内存中查看SSDT表

  使用Windbg,可以使用 kd> dd nt!KeServiceDescriptorTable 指令来查看SSDT表。

  但该指令存在缺点,可以看到第二张表为0,说明如果使用KeServiceDescriptorTable这个公开的导出函数,我们无法看到win32k.sys这张表结构

  kd> dd nt!KeServiceDescriptorTable
    83f759c0  83e89d9c 00000000 00000191 83e8a3e4
    83f759d0  00000000 00000000 00000000 00000000
    83f759e0  83ee86af 00000000 0327aa43 000000bb
    83f759f0  00000011 00000100 5385d2ba d717548f

  为了解决上面这个问题,我们只能使用另外一个指令,该指令对应的是一个未公开导出的函数。

  如下,可以看到其第二行,win32k.sys系统服务表已经可见。

  kd> dd KeServiceDescriptorTableShadow
    83f75a00  83e89d9c 00000000 00000191 83e8a3e4
    83f75a10  83b66000 00000000 00000339 83b6702c
    83f75a20  00000000 00000000 83f75a24 00000340
    83f75a30  00000340 855e8440 00000007 00000000

三、验证ReadMemory真正的内核实现部分

  我们在这篇《Windows系统调用中API的三环部分(依据分析重写ReadProcessMemory函数)》中曾提到过直接使用快速调用来摒弃R3层层封装的API,其中给eax一个函数号,现在我们来实战刨析一下。

mov eax, 0x115
mov edx, 0X7FFE0300

  如下,系统描述符的数据结构,其依次分别为

  

  其依次分别为 ServiceTable 83e89d9c,Count 00000000,ServiceLimit  00000191,ServiceTable 83e8a3e4 

  使用Windbg来查看其115h序号的函数地址 115h*4 + 83e89d9c (ServiceTable)

  得到函数地址为 8406c82c

  kd> dd 115h*4 + 83e89d9c
    83e8a1f0  8406c82c 840feb46 83fb488c 83fb6128 

  再对此进行反汇编可得

  kd > u 8406c82c   
                nt!NtReadVirtualMemory:
                8406c82c 6a18            push    18h
                8406c82e 68282ae683      push    offset nt!? ? ::FNODOBFM::`string‘+0x3ea8 (83e62a28)
                8406c833 e870e3e1ff      call    nt!_SEH_prolog4(83e8aba8)
                8406c838 648b3d24010000  mov     edi, dword ptr fs : [124h]
                8406c83f 8a873a010000    mov     al, byte ptr[edi + 13Ah]
                8406c845 8845e4          mov     byte ptr[ebp - 1Ch], al
                8406c848 8b7514          mov     esi, dword ptr[ebp + 14h]
                8406c84b 84c0            test    al, al

  之后,我们查看该nt!NtReadVirtualMemory函数的参数个数

  kd > db 83e8a3e4 + 115
                83e8a4f9  14 08 04 04 14 04 10 08 - 0c 04 14 18 08 08 08 0c
                83e8a509  0c 08 10 14 08 08 0c 08 - 0c 0c 04 08 08 08 08 08  
                83e8a519  08 0c 0c 24 00 08 08 08 - 0c 04 08 04 08 10 08 04  

  

四、通过修改SSDT表增添系统服务函数

  我们在 Windows系统调用中API的三环部分(依据分析重写ReadProcessMemory函数) 调用的是 115h 号函数。

  现在,我们将该函数地址放到 191 号函数处(之前一共有191个函数,占据0-190位)。

  修改思路:

  1)将 nt!NtReadVirtualMemory 函数地址 8406c82c 放到 191号处(83e89d9 + 191h*4)

    kd> ed 83e89d9 + 191h*4 8406c82c 

  2)  增大 服务表最大个数。 (因为我们上一节分析其反汇编代码的时候,发现其会进行最大个数的判断)

    kd> ed 83f75a00+8 192

  3)  修改参数个数表中对应的191号参数个数。(我们之前查阅过其为 14,以字节为单位)

    kd> eb 83e8a3e4+191 14

  4)  之后,我们运行下列代码。其与《Windows系统调用中API的三环部分(依据分析重写ReadProcessMemory函数)》唯一的不同调用函数号为192,最终效果完全一样。

 1 #include "pch.h"
 2 #include <iostream>
 3 #include <algorithm>
 4 #include <Windows.h>
 5 void  ReadMemory(HANDLE hProcess, PVOID pAddr, PVOID pBuffer, DWORD dwSize, DWORD  *dwSizeRet)
 6 {
 7
 8     _asm
 9     {
10         lea     eax, [ebp + 0x14]
11         push    eax
12         push[ebp + 0x14]
13         push[ebp + 0x10]
14         push[ebp + 0xc]
15         push[ebp + 8]
16         sub esp, 4
17         mov eax, 0x192  // 注意:修改的是这里
18         mov edx, 0X7FFE0300   //sysenter不能直接调用,我间接call的
19         CALL DWORD PTR[EDX]
20         add esp, 24
21
22     }
23 }
24 int main()
25 {
26     HANDLE hProcess = 0;
27     int t = 123;
28     DWORD pBuffer;
29     //hProcess = OpenProcess(PROCESS_ALL_ACCESS, 0,a);
30     ReadMemory((HANDLE)-1, (PVOID)&t, &pBuffer, sizeof(int), 0);
31     printf("%X\n", pBuffer);
32     ReadProcessMemory((HANDLE)-1, &t, &pBuffer, sizeof(int), 0);
33     printf("%X\n", pBuffer);
34
35     getchar();
36     return 0;
37 }

  

原文地址:https://www.cnblogs.com/onetrainee/p/11717309.html

时间: 2024-08-28 13:00:38

Windows系统调用中的系统服务表描述符的相关文章

Windows系统调用中的系统服务表

Windows内核分析索引目录:https://www.cnblogs.com/onetrainee/p/11675224.html Windows系统调用中的系统服务表 如果这部分不理解,可以查看 Windows内核分析索引目录依次阅读. 我们在之前讲过系统调用过程中,给予eax一个编号,操作系统通过这个编号来执行某个内核函数. 这个函数是通过操作系统的系统服务表来查找的. 现在,我们来探究一下nt!KiFastCallEntry的反汇编代码,看看其如何查看系统服务表找到要执行的函数的. 一.

Windows系统调用中API从3环到0环(下)

 Windows内核分析索引目录:https://www.cnblogs.com/onetrainee/p/11675224.html Windows系统调用中API从3环到0环(下) 如果对API在三环的部分不了解的,可以查看 Windows系统调用中的API三环部分(依据分析重写ReadProcessMemory函数 上篇:Windows系统调用中API从3环到0环(上) 这篇文章分为上下两篇,其中上篇初步讲解大体轮廓,下篇着重通过实验来探究其内部实现,最终分析两个函数(快速调用与系统中断)

64位Windows操作系统中的注册表

x64系统上有x64.x86两种注册表,记录下. 64 位Windows系统中的注册表分为 32 位注册表项和 64 位注册表项,许多 32 位注册表项与其相应的 64 位注册表项同名. 在64位版本系统的注册表编辑器中,32 位注册表项显示在以下注册表项下: HKEY_LOCAL_MACHINE\Software\WOW6432Node 使用默认的 64 位版本注册表编辑器%systemroot%\Syswow64\regedt.exe,可以查看或编辑 64 位和 32 位的注册表项和项值.

Windows系统调用中API的3环部分(依据分析重写ReadProcessMemory函数)

Windows内核分析索引目录:https://www.cnblogs.com/onetrainee/p/11675224.html Windows系统调用中API的3环部分 一.R3环API分析的重要性 Windows所提供给R3环的API,实质就是对操作系统接口的封装,其实现部分都是在R0实现的. 很多恶意程序会利用钩子来钩取这些API,从而达到截取内容,修改数据的意图. 现在我们使用olldbg对ReadProcessMemory进行跟踪分析,查看其在R3的实现,并根据我们的分析来重写一个

Windows系统调用中的现场保存

Windows内核分析索引目录:https://www.cnblogs.com/onetrainee/p/11675224.html Windows系统调用中的现场保存 我们之前介绍过三环进零环的步骤,通过中断或者快速调用来实现. 但是我们是否考虑过CPU从三环进入零环时,其三环的寄存器该如何保存. 这一篇文件就来介绍其系统调用中的(三环)现场保存的问题. 一.几个重要的结构体介绍 1. _Ktrap_frame 该结构体简单来说用于三环的寄存器保存,存储于零环,由操作系统维护 详细信息可以查看

python中名称修饰与描述符

名称修饰 java和C#等其他高级语言中都有private关键字来修饰一个属性或字段是私有的,但是python中并没有private,而是有个与它接近的概念旧式名称修饰.每当在一个属性前面加上__前缀,解释器就会立刻将其重命名: 直接访问会抛异常 利用dir函数查看内部属性 python内部会把__前缀的属性重命名为[_类名+属性名]:因此在python中如果一个属性不是共有的就约定使用双下划线__为前缀,它不会调用任何名称修饰的算法,只是说名这个属性是该类的私有属性. 幸运的是python中还

关于Java Web应用中的配置部署描述符web.xml

一.web.xml概述 位于每个Web应用的WEB-INF路径下的web.xml文件被称为配置描述符,这个 web.xml文件对于Java Web应用十分重要,每个Java Web应用都必须包含一个web.xml文件,且必须放在WEB-INF路径下. 对于Java Web应用而言,WEB-INF是一个特殊的文件夹,Web容器会包含该文件夹下的内容,客户端浏览器无法访问WEB-INF路径下的任何内容.Java Web应用的绝大部分内容都由web.xml文件来配置管理.我们后面介绍的如下内容都要通过

Python中的动态属性与描述符

动态属性与属性描述符 属性描述符是什么? ??在解释属性查找顺序之前我们需要了解Python中的属性描述符,属性描述符作为其他类对象的属性而存在,实现了特殊方法中的get.set.delete中的一种即可称作属性描述符. 其中只实现了__get__()的称作非数据描述符,实现了__get__()和__set__()方法的称作数据描述符. Data.py class Data(): def __get__(self, instance, owner): pass def __set__(self,

Linux中文件描述符fd和文件指针flip的理解

转自:http://www.cnblogs.com/Jezze/archive/2011/12/23/2299861.html 简单归纳:fd只是一个整数,在open时产生.起到一个索引的作用,进程通过PCB中的文件描述符表找到该fd所指向的文件指针filp. open:文件描述符的操作(如: open)返回的是一个文件描述符(int fd),内核会在每个进程空间中维护一个文件描述符表, 所有打开的文件都将通过此表中的文件描述符来引用(fd1,fd2,fd3...); fopen:而流(如: f