這個(gè)驅(qū)動(dòng)本來(lái)準(zhǔn)備端午節(jié)搞的,但后來(lái)端午節(jié)去了躺北京玩了幾天,也就擱置了...最近連續(xù)花了4個(gè)晚上,大致把它搞的差不多了,有些收獲...初學(xué)window驅(qū)動(dòng),水平很菜,有些東西我也未必清明,加上3環(huán)的代碼還沒(méi)有吃透,期間也沒(méi)有用調(diào)試器跟蹤,全是IDA(F5)靜態(tài)分析的,謬誤在所難免,高手請(qǐng)飄過(guò),希望對(duì)菜鳥學(xué)習(xí)有點(diǎn)幫助.

1.SSDT檢測(cè)

這個(gè)功能有三個(gè)IoControlCode與之對(duì)應(yīng),他們分別是22000fh(拷貝KeServiceDescriptorTable);220007h(拷貝KeServiceDescriptorTable->ServiceTable);22000bh(恢復(fù)一個(gè)ssdt hook),這個(gè)功能目前還不具備檢測(cè)和恢復(fù)inline hook的功能

2.Shadow SSDT檢測(cè)

這個(gè)功能實(shí)現(xiàn)和SSDT差不多,都是從KeSystemServiceDescriptorTableShadow入手,不過(guò)3環(huán)需要為每個(gè)平臺(tái)配置一張函數(shù)名表(ssdt可以不配置函數(shù)名表,可以從ntdll.dll中收集),詳細(xì)文章可以參見(jiàn)zhuwg兄弟寫的<<shadow ssdt學(xué)習(xí)筆記>>一文

3.進(jìn)程

3.1 進(jìn)程檢測(cè)

IoControlCode是22001Bh,在檢測(cè)之前會(huì)設(shè)置檢測(cè)方式,然后根據(jù)檢測(cè)方式進(jìn)行檢測(cè).這個(gè)功能主要由irp_mj_device_control_dispatch_function函數(shù)的is_22001Bh_list_process分支完成,這里集成了4種檢測(cè)方法,大致如下:

3.1.1 基于PspCidTalbe的檢測(cè),這里rku對(duì)句柄表做了解析,對(duì)每個(gè)Object判定是不是EPROCESS,是則插入到輸出列表(icesword也有這中檢測(cè),不過(guò)在1.22中沒(méi)有解析句柄表,而是用ExEnumHandleTable搞定這些) 詳細(xì)代碼見(jiàn)list_process_in_2k_by_handle_table/list_process_in_not_2k_by_handle_table函數(shù)
3.2.1 基于KiWaitListHead/KiWaitOutListHead的檢測(cè),這個(gè)檢測(cè)方法很簡(jiǎn)單,關(guān)鍵是KiWaitListHead/KiWaitOutListHead兩個(gè)鏈表的獲取, 詳細(xì)代碼見(jiàn)list_process_by_list_head函數(shù)
3.3.1 如果是xp系統(tǒng)則還會(huì)采用*淫**蕩*的內(nèi)存暴力搜索進(jìn)程進(jìn)行檢測(cè),這段代碼看debugman的yykingking發(fā)過(guò), 詳細(xì)代碼在list_process_by_search_memory_in_xp函數(shù)
3.4.1 rku還會(huì)inline hook SwapContext函數(shù),在這個(gè)函數(shù)里會(huì)記錄當(dāng)前的活動(dòng)進(jìn)程情況,經(jīng)過(guò)上面三種方法的洗禮后,對(duì)在SwapContext的記錄里的,但不在輸出列表里的繼續(xù)加入,當(dāng)然是有判定條件的(條件就是EPROCESS不能在ntoskrnl模塊內(nèi),即不為idle進(jìn)程). BTW:這里有個(gè)邏輯我覺(jué)得有問(wèn)題:

.text:000134A7 loc_134A7: ; CODE XREF: irp_mj_device_control_dispatch_function+233j
.text:000134A7 3B 05 34 4E 01 00 cmp eax, g_nCurrentProcessCount
.text:000134AD 7D 5A jge short loc_13509
這個(gè)檢測(cè)方法的代碼就在loc_134A7開(kāi)始位置

上面獲取的只是EPROCESS,要獲取進(jìn)程路徑信息,還需要IoControlCode(220047h)的代碼, 詳細(xì)功能代碼在get_image_path_by_eprocess函數(shù)里,在這個(gè)函數(shù)里,我們可以看到rku先走peb獲取進(jìn)程全路徑,然后對(duì)非2k系統(tǒng)再走一次我們更為熟悉的SectionObject獲取路徑

