from:http://www.debugman.com/read.php?tid=646

現(xiàn)在RK（rootkit）和ARK(anti- rootkit)的斗爭已經進行了很久，在印象中最早出來的ARK工具是冰刃(IceSword)，從冰刃開始出來到現(xiàn)在RK和ARK的斗爭一直在繼續(xù)， 目前冰刃還是在流行當中，自己感覺也正是冰刃的出來才帶動了當前流行的RK和ARK的斗爭 呵呵，現(xiàn)在很多病毒木馬已經廣泛的帶有驅動,使用一些RK的技術和方法使自己更底層些更強大些，當前流行的ARK工具主要包括：隱藏進程檢測，內核驅動檢 測，SSDT檢測，代碼HOOK檢測，注冊表隱藏的檢測，隱藏文件的檢測等一些功能的，下面談談自己對一些功能的簡單愚見 嘻嘻。

關于進程檢測：其實最早在R3下隱藏進程的方法已經很早開始流行起來被用到各種軟件上來，在R0下如斷ActiveProcessLinks鏈，擦掉句柄表等等，一步步的發(fā)展?jié)u漸的更強大起來一些技巧和方法開始出來和流行起來，如FUTO，phide_ex等。。。。。。

檢 測隱藏進程的方法可以把一些現(xiàn)在流行的方法組合起來用，首先可以通過進程的EPROCESS結構中的進程活動鏈表ActiveProcessLinks來 進行掃描一邊，可以通過進程句柄表的枚舉通過EPROCESS的HANDLE_TABLE，HANDLE_TABLE結構中的 HandleTableLis鏈表來掃描一邊來獲得一些EPROCESS，可以通過定位PsLookupProcessByProcessId代碼中的 PspCidTable鏈表掃描一邊獲得一些EPROCESS，PspCidTable在各系統(tǒng)中枚舉是不太一樣的，也可以通過先找出 KiWaitInListHead，KiWaitOutListHead和KiDispatcherReadyListHead這些鏈表然后對這些鏈表掃 描獲得一些EPROCESS，以上具體的實現(xiàn)代碼可以GOOGLE之網上實現(xiàn)的代碼已經很多了，再者也可以找到內核中的線程切換SwapContext函 數(shù)進行HOOK下的，在自己實現(xiàn)的SwapContext函數(shù)根據(jù)線程的偏移量找出進程的EPROCESS結構，把上面獲得的所有EPROCESS匯集起 來還需要判斷下當前進程是否是真正的活著的：）可以通過EPROCESS里的標志位Flags（如XP 下0x248）一些標志判斷下的，還要注意下對上面這些鏈表匯集起來是會有重復的進程的，在你自己的匯集函數(shù)中根據(jù)EPROCESS判斷下的 廢話了，感覺實現(xiàn)了上面的一些方法對付一般的隱藏進程已經足夠了的，但厲害的RK還是有的，現(xiàn)在存在可以逃過這些方法的RK的，在進程EPROCESS的 結構里偏移0x1f8（XP SP2下）有個struct? MMSUPPORT Vm結構：

struct _MMSUPPORT
{
/* off 0x00000000 */? ? union LARGE_INTEGER? ? LastTrimTime;
/* off 0x00000008 */? ? struct? MMSUPPORT_FLAGS? ? Flags;
/* off 0x0000000C */? ? unsigned long? ? PageFaultCount;
/* off 0x00000010 */? ? unsigned long? ? PeakWorkingSetSize;
/* off 0x00000014 */? ? unsigned long? ? WorkingSetSize;
/* off 0x00000018 */? ? unsigned long? ? MinimumWorkingSetSize;
/* off 0x0000001C */? ? unsigned long? ? MaximumWorkingSetSize;
/* off 0x00000020 */? ? struct _MMWSL*? ? VmWorkingSetList;
/* off 0x00000024 */? ? struct LIST_ENTRY? ? WorkingSetExpansionLinks;
/* off 0x0000002C */? ? unsigned long? ? Claim;
/* off 0x00000030 */? ? unsigned long? ? NextEstimationSlot;
/* off 0x00000034 */? ? unsigned long? ? NextAgingSlot;
/* off 0x00000038 */? ? unsigned long? ? EstimatedAvailable;
/* off 0x0000003C */? ? unsigned long? ? GrowthSinceLastEstimate;
};

