恶意软件为了达到保护自己、监视用户行为等目的，会使用Api Hook技术修改系统Api
并重定向到自己的函数中。如何拦截恶意软件修改系统 Api 的行为，是开发一个安全软件时
所需要考虑的问题。
   由于 Api Hook可以直接修改系统函数头部，所以目前常用的方法仍然是“事后检测”，
即定时检查特定的函数是否被修改，并还原之。虽然这种方法某些情况下能解决问题，但它
依然存在许多缺陷。首先，系统Api 的数量非常多，恶意软件所挂钩的可能是其中的任何一
个，如果要定时检查所有的api的话，不仅复杂度过高，其所耗费的时间也是用户难以接受
的。此外，由于在被检查到之前，api 钩子依然生效，恶意软件亦可以通过反复挂钩特定的
函数来绕过这种拦截方式。
   本文所介绍的方法，不是定时检查指定的函数，而是利用系统的“写时复制”机制，挂
钩缺页异常中断，主动拦截修改指定范围内内存的行为。这种方法，无论地址范围多大，所
需要保护的Api有多复杂，都不会有更多的时间开销。此外，由于这种方法属于“主动拦截”，
能在恶意软件完成挂钩Api的操作之前及时阻止，因而反复挂钩特定函数的方法也不再能够
起作用。
   读者可能在实践中发现过如下问题：修改某一个进程中的某个公共的dll （如 kernel32）
中的函数时，无法作用到另一个进程。然而，操作系统为了节省内存，没有理由在每个进程
中保留一个完全独立的 dll 副本（如果这个 dll 被多个进程同时加载的话）。那么，操作系
统又是怎么做到修改一个进程中的某个dll 中的函数时，不会影响到其它进程呢？这就不得
不提到 windows 系统的“写时复制”机制。通常，系统中不同进程的公用dll，都会尽量映
射到相同的物理内存之上，然而当出现上文所述的情况时，系统会拦截到这个写入的行为，
并且单独为这个进程创建一个物理页面，以保证不会影响到其它的进程。通过这种方式，系
统得以共享多个进程中的相同dll 中的数据，并且保证在单一进程中dll 的数据被修改时，
不会影响到其它的进程。
   那么，系统的“写时复制”机制，又和缺页异常中断有什么关系呢？如上文所述，系统
需要拦截写入公用dll 中的共享数据的行为。Windows操作系统通过将 dll中共享数据的部
分设置为不可写，从而在写入这部分数据时，产生一个缺页异常，并在处理异常的过程中进
行“写时复制”的处理。因此，通过挂钩缺页异常中断，就可以在第一次写入共享dll中的
数据前，进行拦截。
我们知道，在 x86 上，当缺页异常发生时，cpu 会将控制权转移到 IDT(Interrupt
descriptor table)中的第 0xe项所指定的处理函数。IDT每项的结构如下所示。 

#pragma pack(1) //按字节对齐
   typedef struct
   {
   USHORT LowOffset;  //处理函数的低16 位地址          
   USHORT selector;
   UCHAR unused_lo;
   unsigned char unused_hi:5;      
   unsigned char DPL:2;
   unsigned char P:1;          
   USHORT HiOffset;           //处理函数的高16 位地址
   } IDTENTRY;
#pragma pack()

通过修改 IDT 中所记录的处理函数地址，我们可以达到挂钩缺页异常中断的目的。
   由于大部分操作都需要在 ring0下完成，本文中，使用驱动来实现。
首先，我们需要获取 idt 所在的地址，下面的函数把获取到的地址保存在全局变量
idtentries中。

void int_get_idt()
{
  /*
  PVOID pidtinfo;
 pidtinfo = &idtinfo;
 __asm 
 {
  push eax
  mov eax,pidtinfo
  sidt [eax]
  pop eax
 };
  idtentries =
(IDTENTRY*)((ULONG)idtinfo.LowIDTbase|((ULONG)idtinfo.HiIDTbase << 16));
 */
 __asm
 {
  push eax
  mov eax,fs:[0x38]
  mov idtentries,eax
  pop eax
 }
}