3.2 殺進(jìn)程 rku提供了兩種殺進(jìn)程的方法

3.2.1 IoControlCode(22001Fh) ZwOpenProcess/ZwTerminateProcess/ZwClose殺進(jìn)程 這種殺法比較的弱
3.2.2 ioControlCode(22004fh) 內(nèi)存清0殺進(jìn)程 具體代碼是kill_process_by_fill_zero函數(shù),這個(gè)代碼看debugman的yykingking也發(fā)過(guò)

3.3 Dump All Process Memory

IoControlCode是22008bh, 沒(méi)什么可說(shuō)的, 詳細(xì)代碼在dump_all_process_memory函數(shù)

3.4 Dump Seleted

這個(gè)就是拷貝主程序的內(nèi)存鏡象, IoControlCode是220083h, 先獲取文件大小(對(duì)xp及其以上系統(tǒng),通過(guò)EPROCESS->SectionObject->segmentObject->SizeOfSegment獲取主程序內(nèi)存鏡象大小,對(duì)2k系統(tǒng),由于手頭缺乏資料,那段代碼什么意思不知道,詳細(xì)代碼在get_main_file_size_by_eprocess函數(shù)), 然后輸出緩沖區(qū)足夠大就進(jìn)入dump_selected函數(shù)拷貝內(nèi)存

4.內(nèi)核模塊和Stealth Code檢測(cè)

IoControlCode是0x220023h,在檢測(cè)之前也會(huì)設(shè)置檢測(cè)方式,然后根據(jù)檢測(cè)方式進(jìn)行檢測(cè).這個(gè)功能主要由list_kernel_module函數(shù)完成,這個(gè)函數(shù)里面集成了很多檢測(cè)方法,很多方法都比較*淫**蕩*,大致的檢測(cè)方法有: 

4.1 用IoDriverObjectType指向的OBJECT_TYPE.TypeList鏈表檢測(cè),遍歷這個(gè)鏈表中的每一項(xiàng),并會(huì)取每個(gè)DriverObject上的DeviceObject,并向上掃描這個(gè)設(shè)備所在的設(shè)備棧(注意這里沒(méi)有向下掃描),嘗試發(fā)現(xiàn)其它的DriverObject 詳細(xì)代碼見(jiàn)list_module_by_IoDriverObjectType函數(shù)
4.2 用IoDeviceObjectType指向的OBJECT_TYPE.TypeList鏈表檢測(cè),遍歷這個(gè)鏈表中的每一個(gè)設(shè)備,并也會(huì)向上掃描這個(gè)設(shè)備所在的設(shè)備棧(注意這里沒(méi)有向下掃描),嘗試發(fā)現(xiàn)其它的DriverObject 詳細(xì)代碼見(jiàn)list_module_by_IoDeviceObjectType
4.3 用目錄對(duì)象樹(ZwOpenDirectoryObject("http://"))檢測(cè),遍歷這棵樹,對(duì)葉子節(jié)點(diǎn)(具體對(duì)象)看其OBJECT_HEADER.Type字段是否指向IoDriverObjectType/IoDeviceObjectType,如果是的話,則會(huì)采用4.1/4.2相似的措施;對(duì)目錄對(duì)象子樹則遞歸處理之(內(nèi)核堆?？臻g太小,遞歸搞始終給人一種不安全感,看SnipeSword里面處理注冊(cè)表部分也大量遞歸,比較汗) 詳細(xì)代碼見(jiàn)list_module_by_OpenDirectoryObject函數(shù)
4.4 用DriverSection(PsLoadedModuleList鏈表)檢測(cè),這個(gè)方法大家都比較熟悉, 詳細(xì)代碼見(jiàn)list_module_by_DriverSection函數(shù)

經(jīng)過(guò)上面4個(gè)方法,DriverObject就獲取完畢了,他們對(duì)應(yīng)的都是有詳細(xì)信息的內(nèi)核模塊(這項(xiàng)檢測(cè)初步給人的感覺(jué)是比icesword可靠些,icesword則是先嘗試恢復(fù)NtQuerySystemInformation,設(shè)置KernelMode,然后調(diào)用NtQuerySystemInformation獲取內(nèi)核模塊信息),下面的檢測(cè)主要是對(duì)一些零星的能執(zhí)行代碼的內(nèi)存塊進(jìn)行檢測(cè)(Stealth Code)

