簡單的說,你要繞過原先程式HOOK的地方,所以你的HOOK要比它的HOOK字节多
以ntOpenProcess為例,在WinDbg中看到的原型是:

lkd> u 8057559e
    nt!NtOpenProcess:
    8057559e 68c4000000      push    0C4h
    805755a3 6860b54e80      push    offset nt!ObReferenceObjectByPointer+0x127 (804eb560)
    805755a8 e8e5e4f6ff      call    nt!InterlockedPushEntrySList+0x79 (804e3a92)
    805755ad 33f6            xor     esi,esi
    原来8057559e就是NtOpenProcess函数所在的起始地址。  
    嗯，如果我们把8057559e改为指向我们函数的地址呢？比如 MyNtOpenProcess，那么系
    统就会直接调用 MyNtOpenProcess，而不是原来的NtOpenProcess了。
    这就是SSDT HOOK 原理所在。

JMP到自己的监视函数，做一些判断然后再JMP回去。一般都是修改函数头，我们来点实际的吧:
     lkd> u nt!NtOpenProcess
     nt!NtOpenProcess:
     8057559e e95d6f4271      jmp     f199c500
     805755a3 e93f953978      jmp     f890eae7
     805755a8 e8e5e4f6ff      call    nt!InterlockedPushEntrySList+0x79 (804e3a92)
     ...
     同时打开“冰刃”跟“Rootkit Unhooker”我们就能在NtOpenProcess函数头看到这样的“奇观”,第一个jmp是“冰刃”的，第二个jmp是“Rootkit Unhooker”的。(冰刃和Rootkit Unhooker一直改版,不保證你現在看到的是這樣,我只是給個例子)

※對冰刃來說它只動了5個字节,但對Rootkit Unhooker來說,它動了10個字节,現在你自己写一个替换的内核函数，以NtOpenProcess为例，就是 MyNtOpenProcess。然后修改SSDT表，让系统服务进入自己的函数MyNtOpenProcess。
而MyNtOpenProcess要做的事就是，实现NtOpenProcess前10字节指令，然后再JMP到原来的NtOpenProcess的10字节后。而當初Rootkit Unhooker的作者則只要实现NtOpenProcess前5字节指令，然后再JMP到原来的NtOpenProcess的5字节后,因為他只要pass過冰刃的Hook,而你要pass過冰刃+Rootkit Unhooker的Hook,因為它們被pass掉了,不是被 "修復" 所以就不會在自我檢測發現被動了手腳又再Hook回來,你的目的就達到了

这二楼等于没回答啥，SSDT HOOK，等到执行到真正的NtOpenProcess，OD的打开进程已经被过滤掉了，，，，，我也想知道答案，不能修改中断服务描述表，也不能修改HOOK者的代码，比如改JMP，它有检测

你hook OD的NtOpenProcess,然后改成DeviceIoControl方式的...