系统调用篇——0环层面调用过程(下)

2021年11月22日 阅读数:3
这篇文章主要向大家介绍系统调用篇——0环层面调用过程(下),主要内容包括基础应用、实用技巧、原理机制等方面,希望对大家有所帮助。

写在前面

  此系列是本人一个字一个字码出来的,包括示例和实验截图。因为系统内核的复杂性,故可能有错误或者不全面的地方,若有错误,欢迎批评指正,本教程将会长期更新。 若有好的建议,欢迎反馈。码字不易,若是本篇文章有帮助你的,若有闲钱,能够打赏支持个人创做。如想转载,请把个人转载信息附在文章后面,并声明个人我的信息和本人博客地址便可,但必须事先通知我html

你若是是从中间插过来看的,请仔细阅读 羽夏看Win系统内核——简述 ,方便学习本教程。windows

  看此教程以前,问一个问题,你明确学系统调用的目的了吗? 没有的话就不要继续了,请从新学习 羽夏看Win系统内核——系统调用篇 里面的内容。api


🔒 华丽的分割线 🔒数组


分析 KiSystemService

  这个函数全部的分析以下,若是本身单独分析完毕后能够查看下面的折叠:app

🔒 点击查看分析 🔒
_KiSystemService proc near              ; CODE XREF: ZwAcceptConnectPort(x,x,x,x,x,x)+C↑p
                                        ; ZwAccessCheck(x,x,x,x,x,x,x,x)+C↑p ...

arg_0           = dword ptr  4

                push    0               ; errorcode
                push    ebp
                push    ebx
                push    esi
                push    edi
                push    fs
                mov     ebx, 30h ; '0'  ; 以上代码填充 Trap_Frame 结构体数据
                mov     fs, bx          ; 加载0环的fs,指向KPCR,基址:0FFDFF000h
                assume fs:nothing
                push    dword ptr ds:0FFDFF000h ; 压入 ExceptionList,是KPCR的第一个成员的TIB的第一个成员
                mov     dword ptr ds:0FFDFF000h, 0FFFFFFFFh ; 将 ExceptionList 置为 -1(EXCEPTION_CHAIN_END)
                mov     esi, ds:0FFDFF124h ; KPCR + 0x124:CurrentThread
                push    dword ptr [esi+140h] ; ETHREAD + 0x140:PreviousMode
                sub     esp, 48h        ; 提栈,目前指向 DbgEbp 的位置
                mov     ebx, [esp+68h+arg_0] ; ebx = SegCs
                and     ebx, 1          ; 判断调用者是否是 0环 权限
                mov     [esi+140h], bl  ; 将计算结果赋给 PreciousMode
                mov     ebp, esp        ; ebp = esp,目前指向 TrapFrame 的首地址
                mov     ebx, [esi+134h] ; 将 CurrentThread 的 TrapFrame 赋给 ebx
                mov     [ebp+3Ch], ebx  ; TrapFrame 的 Edx = ebx 存的 TrapFrame
                mov     [esi+134h], ebp ; 将 CurrentThread 的 TrapFrame 替换为新构建的 TrapFrame
                cld
                mov     ebx, [ebp+60h]  ; 3环的 ebp
                mov     edi, [ebp+68h]  ; 3环的 EIP
                mov     [ebp+0Ch], edx  ; 将 3环 的参数列表存入到 DbgArgPointer
                                        ; 这个参数是在调用 int 2Eh 前传入的
                mov     dword ptr [ebp+8], 0BADB0D00h ; DbgArgMark 赋值,细节未知
                mov     [ebp+0], ebx    ; DbgEbp = ebx 的值,即3环的ebp
                mov     [ebp+4], edi    ; DbgEip = edi 的值,即3环的eip
                test    byte ptr [esi+2Ch], 0FFh ; 判断 DebugActive 是否有值
                jnz     Dr_kss_a        ; 若是是0,则说明未被调试,不跳

KiSystemServiceCallEnd:                 ; CODE XREF: Dr_kss_a+10↑j
                                        ; Dr_kss_a+7C↑j
                sti                     ; 启用中断
                jmp     APIService      ; 跳到这个地址(这个名字是我本身起的)
