搞Windows安全其實并沒有什么神秘的，反而很累，好不容易把系統底層研究懂了， 但是系統一升級， 卻發現完全變了。 反而應用層的東西會相對穩定， 因為微軟要一直考慮應用軟件的兼容...

在很早很早以前，一些用戶突然覺得自己的機器存在異常，并經常有被人監控的感覺，于是使用殺毒軟件進行全盤掃描，答案卻是否定的，于是用戶就信任殺毒軟件，放心的去用了，直到有一天，“灰鴿子”木馬在網上鬧得轟轟烈烈，用戶慌忙去下載了最新專殺工具，這一下，用戶被嚇壞了：我是什么時候被感染的灰鴿子？

普通網民第一次與“會隱形的木馬”打交道，莫過于灰鴿子事件了，但是為什么“灰鴿子”無法被任務管理器和那時候的殺毒軟件找到，甚至用戶自己手動去查找，也是無功而返呢？這是因為，灰鴿子使用了最初的Rootkit技術：SSDT鉤子。

而后，又有一些尚在雛形階段的惡意流氓軟件，也開始大玩“隱身”了，用戶們是絲毫沒有察覺的，除非一些惡意程序太過于張揚，但是，即使如此，他們也始終找不到異常情況發生的依據，任務管理器里沒有、搜索文件沒有、就連注冊表監視軟件，也沒了回應……

造成這些現象的原因是什么呢？因為灰鴿子，以及后來出現的惡意程序，它們使用的交互接口，并非Ring 3用戶層上的標準Win32 API，而是通過各種手段，例如驅動程序，進入到Ring 0內核層的Native API。

“Native API”（原生API）是Windows NT架構系統中真正工作的API，眾所周知，Windows是一個通過大量API函數來實現程序功能的系統，然而，由于Windows是支持POSIX標準（可移植操作系統接口，Portable Operating System Interface）的系統，這就意味著，它除了能運行標準Windows平臺程序（即Win32程序）以外，還支持少量其他平臺上的程序運行，如 OS/2。由于不同平臺的程序功能實現方法差異，系統就必須分別為它支持的各個符合POSIX標準的程序提供相應的接口函數，如果根據這個思路去開發一套龐大而完整的接口函數調用，那就太不切實際了，于是，在NT架構系統上，開發者設計了兩種不同性質的API接口層，一種被稱為“用戶態API”，它包括常見的Win32 API和POSIX接口API等，這些API運行在Ring3用戶層上，構成了今天的Windows世界；而另一種是被稱為“Native”性質的 API，它們才是真正的系統API，通常運行在內核態上，實現真正的系統核心功能調用。同時為了實現POSIX，開發者還設計了被稱為“子系統”（Sub System）的技術來將不同的系統環境區別開來，正常情況下，從系統引導到桌面時，我們就處于“Win32”子系統下，這時候起到作用的自然就是 Win32 API。普通程序員平時接觸到的幾千個Win32 API，實際上都是通過幾百個Native API的不同封裝形式來實現的。系統廠商極少提供這些API的公開文檔，是因為它們要比一般的函數難以應用而且可能發生變化，當程序員使用Win32 API時，最終的執行過程是在系統經過兼容性檢查、錯誤處理、參數選項分離等一系列復雜轉換后，才送入Native API進行處理的，Native API才是真正執行并反饋運行結果的主體，用戶層的API調用只是一種封裝形式罷了，例如fopen和CreateFile這兩個Win32函數，它們的真正執行函數是Native性質的NtCreateFile，這就是rootkit可以讓一般的進程工具不能發現自己的原因，因為它直接干涉了 Native API的執行結果。
因為API還有這樣復雜的故事，所以現在的惡意程序紛紛為了能最大限度提升自己的權限而變身rootkit性質程序，去“鉤”這些原生API，而達到同等層次的安全檢測工具和反病毒產品，也為了達到同樣的效果而做了同樣的事情，到了這個地步，安全產品和惡意軟件在執行過程中已經沒有區別了，唯一的區別是對用戶和系統環境造成的后果差異而已。

