瘟神的尾行 ——Rootkit技術

一. 無法驅逐的“助手”
網管小張正在手忙腳亂的尋找他的手工殺毒工具包，因為他在安裝一個網管工具的時候無意中走了神，點擊了“下一步”按鈕後才驚覺安裝程式的介面裡一個不令人信服的角落裡寫著“安裝CNNIC網路實名”這一行小字，而且最開頭部分有一個小小的勾。於是著名的“中國網民的得力助手”便理所當然的在他的機器裡安了家。
心裡把廠商罵了十八遍的小張終於翻出了他外出修機時最得意的工具IceSword和超級巡警，果然在進程列表和SSDT列表裡發現了紅色警報，小張笑了笑，對付這些一般使用者無法卸載的惡意流氓，自己可謂經驗豐富了，當下便三下五除二的把CNNIC的進程給終結了，SSDT也給恢複了初始狀態，然後小張去刪除註冊表啟動項——突然發出的一個錯誤提示聲音把小張嚇了一跳，再定睛一看，他的笑容凝固了：“刪除項時出錯”。不會吧？小張急忙去刪除CNNIC目錄，結果徹底愣在了那裡，系統彈出的錯誤提示很明確的告訴他，“無法刪除檔案，檔案可能正在被使用”。怎麼回事？小張一下子沒了頭緒……
達爾文的進化論告訴我們，“物競天擇，適者生存”，同樣，在這安全與入侵的網路世界裡，也在進行著這樣一場選擇的過程……

二. 被AIDS糾纏的互連網
Rootkit是什嗎？如果您在幾年前就是本刊的讀者，那您一定已經看過小金寫的涉及Rootkit的相關文章，一種在當時可以被稱為“艾滋病毒AIDS”的技術產物，只是，在這場“適者生存”的殘酷遊戲裡，最終存活的，只剩下Rootkit了，於是，今天的Rootkit地位已經等同於當年的感冒病毒——因為它實在是太普遍了，在使用者上網的同時，瘟神時刻都緊隨著其後，以求伺機而入。

小知識：什麼是Rootkit？
Rootkit自身也是木馬後門或惡意程式的一類，只是，它很特殊，為什麼呢？因為，你無法找到它。
正如自然界的規則一樣，最流行的病毒，對生物的傷害卻是最小的，例如一般的感冒，但是最不流行的病毒，卻是最奪命的。Rootkit木馬就是資訊世界裡的AIDS，一旦感染，就難以用一般手段消滅了，因為它和自然界裡的同類做的事情一樣，破壞了系統自身檢測的完整性——拋開術語的描述也許難以理解，但是可以配合AIDS的圖片想象一下，由於AIDS破壞了人體免疫系統，導致白細胞對它無能為力，只能眼睜睜看著人體機能被慢慢破壞。電腦系統沒有免疫功能，但是它提供了對自身環境的相關檢測功能——枚舉進程、檔案清單、層級許可權保護等，大部分殺毒軟體和進程工具都依賴於系統內建的檢測功能才得以運作，而Rootkit木馬要破壞的，正是這些功能。

 要瞭解Rootkit木馬的原理，就必須從系統原理說起，我們知道，作業系統是由內（Kernel）和外殼（Shell）兩部分組成的，核心負責一切實際的工作，包括CPU任務調度、記憶體配置管理、裝置管理、檔案操作等，外殼是基於核心提供的互動功能而存在的介面，它負責指令傳遞和解釋。由於核心和外殼負責的任務不同，它們的處理環境也不同，因此處理器提供了多個不同的處理環境，把它們稱為運行層級（Ring），Ring讓程式指令能訪問的電腦資源依次逐級遞減，目的在於保護電腦遭受意外損害——核心運行於Ring 0層級，擁有最完全最底層的管理功能，而到了外殼部分，它只能擁有Ring 3層級，這個層級能操作的功能極少，幾乎所有指令都需要傳遞給核心來決定能否執行，一旦發現有可能對系統造成破壞的指令傳遞（例如超越指定範圍的記憶體讀寫），核心便返回一個“非法越權”標誌，發送這個指令的程式就有可能被終止運行，這就是大部分常見的“非法操作”的由來，這樣做的目的是為了保護電腦免遭破壞，如果外殼和核心的運行層級一樣，使用者一個不經意的點擊都有可能破壞整個系統。

     由於Ring的存在，除了由系統核心載入的程式以外，由外殼調用執行的一般程式都只能運行在Ring 3層級，也就是說，它們的操作指令全部依賴於核心授權的功能，一般的進程查看工具和殺毒軟體也不例外，由於這層機制的存在，我們能看到的進程其實是核心“看到”並通過相關介面指令（還記得API嗎？）反饋到應用程式的，這樣就不可避免的存在一條資料通道，雖然在一般情況下它是難以被篡改的，但是不能避免意外的發生，Rootkit正是“製造”這種意外的程式。簡單的說，Rootkit實質是一種“越權執行”的應用程式，它設法讓自己達到和核心一樣的運行層級，甚至進入核心空間，這樣它就擁有了和核心一樣的存取權限，因而可以對核心指令進行修改，最常見的是修改核心枚舉進程的API，讓它們返回的資料始終“遺漏”Rootkit自身進程的資訊，一般的進程工具自然就“看”不到Rootkit了。更進階的Rootkit還篡改更多API，這樣，使用者就看不到進程（進程API被攔截），看不到檔案（檔案讀寫API被攔截），看不到被開啟的連接埠（網路組件Sock API被攔截），更攔截不到相關的網路資料包（網路組件NDIS API被攔截）了，幸好網路裝置的資料指示不受核心控制，否則恐怕Rootkit要讓它也不會亮了才好！我們使用的系統是在核心功能支援下運作的，如果核心變得不可信任了，依賴它啟動並執行程式還能信任嗎？

    這段概念是三年前寫下的，而如今的網路世界，越來越多的木馬後門在反病毒產品的圍剿下消滅殆盡，就如同在一個密封的箱子裡投入五大毒蟲，讓它們自相殘殺，無論結局怎麼樣，總會有一方頑強的存活下來，而倖存的這隻毒蟲，就是最強最可怕的，只不過，反病毒產品並非每次都能成為存活下來的一方，而能夠存活下來的非反病毒產品，必然是Rootkit。