在這個結構里+0x24有個? ? WorkingSetExpansionLinks他也是個LIST_ENTRY鏈表的，遍例下他可以獲得進程的EPROCESS的，如
PEPROCESS eprocess, eprocess2
eprocess =PsGetCurrentProcess();
lp=(PLIST_ENTRY)(*(PVOID )((PUCHAR)eprocess+0x1f8+0x24+4));
cur =lp->Flink;
for(;cur!=lp;cur=cur->Flink)
{
eprocess2=(PEPROCESS)((ULONG)cur-0x1f8-0x24);
PVOID session= (PVOID)(*(PULONG)((PCHAR) eprocess2+ 0x170));
if(MmIsAddressValid(session)){
AddProcess(eprocess2);
}
}

再 者在進程EPROCESS的結構里偏移0x0b4（XP SP2下）存在個struct _LIST_ENTRY? ? SessionProcessLinks結構，他也是個鏈表的 ：）通過遍例他也可以的獲得一些EPROCESS。還有個地方可以的 呵呵 在每個線程對象里（ETHREAD）偏移0x34里有個struct _KAPC_STATE ApcState 結構的在_KAPC_STATE結構里偏移0x10，再者也可以通過遍例內存來查找隱藏進程，從內存MmSystemRangeStart開始到 System進程的EPROCESS地址就可以了主要是判斷這個地址是否是個有效的進程，方法挺多的如判斷下是否是進程對象這個地址如果是 EPROCESS看看PID，ThreadListHead，ReadyListHead是否正確有效的等等，很多方法的應該組合起來判斷下保證肯定是進 程就可以了，還可以通過HOOK一些函數(shù)的如KeUpdateRunTime，KeDispatchInterrupt等來檢測隱藏進程，還可以設置下 PsSetCreateProcessNotifyRoutine在每次進程創(chuàng)建的時候對線程插入個APC的來進行統(tǒng)計檢測的，其實我覺得對于檢測隱藏進 程的方法技巧還有很多，偉大的WINDOWS還需要我們挖掘呀。進程的結束可以通過調用ZwTerminateProcess或者調用未公開的 PspTerminateProcess函數(shù)的，關于這個函數(shù)在網上已經很廣泛了，可以通過遍例進程的每個線程調用 PspTerminateThreadByPointer的結束每個線程的，這些未公開的函數(shù)都需要事先的查找和定位的，還可以使用RKU （RkUnhooker）的內存清零大法的切換到該進程然后對該進程內存清零RtlZeroMemory，再者也可以對該進程的每個線程插入APC來結束 進程的，最后如果你有時間你也可以通過觀看2K的代碼自己來實現(xiàn)進程的結束。

內核驅動檢測首先你可以通過 ZwQuerySystemInformation的SystemModuleInformation功能號來枚舉內核驅動的，然后可以通過打開目錄對 象,進行枚舉代碼就略了GOOGLE之吧，也可以通過枚舉IoDriverObjectType和IoDeviceObjectType對象類型進行查找 枚舉順便把他們的DeviceObject和AttachedDevice等也枚舉下吧，接著可以通過查找PsLoadedModuleList對該鏈進 行下枚舉的，可以對這個目錄對象再搜索一邊的”\\Driver”。通過對上面這些方法的枚舉可以查找到很多驅動對象了，相信現(xiàn)在你的驅動對象鏈表已經夠 多了 嘿嘿，夠累吧，接下來，你可以對上面你已經查找到的驅動對象的0x38偏移MajorFunction查找一邊看看他的地址是否在已知的驅動地址范圍內， 如不在你知道該怎么辦的，再對MajorFunction里的每個例程地址找一邊的從0到28也看看他們的地址是否在已知的驅動地址范圍內，最后再說一種 的方法的，也可以像進程那樣內存枚舉的，像進程那樣從MmSystemRangeStart開始枚舉吧，判斷下是否是PE文件有沒有那幾個關鍵PE特征 的，如MZ，PE等，看看是否存在PE文件頭是否有效，看看這個地址是否已經是你檢測出來的驅動地址的，避免重復的，看看你所檢測出來的所有驅動對象的 MajorFunction[X]和DriverStartIo是否有在這個地址，如果有并且這個地址你先前沒有檢測出來沒有重復的他很有可能是個未知的 驅動的，其實和進程內存查找一樣的，關鍵是判斷的，需要判斷對的，肯定他是某個對象的然后你就可以把他加如到你自己的某個鏈表里。最后也可以通過對一些關 鍵函數(shù)的HOOK 如ExAllocatePool，ExAllocatePoolWithTag等在自己實現(xiàn)這些函數(shù)里記錄下esp+0x24地址的，對這些地址進行判斷 的來看看這些地址是否包含在某些內核模塊當中當然還需要判斷下他是否就是個PE驅動文件，這種方法就是RKU用到的方法的。驅動就說這些吧。