既然大家都要控制到原生API層，那么他們的做法有沒有共同點呢？答案是一定的，Windows作為一個規范的系統，就必須在原生API和用戶層API之間存在一個標準的接口來實現數據傳遞，并限制用戶使用其他不知名的操作來達到目的，這個接口由一個名為“ntdll.dll”的動態鏈接庫文件負責，所有用戶層API的處理都是調用這個DLL文件中的相關API入口實現的，但它只是一個提供從用戶層跳轉到內核層的接口，它并不是最終執行體。當API調用被轉換為ntdll內的相關API函數后，系統就會在一個被稱為 “SSDT”（System Service Descriptor Table，系統服務描述符表）的數據表里查找這個API的位置，然后真正的調用它，這時候執行的API就是真正的原生API了，它們是位于NT系統真正內核程序ntoskrnl.exe里的函數。這一過程，就是系統服務的調用，例如外殼程序需要運行一個新的進程，那么它就會調用kernel32.dll 導出的API函數CreateProcess，接下來就是kernel32.dll內的執行過程，實際上它只是把這個請求又包裝了一下，變形為自己發出的參數，去調用ntdll.dll里導出的NtCreateProcess函數，然后ntdll.dll通過一個中斷請求int 2Eh（Sysenter）進入內核態，并把我們最初的新建進程請求轉換為“服務號”一起傳遞過去，到了內核的世界里，在正常手段下對API的調用都需要先通過一個函數地址描述表的轉變來實現，SSDT就是這個表，它記錄了一個龐大的地址索引，內容為幾百個原生API在內核中導出的地址位置，除此之外還有一些有用的其他信息，在這個例子里，系統根據SSDT里記錄的服務號與函數對應關系來確認我們要使用什么函數，以及這個函數在內核中的位置信息，最終實現功能調用，函數執行完畢后再把結果通過ntdll接口一層層傳遞回去，直到發出請求的程序收到一個表示處理結果的狀態代碼，這一次系統服務的調用過程就結束了。

由于上述原理，無論是惡意程序還是反病毒產品都會優先考慮把SSDT的內容給篡改以達到效果，簡單的說，例如一個惡意程序把SSDT里對于獲取進程標識的服務號對應的原生API地址修改為指向自己位于Ring0層的驅動入口，那么每次系統執行到這個函數時，都會由于SSDT的錯誤引導而進入了作者指定的服務模塊中，就會導致相關的操作請求和參數被這個第三方模塊記錄和篡改，于是各種奇怪的現象就會發生了，就拿隱藏自身進程的rootkit技術來說，其原理就在于通過篡改SSDT里枚舉進程的原生API服務號先指向自己的模塊，再由自己的模塊另行傳遞到真正的系統服務上（如果沒有這一步操作或者操作錯誤，那么這個對應的系統服務就會作廢甚至引發系統崩潰），并對真正的系統服務返回的數據進行加工處理，如刪除帶有自己進程名的數據，那么最終返回的數據里自然就 “看不到”這個進程了。

通過操縱SSDT，以這個技術維生的Rootkit囂張跋扈過一段時間，無論是木馬后門還是流氓插件和惡意軟件。在幕后掙錢的作者們也結結實實的過了個肥得流油的好年，然而好景不長，Anti-Rootki t（反Rootkit，即“ARK”）的概念被提出了，ARK工具也誕生了，如國產的IceSword、超級巡警等。此類ARK工具的運作原理和 Rootkit大相徑庭，它們也是通過驅動模塊將自身投入系統內核中，從而達到了與Rootkit們平起平坐的公平競爭地位，然后，位于用戶層的程序主體和進入內核態的驅動模塊同時產生一個相同的查詢API，例如枚舉當前系統進程列表等，由于Rootkit的存在，用戶層的程序主體最終得到的數據會比驅動模塊返回的數據少那么幾個——很明顯，Rootkit驅動拼命要隱藏起來的用戶層程序就此暴露，不打自招了；而同時，ARK還能將當前SSDT服務號指向的函數幕后的執行主體找出來，如果某個服務號指向的函數對應的執行主體不是NTOSKRNL.EXE（XP及以上系統中，某些機器是 ntkrnlpa.exe），則可以斷定該服務號有問題了。超級巡警以及后來的ARK更是直接提供了“一鍵恢復”功能，只需用戶鼠標輕輕一點，所有第三方程序在SSDT掛住的鉤子紛紛“脫鉤”，短時間內就把RK布下的層層障礙給解除了，在一段時間內RK的勢頭迅速被壓了下去，短暫的世界太平，短暫的，恩。