_KiSystemService endp

  若是你发现本身分析的和个人差很少,恭喜你,你基本掌握了这个函数的处理流程,本小节的下面分析的你就能够跳过了,下面开始对开头部分的代码进行分析,毕竟比较难理解的就在这里:less

push    0               ; errorcode
push    ebp
push    ebx
push    esi
push    edi
push    fs
mov     ebx, 30h ; '0'  ; 以上代码填充 Trap_Frame 结构体数据
mov     fs, bx          ; 加载0环的fs,指向KPCR,基址:0FFDFF000h
assume fs:nothing
push    dword ptr ds:0FFDFF000h ; 压入 ExceptionList,是KPCR的第一个成员的TIB的第一个成员

  讲解前问一个问题:上来第一个push,压栈到哪里去了?到0环的堆栈去了。由于自从int 2Eh咱们就进去了0环,堆栈也被换掉了。既然是Windows写的代码,咱们以前讲过它在0环会维护一个结构体,名为栈帧。那么在这里就是在维护这个结构体。为了方便讲解咱们把这个结构体搬来了:ide

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 PreviousMode : Uint4B
   +0x04c ExceptionList    : Ptr32 _EXCEPTION_REGISTRATION_RECORD
   +0x050 SegFs            : Uint4B
   +0x054 Edi              : Uint4B
   +0x058 Esi              : Uint4B
   +0x05c Ebx              : Uint4B
   +0x060 Ebp              : Uint4B
   +0x064 ErrCode          : Uint4B
   +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环堆栈,所谓的esp0就会指向咱们Trap_Frame结构体偏移+0x07c的位置,即指向V86Es的位置,而后根据CPU的使用中断门的约定,依次压入3环的ssespeflagcseip,是否是和结构体里面的定义如出一辙?
  你可能问道ErrCode是什么鬼东西?我在上一篇教程提了一嘴:ErrCode有时由操做系统压入,有时由CPU压入。咱们先看一张你熟悉的一张图:函数

  这张图在保护模式篇的总结与提高部分讲解过。看没看到Error Code这一列?若是为Yes,发生中断的时候,CPU就会再把这个值压入堆栈当中。Windows系统设计时为了保持对齐,这里的push 0就是这么来的。
  其余的部分就不难了,本身看折叠的分析就能看懂了,自行分析便可。学习

分析 KiFastCallEntry

  如今的CPU都支持sysenter/sysexit指令,KiFastCallEntry这个函数分析必不可少,这个函数全部的分析以下,若是本身单独分析完毕后能够查看下面的折叠:ui

🔒 点击查看分析 🔒
_KiFastCallEntry proc near              ; DATA XREF: KiLoadFastSyscallMachineSpecificRegisters(x)+24↑o
                                        ; _KiTrap01+72↓o

var_B           = byte ptr -0Bh
anonymous_0     = dword ptr -8
anonymous_1     = dword ptr -4

; FUNCTION CHUNK AT .text:00466519 SIZE 00000025 BYTES
; FUNCTION CHUNK AT .text:004667DC SIZE 00000014 BYTES

                mov     ecx, 23h ; '#'
                push    30h ; '0'
                pop     fs              ; 这两行代码是加载 fs 为0环的
                mov     ds, ecx
                mov     es, ecx         ; 加载 ds 和 es
                mov     ecx, ds:0FFDFF040h ; 取出 KPCR 的 TSS
                mov     esp, [ecx+4]    ; 取出 TSS 的 ESP0,并赋给 esp
                push    23h ; '#'       ; 开始填充 TrapFrame 数据
                push    edx
                pushf

