API调用过程

目录

• 一、API调用过程（3环部分）
  • 什么是API？
  • 几个重要的DLL
  • IDA分析ReadProcessMemory API
• （二）API调用过程（3环进0环）
  • 1、_KUSER_SHARED_DATA 结构
  • 2、分析7FFE0300h进Ring0的方式
  • 3、两种进Ring0的方式
    • 3.1 API通过中断门进Ring0
    • 3.2 通过int 0x2e进Ring0
    • 3.3 sysenter进Ring0
• （三）API调用过程（保护现场）
  • 为什么要保存现场？
  • KiFastCallEntry的填表过程
• （四）API调用（系统服务表）
  • 1、前言
  • 2、系统服务表
  • 3、如何找到系统服务表
  • 4、判断调用的函数在哪个表
  • 5、分析API函数的调用过程
• （五）API函数的调用过程（SSDT）
  • 1、分析KeServiceDescriptorTable
  • 2、系统服务描述表，SSDT
  • 3、SSDT Shadow

一、API调用过程（3环部分）

什么是API？

API，Application Programming Interface 应用程序接口，操作系统的API主要放在C:\WINDOWS\system32 。绝大多数的API都是在Ring0实现的，极少数是在3环，3环只是提供一个接口。

几个重要的DLL

1、Kernel32.dll

最核心的功能模块：如管理内存、进程、线程相关函数

2、User3.dll

是Windows用户界面相关应用程序接口，如创建窗口和发送消息

3、GDI32.dll

Graphical Device Interface，图形设备接口，包含用于画图和显示文本的函数：如要显示一个程序窗口

4、Ntdil.dll

大多数API都会通过这个DLL进入内核

IDA分析ReadProcessMemory API

1、Kernel32.dll中搜索ReadProcessMemory

//5个参数压栈
.text:7C8021D0 ProcessHandle   = dword ptr  8 	
.text:7C8021D0 BaseAddress     = dword ptr  0Ch
.text:7C8021D0 Buffer          = dword ptr  10h
.text:7C8021D0 BufferLength    = dword ptr  14h
.text:7C8021D0 lpNumberOfBytesRead= dword ptr  18h
.text:7C8021D0
.text:7C8021D0                 mov     edi, edi
.text:7C8021D2                 push    ebp
.text:7C8021D3                 mov     ebp, esp
.text:7C8021D5                 lea     eax, [ebp+BufferLength]
.text:7C8021D8                 push    eax             ; ReturnLength
.text:7C8021D9                 push    [ebp+BufferLength] ; BufferLength
.text:7C8021DC                 push    [ebp+Buffer]    ; Buffer
.text:7C8021DF                 push    [ebp+BaseAddress] ; BaseAddress
.text:7C8021E2                 push    [ebp+ProcessHandle] ; ProcessHandle
.text:7C8021E5                 call    ds:NtReadVirtualMemory ;核心功能在这里
.text:7C8021EB                 mov     ecx, [ebp+lpNumberOfBytesRead]
.text:7C8021EE                 test    ecx, ecx
.text:7C8021F0                 jnz     short loc_7C8021FD
.text:7C8021F2
.text:7C8021F2 loc_7C8021F2:                           ; CODE XREF: ReadProcessMemory+32j
.text:7C8021F2                 test    eax, eax  	
.text:7C8021F4                 jl      short loc_7C802204 ；小于0则跳转
.text:7C8021F6                 xor     eax, eax
.text:7C8021F8                 inc     eax
.text:7C8021F9
.text:7C8021F9 loc_7C8021F9:                           ; CODE XREF: ReadProcessMemory+3Cj
.text:7C8021F9                 pop     ebp
.text:7C8021FA                 retn    14h
.text:7C8021FD ; ---------------------------------------------------------------------------
.text:7C8021FD
.text:7C8021FD loc_7C8021FD:                           ; CODE XREF: ReadProcessMemory+20j
.text:7C8021FD                 mov     edx, [ebp+BufferLength]
.text:7C802200                 mov     [ecx], edx
.text:7C802202                 jmp     short loc_7C8021F2
.text:7C802204 ; ---------------------------------------------------------------------------
.text:7C802204
.text:7C802204 loc_7C802204:                           ; CODE XREF: ReadProcessMemory+24j
.text:7C802204                 push    eax             ; NtStatus
.text:7C802205                 call    sub_7C8093FD
.text:7C80220A                 xor     eax, eax
.text:7C80220C                 jmp     short loc_7C8021F9

2、参数压栈后，调用了另外一个函数，返回结果在eax中，小于0的话就跳到这里

ReadProcessMemory+24j
.text:7C802204                 push    eax             
.text:7C802205                 call    sub_7C8093FD	;这是一个API用于设置错误号
.text:7C80220A                 xor     eax, eax
.text:7C80220C                 jmp     short loc_7C8021F9

3、Call一个用于设置错误号（BaseSetLastNTError ）函数，将eax清0后，又跳回去。

.text:7C8021F9
.text:7C8021F9 loc_7C8021F9:                           ; CODE XREF: ReadProcessMemory+3Cj
.text:7C8021F9                 pop     ebp
.text:7C8021FA                 retn    14h

跳到这，直接返回，所以失败返回的结果是0.

4、如果eax>0，eax清0，eax+1，返回1

分析完这个函数，发现：主要的功能实现全面在NtReadVirtualMemory 这个API里了。

我们先来看看NtReadVirtualMemory 在哪个DLL中。

打开导入表，发现在ntdll.dll里。

7C801418  NtReadVirtualMemory ntdll

在这个dll里搜索一下NtReadVirtualMemory

发现这个函数里也没什么实现细节，只是提供一个操作码，通过这种方式实现从3环进入0环，而真正的函数实现是在0环。

