柳州城市的城乡建设管理局网站wordpress源码站整站源码

2.6.ReactOS系统中从内核中发起系统调用

2.6.ReactOS系统中从内核中发起系统调用

---

前言

上面我们已经可以看到用户空间（R3）进行系统调用的全过程即两种方法的具体实现。

系统调用一般时从R3发起的。其实window也运行从内核进行系统调用，不过，一般而言在内核里面不能直接调用NtReadFile()一类函数。这方面是因为windows内核并不导出这些函数。另一方面也是应为这些函数往往要求在系统空间队长上有一个属于本次调用的自陷框架，从而内核中直接调用这些函数时显然没有这么一个口昂加，诚然。既然CPU已经运行在内核中，系统空间堆栈上就已经有这样的框架了。 那可能时自陷框架，中断框架或者异常框架。但都不是味本次调用而形成的。所以内核中一般不能直接调用NtReadFile()一类的函数。这就是为什么在内核中只能通过ZwReadFile()一类函数进行系统调用的原因。那么ZwReadFile()时什么样的函数呢？下面有ReactOS中的代码：

__declspec(naked)__stdcall 
ZwReadFile(int dummy0,int dummy1,int dummy2)
{
asm{mov eax,151lea edx,[esp+4] 		//使EDX指向堆栈的参数块pushf					//EFLAGS	push KGDT_R0_CODE 		//CScall _KiSystemService ret 36					//9个参数}
}

这里中间函数调用KiSystemService(),在哪里构建堆栈上的系统调用框架，这点上与通过“int 0x2e"进入内核相似，但是此时当然无需保证用户空间的CS,SS,ESP等寄存器的映射。这样这里的EDX指向堆栈上的参数块。

到这里系统调用返回时，在TRAP_EPILOG末尾处有这么几条指令。

.if _SystemCall 
/*Check if previous CS is from user-mode*/
test dword ptr[esp+4],1
;it's,so ues Fast Exit
jnz FastExit //来自用户空间（R3)//jump back to stub 		//来自系统空间（R0)
pop edx  						//KiSystemService()的返回地址
pop ecx 						//KGDT_R0_CODE
popf 
jmp edx						//挑战到调用KiSystemService时的返回地址

对于来自R0的系统调用，这里 有4条指令实现返回，队长上面中间函数ZwReadFile()的代码，读者不难理解这4条指令的左右红。

类似ZwReadFile()中间函数有两百多个。ReactOS提供了生成这些函数的工具。以系统调用NtReadFile()为例子，这个工具根据sysfuncs.lst生成其用户空间的（R3）的中间函数NtReadFile()和内核版本的中间函数ZwReadFile()的代码，内核版本的中间函数ZwReadFile()的生成"模板为"

#define KernelModeStub_x86  "    asm { \n" \"        mov eax, %xh\n" \"        lea edx, [esp+4]\n" \"        pushf\n" \"        push KGDT_R0_CODE\n" \"        call _KiSystemService\n" \"        ret %xh\n" \"    }\n"

这里需要填入的参数只有两个，一个时系统调用号，另一个时调用参数的数量，课件这些中间函数的生成时很简单的。 到处这些中间函数而颖仓实际的系统调用函数。就为可能为逆向工程设置了障碍。