對于SSDT Hook，現在的所有Anti-Rootkit工具都能輕易找出并解除它的鉤子（脫鉤，Unhook），如IceSword、RKU、超級巡警等。
運行IceSword，首先點擊“進程”，觀察這里是否存在紅色標記的進程，如果有，說明你的系統里絕對存在SSDT Hook，那紅色的進程正是被底層驅動隱藏起來的文件，將它的具體位置記下來，并將其終止。
現在點擊進入SSDT列表，會發現一些被紅色標注出來的行列，記住它的“當前服務函數所在模塊”，這個就是實施SSDT Hook的底層驅動文件。
然后，使用超級巡警切換至高級模式，將SSDT恢復為初始狀態，它的所有防御就被解除了，現在直接查找剛才記錄的文件去刪除吧。

進一步試探：Shadow SSDT Hook
RK 作者不甘心，無論是出于技術上的抗爭還是利益上的損失，反正，ARK既然讓我丟了面子或癟了錢包，那么，“有朝一日龍得水，定叫長江水倒流！”，一些人開始嘗試研究破解Anti-Rootkit工具，誓與之抗爭到底，另一些人，則開始了新的探索，最終，雙方都有了成效：首先，pjf的大作 IceSword被成功反匯編了，雖然得到的并不是最初的C語言代碼而是匯編語句，但是對于研究Rootkit的人來說，匯編在他們眼里，就如同看網絡小說一樣輕而易舉，很快，就有人識破了作者的檢測邏輯，可以繞過IceSword以及其他采用類似檢測方法的工具的Rootkit就此誕生，甚至一部分RK 已經開始反過來監控ARK，一旦相應ARK的驅動被加載，立即開始玉石俱焚——將用戶機器弄成經典的藍屏死機，不明就里的用戶在幾次與藍色屏幕對望后，通常都會無奈的放棄；而另一種藍屏則是更深層次的問題導致的，下面會提到。

而探索另一個方向的研究者們，也傳來了捷報：Windows系統里，除了那個大家都在玩的SSDT（KeServiceDescriptorTable）以外，還有一個隱藏得非常深入的類似SSDT結構的數據段在同時工作著，它被稱為“Shadow SSDT”（SSDT映射），這個“KeServiceDescriptorTableShadow”功能并未從系統內核中導出，但是通過外聯的系統級別調試器，卻看到了它的蹤影。Shadow SSDT的作用和SSDT本身差不多，只不過它主要是提供一些基于圖形用戶界面（GUI）下的系統服務函數，并保存了一份與SSDT相同的服務列表，當然，這也是提供給基于GUI下的程序調用的。Shadow SSDT被安排在win32k.sys中，非常少文獻提及它，因此這幾乎是個被人遺忘的角落，Rootkit作者們很快就發現，控制這里也能達到一定的效果，因為Shadow SSDT同樣具備了SSDT的所有功能，只不過是要利用的時候多了一些步驟而已，于是RK又有了新的玩法，這一次，輪到ARK傻眼了，那時候ARK根本沒有做到Shadow SSDT這一步，于是，只鉤住Shadow SSDT的Rootkit們得以無法無天的生存下去，任由用戶怎么發現惡意程序怎么恢復SSDT都好，始終都是影響不到此類Rootkit！

這個情形，一直到具備了Shadow SSDT檢測功能的ARK工具出現才結束，例如大名鼎鼎的RootKit Unhooker（RKU），它那強大的SSDT以及其Shadow檢測脫鉤功能，幫助許多人解決了這些新生的搗蛋鬼，于是，Rootkit作者們又開始尋求新的生存之道。
此類Hook由于出現得比較晚，很多當初流行的ARK都沒有涉及這塊，所以，我們只能使用RKU、狙劍等工具對其進行操作。
運行RKU（Rootkit Unhooker），它是英文軟件，但是操作十分簡便。點擊“Shadow SSDT”，如果系統中存在Shadow SSDT Hook，你會發現軟件底部狀態欄里“Services/Hooked”不再是“xxx/0”的狀態，同時相應被Hook的函數顯示行里， “Hooked”一欄為“Yes”，現在記下這個文件的位置和地址，然后直接點“UnHooked ALL”，接下來，去找文件刪除吧。

逼近頂峰：Inline Hook

世界上最荒謬的事情是什么？是順著被人故意弄亂方向的路牌，往錯誤的方向走了好遠都沒察覺到有問題？還是被朋友惡作劇的將男女洗手間的標識換了位置？如果有天去造訪寺院，卻發現里面居然是清一色的道士在念經，你一定會驚呼，這簡直太荒謬了！
在狂熱的Rootkit領域里，類似的荒謬正在散布開來，那就是高級的Hook形式——Inline Hook。