.text:7C92D9E0                 mov     eax, 0BAh       ; NtReadVirtualMemory
.text:7C92D9E5                 mov     edx, 7FFE0300h  ;决定了什么方式进0环
.text:7C92D9EA                 call    dword ptr [edx]
.text:7C92D9EC                 retn    14h

我们自己在3环实现一个ReadProcessMemory ，自己实现的好处就在于 能够防止被人来通过API断点来分析我们的程序，对我们的程序进行hook检测。

具体的实现如下：

#include<windows.h>
#include<stdio.h>

void __declspec(naked) read(HANDLE hProcess,LPVOID addr,LPVOID buffer,DWORD len)
{
	_asm
	{
		mov   eax, 0BAh
		mov   edx, 7FFE0300h
		call  dword ptr[edx]

		ret
	}
}

int main(int argc, char* argv[])
{
	HWND hwnd = FindWindow("#32770","xxx");
	DWORD pid;
	GetWindowThreadProcessId(hwnd,&pid);
	HANDLE hProcess = OpenProcess(PROCESS_ALL_ACCESS, FALSE, pid);
	DWORD val = 0;

	read(hProcess,(LPVOID)0x001D6EBC,&val,4);

	printf("val: %d", val);

	getchar();
	return 0;
}

（二）API调用过程（3环进0环）

1、_KUSER_SHARED_DATA 结构

在用户层和核心层分别定义了一个 _KUSER_SHARED_DATA 结构区域，用于用户层和内核层共享某些数据。

它们使用固定的地址值映射，_KUSER_SHARED_DATA 结构区域在用户层和内核层的线性地址分别为：

用户层： 0x7ffe0000

内核层： 0xffdf0000

这两个线性地址对应的物理页是一样的。如图在windbg里查看这两个地址的数据：

备注：虽然指向的是同一个物理页，但在User层是只读的，在Kernel层是可读可写的。

再来看看_KUSER_SHARED_DATA 这个结构，windbg 中输入 dt _KUSER_SHARED_DATA

0: kd> dt _KUSER_SHARED_DATA
nt!_KUSER_SHARED_DATA
   +0x000 TickCountLow     : Uint4B
   +0x004 TickCountMultiplier : Uint4B
   +0x008 InterruptTime    : _KSYSTEM_TIME
   +0x014 SystemTime       : _KSYSTEM_TIME
   +0x020 TimeZoneBias     : _KSYSTEM_TIME
   +0x02c ImageNumberLow   : Uint2B
   +0x02e ImageNumberHigh  : Uint2B
   +0x030 NtSystemRoot     : [260] Uint2B
   +0x238 MaxStackTraceDepth : Uint4B
   +0x23c CryptoExponent   : Uint4B
   +0x240 TimeZoneId       : Uint4B
   +0x244 Reserved2        : [8] Uint4B
   +0x264 NtProductType    : _NT_PRODUCT_TYPE
   +0x268 ProductTypeIsValid : UChar
   +0x26c NtMajorVersion   : Uint4B
   +0x270 NtMinorVersion   : Uint4B
   +0x274 ProcessorFeatures : [64] UChar
   +0x2b4 Reserved1        : Uint4B
   +0x2b8 Reserved3        : Uint4B
   +0x2bc TimeSlip         : Uint4B
   +0x2c0 AlternativeArchitecture : _ALTERNATIVE_ARCHITECTURE_TYPE
   +0x2c8 SystemExpirationDate : _LARGE_INTEGER
   +0x2d0 SuiteMask        : Uint4B
   +0x2d4 KdDebuggerEnabled : UChar
   +0x2d5 NXSupportPolicy  : UChar
   +0x2d8 ActiveConsoleId  : Uint4B
   +0x2dc DismountCount    : Uint4B
   +0x2e0 ComPlusPackage   : Uint4B
   +0x2e4 LastSystemRITEventTickCount : Uint4B
   +0x2e8 NumberOfPhysicalPages : Uint4B
   +0x2ec SafeBootMode     : UChar
   +0x2f0 TraceLogging     : Uint4B
   +0x2f8 TestRetInstruction : Uint8B
   +0x300 SystemCall       : Uint4B
   +0x304 SystemCallReturn : Uint4B
   +0x308 SystemCallPad    : [3] Uint8B
   +0x320 TickCount        : _KSYSTEM_TIME
   +0x320 TickCountQuad    : Uint8B
   +0x330 Cookie           : Uint4B

2、分析7FFE0300h进Ring0的方式

在之前分析的NtReadVirtualMemory中的代码如下：

.text:7C92D9E0                 mov     eax, 0BAh       ; NtReadVirtualMemory
.text:7C92D9E5                 mov     edx, 7FFE0300h  ;决定了什么方式进0环
.text:7C92D9EA                 call    dword ptr [edx]
.text:7C92D9EC                 retn    14h

当通过eax=1来执行cpuid指令时，处理器的特征信息被放在ecx和edx寄存器中，其中edx包含了一个SEP位，该位处于第11位，指明了当前CPU是否支持 sysenter、sysexit 指令，如果支持说明支持快速调用。

当SEP=1时，表明支持快速调用 , ntdll.dll!KiFastSystemCall()

当SEP=0时，表明不支持快速调用，ntdll.dll!KiIntSystemCall()。

7FFE0300h决定了以什么样的方式进入Ring0，那么7FFE0300h到底是如何决定的呢？

接下来我们来拆解一下7FFE0300h：

7FFE0300
‭0111  1111  1111  1110  0000  0011  0000  0000‬

第11位是0，所以不支持快速调用。

进入0环需要修改的寄存器

1、CS的权限由Ring3->Ring0，CS会发生改变

2、SS与CS的权限一致

3、权限发生切换的时候，堆栈也一定会切换，需要新的ESP

4、进Ring0后的代码位置