loc_46655A:                             ; CODE XREF: _KiFastCallEntry2+22↑j
                push    2
                add     edx, 8          ; edx 就是 3环 传来的参数列表地址,加个8
                popf                    ; eflag = 2,即清空Eflag
                or      [esp+0Ch+var_B], 2 ; 设置存入的EFLAG的第二个位
                push    1Bh             ; SegCs
                push    dword ptr ds:0FFDF0304h ; SystemCallReturn
                push    0               ; errorcode
                push    ebp
                push    ebx
                push    esi
                push    edi
                mov     ebx, ds:0FFDFF01Ch ; ebx = KPCR
                push    3Bh ; ';'       ; SegFs
                mov     esi, [ebx+124h] ; esi = KPCR.CurrentThread
                push    dword ptr [ebx] ; ExceptionList
                mov     dword ptr [ebx], 0FFFFFFFFh ; 将 ExceptionList 置 -1(EXCEPTION_CHAIN_END)
                mov     ebp, [esi+18h]  ; InitialStack,指向 TrapFrame 基址
                push    1               ; PreviousMode
                sub     esp, 48h        ; 提栈,此时 esp 指向 TrapFrame 的结构体首地址
                sub     ebp, 29Ch       ; 0x29C = NPX_FRAME_LENGTH + KTRAP_FRAME_LENGTH
                                        ; = sizeof(_FX_SAVE_AREA) + sizeof(_Trap_Frame)
                                        ; = 0x210 + 0x8c
                mov     byte ptr [esi+140h], 1 ; ApcNeeded
                cmp     ebp, esp
                jnz     short loc_46653C ; 若是不相等说明这个是 VX86 线程,拒绝访问,跳走
                and     dword ptr [ebp+2Ch], 0 ; Dr7
                test    byte ptr [esi+2Ch], 0FFh ; DebugActive
                mov     [esi+134h], ebp ; 替换 TrapFrame
                jnz     Dr_FastCallDrSave

loc_4665B6:                             ; CODE XREF: Dr_FastCallDrSave+10↑j
                                        ; Dr_FastCallDrSave+7C↑j
                mov     ebx, [ebp+60h]  ; ebx = TrapFrame.Ebp
                mov     edi, [ebp+68h]  ; edi = TrapFrame.Eip
                mov     [ebp+0Ch], edx  ; DbgArgPointer = 3环传来的参数列表
                mov     dword ptr [ebp+8], 0BADB0D00h ; DbgArgMark
                mov     [ebp+0], ebx    ; DbgEbp
                mov     [ebp+4], edi    ; DbgEip
                sti                     ; 启用中断

APIService:                             ; CODE XREF: _KiBBTUnexpectedRange+18↑j
                                        ; _KiSystemService+6F↑j

  一样,接下来我对比较难理解难分析的部分逐个讲述,简单的部分自行分析:

push    dword ptr [ebx] ; ExceptionList
mov     dword ptr [ebx], 0FFFFFFFFh ; 将 ExceptionList 置 -1(EXCEPTION_CHAIN_END)
mov     ebp, [esi+18h]  ; InitialStack,指向 TrapFrame 基址
push    1               ; PreviousMode
sub     esp, 48h        ; 提栈,此时 esp 指向 TrapFrame 的结构体首地址
sub     ebp, 29Ch       ; 0x29C = NPX_FRAME_LENGTH + KTRAP_FRAME_LENGTH
                        ; = sizeof(_FX_SAVE_AREA) + sizeof(_Trap_Frame)
                        ; = 0x210 + 0x8c
mov     byte ptr [esi+140h], 1
cmp     ebp, esp
jnz     short loc_46653C ; 若是不相等说明这个是 VX86 线程,拒绝访问,跳走

  既然有了分析KiSystemService的基础,前面的应该就不太难了,一样是填充结构体,只是多作中断门作了,而sysenter没作的事情,也就上面的部分难以理解。我也没讲过,百度也没了做用。然而为什么不看看WRK呢?通过函数定位,咱们定位到了这几句:

;
; Save the old exception list in trap frame and initialize a new empty
; exception list.
;

        push    [ebx].PcExceptionList       ; save old exception list
        mov     [ebx].PcExceptionList, EXCEPTION_CHAIN_END ; set new empty list
        mov     ebp, [esi].ThInitialStack

;
; Save the old previous mode in trap frame, allocate remainder of trap frame,
; and set the new previous mode.
;
        push    MODE_MASK                  ; Save previous mode as user
        sub     esp,TsPreviousPreviousMode ; allocate remainder of trap frame
        sub     ebp, NPX_FRAME_LENGTH + KTRAP_FRAME_LENGTH
        mov     byte ptr [esi].ThPreviousMode,MODE_MASK ; set new previous mode of user
