tqsheng

這個驅動本來準備端午節搞的,但后來端午節去了躺北京玩了幾天,也就擱置了...最近連續花了4個晚上,大致把它搞的差不多了,有些收獲...初學window驅動,水平很菜,有些東西我也未必清明,加上3環的代碼還沒有吃透,期間也沒有用調試器跟蹤,全是IDA(F5)靜態分析的,謬誤在所難免,高手請飄過,希望對菜鳥學習有點幫助.

1.SSDT檢測

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

2.Shadow SSDT檢測

這個功能實現和SSDT差不多,都是從KeSystemServiceDescriptorTableShadow入手,不過3環需要為每個平臺配置一張函數名表(ssdt可以不配置函數名表,可以從ntdll.dll中收集),詳細文章可以參見zhuwg兄弟寫的<<shadow ssdt學習筆記>>一文

3.進程

3.1 進程檢測

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

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

.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
這個檢測方法的代碼就在loc_134A7開始位置

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

3.2 殺進程 rku提供了兩種殺進程的方法

3.2.1 IoControlCode(22001Fh) ZwOpenProcess/ZwTerminateProcess/ZwClose殺進程 這種殺法比較的弱
3.2.2 ioControlCode(22004fh) 內存清0殺進程 具體代碼是kill_process_by_fill_zero函數,這個代碼看debugman的yykingking也發過

3.3 Dump All Process Memory

IoControlCode是22008bh, 沒什么可說的, 詳細代碼在dump_all_process_memory函數

3.4 Dump Seleted

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

4.內核模塊和Stealth Code檢測

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

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

經過上面4個方法,DriverObject就獲取完畢了,他們對應的都是有詳細信息的內核模塊(這項檢測初步給人的感覺是比icesword可靠些,icesword則是先嘗試恢復NtQuerySystemInformation,設置KernelMode,然后調用NtQuerySystemInformation獲取內核模塊信息),下面的檢測主要是對一些零星的能執行代碼的內存塊進行檢測(Stealth Code)

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

到這里檢測就完成了,上面的檢測方法太多,有些檢測獲取的信息不足,rku會進行一些額外的修正處理,這些代碼都在list_kernel_module的結尾部分,詳細請參見源碼,我都做了一些注釋

5.File檢測

由于目前一直在用IDA反,并沒有使用調試器,主程序目前還只反了一點,這個部分具體做什么的,我不太清楚,不過在驅動里看到一個IoControlCode(2200A7)是在做扇區級別的操作......

6.Code Hooks檢測

在驅動里并沒有看到分析code hooks的代碼, 只看到一些拷貝內存到3環的功能函數,把一些系統關鍵手工load展開后,進行內存對照比較就可以搞定這個了,當然這個里面還具備KiSystemService/KiFastCallEntry hook的檢測和恢復代碼,詳細可以看IDB文件

7.rku的進程保護

7.1 ssdt上的保護,在ssdt上對三個函數(NtOpenProcess, NtOpenThread, NtDuplicateObject)進行了inline hook
NtOpenProcess 防止打開rku進程
NtOpenThread 防止打開rku的線程
NtDuplicateObject 防止復制rku進程的句柄

7.2 shadow ssdt上的保護,在shadow上對四個函數(NtUserQueryWindow, NtUserFindWindowEx, NtUserWindowFromPoint, NtUserNotifyIMEStatus)進行了inline hook,防止其它程序通過FindWindow,WindowFromPoint等函數來枚舉rku的窗口,你可以看到spy++對rku已經失效

8.逆向這個的過程中,參考了網上很多大牛的文章,
IceSword&Rootkit Unhooker驅動簡析
zhuwg <<shadow ssdt學習筆記>>
prince 翻譯的<<偵測隱藏進程的強文>>
yykingking 發在debugman上的兩個代碼片段
還有些文章,無法一一列舉,再次一并表示感謝

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