3、两种进Ring0的方式

3.1 API通过中断门进Ring0

如上所示的7FFE0300h就不支持快速调用，那么这种情况该如何进内核呢？

我们可以通过中断门进Ring0：

.text:7C92E500                 public KiIntSystemCall
.text:7C92E500 KiIntSystemCall proc near               ; DATA XREF: .text:off_7C923428o
.text:7C92E500
.text:7C92E500 arg_4           = byte ptr  8
.text:7C92E500
.text:7C92E500                 lea     edx, [esp+arg_4] ；edx是参数指针，系统调用号在eax寄存器
.text:7C92E504                 int     2Eh             ; DOS 2+ internal - EXECUTE COMMAND
.text:7C92E504                                         ; DS:SI -> counted CR-terminated command string
.text:7C92E506                 retn
.text:7C92E506 KiIntSystemCall endp

eax里的值是内核操作码，edx存的是参数的指针，api统一中断号0x2e，因为idt表在2e的位置。

3.2 通过int 0x2e进Ring0

具体步骤如下：

1、在IDT表中找到0x2e号的描述符

2、分析CS/SS/ESP/EIP的来源

3、分析EIP是什么

通过 >dq idtr L30 找到0x2e处的描述符，如图所示：

0: kd> dq idtr L30
8003f400  80548e00`000831a0 80548e00`0008331c
8003f410  00008500`0058113e 8054ee00`00083730
8003f420  8054ee00`000838b0 80548e00`00083a10
8003f430  80548e00`00083b84 80548e00`000841fc
8003f440  00008500`00501198 80548e00`00084600
8003f450  80548e00`00084720 80548e00`00084860
8003f460  80548e00`00084ac0 80548e00`00084dac
8003f470  80548e00`000854a8 80548e00`000857e0
8003f480  80548e00`00085900 80548e00`00085a3c
8003f490  80548500`00a057e0 80548e00`00085ba4
8003f4a0  80548e00`000857e0 80548e00`000857e0
8003f4b0  80548e00`000857e0 80548e00`000857e0
8003f4c0  80548e00`000857e0 80548e00`000857e0
8003f4d0  80548e00`000857e0 80548e00`000857e0
8003f4e0  80548e00`000857e0 80548e00`000857e0
8003f4f0  80548e00`000857e0 806e8e00`0008710c
8003f500  00000000`00080000 00000000`00080000
8003f510  00000000`00080000 00000000`00080000
8003f520  00000000`00080000 00000000`00080000
8003f530  00000000`00080000 00000000`00080000
8003f540  00000000`00080000 00000000`00080000
8003f550  8054ee00`000829ce 8054ee00`00082ad0
8003f560  8054ee00`00082c80 8054ee00`0008360c
8003f570  8054ee00`00082451 80548e00`000857e0

如图所示的最后一行的位置：8054ee00`00082451

0008就是CS，高4字节+低4字节就是EIP：80542451 ，SS和ESP是TSS提供的，如图所示：

通过 >u 80542451 查看反汇编，如图：

0: kd> u 80542451
nt!KiSystemService:

EIP：KiSystemService()，这个函数在内核模块里：

1、固定中断号为0x2e

2、CS/EIP由门描述符提供，ESP/SS由TSS提供

3、进入Ring0后执行内核函数： NT!KiSystemService

4、通过iret/iretd指令返回到用户模式

3.3 sysenter进Ring0

通过快速调用进Ring0，分析KiFastSystemCall()函数

.text:7C92E4F0                 public KiFastSystemCall
.text:7C92E4F0 KiFastSystemCall proc near              ; DATA XREF: .text:off_7C923428o
.text:7C92E4F0                 mov     edx, esp ;edx 3环栈顶，系统调用号在eax寄存器
.text:7C92E4F2                 sysenter ;寄存器数据传递
.text:7C92E4F2 KiFastSystemCall endp ; sp-analysis failed

eax是操作码，edx是返回地址以及参数的指针。

1、为什么叫快速调用

中断门进Ring0需要CS、EIP在IDT表中，需要查内存。

假设CPU支持sysenter指令时，OS会提前将CS、SS、EIP、ESP的值存储在MSR寄存器中，sysenter指令执行时，CPU会将MSR寄存器中的值直接写入相关的寄存器，没有读取内存的过程，所以叫快速调用。

2、在执行sysenter指令前，OS必须指定0环的CS段、SS段、EIP以及ESP。

MSR寄存器	MSR地址	含义
IA32_SYSENTER_CS	174h	低16位值指定了特权级0的代码段和栈段的段选择符
IA32_SYSENTER_ESP	175h	内核栈指针的32位偏移
IA32_SYSENTER_EIP	176h	目前例程的32位偏移

如上表所示：0x174位置存放的是新的CS，0x175位置存放的是新的ESP，0x176位置存放的是新的EIP。SS并没有存在MSR寄存器里，执行sysenter后，CS+8就是SS。

可以通过RDMSR/WRMST来进行读写。

windbg查看这几个值：

   rdmsr 174	 //查看CS
   rdmsr 175	//查看ESP
   rdmsr 176	//查看EIP

0: kd> rdmsr 174
msr[174] = 00000000`00000008
0: kd> rdmsr 175
msr[175] = 00000000`bacd0000
0: kd> rdmsr 176
msr[176] = 00000000`80542520

EIP：KiFastCallEntry()

0: kd> u 80542520
nt!KiFastCallEntry:
80542520 b923000000      mov     ecx,23h
80542525 6a30            push    30h
80542527 0fa1            pop     fs
80542529 8ed9            mov     ds,cx
8054252b 8ec1            mov     es,cx
8054252d 648b0d40000000  mov     ecx,dword ptr fs:[40h]
80542534 8b6104          mov     esp,dword ptr [ecx+4]
80542537 6a23            push    23h