在最初的運作流程里，所有被設置了掛鉤的函數操作，最終還是要回到原始功能模塊內處理的，畢竟第三方程序作者不是Windows系統編寫者，為了保證系統的正常運行，最明智的做法當然是讓被攔截的相關函數請求在經過自己編寫的模塊的層層檢測并發現無害以后，立即將這個即將進行正常工作的請求原封不動的送到它該干活的地方去，以便系統完成整個工作流程，所以大家都在打SSDT等地方的主意，就是為了在這條必經之路上插上一腳，力求能絆倒那些看著不順眼的路人。而現在，路上出現會砍腳的保安了，怎么辦，難道玩不下去了嗎？然而，迎接挑戰正是每個研究者的興趣所在，于是，荒謬的念頭帶出了可怕的技術，這就是 Inline Hook。

其實，Inline Hook早就作為一種高級的Hook技術存在了，在用戶層上的一些特殊程序如游戲外掛等，為了獲得最完整可靠的數據，它們都不再采用錯誤指路牌的方法來將數據轉移了，因為這樣很可能會因為觸發程序編寫者針對此問題而設置的處理程序，最終功虧一簣。那么，怎么樣才能讓這個處理程序不能達到觸發條件呢？那就是千萬別去鉤這個程序，但是如果不鉤住程序，又該如何取得相關數據呢？在這樣的思考模式下，一種新的鉤子技術誕生了：它雖然也在玩鉤子，但是它卻不是來鉤目標程序的，而是將系統里相應的API函數給虜了去，由于任何普通程序作者對系統API都是絕對信任的，于是，當他們的程序請求調用相關API并將參數一同發送過去時，由于提供這個API的相應模塊被鉤住了，它的“先知”——布施鉤子者就搶先一步得到了數據內容，接下來就得看作者的編程功底來決定程序的生死了，因為作者并不能自己寫出相應的系統函數，他就必須得設法將數據送回原函數執行模塊里去，這一步稍有差錯，就會導致調用這個API的程序崩潰退出。

正因如此，Inline Hook是一種相對一般Hook而言更復雜的技術，除非作者有較深的編程功底和對系統的了解，否則冒冒失失就大量使用這個技術是很容易出問題的，不僅受害者不好過，攻擊者也無法取得他所需數據，得不償失。

既然在用戶層（Ring 3）上使用Inline Hook都要如此注意，那么在Rootkit的世界里有沒有人吃螃蟹呢？答案是一定的，當鉤住SSDT和Shadow SSDT的途徑都被堵死以后，Rootkit技術終于向Inline Hook邁出了一步。

設想一下，當所有檢測工具都在虎視眈眈SSDT這個關口時，某個Rootkit早已用自己的函數把系統內核里的敏感函數給替換了，當用戶層的函數操作請求通過正常的SSDT找到相應內核態函數的執行主體時，卻不知道這個執行主體早已被Rootkit冒名頂替了，那么情形會是怎么樣的呢？雖然所有檢測工具都報告情況正常，但是機器內其實早已被Rootkit安家，如果這個Rootkit預置了在某個時刻進行破壞行為的邏輯，那么用戶直到系統出問題的那一刻，都還不知道究竟發生了什么事情！

位于Ring 0的Inline Hook是十分隱蔽的，除非研究者對系統了解較深，否則他想破了頭也不能找出原因所在，更別提連殺個進程的概念都很迷茫的普通用戶了。但是使用 Inline Hook是必須付出代價的，由于內核的復雜性，尤其因為位于這一層的函數是所有程序都必須頻繁調用的，很多時候如果設鉤者沒考慮周全，導致某個已經 Inline Hook的函數被意外的直接調用，就會導致嚴重后果。所以，使用Inline Hook的Rootkit能否正常穩定的工作，是與作者的水平連接得十分緊密的，一個不成熟的用戶層Inline Hook程序大不了就是跟著它要監控的程序一起引發內存錯誤導致非法操作異常退出，僅此而已，但是到了系統核心層，這里可沒有任何錯誤檢測模塊來保證你的程序在做出會導致內核崩潰的事情之前就趕緊將它終止——這已經是最底層了，一個錯誤的內存讀寫都會直接引發內核級別的崩潰，即我們俗稱的“藍屏死機” （BSoD，Blue Screen of Dealth）。于是，不成熟的Inline Hook Rootkit的代價就是系統變得及其不穩定，在用戶看來，電腦表現出來的癥狀就是莫名其妙的非常容易藍屏，這就是技術不成熟的Rootkit導致的后果，只不過，這個代價是由受害的用戶來承擔的。