;
; Now the full trap frame is build.
; Calculate initial stack pointer from thread initial stack to contain NPX and trap.
; If this isn't the same as esp then we are a VX86 thread and we are rejected
;

        cmp     ebp, esp
        jne     short Kfsc91

  里面有几个伪指令定义,咱们把它给找出来:

EXCEPTION_CHAIN_END equ 0FFFFFFFFH
TsPreviousPreviousMode equ 00048H
NPX_FRAME_LENGTH equ 00210H
KTRAP_FRAME_LENGTH equ 0008CH
MODE_MASK equ 00001H

  经过上面的注释,咱们明白了ExceptionList赋值为-1的含义,还有下面的代码是怎么来的:

sub     esp, 48h        ; 提栈,此时 esp 指向 TrapFrame 的结构体首地址
sub     ebp, 29Ch       ; 0x29C = NPX_FRAME_LENGTH + KTRAP_FRAME_LENGTH
                        ; = sizeof(_FX_SAVE_AREA) + sizeof(_Trap_Frame)
                        ; = 0x210 + 0x8c
mov     byte ptr [esi+140h], 1
cmp     ebp, esp
jnz     short loc_46653C ; 若是不相等说明这个是 VX86 线程,拒绝访问,跳走

  但我仍是不明白NPX_FRAME_LENGTH是啥,NPX究竟是啥,搜啊。在WRK搜一下有没有,尝试失败:

  放心,这个是百度搜不到的。经过谷歌搜索找到了一个线索,来源于 此连接 ,我把这位同志画的整理一下,以下所示:

  经过它画的内核线程堆栈图可知,所谓的NPX不过是一个FX_SAVE_AREA结构体,咱们在WRK搜一下,结果搜到了,整理一下:

// Union for FLOATING_SAVE_AREA and MMX_FLOATING_SAVE_AREA
typedef struct _FX_SAVE_AREA {
    union {
        FNSAVE_FORMAT   FnArea;
        FXSAVE_FORMAT   FxArea;
    } U;
    ULONG   NpxSavedCpu;        // Cpu that last did fxsave for this thread
    ULONG   Cr0NpxState;        // Has to be the last field because of the
                                // Boot thread
} FX_SAVE_AREA, *PFX_SAVE_AREA;

//  Define the size of the 80387 save area, which is in the context frame.
#define SIZE_OF_80387_REGISTERS      80

// Format of data for fnsave/frstor instruction
typedef struct _FNSAVE_FORMAT {
    ULONG   ControlWord;
    ULONG   StatusWord;
    ULONG   TagWord;
    ULONG   ErrorOffset;
    ULONG   ErrorSelector;
    ULONG   DataOffset;
    ULONG   DataSelector;
    UCHAR   RegisterArea[SIZE_OF_80387_REGISTERS];
} FNSAVE_FORMAT, *PFNSAVE_FORMAT;

  这个结构体根据注释来看和浮点运算有关,这个不在咱们研究的范围,仅做了解。而后计算一下,果真大小和咱们上面的NPX_FRAME_LENGTH的值是如出一辙的,这个问题也就迎刃而解了。
  下面的部分是本篇文章将要介绍的部分:系统服务表。

SystemServiceTable

  以前咱们讲到进0环后,3环的各类寄存器的值都会保留到_Trap_Frame结构体中,接下来我将会讲解:如何根据系统服务号(eax中存储)找到要执行的内核函数?调用时参数是存储到3环的堆栈,如何传递给内核函数?

结构

  首先咱们得知道一个结构体,用来描述内核函数信息的表:SystemServiceTable,即系统服务表,它不是SSDT,至于SSDT的详细内容将会在下一篇讲解。如今咱们看一看它的结构:

  能够看出这个表由4部分组成,ServiceTable指向的是函数地址数组,每一个成员四个字节;Count表示调用次数,没啥意义;ServiceLimit表示这张表有几个函数;ArgumentTable指向对应函数有几个参数,每一个成员一个字节。
  从图中能够看出,Windows提供了两张表:上面的表是用来处理通常内核函数的,下面这张表是用来处理与GUI相关的内核函数。