前面說得太多了，后面說少點吧 嘿嘿。

關于SSDT HOOK的檢測，通過定位ntoskrnl.exe磁盤文件里KeServiceDescriptorTable與內存中的KeServiceDescriptorTable對各個服務函數(shù)進行比較就可以的。代碼網上很多的。

關 于代碼HOOK檢測，我也不想說什么的，可以對內存中ntoskrnl.exe 的導入函數(shù)和導出函數(shù)與磁盤文件中的地址進行比較，也可以通過對ntoskrnl.exe PE文件里的某些節(jié)（section）進行掃描的，再加上對一些關鍵文件的導入函數(shù)和導出函數(shù)進行掃描，加上對某些關鍵驅動（如文件系統(tǒng)驅動）的 MajorFunction里的每個例程進行掃描，再者對IDT，GDT掃描下的。

關于注冊表隱藏的檢測，首先可以用到把一些注冊表相關 的函數(shù)INLINE HOOK的SSDT HOOK的都恢復下再使用的其實所謂的不相關的也需要UNHOOK下的，如badrkdemo 他就HOOK了ObOpenObjectByName函數(shù)組織對注冊表的訪問的 具體的看情況來吧 哈哈，也可以通過對一些未公開的函數(shù)進行使用的CM系列函數(shù)的，再者可以通過分析HIVE文件的來顯示注冊表各個項的，通過分析HIVE文件其實也不是很 難的，了解了HIVE文件結構和HIVE文件的組織的，就可以讀他了，這些資料網上可以找到的，通過讀HIVE文件來給用戶顯示當前注冊表各個項的可以的 但我并不推薦自己改寫系統(tǒng)的HIVE文件的，如提供DELETE MODIFE等功能的我覺得如改的不好，或結構沒有完全清楚的，寫到HIVE文件里是錯誤的，那么當再次啟動時系統(tǒng)讀HIVE文件時就不好過了，自己一點 愚見，如果你夠強大當然是沒有問題的。

關于隱藏文件的檢測，現(xiàn)在流行的隱藏文件的RK很多的，如Unreal.A，AK922等，自己可 以通過在驅動中自己構建IRP包自己發(fā)送給文件驅動的方法的，還有就是先恢復些關鍵函數(shù)的，像注冊表那樣的，恢復INLINE HOOK SSDT HOOK，文件驅動關鍵例程HOOK的，現(xiàn)在流行HOOK內核的完成例程的，HOOK是防不勝防的，還要注意下附加在文件系統(tǒng)上的一些過濾驅動的，還有就 是通過使用DeviceIoControl發(fā)送一些特殊的IoControlCode控制代碼給文件系統(tǒng)的，這需要對文件系統(tǒng)的熟悉的，還有就是自己分析 磁盤文件的對FAT32，NTFS等格式文件系統(tǒng)自己分析來查找文件的，關于自己分析磁盤文件的，網上的信息和資料也是很多的，首先判斷下屬于哪個文件系 統(tǒng)，然后根據(jù)特定的文件系統(tǒng)格式自己分析的就可以的，其實這些方法的關鍵是怎么讀和寫的，讀和寫做到最底層，把讀和寫做好我想他檢測文件功能是強大的。

夠 了，一些ARK的功能說到這就可以了，我希望各位搞RK的和ARK的人看了之后又會作出很多厲害，強大的東西來，希望看了之后會對各位有一點幫助的，希望 可以在當前流行的RK和ARK中會有更新更強大的東西出現(xiàn)的，來激勵我們學習和前進的，引用一位好友的話“現(xiàn)在感覺大部分木馬病毒什么的都是用的老一套東 西的什么SSDT HOOK的。。。。。。，希望可以有些新的技術出現(xiàn)的”，其實現(xiàn)在有些RK是很牛的，其實都是一個目標的 希望技術和知識可以不斷進步的 嘿嘿。一個沒有未來的人:）談談關于RK和ARK未來的發(fā)展 RK 更底層，ARK也更底層，攻和防，RK和ARK的斗爭會繼續(xù)的，RK會出現(xiàn)固化在某個文件里，會在重裝系統(tǒng)后還會存在，會寫到硬件中。。。。。。，ARK 勢必也需要對這些問題關注的。

謝謝各位看完文章的，本人一介小菜知識有限，以上是自己的一點愚見，如有什么錯誤和不足之處，請各位指教。

本文之中的有些知識是朋友和一些牛人給予幫助，謝謝他們的幫助。

作者：single
2007-10-19