不過，目前能流行開來的Inline Hook Rootkit，基本上都是已經在開發者的機器上經歷了無數次藍屏考驗后才出場的，所以通常情況下，用戶并不會因為這些Rootkit的存在而頻頻藍屏，并且，它已經成為當前Rootkit的主流技術。

對付Inline Hook，無論是狙劍、RKU還是Wsyscheck都可以做到，以狙劍為例，點擊程序主界面的“擴展功能”，然后點擊“SSDT檢查”，你會突然有眼花繚亂的感覺，所以請點擊右鍵——“篩選可疑項”，讓它僅僅把異常部分顯示出來（注意那個SnipeSword.sys，它是狙劍自身的驅動，不要弄錯了），如果系統存在異常，“HOOK類型”里會列出相關說明，如HOOK、Inline-Hook等，首先可以嘗試右鍵選擇“恢復所有HOOK”，然后刷新一次，如果仍然列出異常項目，就得在相應的項目列上點擊右鍵選擇“恢復選定的Inline-HOOK”了。

緊緊纏繞的寄生藤：FSD Hook

隨著RK與ARK的斗爭進展，SSDT Hook（包括Shadow Hook）的道路被清理了，Inline Hook也被揪出來清理了，但是一些用戶驚訝的發現，他們仍然無法刪除這些已經暴露在眼皮底下的文件，這是為什么？

在解說這個問題之前，我們先來了解一些概念。為了讓用戶敲打鍵盤、點擊鼠標、插入U盤等就能直接進入計算機的世界，操作系統在幕后是做了相當多的工作的，這些在底層運作的功能層層匯聚，最終建立出一個可用的操作平臺，其中，負責管理磁盤數據和文件讀寫的部分被稱為“文件系統”（File System，FS），其中，Windows系列操作系統是采用IOS（Input/Output Supervisor，輸入輸出管理程序）技術進行文件系統管理的。它接管所有的存儲設備，如硬盤、可移動式磁盤、光驅等。

IOS是一種層次結構的管理方案，展現在用戶層上的是各種應用程序的讀寫操作，其下一層緊接著的是被稱為“可安裝文件系統”（Installable File System，IFS）的接口層，這一層是以下各層的最終匯聚，通俗點說，也就是我們在屏幕上看到磁盤盤符、光驅盤符、U盤盤符、網絡磁盤映射盤符等圖標并對它們進行操作的由來。繼IFS以后，就是各種文件系統驅動所在的層，即“FSD”（File System Driver，文件系統驅動），這一層直接與IOS連接，用于接受并處理屬于自己任務分派內的數據；FSD下一層直達IOS，而到了IOS的下一層，數據就開始往硬件化發展了。
而這次Rootkit的目標，就是到達IOS之前的最后一層：FSD。

FSD在Windows系統中屬于開放給編程人員可接觸到的最深入的一塊區域（再往下就是操作系統自身提供的驅動和硬件廠商的事情了），所以，這一層的權限是很高的，控制了這個層次，開發者就能掌握到最多最全面的文件讀寫操作控制，于是，當所有的道路都被Anti-Rootkit工具阻撓后， Rootkit作者開始反抗，方法是阻止他們的工具將揪出來的Rootkit直接殲滅。

FSD并非絕對禁地，在這之前，反病毒廠商和磁盤數據加密廠商早就在這一層里專研了，一部分人致力于編寫自己的FSD，而更多的人，是通過編寫FSD Filter Driver（文件系統驅動過濾器）來達到目的，以便從中析出它們敏感的數據來進行其他工作，而Filter驅動的一個要點就是鉤住FSD，即“FSD Hook”。當FSD被你掌握后，你就可以通過操縱它的數據來控制別人的文件讀寫請求，對于Rootkit來說，它們可以將一些敏感文件如自身驅動程序文件、用戶層相關文件等設置為除了它們自己以外的程序都無法對其進行讀寫的效果，到了用戶層，直接反映出來的就是無法對其進行編輯、改名和刪除。

用了這個技術，Rootkit作者們又可以偷笑了，因為即使用戶用各種手段找到了它并將其進程終止，他也無法操作那些被保護起來的文件。
只是，鉤子始終是鉤子，總會有人去脫鉤的，在克制FSD Hook技術的ARK工具出現后，一部分人面對著十分難以操作的FSD而放棄了，因為到了這一層已經非常容易導致系統不穩定了。
而一些人，仍然走了下去。