位置

  既然知道了表的结构,咱们得知道它在哪里,不然怎么调用它?它在EThread结构体里面,我再把前面放的拿来:

   kd> dt _KTHREAD
nt!_KTHREAD
   +0x000 Header           : _DISPATCHER_HEADER
   +0x010 MutantListHead   : _LIST_ENTRY
   +0x018 InitialStack     : Ptr32 Void
   +0x01c StackLimit       : Ptr32 Void
   +0x020 Teb              : Ptr32 Void
   +0x024 TlsArray         : Ptr32 Void
   +0x028 KernelStack      : Ptr32 Void
   +0x02c DebugActive      : UChar
   +0x02d State            : UChar
   +0x02e Alerted          : [2] UChar
   +0x030 Iopl             : UChar
   +0x031 NpxState         : UChar
   +0x032 Saturation       : Char
   +0x033 Priority         : Char
   +0x034 ApcState         : _KAPC_STATE
   +0x04c ContextSwitches  : Uint4B
   +0x050 IdleSwapBlock    : UChar
   +0x051 Spare0           : [3] UChar
   +0x054 WaitStatus       : Int4B
   +0x058 WaitIrql         : UChar
   +0x059 WaitMode         : Char
   +0x05a WaitNext         : UChar
   +0x05b WaitReason       : UChar
   +0x05c WaitBlockList    : Ptr32 _KWAIT_BLOCK
   +0x060 WaitListEntry    : _LIST_ENTRY
   +0x060 SwapListEntry    : _SINGLE_LIST_ENTRY
   +0x068 WaitTime         : Uint4B
   +0x06c BasePriority     : Char
   +0x06d DecrementCount   : UChar
   +0x06e PriorityDecrement : Char
   +0x06f Quantum          : Char
   +0x070 WaitBlock        : [4] _KWAIT_BLOCK
   +0x0d0 LegoData         : Ptr32 Void
   +0x0d4 KernelApcDisable : Uint4B
   +0x0d8 UserAffinity     : Uint4B
   +0x0dc SystemAffinityActive : UChar
   +0x0dd PowerState       : UChar
   +0x0de NpxIrql          : UChar
   +0x0df InitialNode      : UChar
   +0x0e0 ServiceTable     : Ptr32 Void
   +0x0e4 Queue            : Ptr32 _KQUEUE
   +0x0e8 ApcQueueLock     : Uint4B
   +0x0f0 Timer            : _KTIMER
   +0x118 QueueListEntry   : _LIST_ENTRY
   +0x120 SoftAffinity     : Uint4B
   +0x124 Affinity         : Uint4B
   +0x128 Preempted        : UChar
   +0x129 ProcessReadyQueue : UChar
   +0x12a KernelStackResident : UChar
   +0x12b NextProcessor    : UChar
   +0x12c CallbackStack    : Ptr32 Void
   +0x130 Win32Thread      : Ptr32 Void
   +0x134 TrapFrame        : Ptr32 _KTRAP_FRAME
   +0x138 ApcStatePointer  : [2] Ptr32 _KAPC_STATE
   +0x140 PreviousMode     : Char
   +0x141 EnableStackSwap  : UChar
   +0x142 LargeStack       : UChar
   +0x143 ResourceIndex    : UChar
   +0x144 KernelTime       : Uint4B
   +0x148 UserTime         : Uint4B
   +0x14c SavedApcState    : _KAPC_STATE
   +0x164 Alertable        : UChar
   +0x165 ApcStateIndex    : UChar
   +0x166 ApcQueueable     : UChar
   +0x167 AutoAlignment    : UChar
   +0x168 StackBase        : Ptr32 Void
   +0x16c SuspendApc       : _KAPC
   +0x19c SuspendSemaphore : _KSEMAPHORE
   +0x1b0 ThreadListEntry  : _LIST_ENTRY
   +0x1b8 FreezeCount      : Char
   +0x1b9 SuspendCount     : Char
   +0x1ba IdealProcessor   : UChar
   +0x1bb DisableBoost     : UChar

  因为EThread结构体挺大的,而咱们的服务表在它的第一个成员里面,我就只放这个结构体。明显它在+0x0e0偏移位置。

