|
|
|---|---|
|
|
|
|
|
|
|
|
|
|
|
@czcqq， 感谢你的回答， 这个虚拟层 是内核的吗， 反编译调试一个32位程序时， 好像没发现这个， 调用api时 直接走了 fastsyscall了，是转到内核时由虚拟层接手的吗。 |
|
|
并不是全是内核，是内核有一部分，还有应用的RING3有一大部分，RING3负责转换，而驱动部分负责返回RING3的X86函数需要的格式！这个虚拟层是内核和ring3的应用配合而成的！大概是这样的，32位程序->NTDLL.DLL(32位)->虚拟层->NTDLL.DLL(64位)->SystemCall\SystemEntry指令进入内核->Nt\Zw系列函数->系统处理->判断是64位程序还是32位程序，如果是64位程序，则直接处理，完成之后返回。如果是32位程序，就将参数转换为64位的参数，然后处理，处理完成之后再次将参数转换为32位参数。->Nt\Zw系列函数返回->SystemRet/SystemLeave指令->NTDLL.DLL(64位)->虚拟层->NTDLL.DLL(32位)->32位程序 这样，一个处理流程就完成了，可以看出，虚拟层分为应用和驱动两个部分的，这个虚拟层需要两个部分配合才能运行的! |
|
|
驱动负责的转换需要有返回的类型的参数的指针，以便应用程序能正确接收到参数 |
|
|
而如果是驱动调用系统服务函数的话，系统通过以下代码直接跳过了检查： PreviousMode = KeGetPreviousMode(); if (PreviousMode != KernelMode) { 。。。。。这是来自应用的调用，需要区分是64位还是32位进行处理 } 。。。。。这是处理完毕符合64位程序调用，或者是来自驱动的调用，看代码就知道如果64位系统允许加载32位驱动的话，程序就会运行到这里，没有经过转换直接运行到这里，就会有蓝屏的危险 也就是不管是什么程序调用，直接调用，如果程序位数不是同一个的话，你想会有什么后果。 |
|
|
结合代码给你看看虚拟层在哪就是了！这个是64位系统下32位程序调用ZwOpenProcess的情况   |
|
|
这个是64位系统下64位程序调用ZwOpenProcess的情况
这和
64位系统下32位程序调用ZwOpenProcess的情况，有个明显的区别，就是32位下，先进入了虚拟层，而64位下直接SysCall了  |
|
|
感谢解答 
|
|
|
|
|
|
|
|
|
|
|
|
请问您这个函数调用路径是怎么看到的，谢谢！ |
|
|
|