4.5 用上面幾種方法已經(jīng)找到了一些DriverObject,這里就對(duì)這些DriverObject下手,檢測(cè)這些DriverObject的DriverStartIo/MajorFunction是否被hook,如果被hook且新地址不在我們已經(jīng)找到的模塊里,則說(shuō)明是那種分內(nèi)存,寫代碼似的hook,記錄這塊內(nèi)存信息 詳細(xì)代碼見(jiàn)list_module_by_DriverStartIo_and_MajorFunction函數(shù)
4.6 暴力搜索內(nèi)存, 找到PE頭部,并判定OptionalHeader.Subsystem是否是Native 詳細(xì)代碼見(jiàn)list_module_by_scan_memory函數(shù)
4.7 利用句柄表檢測(cè),這個(gè)的具體原理我未能理解, 詳細(xì)代碼在list_module_use_suspicious_thread_by_handle_table_in_not_2k/list_module_use_suspicious_thread_by_handle_table_in_2k這兩個(gè)函數(shù),感覺(jué)跟內(nèi)核模塊檢測(cè)無(wú)關(guān)......知道的請(qǐng)說(shuō)一聲
4.8 rku會(huì)inline hook三個(gè)調(diào)用頻度很高的函數(shù)(ExAllocatePool/ExAllocatePoolWithTag/KeDelayExecutionThread),在這三個(gè)函數(shù)里會(huì)記錄它們的返回地址,并利用這些地址來(lái)檢測(cè)一些模塊,如果返回地址不在某具體模塊范界則會(huì)記錄其內(nèi)存信息 詳細(xì)代碼見(jiàn)list_module_by_return_address函數(shù)
4.9 檢測(cè)KiSystemService/KiFastCallEntry是否在某具體模塊范界,如果不在也記錄其內(nèi)存信息

到這里檢測(cè)就完成了,上面的檢測(cè)方法太多,有些檢測(cè)獲取的信息不足,rku會(huì)進(jìn)行一些額外的修正處理,這些代碼都在list_kernel_module的結(jié)尾部分,詳細(xì)請(qǐng)參見(jiàn)源碼,我都做了一些注釋

5.File檢測(cè)

由于目前一直在用IDA反,并沒(méi)有使用調(diào)試器,主程序目前還只反了一點(diǎn),這個(gè)部分具體做什么的,我不太清楚,不過(guò)在驅(qū)動(dòng)里看到一個(gè)IoControlCode(2200A7)是在做扇區(qū)級(jí)別的操作......

6.Code Hooks檢測(cè)

在驅(qū)動(dòng)里并沒(méi)有看到分析code hooks的代碼, 只看到一些拷貝內(nèi)存到3環(huán)的功能函數(shù),把一些系統(tǒng)關(guān)鍵手工load展開(kāi)后,進(jìn)行內(nèi)存對(duì)照比較就可以搞定這個(gè)了,當(dāng)然這個(gè)里面還具備KiSystemService/KiFastCallEntry hook的檢測(cè)和恢復(fù)代碼,詳細(xì)可以看IDB文件

7.rku的進(jìn)程保護(hù)

7.1 ssdt上的保護(hù),在ssdt上對(duì)三個(gè)函數(shù)(NtOpenProcess, NtOpenThread, NtDuplicateObject)進(jìn)行了inline hook
NtOpenProcess 防止打開(kāi)rku進(jìn)程
NtOpenThread 防止打開(kāi)rku的線程
NtDuplicateObject 防止復(fù)制rku進(jìn)程的句柄

7.2 shadow ssdt上的保護(hù),在shadow上對(duì)四個(gè)函數(shù)(NtUserQueryWindow, NtUserFindWindowEx, NtUserWindowFromPoint, NtUserNotifyIMEStatus)進(jìn)行了inline hook,防止其它程序通過(guò)FindWindow,WindowFromPoint等函數(shù)來(lái)枚舉rku的窗口,你可以看到spy++對(duì)rku已經(jīng)失效

8.逆向這個(gè)的過(guò)程中,參考了網(wǎng)上很多大牛的文章,
IceSword&Rootkit Unhooker驅(qū)動(dòng)簡(jiǎn)析
zhuwg <<shadow ssdt學(xué)習(xí)筆記>>
prince 翻譯的<<偵測(cè)隱藏進(jìn)程的強(qiáng)文>>
yykingking 發(fā)在debugman上的兩個(gè)代碼片段
還有些文章,無(wú)法一一列舉,再次一并表示感謝

大致就是這樣了.
linxer 2008-06-19 于哈爾濱