如何调用

  拿到了服务号,如何找到真正的函数呢?咱们先看一张示意图:

  咱们根据服务表的索引12这个位能够判断是哪张服务表,既然找到了哪张服务表,后12位就是在服务表的索引。经过这个索引,找到函数地址,有几个参数,咱们就能够调用它了,接下来咱们开始分析调用真正函数地址的细节。

分析 APIService

  APIService是我本身起的名字,你应该是默认的名字,本身随便起。APIService这个地址颇有意思,不管是经过中断门进行系统调用,仍是sysenter,最终都会走这里。好,咱们下来能够继续分析,你能够以再也不阅读,停下来自行分析,分析不动了再回来看看:

APIService:                             ; CODE XREF: _KiBBTUnexpectedRange+18↑j
                                        ; _KiSystemService+6F↑j
                mov     edi, eax        ; eax = 3环传来的服务号
                shr     edi, 8
                and     edi, 30h
                mov     ecx, edi        ; 正好一个表的大小就是0x10,若是是GUI相关,就加;反之不加。
                add     edi, [esi+0E0h] ; edi = ServiceTable
                mov     ebx, eax        ; eax = 3环传来的服务号
                and     eax, 0FFFh      ; 去掉索引为12的位
                cmp     eax, [edi+8]    ; 获得的结果与ServiceLimit比较
                jnb     _KiBBTUnexpectedRange ; 若是超出,说明越界,跳走
                cmp     ecx, 10h
                jnz     short loc_46660C ; 判断是不是调用 win32k.sys 的,不是的话跳走
                mov     ecx, ds:0FFDFF018h ; _DWORD
                xor     ebx, ebx

loc_4665FA:                             ; DATA XREF: _KiTrap0E+113↓o
                or      ebx, [ecx+0F70h]
                jz      short loc_46660C
                push    edx
                push    eax
                call    ds:_KeGdiFlushUserBatch
                pop     eax
                pop     edx

loc_46660C:                             ; CODE XREF: _KiFastCallEntry+B0↑j
                                        ; _KiFastCallEntry+C0↑j
                inc     dword ptr ds:0FFDFF638h ; KeSystemCalls 自增 1
                mov     esi, edx        ; 3环来的参数列表
                mov     ebx, [edi+0Ch]  ; SSDT参数表地址
                xor     ecx, ecx
                mov     cl, [eax+ebx]   ; 得到调用指定函数的参数表的参数长度
                mov     edi, [edi]      ; 函数地址表
                mov     ebx, [edi+eax*4] ; 获取调用的指定函数的地址
                sub     esp, ecx        ; 提栈,供给参数拷贝空间
                shr     ecx, 2          ; number of argument DWORDs
                mov     edi, esp        ; 设置拷贝地址
                cmp     esi, ds:_MmUserProbeAddress ; 判断拷贝的源地址是否超出用户态能读取的宽度
                jnb     loc_4667DC      ; 若是超出,跳走,报错

loc_466634:                             ; CODE XREF: _KiFastCallEntry+2A0↓j
                                        ; DATA XREF: _KiTrap0E+109↓o
                rep movsd               ; 从3环拷贝参数到0环
                call    ebx             ; 真正调用函数

loc_466638:                             ; CODE XREF: _KiFastCallEntry+2AB↓j
                                        ; DATA XREF: _KiTrap0E+129↓o ...
                mov     esp, ebp

loc_46663A:                             ; CODE XREF: _KiBBTUnexpectedRange+38↑j
                                        ; _KiBBTUnexpectedRange+43↑j
                mov     ecx, ds:0FFDFF124h
                mov     edx, [ebp+3Ch]
                mov     [ecx+134h], edx
_KiFastCallEntry endp

  此次分析应该没啥难度了。能够看出若是经过服务号发现是与GUI相关的函数,它会调用一个函数。若是找到正确的函数地址和参数,它会提栈把3环的数据拷贝过来,而后正式调用。咱们来看看WRK是怎么写的:

; (eax) = Service number
; (edx) = Callers stack pointer
; (esi) = Current thread address
;
; All other registers have been saved and are free.
;
; Check if the service number within valid range
;

_KiSystemServiceRepeat:
        mov     edi, eax                ; copy system service number
        shr     edi, SERVICE_TABLE_SHIFT ; isolate service table number
        and     edi, SERVICE_TABLE_MASK ;
        mov     ecx, edi                ; save service table number
        add     edi, [esi]+ThServiceTable ; compute service descriptor address
        mov     ebx, eax                ; save system service number
        and     eax, SERVICE_NUMBER_MASK ; isolate service table offset

;
; If the specified system service number is not within range, then attempt
; to convert the thread to a GUI thread and retry the service dispatch.
;

        cmp     eax, [edi]+SdLimit      ; check if valid service
        jae     Kss_ErrorHandler        ; if ae, try to convert to GUI thread

;
; If the service is a GUI service and the GDI user batch queue is not empty,
; then call the appropriate service to flush the user batch.
;

        cmp     ecx, SERVICE_TABLE_TEST ; test if GUI service
        jne     short Kss40             ; if ne, not GUI service
        mov     ecx, PCR[PcTeb]         ; get current thread TEB address
        xor     ebx, ebx                ; get number of batched GDI calls

KiSystemServiceAccessTeb:
        or      ebx, [ecx]+TbGdiBatchCount ; may cause an inpage exception

        jz      short Kss40             ; if z, no batched calls
        push    edx                     ; save address of user arguments
        push    eax                     ; save service number
        call    [_KeGdiFlushUserBatch]  ; flush GDI user batch
        pop     eax                     ; restore service number
        pop     edx                     ; restore address of user arguments

;
; The arguments are passed on the stack. Therefore they always need to get
; copied since additional space has been allocated on the stack for the
; machine state frame.  Note that we don't check for the zero argument case -
; copy is always done regardless of the number of arguments because the
; zero argument case is very rare.
;

Kss40:  inc     dword ptr PCR[PcPrcbData+PbSystemCalls] ; system calls

FPOFRAME ?FpoValue, 0

        mov     esi, edx                ; (esi)->User arguments
        mov     ebx, [edi]+SdNumber     ; get argument table address
        xor     ecx, ecx
        mov     cl, byte ptr [ebx+eax]  ; (ecx) = argument size
        mov     edi, [edi]+SdBase       ; get service table address
        mov     ebx, [edi+eax*4]        ; (ebx)-> service routine
        sub     esp, ecx                ; allocate space for arguments
        shr     ecx, 2                  ; (ecx) = number of argument DWORDs
        mov     edi, esp                ; (edi)->location to receive 1st arg
        cmp     esi, _MmUserProbeAddress ; check if user address
        jae     kss80                   ; if ae, then not user address

KiSystemServiceCopyArguments:
        rep     movsd                   ; copy the arguments to top of stack.
                                        ; Since we usually copy more than 3
                                        ; arguments.  rep movsd is faster than
                                        ; mov instructions.

;
; Make actual call to system service
;

kssdoit:
        call    ebx                     ; call system service

kss61:

;
; Upon return, (eax)= status code. This code may also be entered from a failed
; KiCallbackReturn call.
;

        mov     esp, ebp                ; deallocate stack space for arguments

;
; Restore old trap frame address from the current trap frame.
;

kss70:  mov     ecx, PCR[PcPrcbData+PbCurrentThread] ; get current thread address
        mov     edx, [ebp].TsEdx        ; restore previous trap frame address
        mov     [ecx].ThTrapFrame, edx  ;

回到3环

  分析到如今,函数其实没有结束完,它还得经过KiServiceExit退到3环,完成系统调用。可是不幸的是,这得须要APC的知识,可能至关的一段时间才能讲解到。学会APC后,咱们将从新分析该部份内容,下面是WRK的有关该函数的注释说明:

;
;   System service's private version of KiExceptionExit
;   (Also used by KiDebugService)
;
;   Check for pending APC interrupts, if found, dispatch to them
;   (saving eax in frame first).
;

下一篇

  系统调用篇——SSDT