如何清理這個類型的Rootkit呢？以最容易操作的Wsyscheck為例，首先運行Wsyscheck（你會發現一個有趣現象：IceSword無法檢測到Wsyscheck的Hook，因為它用的技術是Inline Hook和FSD Hook），點擊進入“內核檢查”，選中“FSD檢查”，留意“代碼異常”項里是否有標注為“Yes”的項，如果有，請在界面里右鍵點擊，并選擇“恢復所有函數”。Wsyscheck的進程列表并非使用IceSword一類的邏輯，所以如果你看到存在紅色的列表也不要太過于緊張，它只是表示這個程序是沒有系統簽名驗證、且類型特殊（如服務、加載驅動等）的應用程序而已，并非是IceSword這樣的“壞人標識”。

產于極端的終極技術：FSD Inline Hook

Rootkit到了FSD Hook這一層，對系統造成的影響已經相當危險了，然而，由于出現了對抗的工具觸動了某些人的利益，終于，一個著名的流氓軟件吃了這只大家都會因為良心不安而不去觸碰的螃蟹——FSD Inline Hook。

在及其重要敏感的FSD環境下放鉤子本身就是一件要求很高的事情，而用自己的函數去替代這個雷區的系統函數，更是被很多人認為是嚴禁操作的事情，而現在，真的有人帶頭違反了，以后的局勢又將如何呢？

所以，將CNNIC列為當前流氓軟件作者的所有研究目標都不過分，因為CNNIC身上，就具備了多種高級技術，只可惜，全都沒有用于正道。
Inline Hook的概念我們在前面已經說過了，現在主要說說這個Rootkit的行為以及后果。

也許是CNNIC的開發者對于自家產品頻頻被刪除而惱怒了吧，這次最新發布的程序中，FSD Inline Hook終于出現了，它直接將操作系統廠商編寫的相關功能使用自己的函數去取代了，而搞過FSD開發的人都知道，這一層的功能函數對硬件平臺、系統版本是具有高度依賴性的，每個操作系統采用的函數都會有些許差異，但是操作系統廠商并不是制作通用的FSD方案，更何況，這個標準就是他們自己提出來的，所以這些變動對他們而言都是無傷大雅的，但是對于第三方廠商來說，他們缺少必要的開發文檔（微軟并未公布任何涉及FSD Inline Hook技術文檔，也不鼓勵開發者這樣做）和齊全的硬件測試平臺，所以，在不齊全的操作系統環境和硬件配置下實現的技術，必然很容易就導致受害用戶直接欣賞到賞心悅目的藍屏。

CNNIC必然清楚這點，但是，他們什么也不顧了。而且，CNNIC的技術水平果然也沒達到穩定的水平，在被CNNIC安家的系統里，用戶只要運行 IceSword檢測，就會直接導致藍屏，這是因為它們都同時鉤住了一個底層函數，但是下鉤的位置存在些許偏差，例如，一個鉤住了頭部，一個鉤住了屁股，于是內核受不了這很黃很暴力的行為，而直接崩潰了。

但是，畢竟已經有人起了頭。以后的Rootkit世界將會變成什么樣子，誰也不知道。

要消滅CNNIC以及采用FSD Inline Hook技術的Rootkit，首選應該是360安全衛士，但是如果出現了360安全衛士也未加入識別的Rootkit，用戶就得使用“狙劍”了，解決方法與前面提及的大同小異，只需要對其“脫鉤”就可以了，關鍵在于，用戶還得留意Rootkit的用戶層程序是否也使用Hook，如線程注入等。

RK 多了，ARK也多了，這是好事還是壞事呢？答案自然是后者，無論是RK還是ARK，它們都必須進行同一個行為，就是進入系統內核層次并達到目的，于是不兼容現象往往會發生在幾個ARK之間，例如，在運行了狙劍后，Wsyscheck經常會直接報錯退出，而如果用戶在開啟了Wsyscheck的情況下運行 IceSword，他將會有很大幾率看到那藍底白字的屏幕。

三. 結語
雖然到處都在提倡和諧網絡的普及，但是，“健康上網”僅僅是指代那些黃賭毒而已嗎？在利益面前，開發者的正義感越發渺小起來，我們的網絡世界，是被瘟神緊緊跟隨著的。技術的斗爭越發激烈，但是用戶的電腦知識是不會跟著時代發展而自動填充的，最終，大眾上網的人民成了這一切技術較量的受害者。

這個荒謬的發展方向，何時才能休止呢？