note: Rootkit in Windows進展 : SSDT Hook & Shadow SSDT Hook
|
Inline Hook (IDT Hook)
|
FSD Hook
|
FSD Inline Hook
next one??
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 ”，多用於高人之間的交流稱謂。
而普通上網民眾，對這些東西的存在完全是概不知情的，或者，僅限於一個模糊的概念……
當其他類型的木馬後門技術已可以輕而易舉被殲滅以後，Rootkit技術就成了這場對抗賽的主力軍，於是，為了存活，“驅動馬”也開始出現不同的發展分支，在普通網民尚未察覺的時候，它們早已經“變異”出不同派係了……
一切的開端：SSDT Hook
在很早很早以前，一些用戶突然覺得自己的機器存在異常，並經常有被人監控的感覺，於是使用殺毒軟件進行全盤掃描，答案卻是否定的，於是用戶就信任殺毒軟件，放心的去用了，直到有一天，“灰鴿子”木馬在網上鬧得轟轟烈烈，用戶慌忙去下載了最新專殺工具，這一下，用戶被嚇壞了：我是什麼時候被感染的灰鴿子？
普通網民第一次與“會隱形的木馬”打交道，莫過於灰鴿子事件了，但是為什麼“灰鴿子”無法被任務管理器和那時候的殺毒軟件找到，甚至用戶自己手動去查找，也是無功而返呢？這是因為，灰鴿子使用了最初的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，他將會有很大機率看到那藍底白字的屏幕。
結語
雖然到處都在提倡和諧網絡的普及，但是，“健康上網”僅僅是指代那些黃賭毒而已嗎？在利益面前，開發者的正義感越發渺小起來，我們的網絡世界，是被瘟神緊緊跟隨著的。技術的鬥爭越發激烈，但是用戶的電腦知識是不會跟著時代發展而自動填充的，最終，大眾上網的人民成了這一切技術較量的受害者。
這個荒謬的發展方向，何時才能休止呢？