用户代码调用sysenter指令以前，必须将要返回的指令地址和栈指针保存到edx和ecx寄存器中，否则，内核模式代码将来无法设置正确的值，以使sysexit还能返回到用户模式代码原来的位置。

API通过sysenter指令进0环：

1、CS、ESP、EIP由MSR寄存器提供

2、进0环后执行的内核函数： NT!KiCallEntry

3、通过sysexit指令返回用户模式

sysexit：

将IA32_SYSENTER_CS+16装载到CS寄存器；将edx寄存器中的指针装载到eip寄存器中；（指定用户模式代码段）

将IA32_SYSENTER_CS+24装载到SS寄存器；将ecx寄存器中的指针装载到esp寄存器中；（指定用户模式栈段）

切换到特权级3，执行eip寄存器中指定的用户代码。

（三）API调用过程（保护现场）

为什么要保存现场？

要理解保存现场的必要性，首先得明白：

1、API调用过程中发生了什么？

内核API调用的过程，会涉及到进程的切换，如从3环切换到0环。

2、这些东西在调用前后有什么变化？

3、保存现场在这其中的作用？

如何保存现场？

先来熟悉一个结构：_KTrap_Frame 结构

0: kd> dt _KTrap_Frame
nt!_KTRAP_FRAME

//调试系统服务
   +0x000 DbgEbp           : Uint4B
   +0x004 DbgEip           : Uint4B
   +0x008 DbgArgMark       : Uint4B
   +0x00c DbgArgPointer    : Uint4B
  
 //当需要调整栈时，以下作为临时变量
   +0x010 TempSegCs        : Uint4B
   +0x014 TempEsp          : Uint4B
 
 //调试寄存器
   +0x018 Dr0              : Uint4B
   +0x01c Dr1              : Uint4B
   +0x020 Dr2              : Uint4B
   +0x024 Dr3              : Uint4B
   +0x028 Dr6              : Uint4B
   +0x02c Dr7              : Uint4B
   
 //段寄存器
   +0x030 SegGs            : Uint4B
   +0x034 SegEs            : Uint4B
   +0x038 SegDs            : Uint4B
   
 //易失寄存器
   +0x03c Edx              : Uint4B
   +0x040 Ecx              : Uint4B
   +0x044 Eax              : Uint4B
   
 //非易失寄存器需要在中断历程中先保存
   +0x048 PreviousPreviousMode : Uint4B
   +0x04c ExceptionList    : Ptr32 _EXCEPTION_REGISTRATION_RECORD
   +0x050 SegFs            : Uint4B
   
 //非易失寄存器
   +0x054 Edi              : Uint4B
   +0x058 Esi              : Uint4B
   +0x05c Ebx              : Uint4B
   +0x060 Ebp              : Uint4B
   
  //硬件填充，通过中断门进入的话，这个值就是NULL
   +0x064 ErrCode          : Uint4B
   
  //中断发生时保存被中断的代码段和地址，iret返回到此地址
   +0x068 Eip              : Uint4B //硬件填充
   +0x06c SegCs            : Uint4B //硬件填充
   +0x070 EFlags           : Uint4B //硬件填充
   
   +0x074 HardwareEsp      : Uint4B
   +0x078 HardwareSegSs    : Uint4B
   +0x07c V86Es            : Uint4B
   +0x080 V86Ds            : Uint4B
   +0x084 V86Fs            : Uint4B
   +0x088 V86Gs            : Uint4B

无论是通过中断门进入0环，还是通过快速调用，3环所有的寄存器都会保存在这个结构里。

通过快速调用是不需要68~78号寄存器的。

IDA打开ntkrnlpa.exe， 查看KiSystemService函数细节如下：

（如果找不到这个函数，那可能就是符号库没加载成功，可以将调试机上的pdb文件拷到对应的被调试机的ntkrnlpa.exe目录）

.text:0046A451 _KiSystemService proc near              ; CODE XREF: ZwAcceptConnectPort(x,x,x,x,x,x)+Cp
.text:0046A451                                         ; ZwAccessCheck(x,x,x,x,x,x,x,x)+Cp ...
.text:0046A451
.text:0046A451 arg_0           = dword ptr  4
.text:0046A451
.text:0046A451                 push    0	;保存ErrCode到esp0
.text:0046A453                 push    ebp	;保存ebp到esp0
.text:0046A454                 push    ebx	;保存ebx到esp0
.text:0046A455                 push    esi	;保存esi到esp0
.text:0046A456                 push    edi	;保存edi到esp0
.text:0046A457                 push    fs	;保存fs到esp
.text:0046A459                 mov     ebx, 30h ;FS寄存器，指向KPCR
.text:0046A45E                 mov     fs, bx

权限发生切换时，堆栈也会发生改变。

内核层的ESP=TSS+4

Windows操作系统在每个处理器初始化时，会在GDT中为它构造一个TSS段，然后利用ltr指令设置处理器的任务环境段。

另外，Windows每次切换线程时，总会设置好TSS中0环的ESP，使其指向当前线程的内核栈。

保存3环寄存器值到_KTrap_Frame的0x50~0x64 的位置