這唯一倖存的毒蟲所採用的技術迅速成了眾人研究學習的重點，於是，Rootkit在短短几年內就走下了神秘的舞台，越來越“平民化”了，網路終於成為一個新的“艾滋病村”，在如此“平民化”的氛圍裡，Rootkit終於有了它“平民化”的名稱： 驅動木馬、驅動馬、帶驅動的木馬，諸如此類，而它的本名，也被縮寫為“RK”，多用於高人之間的交流稱謂。而普通上網民眾，對這些東西的存在完全是概不知情的，或者，僅限於一個模糊的概念……

 

既然大家都要控制到原生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的相應模組被鉤住了，它的“Crowdsourced Security Testing”——布施鉤子者就搶先一步得到了資料內容，接下來就得看作者的編程功底來決定程式的生死了，因為作者並不能自己寫出相應的系統函數，他就必須得設法將資料送回原函數執行模組裡去，這一步稍有差錯，就會導致調用這個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也被揪出來清理了，但是一些使用者驚訝的發現，他們仍然無法刪除這些已經暴露在眼皮底下的檔案，這是為什嗎？在解說這個問題之前，我們先來瞭解一些概念。為了讓使用者敲打鍵盤、點擊滑鼠、插入隨身碟等就能直接進入電腦的世界，作業系統在幕後是做了相當多的工作的，這些在底層運作的功能層層匯聚，最終建立出一個可用的操作平台，其中，負責管理磁碟資料和檔案讀寫的部分被稱為“檔案系統”（File System，FS），其中，Windows系列作業系統是採用IOS（Input/Output Supervisor，輸入輸出管理程式）技術進行檔案系統管理的。它接管所有的存放裝置，如硬碟、可移動式磁碟、光碟機等。

 

IOS是一種階層的管理方案，展現在使用者層上的是各種應用程式的讀寫操作，其下一層緊接著的是被稱為“可安裝檔案系統”（Installable File System，IFS）的介面層，這一層是以下各層的最終匯聚，通俗點說，也就是我們在螢幕上看到磁碟盤符、光碟機盤符、隨身碟盤符、網路磁碟映射盤符等表徵圖並對它們進行操作的由來。繼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這樣的“壞人標識”。

 

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

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

 

三. 結語
雖然到處都在提倡和諧網路的普及，但是，“健康上網”僅僅是指代那些黃賭毒而已嗎？在利益面前，開發人員的正義感越發渺小起來，我們的網路世界，是被瘟神緊緊跟隨著的。技術的鬥爭越發激烈，但是使用者的電腦知識是不會跟著時代發展而自動填滿的，最終，福士上網的人民成了這一切技術較量的受害者。這個荒謬的發展方向，何時才能休止呢？