搞Windows安全其實(shí)并沒有什么神秘的，反而很累，好不容易把系統(tǒng)底層研究懂了， 但是系統(tǒng)一升級(jí)， 卻發(fā)現(xiàn)完全變了。 反而應(yīng)用層的東西會(huì)相對(duì)穩(wěn)定， 因?yàn)槲④浺恢笨紤]應(yīng)用軟件的兼容...
在很早很早以前，一些用戶突然覺得自己的機(jī)器存在異常，并經(jīng)常有被人監(jiān)控的感覺，于是使用殺毒軟件進(jìn)行全盤掃描，答案卻是否定的，于是用戶就信任殺毒軟件，放心的去用了，直到有一天，“灰鴿子”木馬在網(wǎng)上鬧得轟轟烈烈，用戶慌忙去下載了最新專殺工具，這一下，用戶被嚇壞了：我是什么時(shí)候被感染的灰鴿子？
普通網(wǎng)民第一次與“會(huì)隱形的木馬”打交道，莫過于灰鴿子事件了，但是為什么“灰鴿子”無法被任務(wù)管理器和那時(shí)候的殺毒軟件找到，甚至用戶自己手動(dòng)去查找，也是無功而返呢？這是因?yàn)椋银澴邮褂昧俗畛醯腞ootkit技術(shù)：SSDT鉤子。
而后，又有一些尚在雛形階段的惡意流氓軟件，也開始大玩“隱身”了，用戶們是絲毫沒有察覺的，除非一些惡意程序太過于張揚(yáng)，但是，即使如此，他們也始終找不到異常情況發(fā)生的依據(jù)，任務(wù)管理器里沒有、搜索文件沒有、就連注冊表監(jiān)視軟件，也沒了回應(yīng)……
造成這些現(xiàn)象的原因是什么呢？因?yàn)榛银澴樱约昂髞沓霈F(xiàn)的惡意程序，它們使用的交互接口，并非Ring 3用戶層上的標(biāo)準(zhǔn)Win32 API，而是通過各種手段，例如驅(qū)動(dòng)程序，進(jìn)入到Ring 0內(nèi)核層的Native API。
“Native API”（原生API）是Windows NT架構(gòu)系統(tǒng)中真正工作的API，眾所周知，Windows是一個(gè)通過大量API函數(shù)來實(shí)現(xiàn)程序功能的系統(tǒng)，然而，由于Windows是支持POSIX標(biāo)準(zhǔn)（可移植操作系統(tǒng)接口，Portable Operating System Interface）的系統(tǒng)，這就意味著，它除了能運(yùn)行標(biāo)準(zhǔn)Windows平臺(tái)程序（即Win32程序）以外，還支持少量其他平臺(tái)上的程序運(yùn)行，如 OS/2。由于不同平臺(tái)的程序功能實(shí)現(xiàn)方法差異，系統(tǒng)就必須分別為它支持的各個(gè)符合POSIX標(biāo)準(zhǔn)的程序提供相應(yīng)的接口函數(shù)，如果根據(jù)這個(gè)思路去開發(fā)一套龐大而完整的接口函數(shù)調(diào)用，那就太不切實(shí)際了，于是，在NT架構(gòu)系統(tǒng)上，開發(fā)者設(shè)計(jì)了兩種不同性質(zhì)的API接口層，一種被稱為“用戶態(tài)API”，它包括常見的Win32 API和POSIX接口API等，這些API運(yùn)行在Ring3用戶層上，構(gòu)成了今天的Windows世界；而另一種是被稱為“Native”性質(zhì)的 API，它們才是真正的系統(tǒng)API，通常運(yùn)行在內(nèi)核態(tài)上，實(shí)現(xiàn)真正的系統(tǒng)核心功能調(diào)用。同時(shí)為了實(shí)現(xiàn)POSIX，開發(fā)者還設(shè)計(jì)了被稱為“子系統(tǒng)”（Sub System）的技術(shù)來將不同的系統(tǒng)環(huán)境區(qū)別開來，正常情況下，從系統(tǒng)引導(dǎo)到桌面時(shí)，我們就處于“Win32”子系統(tǒng)下，這時(shí)候起到作用的自然就是 Win32 API。普通程序員平時(shí)接觸到的幾千個(gè)Win32 API，實(shí)際上都是通過幾百個(gè)Native API的不同封裝形式來實(shí)現(xiàn)的。系統(tǒng)廠商極少提供這些API的公開文檔，是因?yàn)樗鼈円纫话愕暮瘮?shù)難以應(yīng)用而且可能發(fā)生變化，當(dāng)程序員使用Win32 API時(shí)，最終的執(zhí)行過程是在系統(tǒng)經(jīng)過兼容性檢查、錯(cuò)誤處理、參數(shù)選項(xiàng)分離等一系列復(fù)雜轉(zhuǎn)換后，才送入Native API進(jìn)行處理的，Native API才是真正執(zhí)行并反饋運(yùn)行結(jié)果的主體，用戶層的API調(diào)用只是一種封裝形式罷了，例如fopen和CreateFile這兩個(gè)Win32函數(shù)，它們的真正執(zhí)行函數(shù)是Native性質(zhì)的NtCreateFile，這就是rootkit可以讓一般的進(jìn)程工具不能發(fā)現(xiàn)自己的原因，因?yàn)樗苯痈缮媪?Native API的執(zhí)行結(jié)果。
因?yàn)锳PI還有這樣復(fù)雜的故事，所以現(xiàn)在的惡意程序紛紛為了能最大限度提升自己的權(quán)限而變身rootkit性質(zhì)程序，去“鉤”這些原生API，而達(dá)到同等層次的安全檢測工具和反病毒產(chǎn)品，也為了達(dá)到同樣的效果而做了同樣的事情，到了這個(gè)地步，安全產(chǎn)品和惡意軟件在執(zhí)行過程中已經(jīng)沒有區(qū)別了，唯一的區(qū)別是對(duì)用戶和系統(tǒng)環(huán)境造成的后果差異而已。
既然大家都要控制到原生API層，那么他們的做法有沒有共同點(diǎn)呢？答案是一定的，Windows作為一個(gè)規(guī)范的系統(tǒng)，就必須在原生API和用戶層API之間存在一個(gè)標(biāo)準(zhǔn)的接口來實(shí)現(xiàn)數(shù)據(jù)傳遞，并限制用戶使用其他不知名的操作來達(dá)到目的，這個(gè)接口由一個(gè)名為“ntdll.dll”的動(dòng)態(tài)鏈接庫文件負(fù)責(zé)，所有用戶層API的處理都是調(diào)用這個(gè)DLL文件中的相關(guān)API入口實(shí)現(xiàn)的，但它只是一個(gè)提供從用戶層跳轉(zhuǎn)到內(nèi)核層的接口，它并不是最終執(zhí)行體。當(dāng)API調(diào)用被轉(zhuǎn)換為ntdll內(nèi)的相關(guān)API函數(shù)后，系統(tǒng)就會(huì)在一個(gè)被稱為 “SSDT”（System Service Descriptor Table，系統(tǒng)服務(wù)描述符表）的數(shù)據(jù)表里查找這個(gè)API的位置，然后真正的調(diào)用它，這時(shí)候執(zhí)行的API就是真正的原生API了，它們是位于NT系統(tǒng)真正內(nèi)核程序ntoskrnl.exe里的函數(shù)。這一過程，就是系統(tǒng)服務(wù)的調(diào)用，例如外殼程序需要運(yùn)行一個(gè)新的進(jìn)程，那么它就會(huì)調(diào)用kernel32.dll 導(dǎo)出的API函數(shù)CreateProcess，接下來就是kernel32.dll內(nèi)的執(zhí)行過程，實(shí)際上它只是把這個(gè)請求又包裝了一下，變形為自己發(fā)出的參數(shù)，去調(diào)用ntdll.dll里導(dǎo)出的NtCreateProcess函數(shù)，然后ntdll.dll通過一個(gè)中斷請求int 2Eh（Sysenter）進(jìn)入內(nèi)核態(tài)，并把我們最初的新建進(jìn)程請求轉(zhuǎn)換為“服務(wù)號(hào)”一起傳遞過去，到了內(nèi)核的世界里，在正常手段下對(duì)API的調(diào)用都需要先通過一個(gè)函數(shù)地址描述表的轉(zhuǎn)變來實(shí)現(xiàn)，SSDT就是這個(gè)表，它記錄了一個(gè)龐大的地址索引，內(nèi)容為幾百個(gè)原生API在內(nèi)核中導(dǎo)出的地址位置，除此之外還有一些有用的其他信息，在這個(gè)例子里，系統(tǒng)根據(jù)SSDT里記錄的服務(wù)號(hào)與函數(shù)對(duì)應(yīng)關(guān)系來確認(rèn)我們要使用什么函數(shù)，以及這個(gè)函數(shù)在內(nèi)核中的位置信息，最終實(shí)現(xiàn)功能調(diào)用，函數(shù)執(zhí)行完畢后再把結(jié)果通過ntdll接口一層層傳遞回去，直到發(fā)出請求的程序收到一個(gè)表示處理結(jié)果的狀態(tài)代碼，這一次系統(tǒng)服務(wù)的調(diào)用過程就結(jié)束了。
由于上述原理，無論是惡意程序還是反病毒產(chǎn)品都會(huì)優(yōu)先考慮把SSDT的內(nèi)容給篡改以達(dá)到效果，簡單的說，例如一個(gè)惡意程序把SSDT里對(duì)于獲取進(jìn)程標(biāo)識(shí)的服務(wù)號(hào)對(duì)應(yīng)的原生API地址修改為指向自己位于Ring0層的驅(qū)動(dòng)入口，那么每次系統(tǒng)執(zhí)行到這個(gè)函數(shù)時(shí)，都會(huì)由于SSDT的錯(cuò)誤引導(dǎo)而進(jìn)入了作者指定的服務(wù)模塊中，就會(huì)導(dǎo)致相關(guān)的操作請求和參數(shù)被這個(gè)第三方模塊記錄和篡改，于是各種奇怪的現(xiàn)象就會(huì)發(fā)生了，就拿隱藏自身進(jìn)程的rootkit技術(shù)來說，其原理就在于通過篡改SSDT里枚舉進(jìn)程的原生API服務(wù)號(hào)先指向自己的模塊，再由自己的模塊另行傳遞到真正的系統(tǒng)服務(wù)上（如果沒有這一步操作或者操作錯(cuò)誤，那么這個(gè)對(duì)應(yīng)的系統(tǒng)服務(wù)就會(huì)作廢甚至引發(fā)系統(tǒng)崩潰），并對(duì)真正的系統(tǒng)服務(wù)返回的數(shù)據(jù)進(jìn)行加工處理，如刪除帶有自己進(jìn)程名的數(shù)據(jù)，那么最終返回的數(shù)據(jù)里自然就 “看不到”這個(gè)進(jìn)程了。
通過操縱SSDT，以這個(gè)技術(shù)維生的Rootkit囂張跋扈過一段時(shí)間，無論是木馬后門還是流氓插件和惡意軟件。在幕后掙錢的作者們也結(jié)結(jié)實(shí)實(shí)的過了個(gè)肥得流油的好年，然而好景不長，Anti-Rootki t（反Rootkit，即“ARK”）的概念被提出了，ARK工具也誕生了，如國產(chǎn)的IceSword、超級(jí)巡警等。此類ARK工具的運(yùn)作原理和 Rootkit大相徑庭，它們也是通過驅(qū)動(dòng)模塊將自身投入系統(tǒng)內(nèi)核中，從而達(dá)到了與Rootkit們平起平坐的公平競爭地位，然后，位于用戶層的程序主體和進(jìn)入內(nèi)核態(tài)的驅(qū)動(dòng)模塊同時(shí)產(chǎn)生一個(gè)相同的查詢API，例如枚舉當(dāng)前系統(tǒng)進(jìn)程列表等，由于Rootkit的存在，用戶層的程序主體最終得到的數(shù)據(jù)會(huì)比驅(qū)動(dòng)模塊返回的數(shù)據(jù)少那么幾個(gè)——很明顯，Rootkit驅(qū)動(dòng)拼命要隱藏起來的用戶層程序就此暴露，不打自招了；而同時(shí)，ARK還能將當(dāng)前SSDT服務(wù)號(hào)指向的函數(shù)幕后的執(zhí)行主體找出來，如果某個(gè)服務(wù)號(hào)指向的函數(shù)對(duì)應(yīng)的執(zhí)行主體不是NTOSKRNL.EXE（XP及以上系統(tǒng)中，某些機(jī)器是 ntkrnlpa.exe），則可以斷定該服務(wù)號(hào)有問題了。超級(jí)巡警以及后來的ARK更是直接提供了“一鍵恢復(fù)”功能，只需用戶鼠標(biāo)輕輕一點(diǎn)，所有第三方程序在SSDT掛住的鉤子紛紛“脫鉤”，短時(shí)間內(nèi)就把RK布下的層層障礙給解除了，在一段時(shí)間內(nèi)RK的勢頭迅速被壓了下去，短暫的世界太平，短暫的，恩。
對(duì)于SSDT Hook，現(xiàn)在的所有Anti-Rootkit工具都能輕易找出并解除它的鉤子（脫鉤，Unhook），如IceSword、RKU、超級(jí)巡警等。
運(yùn)行IceSword，首先點(diǎn)擊“進(jìn)程”，觀察這里是否存在紅色標(biāo)記的進(jìn)程，如果有，說明你的系統(tǒng)里絕對(duì)存在SSDT Hook，那紅色的進(jìn)程正是被底層驅(qū)動(dòng)隱藏起來的文件，將它的具體位置記下來，并將其終止。
現(xiàn)在點(diǎn)擊進(jìn)入SSDT列表，會(huì)發(fā)現(xiàn)一些被紅色標(biāo)注出來的行列，記住它的“當(dāng)前服務(wù)函數(shù)所在模塊”，這個(gè)就是實(shí)施SSDT Hook的底層驅(qū)動(dòng)文件。
然后，使用超級(jí)巡警切換至高級(jí)模式，將SSDT恢復(fù)為初始狀態(tài)，它的所有防御就被解除了，現(xiàn)在直接查找剛才記錄的文件去刪除吧。
進(jìn)一步試探：Shadow SSDT Hook
RK 作者不甘心，無論是出于技術(shù)上的抗?fàn)庍€是利益上的損失，反正，ARK既然讓我丟了面子或癟了錢包，那么，“有朝一日龍得水，定叫長江水倒流！”，一些人開始嘗試研究破解Anti-Rootkit工具，誓與之抗?fàn)幍降祝硪恍┤耍瑒t開始了新的探索，最終，雙方都有了成效：首先，pjf的大作 IceSword被成功反匯編了，雖然得到的并不是最初的C語言代碼而是匯編語句，但是對(duì)于研究Rootkit的人來說，匯編在他們眼里，就如同看網(wǎng)絡(luò)小說一樣輕而易舉，很快，就有人識(shí)破了作者的檢測邏輯，可以繞過IceSword以及其他采用類似檢測方法的工具的Rootkit就此誕生，甚至一部分RK 已經(jīng)開始反過來監(jiān)控ARK，一旦相應(yīng)ARK的驅(qū)動(dòng)被加載，立即開始玉石俱焚——將用戶機(jī)器弄成經(jīng)典的藍(lán)屏死機(jī)，不明就里的用戶在幾次與藍(lán)色屏幕對(duì)望后，通常都會(huì)無奈的放棄；而另一種藍(lán)屏則是更深層次的問題導(dǎo)致的，下面會(huì)提到。
而探索另一個(gè)方向的研究者們，也傳來了捷報(bào)：Windows系統(tǒng)里，除了那個(gè)大家都在玩的SSDT（KeServiceDescriptorTable）以外，還有一個(gè)隱藏得非常深入的類似SSDT結(jié)構(gòu)的數(shù)據(jù)段在同時(shí)工作著，它被稱為“Shadow SSDT”（SSDT映射），這個(gè)“KeServiceDescriptorTableShadow”功能并未從系統(tǒng)內(nèi)核中導(dǎo)出，但是通過外聯(lián)的系統(tǒng)級(jí)別調(diào)試器，卻看到了它的蹤影。Shadow SSDT的作用和SSDT本身差不多，只不過它主要是提供一些基于圖形用戶界面（GUI）下的系統(tǒng)服務(wù)函數(shù)，并保存了一份與SSDT相同的服務(wù)列表，當(dāng)然，這也是提供給基于GUI下的程序調(diào)用的。Shadow SSDT被安排在win32k.sys中，非常少文獻(xiàn)提及它，因此這幾乎是個(gè)被人遺忘的角落，Rootkit作者們很快就發(fā)現(xiàn)，控制這里也能達(dá)到一定的效果，因?yàn)镾hadow SSDT同樣具備了SSDT的所有功能，只不過是要利用的時(shí)候多了一些步驟而已，于是RK又有了新的玩法，這一次，輪到ARK傻眼了，那時(shí)候ARK根本沒有做到Shadow SSDT這一步，于是，只鉤住Shadow SSDT的Rootkit們得以無法無天的生存下去，任由用戶怎么發(fā)現(xiàn)惡意程序怎么恢復(fù)SSDT都好，始終都是影響不到此類Rootkit！
這個(gè)情形，一直到具備了Shadow SSDT檢測功能的ARK工具出現(xiàn)才結(jié)束，例如大名鼎鼎的RootKit Unhooker（RKU），它那強(qiáng)大的SSDT以及其Shadow檢測脫鉤功能，幫助許多人解決了這些新生的搗蛋鬼，于是，Rootkit作者們又開始尋求新的生存之道。
此類Hook由于出現(xiàn)得比較晚，很多當(dāng)初流行的ARK都沒有涉及這塊，所以，我們只能使用RKU、狙劍等工具對(duì)其進(jìn)行操作。
運(yùn)行RKU（Rootkit Unhooker），它是英文軟件，但是操作十分簡便。點(diǎn)擊“Shadow SSDT”，如果系統(tǒng)中存在Shadow SSDT Hook，你會(huì)發(fā)現(xiàn)軟件底部狀態(tài)欄里“Services/Hooked”不再是“xxx/0”的狀態(tài)，同時(shí)相應(yīng)被Hook的函數(shù)顯示行里， “Hooked”一欄為“Yes”，現(xiàn)在記下這個(gè)文件的位置和地址，然后直接點(diǎn)“UnHooked ALL”，接下來，去找文件刪除吧。
逼近頂峰：Inline Hook
世界上最荒謬的事情是什么？是順著被人故意弄亂方向的路牌，往錯(cuò)誤的方向走了好遠(yuǎn)都沒察覺到有問題？還是被朋友惡作劇的將男女洗手間的標(biāo)識(shí)換了位置？如果有天去造訪寺院，卻發(fā)現(xiàn)里面居然是清一色的道士在念經(jīng)，你一定會(huì)驚呼，這簡直太荒謬了！
在狂熱的Rootkit領(lǐng)域里，類似的荒謬正在散布開來，那就是高級(jí)的Hook形式——Inline Hook。
在最初的運(yùn)作流程里，所有被設(shè)置了掛鉤的函數(shù)操作，最終還是要回到原始功能模塊內(nèi)處理的，畢竟第三方程序作者不是Windows系統(tǒng)編寫者，為了保證系統(tǒng)的正常運(yùn)行，最明智的做法當(dāng)然是讓被攔截的相關(guān)函數(shù)請求在經(jīng)過自己編寫的模塊的層層檢測并發(fā)現(xiàn)無害以后，立即將這個(gè)即將進(jìn)行正常工作的請求原封不動(dòng)的送到它該干活的地方去，以便系統(tǒng)完成整個(gè)工作流程，所以大家都在打SSDT等地方的主意，就是為了在這條必經(jīng)之路上插上一腳，力求能絆倒那些看著不順眼的路人。而現(xiàn)在，路上出現(xiàn)會(huì)砍腳的保安了，怎么辦，難道玩不下去了嗎？然而，迎接挑戰(zhàn)正是每個(gè)研究者的興趣所在，于是，荒謬的念頭帶出了可怕的技術(shù)，這就是 Inline Hook。
其實(shí)，Inline Hook早就作為一種高級(jí)的Hook技術(shù)存在了，在用戶層上的一些特殊程序如游戲外掛等，為了獲得最完整可靠的數(shù)據(jù)，它們都不再采用錯(cuò)誤指路牌的方法來將數(shù)據(jù)轉(zhuǎn)移了，因?yàn)檫@樣很可能會(huì)因?yàn)橛|發(fā)程序編寫者針對(duì)此問題而設(shè)置的處理程序，最終功虧一簣。那么，怎么樣才能讓這個(gè)處理程序不能達(dá)到觸發(fā)條件呢？那就是千萬別去鉤這個(gè)程序，但是如果不鉤住程序，又該如何取得相關(guān)數(shù)據(jù)呢？在這樣的思考模式下，一種新的鉤子技術(shù)誕生了：它雖然也在玩鉤子，但是它卻不是來鉤目標(biāo)程序的，而是將系統(tǒng)里相應(yīng)的API函數(shù)給虜了去，由于任何普通程序作者對(duì)系統(tǒng)API都是絕對(duì)信任的，于是，當(dāng)他們的程序請求調(diào)用相關(guān)API并將參數(shù)一同發(fā)送過去時(shí)，由于提供這個(gè)API的相應(yīng)模塊被鉤住了，它的“先知”——布施鉤子者就搶先一步得到了數(shù)據(jù)內(nèi)容，接下來就得看作者的編程功底來決定程序的生死了，因?yàn)樽髡卟⒉荒茏约簩懗鱿鄳?yīng)的系統(tǒng)函數(shù)，他就必須得設(shè)法將數(shù)據(jù)送回原函數(shù)執(zhí)行模塊里去，這一步稍有差錯(cuò)，就會(huì)導(dǎo)致調(diào)用這個(gè)API的程序崩潰退出。
正因如此，Inline Hook是一種相對(duì)一般Hook而言更復(fù)雜的技術(shù)，除非作者有較深的編程功底和對(duì)系統(tǒng)的了解，否則冒冒失失就大量使用這個(gè)技術(shù)是很容易出問題的，不僅受害者不好過，攻擊者也無法取得他所需數(shù)據(jù)，得不償失。
既然在用戶層（Ring 3）上使用Inline Hook都要如此注意，那么在Rootkit的世界里有沒有人吃螃蟹呢？答案是一定的，當(dāng)鉤住SSDT和Shadow SSDT的途徑都被堵死以后，Rootkit技術(shù)終于向Inline Hook邁出了一步。
設(shè)想一下，當(dāng)所有檢測工具都在虎視眈眈SSDT這個(gè)關(guān)口時(shí)，某個(gè)Rootkit早已用自己的函數(shù)把系統(tǒng)內(nèi)核里的敏感函數(shù)給替換了，當(dāng)用戶層的函數(shù)操作請求通過正常的SSDT找到相應(yīng)內(nèi)核態(tài)函數(shù)的執(zhí)行主體時(shí)，卻不知道這個(gè)執(zhí)行主體早已被Rootkit冒名頂替了，那么情形會(huì)是怎么樣的呢？雖然所有檢測工具都報(bào)告情況正常，但是機(jī)器內(nèi)其實(shí)早已被Rootkit安家，如果這個(gè)Rootkit預(yù)置了在某個(gè)時(shí)刻進(jìn)行破壞行為的邏輯，那么用戶直到系統(tǒng)出問題的那一刻，都還不知道究竟發(fā)生了什么事情！
位于Ring 0的Inline Hook是十分隱蔽的，除非研究者對(duì)系統(tǒng)了解較深，否則他想破了頭也不能找出原因所在，更別提連殺個(gè)進(jìn)程的概念都很迷茫的普通用戶了。但是使用 Inline Hook是必須付出代價(jià)的，由于內(nèi)核的復(fù)雜性，尤其因?yàn)槲挥谶@一層的函數(shù)是所有程序都必須頻繁調(diào)用的，很多時(shí)候如果設(shè)鉤者沒考慮周全，導(dǎo)致某個(gè)已經(jīng) Inline Hook的函數(shù)被意外的直接調(diào)用，就會(huì)導(dǎo)致嚴(yán)重后果。所以，使用Inline Hook的Rootkit能否正常穩(wěn)定的工作，是與作者的水平連接得十分緊密的，一個(gè)不成熟的用戶層Inline Hook程序大不了就是跟著它要監(jiān)控的程序一起引發(fā)內(nèi)存錯(cuò)誤導(dǎo)致非法操作異常退出，僅此而已，但是到了系統(tǒng)核心層，這里可沒有任何錯(cuò)誤檢測模塊來保證你的程序在做出會(huì)導(dǎo)致內(nèi)核崩潰的事情之前就趕緊將它終止——這已經(jīng)是最底層了，一個(gè)錯(cuò)誤的內(nèi)存讀寫都會(huì)直接引發(fā)內(nèi)核級(jí)別的崩潰，即我們俗稱的“藍(lán)屏死機(jī)” （BSoD，Blue Screen of Dealth）。于是，不成熟的Inline Hook Rootkit的代價(jià)就是系統(tǒng)變得及其不穩(wěn)定，在用戶看來，電腦表現(xiàn)出來的癥狀就是莫名其妙的非常容易藍(lán)屏，這就是技術(shù)不成熟的Rootkit導(dǎo)致的后果，只不過，這個(gè)代價(jià)是由受害的用戶來承擔(dān)的。
不過，目前能流行開來的Inline Hook Rootkit，基本上都是已經(jīng)在開發(fā)者的機(jī)器上經(jīng)歷了無數(shù)次藍(lán)屏考驗(yàn)后才出場的，所以通常情況下，用戶并不會(huì)因?yàn)檫@些Rootkit的存在而頻頻藍(lán)屏，并且，它已經(jīng)成為當(dāng)前Rootkit的主流技術(shù)。
對(duì)付Inline Hook，無論是狙劍、RKU還是Wsyscheck都可以做到，以狙劍為例，點(diǎn)擊程序主界面的“擴(kuò)展功能”，然后點(diǎn)擊“SSDT檢查”，你會(huì)突然有眼花繚亂的感覺，所以請點(diǎn)擊右鍵——“篩選可疑項(xiàng)”，讓它僅僅把異常部分顯示出來（注意那個(gè)SnipeSword.sys，它是狙劍自身的驅(qū)動(dòng)，不要弄錯(cuò)了），如果系統(tǒng)存在異常，“HOOK類型”里會(huì)列出相關(guān)說明，如HOOK、Inline-Hook等，首先可以嘗試右鍵選擇“恢復(fù)所有HOOK”，然后刷新一次，如果仍然列出異常項(xiàng)目，就得在相應(yīng)的項(xiàng)目列上點(diǎn)擊右鍵選擇“恢復(fù)選定的Inline-HOOK”了。
緊緊纏繞的寄生藤：FSD Hook
隨著RK與ARK的斗爭進(jìn)展，SSDT Hook（包括Shadow Hook）的道路被清理了，Inline Hook也被揪出來清理了，但是一些用戶驚訝的發(fā)現(xiàn)，他們?nèi)匀粺o法刪除這些已經(jīng)暴露在眼皮底下的文件，這是為什么？
在解說這個(gè)問題之前，我們先來了解一些概念。為了讓用戶敲打鍵盤、點(diǎn)擊鼠標(biāo)、插入U(xiǎn)盤等就能直接進(jìn)入計(jì)算機(jī)的世界，操作系統(tǒng)在幕后是做了相當(dāng)多的工作的，這些在底層運(yùn)作的功能層層匯聚，最終建立出一個(gè)可用的操作平臺(tái)，其中，負(fù)責(zé)管理磁盤數(shù)據(jù)和文件讀寫的部分被稱為“文件系統(tǒng)”（File System，F(xiàn)S），其中，Windows系列操作系統(tǒng)是采用IOS（Input/Output Supervisor，輸入輸出管理程序）技術(shù)進(jìn)行文件系統(tǒng)管理的。它接管所有的存儲(chǔ)設(shè)備，如硬盤、可移動(dòng)式磁盤、光驅(qū)等。
IOS是一種層次結(jié)構(gòu)的管理方案，展現(xiàn)在用戶層上的是各種應(yīng)用程序的讀寫操作，其下一層緊接著的是被稱為“可安裝文件系統(tǒng)”（Installable File System，IFS）的接口層，這一層是以下各層的最終匯聚，通俗點(diǎn)說，也就是我們在屏幕上看到磁盤盤符、光驅(qū)盤符、U盤盤符、網(wǎng)絡(luò)磁盤映射盤符等圖標(biāo)并對(duì)它們進(jìn)行操作的由來。繼IFS以后，就是各種文件系統(tǒng)驅(qū)動(dòng)所在的層，即“FSD”（File System Driver，文件系統(tǒng)驅(qū)動(dòng)），這一層直接與IOS連接，用于接受并處理屬于自己任務(wù)分派內(nèi)的數(shù)據(jù)；FSD下一層直達(dá)IOS，而到了IOS的下一層，數(shù)據(jù)就開始往硬件化發(fā)展了。
而這次Rootkit的目標(biāo)，就是到達(dá)IOS之前的最后一層：FSD。
FSD在Windows系統(tǒng)中屬于開放給編程人員可接觸到的最深入的一塊區(qū)域（再往下就是操作系統(tǒng)自身提供的驅(qū)動(dòng)和硬件廠商的事情了），所以，這一層的權(quán)限是很高的，控制了這個(gè)層次，開發(fā)者就能掌握到最多最全面的文件讀寫操作控制，于是，當(dāng)所有的道路都被Anti-Rootkit工具阻撓后， Rootkit作者開始反抗，方法是阻止他們的工具將揪出來的Rootkit直接殲滅。
FSD并非絕對(duì)禁地，在這之前，反病毒廠商和磁盤數(shù)據(jù)加密廠商早就在這一層里專研了，一部分人致力于編寫自己的FSD，而更多的人，是通過編寫FSD Filter Driver（文件系統(tǒng)驅(qū)動(dòng)過濾器）來達(dá)到目的，以便從中析出它們敏感的數(shù)據(jù)來進(jìn)行其他工作，而Filter驅(qū)動(dòng)的一個(gè)要點(diǎn)就是鉤住FSD，即“FSD Hook”。當(dāng)FSD被你掌握后，你就可以通過操縱它的數(shù)據(jù)來控制別人的文件讀寫請求，對(duì)于Rootkit來說，它們可以將一些敏感文件如自身驅(qū)動(dòng)程序文件、用戶層相關(guān)文件等設(shè)置為除了它們自己以外的程序都無法對(duì)其進(jìn)行讀寫的效果，到了用戶層，直接反映出來的就是無法對(duì)其進(jìn)行編輯、改名和刪除。
用了這個(gè)技術(shù)，Rootkit作者們又可以偷笑了，因?yàn)榧词褂脩粲酶鞣N手段找到了它并將其進(jìn)程終止，他也無法操作那些被保護(hù)起來的文件。
只是，鉤子始終是鉤子，總會(huì)有人去脫鉤的，在克制FSD Hook技術(shù)的ARK工具出現(xiàn)后，一部分人面對(duì)著十分難以操作的FSD而放棄了，因?yàn)榈搅诉@一層已經(jīng)非常容易導(dǎo)致系統(tǒng)不穩(wěn)定了。
而一些人，仍然走了下去。
如何清理這個(gè)類型的Rootkit呢？以最容易操作的Wsyscheck為例，首先運(yùn)行Wsyscheck（你會(huì)發(fā)現(xiàn)一個(gè)有趣現(xiàn)象：IceSword無法檢測到Wsyscheck的Hook，因?yàn)樗玫募夹g(shù)是Inline Hook和FSD Hook），點(diǎn)擊進(jìn)入“內(nèi)核檢查”，選中“FSD檢查”，留意“代碼異常”項(xiàng)里是否有標(biāo)注為“Yes”的項(xiàng)，如果有，請?jiān)诮缑胬镉益I點(diǎn)擊，并選擇“恢復(fù)所有函數(shù)”。Wsyscheck的進(jìn)程列表并非使用IceSword一類的邏輯，所以如果你看到存在紅色的列表也不要太過于緊張，它只是表示這個(gè)程序是沒有系統(tǒng)簽名驗(yàn)證、且類型特殊（如服務(wù)、加載驅(qū)動(dòng)等）的應(yīng)用程序而已，并非是IceSword這樣的“壞人標(biāo)識(shí)”。
產(chǎn)于極端的終極技術(shù)：FSD Inline Hook
Rootkit到了FSD Hook這一層，對(duì)系統(tǒng)造成的影響已經(jīng)相當(dāng)危險(xiǎn)了，然而，由于出現(xiàn)了對(duì)抗的工具觸動(dòng)了某些人的利益，終于，一個(gè)著名的流氓軟件吃了這只大家都會(huì)因?yàn)榱夹牟话捕蝗ビ|碰的螃蟹——FSD Inline Hook。
在及其重要敏感的FSD環(huán)境下放鉤子本身就是一件要求很高的事情，而用自己的函數(shù)去替代這個(gè)雷區(qū)的系統(tǒng)函數(shù)，更是被很多人認(rèn)為是嚴(yán)禁操作的事情，而現(xiàn)在，真的有人帶頭違反了，以后的局勢又將如何呢？
所以，將CNNIC列為當(dāng)前流氓軟件作者的所有研究目標(biāo)都不過分，因?yàn)镃NNIC身上，就具備了多種高級(jí)技術(shù)，只可惜，全都沒有用于正道。
Inline Hook的概念我們在前面已經(jīng)說過了，現(xiàn)在主要說說這個(gè)Rootkit的行為以及后果。
也許是CNNIC的開發(fā)者對(duì)于自家產(chǎn)品頻頻被刪除而惱怒了吧，這次最新發(fā)布的程序中，F(xiàn)SD Inline Hook終于出現(xiàn)了，它直接將操作系統(tǒng)廠商編寫的相關(guān)功能使用自己的函數(shù)去取代了，而搞過FSD開發(fā)的人都知道，這一層的功能函數(shù)對(duì)硬件平臺(tái)、系統(tǒng)版本是具有高度依賴性的，每個(gè)操作系統(tǒng)采用的函數(shù)都會(huì)有些許差異，但是操作系統(tǒng)廠商并不是制作通用的FSD方案，更何況，這個(gè)標(biāo)準(zhǔn)就是他們自己提出來的，所以這些變動(dòng)對(duì)他們而言都是無傷大雅的，但是對(duì)于第三方廠商來說，他們?nèi)鄙俦匾拈_發(fā)文檔（微軟并未公布任何涉及FSD Inline Hook技術(shù)文檔，也不鼓勵(lì)開發(fā)者這樣做）和齊全的硬件測試平臺(tái)，所以，在不齊全的操作系統(tǒng)環(huán)境和硬件配置下實(shí)現(xiàn)的技術(shù)，必然很容易就導(dǎo)致受害用戶直接欣賞到賞心悅目的藍(lán)屏。
CNNIC必然清楚這點(diǎn)，但是，他們什么也不顧了。而且，CNNIC的技術(shù)水平果然也沒達(dá)到穩(wěn)定的水平，在被CNNIC安家的系統(tǒng)里，用戶只要運(yùn)行 IceSword檢測，就會(huì)直接導(dǎo)致藍(lán)屏，這是因?yàn)樗鼈兌纪瑫r(shí)鉤住了一個(gè)底層函數(shù)，但是下鉤的位置存在些許偏差，例如，一個(gè)鉤住了頭部，一個(gè)鉤住了屁股，于是內(nèi)核受不了這很黃很暴力的行為，而直接崩潰了。
但是，畢竟已經(jīng)有人起了頭。以后的Rootkit世界將會(huì)變成什么樣子，誰也不知道。
要消滅CNNIC以及采用FSD Inline Hook技術(shù)的Rootkit，首選應(yīng)該是360安全衛(wèi)士，但是如果出現(xiàn)了360安全衛(wèi)士也未加入識(shí)別的Rootkit，用戶就得使用“狙劍”了，解決方法與前面提及的大同小異，只需要對(duì)其“脫鉤”就可以了，關(guān)鍵在于，用戶還得留意Rootkit的用戶層程序是否也使用Hook，如線程注入等。
RK 多了，ARK也多了，這是好事還是壞事呢？答案自然是后者，無論是RK還是ARK，它們都必須進(jìn)行同一個(gè)行為，就是進(jìn)入系統(tǒng)內(nèi)核層次并達(dá)到目的，于是不兼容現(xiàn)象往往會(huì)發(fā)生在幾個(gè)ARK之間，例如，在運(yùn)行了狙劍后，Wsyscheck經(jīng)常會(huì)直接報(bào)錯(cuò)退出，而如果用戶在開啟了Wsyscheck的情況下運(yùn)行 IceSword，他將會(huì)有很大幾率看到那藍(lán)底白字的屏幕。
三. 結(jié)語
雖然到處都在提倡和諧網(wǎng)絡(luò)的普及，但是，“健康上網(wǎng)”僅僅是指代那些黃賭毒而已嗎？在利益面前，開發(fā)者的正義感越發(fā)渺小起來，我們的網(wǎng)絡(luò)世界，是被瘟神緊緊跟隨著的。技術(shù)的斗爭越發(fā)激烈，但是用戶的電腦知識(shí)是不會(huì)跟著時(shí)代發(fā)展而自動(dòng)填充的，最終，大眾上網(wǎng)的人民成了這一切技術(shù)較量的受害者。
這個(gè)荒謬的發(fā)展方向，何時(shí)才能休止呢？