将fs：0030做拆分，0030转化成二进制 0000 0000 0011 0000，RPL=0，index=6，即查GDT表的第6组：【ffc093df`f0000001 】

ffdff000这个地址刚好指向的就是CPU的KPCR结构，fs在3环指向的事PEB结构，在0环指向的就是KPCR。

.text:0046A461                 assume fs:nothing
.text:0046A461                 push    large dword ptr fs:0 ;保存老的ExceptionList,KPCR+0x00-> _NT_TIB -> ExceptionList
.text:0046A468                 mov     large dword ptr fs:0, 0FFFFFFFFh ;新的ExceptionList是空白的
.text:0046A473                 mov     esi, large fs:124h ;得到当前正在执行的线程信息:KPCR
.text:0046A47A                 push    dword ptr [esi+140h] ;保存老的“先前模式”到堆栈
														;KTHREAD
														;+0x140 PreviousMode
.text:0046A480                 sub     esp, 48h 			;ESP _KTRAP_FRAME 结构指针
.text:0046A483                 mov     ebx, [esp+68h+arg_0] ;取出3环压入的参数CS _KTRAP_FRAME + 0x6C
.text:0046A487                 and     ebx, 1 ;0环最低为0, 3环最低为1
.text:0046A48A                 mov     [esi+140h], bl  ;新的先前模式
.text:0046A490                 mov     ebp, esp		   ;ESP==EDP  _KTRAP_FRAME结构指针
.text:0046A492                 mov     ebx, [esi+134h]  ;_KTHREAD中TrapFrame
.text:0046A498                 mov     [ebp+3Ch], ebx	;将_KTHREAD中的TrapFrame暂存在这个位置，后面会将这个值取出来，重新恢复给_KTHREAD中TrapFrame

Exceptionlist是异常链表

把老的Exceptionlist保存到_KTRAP_FRAME的 +0x4c位置，然后把它清0.

将KPCR+0x124放在esi中，也就是说将CurrentThread放在esi中。

将[esi+140]保存先前模式（_KTHREAD.PreviousMode ）到_KTRAP_FRAME 的+0x48的位置。

再将堆栈提升0x48.

取出3环的CS放到ebx，然后将 esi+0x140=ebx &1，此时esi+0x140存储的就是新的先前模式。

那么这里反复提到的先前模式到底有什么用呢？

当我们调用这段代码的时候，如果是0环程序的先前模式就存0，3环就存1。OS通过先前模式就可以知道到底是哪一环的程序在调用自己。

提升栈底ebp与esp指向同一个位置 _KTRAP_FRAME 最开始的位置。

取出esi+0x134的位置是_KTHREAD.TrapFrame ，放在ebp+3c ???

.text:0046A49B                 mov     [esi+134h], ebp ;将堆栈中形成的_KTRAP_FRAME的结构指针赋值给_KTHREAD中的TrapFrame
.text:0046A4A1                 cld
.text:0046A4A2                 mov     ebx, [ebp+60h] ;3环的EBP
.text:0046A4A5                 mov     edi, [ebp+68h] ;3环的EIP
.text:0046A4A8                 mov     [ebp+0Ch], edx  ;edx存储的是3环参数的指针

_KTRAP_FRAME 放到 _KTHREAD.TrapFrame

把3环的ebp放到ebx

把3环的eip放到edi

把3环的参数指针放到 _KTRAP_FRAME.DbgArgPointer

.text:0046A4AB                 mov     dword ptr [ebp+8], 0BADB0D00h
.text:0046A4B2                 mov     [ebp+0], ebx  ;3环的ebp存储到_KTRAP_FRAME +0x00  DbgEbp 的位置
.text:0046A4B5                 mov     [ebp+4], edi  ;3环的eip存储到_KTRAP_FRAME+0x004 DbgEip的位置
.text:0046A4B8                 test    byte ptr [esi+2Ch], 0FFh ;判断_KTHREAD的+0x2c  DebugActive 是否为-1
.text:0046A4BC                 jnz     Dr_kss_a	;如果处于调试状态，跳转
.text:0046A4C2
.text:0046A4C2 loc_46A4C2:                           ; CODE XREF: Dr_kss_a+10j
.text:0046A4C2                                       ; Dr_kss_a+7Cj
.text:0046A4C2                 sti				    ;关闭中断
.text:0046A4C3                 jmp     loc_46A5AF	 ;取出从3环传进来的系统调用号
.text:0046A4C3 _KiSystemService endp

0BADB0D00h 这是操作系统用到的一个标志，将它放到 _KTRAP_FRAME.DbgArgMark 。

ebp+0x00 = _KTRAP_FRAME.DbgEbp
ebp+0x04 = _KTRAP_FRAME.DbgEip

比较 _KTHREAD.DebugActive ，判断当前线程是否处于调试状态，如果是这个值就不是0ff。处于调试状态中的代码就会跳转到下面的代码。

.text:0046A34C Dr_kss_a        proc near               ; CODE XREF: _KiSystemService+6Bj
.text:0046A34C                 test    dword ptr [ebp+70h], 20000h ;是否是虚拟8086模式（Eflags标志寄存器的VM位）
.text:0046A353                 jnz     short loc_46A362 ;不是跳转
.text:0046A355                 test    dword ptr [ebp+6Ch], 1
.text:0046A35C                 jz      loc_46A4C2	;关闭中断
.text:0046A362
.text:0046A362 loc_46A362:                             ; CODE XREF: Dr_kss_a+7j
.text:0046A362                 mov     ebx, dr0
.text:0046A365                 mov     ecx, dr1
.text:0046A368                 mov     edi, dr2
.text:0046A36B                 mov     [ebp+18h], ebx ;存储Dr0寄存器到 _KTRAP_FRAME+0x18
.text:0046A36E                 mov     [ebp+1Ch], ecx ;存储Dr1寄存器到 _KTRAP_FRAME+0x1C
.text:0046A371                 mov     [ebp+20h], edi ;存储Dr0寄存器到 _KTRAP_FRAME+0x20
.text:0046A374                 mov     ebx, dr3
.text:0046A377                 mov     ecx, dr6
.text:0046A37A                 mov     edi, dr7
.text:0046A37D                 mov     [ebp+24h], ebx ;存储Dr3寄存器到_KTRAP_FRAME
.text:0046A380                 mov     [ebp+28h], ecx ;存储Dr6寄存器到_KTRAP_FRAME
.text:0046A383                 xor     ebx, ebx
.text:0046A385                 mov     [ebp+2Ch], edi ;存储Dr7寄存器到_KTRAP_FRAME
.text:0046A388                 mov     dr7, ebx	;将Dr7寄存器清零
.text:0046A38B                 mov     edi, large fs:20h ;得到_KPRCD指针
.text:0046A392                 mov     ebx, [edi+2F8h]
.text:0046A398                 mov     ecx, [edi+2FCh]
.text:0046A39E                 mov     dr0, ebx
.text:0046A3A1                 mov     dr1, ecx

就是dr0~dr7存到_KTRAP_FRAME +0x18~+0x2c 。

如果当前线程的状态不处于调试的状态，就会转到下面这段代码：

.text:0046A5AF loc_46A5AF:                             ; CODE XREF: _KiBBTUnexpectedRange+18j
.text:0046A5AF                                         ; _KiSystemService+72j
.text:0046A5AF                 mov     edi, eax
.text:0046A5B1                 shr     edi, 8
.text:0046A5B4                 and     edi, 30h
.text:0046A5B7                 mov     ecx, edi
.text:0046A5B9                 add     edi, [esi+0E0h]
.text:0046A5BF                 mov     ebx, eax
.text:0046A5C1                 and     eax, 0FFFh
.text:0046A5C6                 cmp     eax, [edi+8]
.text:0046A5C9                 jnb     _KiBBTUnexpectedRange
.text:0046A5CF                 cmp     ecx, 10h
.text:0046A5D2                 jnz     short loc_46A5EF
.text:0046A5D4                 mov     ecx, large fs:18h
.text:0046A5DB                 xor     ebx, ebx
.text:0046A5DD
.text:0046A5DD loc_46A5DD:                             ; DATA XREF: _KiTrap0E+117o
.text:0046A5DD                 or      ebx, [ecx+0F70h]
.text:0046A5E3                 jz      short loc_46A5EF
.text:0046A5E5                 push    edx
.text:0046A5E6                 push    eax
.text:0046A5E7                 call    ds:_KeGdiFlushUserBatch
.text:0046A5ED                 pop     eax
.text:0046A5EE                 pop     edx
.text:0046A5EF
.text:0046A5EF loc_46A5EF:                             ; CODE XREF: _KiFastCallEntry+B2j
.text:0046A5EF                                         ; _KiFastCallEntry+C3j

我们跟踪代码发现，无论是KiFastCallEntry 还是 KisystenService ，最终都会调用一下这个代码。

kiSystenService：
进入0环后原来3环的寄存器保存在_KTrap_Frame的0x50~0x64
把3环的参数指针放到_KTRAP_FRAME.DbgArgPointer

以上过程是kiSystenService从0环进入3环的填表过程。

KiFastCallEntry的填表过程

.text:0046A520                 mov     ecx, 23h
.text:0046A525                 push    30h
.text:0046A527                 pop     fs       ;修改fs寄存器为30
.text:0046A529                 mov     ds, ecx
.text:0046A52B                 mov     es, ecx
.text:0046A52D                 mov     ecx, large fs:40h ;获取当前TSS
.text:0046A534                 mov     esp, [ecx+4] ;TSS中得到ESP
.text:0046A537                 push    23h		;原SS压栈
.text:0046A539                 push    edx		;原ESP压栈
.text:0046A53A                 pushf			;EFLAGS压栈

TSS = KPCR+40，ESP0=TSS+4（0表示0环）

push到 _KTrap_Frame

+0x078 HardwareSegSs : Uint4B

+0x074 HardwareEsp : Uint4B

+0x070 EFlags : Uint4B

完整的IDA分析代码如下：

.text:0046A520
.text:0046A520                 mov     ecx, 23h
.text:0046A525                 push    30h
.text:0046A527                 pop     fs		;修改fs寄存器为30
.text:0046A529                 mov     ds, ecx
.text:0046A52B                 mov     es, ecx
.text:0046A52D                 mov     ecx, large fs:40h  ;获取当前TSS
.text:0046A534                 mov     esp, [ecx+4]		  ;TSS中得到ESP
.text:0046A537                 push    23h				;原ss压栈
.text:0046A539                 push    edx				;原esp压栈
.text:0046A53A                 pushf				    ;EFLAGS压栈
.text:0046A53B
.text:0046A53B loc_46A53B:                             ; CODE XREF: _KiFastCallEntry2+23j
.text:0046A53B                 push    2
.text:0046A53D                 add     edx, 8	;当前保存着systener进入前的esp的值，esp+8=参数指针
.text:0046A540                 popf
.text:0046A541                 or      byte ptr [esp+1], 2 ;KtrapFrame->Eflags.if = 1
.text:0046A546                 push    1Bh  	; KtrapFrame->CS=0x1b 保存r3的cs
.text:0046A548                 push    dword ptr ds:0FFDF0304h  ; KtrapFrame->EIP =返回地址
.text:0046A54E                 push    0  ; KtrapFrame->Error = 0
.text:0046A550                 push    ebp	; KtrapFrame->ebp = ebp
.text:0046A551                 push    ebx	; KtrapFrame->ebx = ebx
.text:0046A552                 push    esi  ; KtrapFrame->esi = esi
.text:0046A553                 push    edi   ; KtrapFrame->edi = edi
.text:0046A554                 mov     ebx, large fs:1Ch
.text:0046A55B                 push    3Bh		; KtrapFrame->SegFs = 0x3b 保存r3的fs
.text:0046A55D                 mov     esi, [ebx+124h]  ; 得到当前线程结构
.text:0046A563                 push    dword ptr [ebx]    ; KtrapFrame->0x4c 保存原异常链
.text:0046A565                 mov     dword ptr [ebx], 0FFFFFFFFh  ; 设置为空的异常链
.text:0046A56B                 mov     ebp, [esi+18h]   ; 得到初始堆栈KtrapFrame->0x48
.text:0046A56E                 push    1   ; KtrapFrame->PreviousPreviousMode = 1
.text:0046A570                 sub     esp, 48h    ; 提升栈顶指针到_Ktrap_Frame
.text:0046A573                 sub     ebp, 29Ch	; Ktrap_Frame
.text:0046A579                 mov     byte ptr [esi+140h], 1   ; 先前模式
.text:0046A580                 cmp     ebp, esp
.text:0046A582                 jnz     short loc_46A511
.text:0046A584                 and     dword ptr [ebp+2Ch], 0   ; 清零dr7
.text:0046A588                 test    byte ptr [esi+2Ch], 0FFh  ; 检查是否处于调试状态
.text:0046A58C                 mov     [esi+134h], ebp
.text:0046A592                 jnz     Dr_FastCallDrSave
.text:0046A598
.text:0046A598 loc_46A598:                             ; CODE XREF: Dr_FastCallDrSave+10j
.text:0046A598                                         ; Dr_FastCallDrSave+7Cj
.text:0046A598                 mov     ebx, [ebp+60h]  ; ebp = KtrapFrame->ebp
.text:0046A59B                 mov     edi, [ebp+68h]   ; edi = KtrapFrame->eip
.text:0046A59E                 mov     [ebp+0Ch], edx   ; KtrapFrame->DbgArgPointer = 参数指针
.text:0046A5A1                 mov     dword ptr [ebp+8], 0BADB0D00h
.text:0046A5A8                 mov     [ebp+0], ebx    ; KtrapFrame->DbgEbp = ebx
.text:0046A5AB                 mov     [ebp+4], edi    ; KtrapFrame->DbgEip = edi
.text:0046A5AE                 sti

（四）API调用（系统服务表）

1、前言

API从Ring3到Ring0需要带两个寄存器：eax，edx。其中eax保存的是系统的服务号，edx保存的事Ring3的esp，我们可以通过esp找到三环的参数。

那我们该如何找到Ring0的参数呢？

本篇主要解决的是，如何通过eax找到Ring0的函数，Ring0的函数是如何被调用的，并且在这个过程中，Ring0的函数是如何使用Ring3的参数的？

2、系统服务表

在OS内核里，有一张系统服务表（SystemServiceTable），如下图：

在这里有4个成员分别为：

• ServiceTable 这个成员是个地址，通过这个地址可以找到一个函数地址表，从三环进0环的eax服务号就是函数地址表的索引。

• count当前的系统服务表被调用了多少次。

• ServiceLimit 保存的是函数地址表的大小，即服务函数的个数。

• ArgmentTable 函数参数表，里面保存的是函数地址表对应的参数个数。

• 总共有两份系统服务表，其中一份函数来自于Ntoskrl.exe 内核模块的导出函数，里面保存常用的系统服务；另一份来自Win32k.sys的导出函数，里面是与图形和用户界面相关的系统服务。它们向三环提供的内核函数全在这两张表里。

3、如何找到系统服务表

系统服务表位于_KTHREAD结构体0xE0的位置。

4、判断调用的函数在哪个表

• 要找到两张表取决于eax系统服务号，这个系统服务号总共有32位，但是真正只使用了13位。

• 系统服务号在使用的时候分为两部分，低12位表示的是函数地址表的索引，下标为12的位置的值，决定使用哪张表。

• 如果第12位为0，则找第一张表（图中的白色区域）；如果第12位为1，则找第二张表（图中的灰色区域）。

5、分析API函数的调用过程

通过以上的系统服务表分析，思考一下0环代码是如何通过服务号找到0环的函数的？0环的函数是如何使用在三环的参数的？

用IDA打开 ntkrnlpa.exe ,找到 KiFastCallEntry 、KiSystemService 函数，KiFastCallEntry 和 KiSystemService前面的代码都是用于保存现场，代码如下：

保存现场后，取出3环传进来的系统调用号：

.text:0046A5AF                 mov     edi, eax ;取出3环传进来的系统调用号

首先将3环传递过来的系统调用号保存到edi里：

.text:0046A5B1                 shr     edi, 8  ;系统调用号右移8位
.text:0046A5B4                 and     edi, 30h ;判断调用号的第12位是0还是1
.text:0046A5B7                 mov     ecx, edi	;ecx存储的值是00 或 0x10

然后将系统调用号右移8位，然后再和0x30做与运算。此时，edi的结果只能有两种，要么是0x0，要么是0x10。如果是0的话，就说明调用号下标为12的位置是0，如果edi的结果是0x10，那么调用号下标为12的位置是1。

.text:0046A5B9                 add     edi, [esi+0E0h] ;edi指向KTHREAD-->ServiceTable

esi指向的是ETHREAD线程结构体，ETHREAD+0xE位置存的就是ServiceTable。

当edi=0时，ServiceTable+edi 指向的就是第一张ServiceTable；

当edi=0x10时，ServiceTable+edi 指向的就是第二张ServiceTable。

.text:0046A5BF                 mov     ebx, eax ;把三环的系统服务号存到ebx备份
.text:0046A5C1                 and     eax, 0FFFh ;系统调用号，只保留后12位

接着把系统调用号备份到ebx，然后 &0FFFh，保留后12位。

.text:0046A5C6                 cmp     eax, [edi+8] 
.text:0046A5C9                 jnb     _KiBBTUnexpectedRange

[edi+8]存的是ServiceLimit（服务函数个数），如果传入的调用号的低12位>ServiceLimit，就jmp到_KiBBTUnexpectedRange。 这里是判断是否越界，即要找的函数地址有没有超过函数地址表的范围，如果没有越界就继续往下走。

.text:0046A5CF                 cmp     ecx, 10h ;判断是否是查第二张系统服务表
.text:0046A5D2                 jnz     short loc_46A5EF ;如果是查第一张系统服务表，则jmp

这里将ecx和0x10进行比较，ecx存储的是 0x00或0x10，如果ecx是0x10，就说明要查第二张系统服务表。

如果要查第一张服务表，就会jmp；如果查第一张表则继续往下执行。

.text:0046A5D4                 mov     ecx, large fs:18h
.text:0046A5DB                 xor     ebx, ebx
.text:0046A5DD
.text:0046A5DD loc_46A5DD:                             ; DATA XREF: _KiTrap0E+117o
.text:0046A5DD                 or      ebx, [ecx+0F70h]
.text:0046A5E3                 jz      short loc_46A5EF
.text:0046A5E5                 push    edx
.text:0046A5E6                 push    eax
.text:0046A5E7                 call    ds:_KeGdiFlushUserBatch
.text:0046A5ED                 pop     eax
.text:0046A5EE                 pop     edx

调用_KeGdiFlushUserBatch函数后，假设我们查找的是第一张系统服务表

.text:0046A5EF                                         ; _KiFastCallEntry+C3j
.text:0046A5EF                 inc     large dword ptr fs:638h ; _KPCRB->0x518 KeSystemCall增加1
.text:0046A5F6                 mov     esi, edx  ; edx存储的三环的参数指针

这里将edx保存到esi，edx存储的是三环的参数指针。

.text:0046A5F8                 mov     ebx, [edi+0Ch] ;ebx-->参数起始位置

edi->系统服务表的起始位置，[edi+0Ch]存的是ParamTableBase 参数表的基址 ，ebx-->参数起始位置。

.text:0046A5FD                 mov     cl, [eax+ebx] ;eax->函数地址表索引，ebx->参数表的起始位置 ，cl->参数的个数

参数表的基址+函数地址表的索引，再取得到的值就是要调用的函数的参数个数。

.text:0046A600                 mov     edi, [edi] ;edi->系统服务表，第一个成员是函数地址表

取出函数地址表，放到edi。

.text:0046A602                 mov     ebx, [edi+eax*4]  ;ebx->零环的函数地址

edi为函数地址表+eax索引*4，实现将0环的函数地址存到ebx。

.text:0046A605                 sub     esp, ecx ;提升堆栈高度到cl

为了能够存储3环的参数，提升堆栈到cl（参数个数）。

.text:0046A607                 shr     ecx, 2    ;参数总长度/4 = 参数的个数
.text:0046A60A                 mov     edi, esp	
.text:0046A60C                 cmp     esi, ds:_MmUserProbeAddress
.text:0046A612                 jnb     loc_46A7C0
.text:0046A618
.text:0046A618 loc_46A618:                             ; CODE XREF: _KiFastCallEntry+2A4j
.text:0046A618                                         ; DATA XREF: _KiTrap0E+10Do
.text:0046A618                 rep movsd	;开始拷贝参数
.text:0046A61A                 call    ebx

将ecx右移2位，即将ecx/4=参数的个数。我们知道rep的次数，取决于ecx，而movsd每次复制4个字节，所以需要将ecx/4。

.text:0046A60C                 cmp     esi, ds:_MmUserProbeAddress ;判断3环参数的地址范围是否越界
.text:0046A612                 jnb     loc_46A7C0 ;越界跳转到错误处理模块

_MmUserProbeAddress是一个全局变量，是用户程序能访问地址的最大范围。esi指向的是3环的函数指针，将esi与_MmUserProbeAddress比较，是为了判断3环参数的地址范围是否越界，如果越界则跳转到错误处理模块。

.text:0046A61A                 call    ebx ;调用函数

最后将3环的参数赋值到0环，开始真正的内核函数。

（五）API函数的调用过程（SSDT）

在前一章，我们逆向分析得出：KTHREAD +0xE0 -->系统服务表。实际上，Windows提供了一个到处的全局变量，通过这个变量，就可以直接访问系统服务表。

1、分析KeServiceDescriptorTable

• IDA打开ntkrnlpa.exe ，在export中搜索KeServiceDescriptorTable

• 在Windbg中查看这个变量

2

这就是所谓的SSDT了。

2、系统服务描述表，SSDT

SSDT（System Service Despcriptor Table，系统服务描述表），SSDT结构包含4个成员，这4个成员都是一个系统服务表的结构体。

接下来，在windbg里看一下每个成员：

3

用SSDT查看只有一张表，这个表就是Ntoskrl.exe![]
导出的，后面的3个成员都是空的。

3、SSDT Shadow

通过SSSDT就能同时看到Ntoskrl.exe与win32k.sys导出的表 。

4

typedef struct _KSYSTEM_SERVICE_TABLE
{
	PULONG ServiceTableBase;		//这个指向系统服务函数地址表
	PULONG ServiceCounterTableBase;	//系统这个服务表调用了几次
	ULONG NumberOfService;			//服务函数的个数
	PULONG ParamTableBase;			//参数表 

}KSYSTEM_SERVICE_TABLE, *PKSYSTEM_SERVICE_TABLE;

PSYSTEM_SERVICE_TABLE Ntoskr_ssdt;

//这4个参数就是对应第一个系统服务表导出的值
Ntoskr_ssdt->ServiceTableBase = 80505450;
Ntoskr_ssdt->ServiceCounterTableBase = 00000000;
Ntoskr_ssdt->NumberOfService = 0000011c;
Ntoskr_ssdt->ParamTableBase = 805058c4;

系统服务表基址+0xBA--->ReadVirtualMemory：

查看ReadVirtualMemory函数反汇编：

查看参数表

0x14的十进制是20，它当前所有的参数加起来有20个字节，每个参数4字节，所以它有5个参数。