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

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

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

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

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

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

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

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

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

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

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

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

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

逼近頂峰：Inline Hook

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

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

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

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

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

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

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

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

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

緊緊纏繞的寄生藤：FSD Hook

隨著RK與ARK的斗爭進展，SSDT Hook（包括Shadow Hook）的道路被清理了，Inline Hook也被揪出來清理了，但是一些用戶驚訝的發(fā)現(xiàn)，他們?nèi)匀粺o法刪除這些已經(jīng)暴露在眼皮底下的文件，這是為什么？

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

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

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

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

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

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

產(chǎn)于極端的終極技術(shù)：FSD Inline Hook

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

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

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

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

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

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

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

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

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

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