《未文档化WIN2000揭秘》笔记1

 

        The windows 2000 Native API

WIN2000采用中断机制将对内核服务的请求从用户模式向内核模式传递。

 

NT平台暴露出一个隐藏的事实是：存在一个比Win32 API更为基础的调用接口Native API,即使一个普通的Win32应用程序也可以在任何时候调用Native API,并不需要到驱动程序一层才能访问此接口。没什么技术上的限制-----仅仅是微软不支持此种应用程序开发模式而已。

 

Win32子系统和Native API之间的关系可以由Win32核心模块与Windows 2000内核模块之间的依赖关系很好的解释。

 

 

Windows 2000内核API函数使用三种调用约定：__stdcall、__cdecl和__fastcall，它们处理参数的方式有很大的不同。__stdcall和__cdecl要求所有的参数都应传入到堆栈中，但是，__fastcall为了使搜索参数堆栈的开销最小化，会将前两个参数传入CPU寄存器ECX和EDX。从另一方面来看，__stdcall和__fastcall将参数从堆栈中移除的方式是一致的，这两种调用约定均强制被调用代码来完成这一工作。不过，对于__cdecl来说，这一工作将由调用者完成。尽管通过保存堆栈指针（在调用和将堆栈指针恢复到其原始位置之前，来完成堆栈指针的保存）可以很容易的解决清除堆栈的问题，但不论采用什么样的调用约定，驱动程序对于__fastcall约定都显得无能为力。因此，调用者必须针对每个调用来明确地指出其是否采用了__fastcall调用约定，这样驱动程序才能确定是否需要ECX和EDX寄存器（如果必须的话）。

 

在用户模式下调用内核API 函数

设计通向内核的门

运行于用户模式的程序想调用内核模式的函数，必须解决两个问题：

首先，必须以某种方式跳过用户态和内核态之间的障碍。

其次，它必须将数据传入和传出。

 

 

对于由 Native API 组成的子集， ntdll.dll 组件替我们完成了这一任务，它使用一个中断门来实现模式的切换，并使用 CPU 寄存器来传入指向调用者参数堆栈的指针，函数的运行结果也是通过 CPU 寄存器返回给调用者的。

 

对于非Native API的内核函数，操作系统没有提供这种门机制。因此，我们必须自己来实现一个这样的门。 

 

 

整个问题可浓缩为如下几个简单的顺序步骤：

1. 用户模式的应用程序提交一个 IOCTL 请求，并传入调用该函数所需的信息，如，指向函数参数堆栈的指针。

2. 内核模式的驱动程序处理这一请求，并将参数复制到自己的堆栈中，然后调用制定函数，最后通过 IOCTL 的输出缓冲区将函数的执行结果返回给调用者。

3. 调用者取出 IOCTL 操作的结果，并像对普通的 DLL 函数调用一样进行处理。