Do all in one exe file Under Win32
icelord @ 2006
希望題目沒有語法錯誤。
Exe可執(zhí)行，可以使用系統(tǒng)提供的各種服務，do all in one exe看起來是句廢話。
很早就看過高手寫過的文章，<<腳本的故事>>、<<do all in smd shell>>,今天我也來班門弄斧一把。做后門、木馬，現(xiàn)在的技術(shù)不知道是什么樣的，但是個人認為將他們做到內(nèi)核之中，將更有威力。當然，這也是把雙刃劍。
見過一些rootkit,通常做法是寫驅(qū)動，然后將驅(qū)動包含在exe中，運行時釋放驅(qū)動為一個獨立文件，然后加載驅(qū)動，由驅(qū)動完成Rootkit的各種功能，這樣就會生成兩個文件。為什么不把它們在一個exe文件中實現(xiàn)呢？今天我們就試驗一下，能不能在exe中實現(xiàn)驅(qū)動的功能。
其實這個想法來自一個程序。當時想試驗一下arp攻擊，還以為win32下有相關(guān)的系統(tǒng)調(diào)用，google了一把，不，baidu了一把，說win32下發(fā)包IpPacket到可以，Arp只能用IpHlpApi提供的SendARP()函數(shù)發(fā)送（可能孤陋寡聞），而且不能手動構(gòu)造arp包，而且SP2下發(fā)送TCP SYN是不允許的。暈。借助工具的話就要使用WinPcap，或者自己寫驅(qū)動。我當時想是否能像Fport那樣，直接操作AFD(好像是TDI，還是\device\tcp udp?)，會不會能成功。看了看網(wǎng)上流傳的源碼，好復雜。WinPcap導出的調(diào)用很簡單，而且linux下可以平滑過渡。不過，我的初始想法是一個比較隱蔽的程序，這就要求它有很高的獨立性。所以,很自然的落到了exe驅(qū)動上來。
第一個想法：在exe中導出DriverEntry,看了看sys文件，好像沒有這個導出函數(shù)，那么程序入口就是DriverEntry,但是win32下exe的ImageBase是4MB,驅(qū)動好像是0x10000,不知道win32在加載時會不會對程序作重定位。將EXE的入口修改為DriverEntry…,然后在入口函數(shù)中作判斷，是用戶態(tài)還是ring0。好像VC的編譯器會在入口加入xxx代碼，這樣很麻煩，而且相當麻煩。以上證明這個想法暫時不對。不過突然有個想法，程序里面包含main 和DriverEntry，入口為main,運行后修改入口為DriverEntry，然后加載驅(qū)動…，弊端很多…
第二個想法，在exe中執(zhí)行ring0代碼。這是老想法了，網(wǎng)上有無驅(qū)執(zhí)行ring0的源碼，我當初也裝模作樣的分析了一下。具體的實現(xiàn)方法是使用\Device\PhysicalMemory對象映射物理內(nèi)存并修改（GDT,IDT,或者hook內(nèi)核函數(shù)），對此有篇文章有精彩的解說（baidu關(guān)鍵字'/dev/kmem ring0'）。個人覺得hook內(nèi)核函數(shù)比較簡單快速，進入ring0后不需要作任何環(huán)境修改。如果使用中斷門或者調(diào)用門，構(gòu)造就很麻煩，而且好像在哪見過門的段地址要自己重新構(gòu)造…。沒試驗過，僅是猜測。
具體思路：
（1） 使用ZwQuerySystemInformation獲取ntoskrnl.exe的基址
（2） 用戶態(tài)加載ntoskrnl.exe,獲取內(nèi)核api相對于它所在模塊基址的偏移，加上內(nèi)核鏡像的基址獲得真正的api的地址，計算需要使用的Kernel API的地址。
（3） 將api地址減去0x80000000（NT使用flat內(nèi)存映射，前512Mb物理內(nèi)存直接映射到2GB,不知道打開/3GB開關(guān)是什么情況，暫不考慮）,獲得api的物理內(nèi)存地址
（4） 映射物理內(nèi)存并寫入hook代碼
（5） 調(diào)用Kernel API對應的NaiveAPI,進入ring0
（6） 系統(tǒng)調(diào)用在當前進程的內(nèi)存空間執(zhí)行，所以可以使用整個進程空間，直接調(diào)用（2）計算的KernelAPI完成任務（注意Irql）
看到這里，問題似乎解決了。但是，以上方法只能執(zhí)行ring0代碼并不能實現(xiàn)驅(qū)動所實現(xiàn)的功能，功能還非常弱，對于一個簡單的MemoryDump/ProcessList還可以，其它很多都受限制。由于代碼運行于進程用戶內(nèi)存空間，使用內(nèi)核棧，如果在別的進程空間調(diào)用將KeBugCheck之類的…。很自然，我們會想到把代碼拷貝到內(nèi)核空間去運行。這的確是解決方法。
第一種方案：由于KernelAPI大部分由ntoskrnl.exe和HAL.DLL導出，我們可以計算這些導出函數(shù)的地址，調(diào)用ExAllocatePool()分配空間(設pKeApiSet)，拷貝。然后使用同樣的方法來拷貝函數(shù)代碼到內(nèi)核，然后將pKeApiSet作為拷貝函數(shù)的參數(shù)，調(diào)用，這樣代碼就運行在內(nèi)核空間了，但是還是只能在當前線程的時間片下運行。如果向其它驅(qū)動注冊回調(diào)函數(shù)就麻煩了，因為這些函數(shù)都有固定的格式,而且調(diào)用時無法取得我們自己的參數(shù)。使用過下面的方法解決了這個問題：
//===========================================
//修改堆棧,對于_fastcall沒試過 !!!!!
#define X_RELOC_CODE "\xFF\x34\x24"\
"\xC7\x44\x24\x04\x00\x00\x00\x00"
//若想對齊，此代碼后面可以加入 nop nop
//若想跳轉(zhuǎn)，此處加入push addr; ret即可，好像不能直接jmp abs_addr??(VC)
//vc編譯使用相對地址
// __asm push dword ptr [esp]
// __asm mov dword [esp+4],lpParam
#define X_RELOC_HEADER_SIZE 11
#define X_RELOC_CODE_SIZE 11
typedef struct
{
char b1[7];
void *lpParam;
}X_RELOC_HEADER;
//=================================================
X_RELOC_HEADER *pCode=( X_RELOC_HEADER *)__KeApiSet.ExAllocatePool(NonPagedPool,UPALIGN(size+ X_RELOC_CODE_SIZE,4096));
Memcpy((char *)pCode, X_RELOC_CODE, X_RELOC_CODE_SIZE);
pCode->lpParam=(void *)&__KeApiSet;
//x_size>=MyCallback函數(shù)的大小
memcpy((void *)((ULONG)pCode+11),(void *)MyCallback,x_size);
//這里將pCode注冊到其它驅(qū)動或者對象的回調(diào)函數(shù)去，對于新的回調(diào)函數(shù)添加一個參數(shù)（指向__KeApiSet）在最左邊。
例如，原來的回調(diào)函數(shù)為
OriginalCallback(Type1 Param1,Type2 Param2….)
新的回調(diào)函數(shù)如下
MyCallback(void *lpParam, Type1 Param1,Type2 Param2…)
其實就是在調(diào)用函數(shù)時修改函數(shù)堆棧
-------------------------------------------------------------
[堆棧狀態(tài)]
NewCallback ' |EIP | OriginalCallback' |EIP |
|MyParam | |Param1 |
|Param1 | |Param2 |
|Param2 |
-------------------------------------------------------------
CodeAddr' NewCodeLayout'
|push ebp | |push dword ptr [esp] |
|mov ebp,esp | |movdword [esp+4],xParam |
|sub esp,xxxx | |push ebp |
| …. | |mov ebp,esp |
-------------------------------------------------------------
還有一種方法是使用EIP定位。Linux下的動態(tài)庫有一種浮動代碼的技術(shù)，其中就用到了使用EIP定位，原理如下
Call Nextaddr___ //?push eip(=Nextaddr___) + jmp addr
Nextaddr___: //
Pop ebx //ebx=EIP
在剛進入函數(shù)時獲取EIP值，將參數(shù)拷貝到代碼前面，eip減去一個數(shù)值就可以找到參數(shù)。不過這樣好象有點麻煩。
后來想起來VC編譯器支持一種naked函數(shù)，用這個函數(shù)__declspec(naked)寫就可以了，白白花費了這么長時間。
應用：使用第一種方法（代碼拷貝到內(nèi)核空間，修改堆棧），在進入ring0后，可以注冊一個回調(diào)函數(shù)到IPFilterDriver,實現(xiàn)一個簡單的Ip過濾，美其名曰："放火墻"。IoGetDevicePointer'IoBuildDeviceIoControlRequest'IofCallDriver。細節(jié)可以看網(wǎng)上的高手寫的xxxWndows下防火墻。
第三種方法，好像有篇文章說可以使用ZwSetSystemInformation(SysLoadAndCallImage)，可以直接加載并運行，而且有種rootkit就使用了這種方法。具體沒有看過，可以到網(wǎng)上看看。
-------------------------------------------------------
本來到這里基本算結(jié)束了，但是上面的方法只能實現(xiàn)簡單的功能，而且代碼有點復雜，對于第二種方法，特別是函數(shù)調(diào)用，必須使用額外參數(shù)來定位。這樣還不如單獨寫一個sys文件快。這時我考慮到了代碼重定位，于是baidu一下,找到了局部變量大哥寫的《NT環(huán)境下進程的隱藏》，如獲珍寶，自己按著方法把代碼重寫了一遍，學到不少。其實PE教程說的很明白，就是看不下去…。
對EXE進行重定位方法我就不多說了。具體方法就是在內(nèi)核空間中分配代內(nèi)存，拷貝自身鏡像到內(nèi)核，然后對內(nèi)核空間的鏡像作重定位。由于進入ring0后，在win2k下還可以調(diào)用用戶態(tài)API(printf()還可以使用,在當前進程空間)，在xp下調(diào)用會導致進程退出，估計對調(diào)用前后狀態(tài)或者地址作了限制。
有了重定位，就可在函數(shù)中使用全局變量，這樣對函數(shù)的限制大大減小。但還有個問題，就是對kernel API的調(diào)用還是使用的顯式調(diào)用，非常麻煩，對每個函數(shù)都要GetProcAddress()，于是我將ntoskrnl.lib和hal.lib加入到程序中，原本以為這樣就可以了，可是編譯通過，程序根本運行不起來，運行便出錯。不知道是機器上的VC有問題，還是…，估計是加載EXE時，回加載它所使用的所有庫，估計在加載ntoskrnl.exe時出錯了。我手動修改PE的導入表，去掉ntoskrnl.exe模塊，程序便能正常運行。
卡到了這里，決定使用先編譯，再用工具修改導入表，去掉ntoskrnl.exe的引用。方法就是將ntoskrnl.exe的描述符放到導入表的最后一項，然后將ntoskrnl.exe的IMAGE_IMPORT_DESCRIPTOR拷貝到程序的其他地方（就像病毒那樣，將代碼寫入到PE的間隙處，VC默認對齊大小是4096,這樣會有很多空隙），然后將這項置零。這樣加載時就不會加載ntoskrnl.exe。說起來容易，實際根本不可行，也沒試，因為我查到了VC編譯器的延時加載功能(/DelayLoad:dll_name)。
通常在調(diào)用dll導出函數(shù)時，編譯器為所調(diào)用的函數(shù)生成導入地址表，將函數(shù)所在模塊生成IMAGE_IMPORT_DESCRIPTOR,win32在加載程序時會自動加載指定的模塊，并確定導入函數(shù)的實際地址。DelayLoad將所調(diào)用的導出函數(shù)生成一個stub,類似如下：
Pid=PsGetCurentProcessId();
Call 40E68E //這里使用了Debug模式/增量編譯，所以會有個跳轉(zhuǎn)
//release/static/GZ估計為call dword ptr[xxxxxxxx]
-------------------------------------------------------------------------------
0040E682 Push ecx
Push edx
Push 00429364 //壓入IAT地址
Jmp 40E66E
-------------------------------------------------------------------------------
0040E68E jmp dword ptr [00429364]//'0040E682
-------------------------------------------------------------------------------
0040E66E Push 00429000 //壓入PCImgDelayDescr地址,類似導入表
Call 00401087 //__delayLoadHelper（pImgDelayDesc,ppfnIATEntry）
Pop edx //__ delayLoadHelper計算API真正地址，填入IAT
Pop ecx
Jmp eax //eax=Real Address==[IAT]
-------------------------------------------------------------------------------
由于PCImgDelayDescr被放置在單獨的延時輸入描述符目錄中，而不是通常的輸入表目錄，所以win32在加載時，這些延時加載的模塊不會被加載。第一次調(diào)用函數(shù)時IAT間接指向__delayLoadHelper函數(shù)，而__delayLoadHelper根據(jù)函數(shù)所在模塊名和函數(shù)名計算函數(shù)地址，然后寫會IAT,下次執(zhí)行直接跳轉(zhuǎn)到真正的函數(shù)地址上去。
DelayLoad的這種特性正好解決了當前的問題。方法就是連接ntoskrnl.lib和hal.lib,然后將ntoskrnl.exe和hal.dll延時加載，自己重寫__delayLoadHelper函數(shù)來取得KernelAPi的地址，這樣問題迎刃而解了。VC6自己的__delayLoadHelper函數(shù)在文件DELAYHLP.CPP中實現(xiàn)，其中加入了對函數(shù)Hook的功能，就是導出兩個函數(shù)指針，在__delayLoadHelper中先調(diào)用指針指向的函數(shù)，若為空怎使用默認的LoadLibrary()和GetProcAddress()。這樣如果想hook函數(shù)只需要將模塊延時加載然后自己實現(xiàn)__pfnDliNotifyHook即可。
問題：
（1） 由于在內(nèi)核之中，（同一進程空間）不能調(diào)用win32API (XP下不行，2K下可以，注意：非GUI API),如果還可能在其它進程空間使用，則根本不能使用UserAPI
（2） 經(jīng)過重定位的鏡像在獲取API名稱時有問題，鏡像基址大于0x80000000,地址的最高位肯定為1，這在PE中與函數(shù)的INT沖突，信息會丟失。
解決方法：
（1） 其實使用的API就是LoadLibrary() 和GetProcAddress,重寫LoadLibrary和GetProcAddress函數(shù)即可。對于LoadLibrary()，只需要調(diào)用ZwQuerySystemInformation獲得模塊的基址即可；對于GetProcAddress,根據(jù)模塊鏡像的基址找到IMAGE_NT_HEADERS->IMAGE_EXPORT_DIRECTORY逐個查找即可，注意函數(shù)使用序號(ordinal)的查找。
（2） WIN32 PE文件的導入表和延時加載描述符表都有各自的INT和IAT（暫時這樣理解），對于函數(shù)地址的確定都使用類似的機制。從INT獲得函數(shù)名稱或者函數(shù)ordinal,然后從模塊里查找函數(shù)地址，填入IAT，只是確定函數(shù)地址時間有不同。對于函數(shù)名稱,，PE使用IMAGE_THUNK_DATA來描述，它其實是一個DWORD指針，指向一個DWORD數(shù)組，對于數(shù)組中的每個DWORD，如果最高位為1（&IMAGE_ORDINAL_FLAG32），則此函數(shù)按序號引入，否則此DWORD指向一個IMAGE_IMPORT_BY_NAME結(jié)構(gòu)，此結(jié)構(gòu)包含函數(shù)名稱字符串的RVA。普通Win32進程運行在0-2GB中，所以這沒問題。但我們的鏡像被拷貝到0xFExx xxxx ,重定位后IMAGE_THUNK_DATA的地址肯定>0x80000000,所以只能根據(jù)經(jīng)驗，全部按名稱引入，理由是NT、95的函數(shù)序號并不一致（從書上看的，很簡單，xp導出的函數(shù)比2K多，如果按序號肯定出問題）。就在這個地方，沒有調(diào)試器，只有printf，浪費了兩天的時間，暈。還以為是VC自帶的代碼決不會有問題，重寫__delayLoadHelper后解決（__delayLoadHelper對函數(shù)Ordinal & IMAGE_ORDINAL_FLAG做了判斷…）。
呵呵，終于到主題了，其實前面的要困難些。
當代運行在ring0時，它已經(jīng)能實現(xiàn)多數(shù)功能了，但是如果要作個木馬，后門之類的，還要解決與用戶態(tài)通信的問題（其實并不是這樣），所以想到了事件之類的，或者ring0 call ring0,apc…最后還是落到了文件設備上。通過文件設備，任何進程都可以與ring0通信，而且創(chuàng)建驅(qū)動的宿主可以安全撤退。如果使用ring0 代碼(call gate,hook),則進程不能退出，因為線程的系統(tǒng)調(diào)用沒有返回，所以即使強行中止也無濟于事。如果通過ring0代碼創(chuàng)建一個驅(qū)動，然后ring0返回到ring3,進程就可以安全退出。而這時的代碼還駐留在內(nèi)核的未分頁區(qū)，以回調(diào)的方式響應請求。
學過操作系統(tǒng)都知道，VFS的特性，就是所有設備都是用文件來表示，其實質(zhì)就是分層的函數(shù)調(diào)用，使用注冊機制來處理各種設備之間的差異。實際實現(xiàn)表現(xiàn)為一個文件對象對應一個設備對象，同時設備對象又對應一個驅(qū)動對象，不同的i/o請求通過文件對象分發(fā)到不同的設備，進而轉(zhuǎn)發(fā)到設備對應的驅(qū)動對象，由驅(qū)動完成最終請求。這種分層的設計有何多優(yōu)點，特別適合擴展和抽象，下面深略3000字。
要創(chuàng)建驅(qū)動，無非就是創(chuàng)建一個驅(qū)動對象，創(chuàng)建一個設備對象，注冊函數(shù)到設備對象，然后創(chuàng)建設備鏈接以使win32可以訪問到設備。看win2K 源碼（\private\ntos\io\internal.c），驅(qū)動加載的基本過程為
+-->'一堆注冊表操作
+-->'取得驅(qū)動文件名
+-->'MmLoadSystemImage()加載驅(qū)動到內(nèi)存
+-->'ObCreateObject()創(chuàng)建驅(qū)動對象
+-->'對驅(qū)動對象的各成員初始化
+-->'ObInsertObject()
+-->'ObReferenceObjectByHandle() //取得對象指針
+-->'NtClose() //關(guān)閉ObInsertObject()創(chuàng)建的句柄
+-->'驅(qū)動名稱操作..
+-->'status = driverObject->DriverInit( driverObject, ®istryPath->Name );
+-->//調(diào)用驅(qū)動入口DriverEntry進行驅(qū)動初始化
+-->'檢查驅(qū)動對象的合法性(MajorFunction函數(shù),驅(qū)動是否創(chuàng)建設備…)
+-->'IopBootLog()
+-->'MmFreeDriverInitialization()
+-->'IopReadyDeviceObjects() //VIP！！！！！
有了上面的過程，基本可以自己手動創(chuàng)建驅(qū)動并加載了，看了看搜索結(jié)果，發(fā)現(xiàn)ntoskrnl.exe導出了IoCreatDriver這個函數(shù)，其中實現(xiàn)了IopLoadDriver的大部分功能，事情變得簡單起來。
NTKERNELAPI
NTSTATUS
IoCreateDriver (
IN PUNICODE_STRING DriverName, OPTIONAL
IN PDRIVER_INITIALIZE InitializationFunction
);
具體方法就是：用exe中的DriverEntry做為參數(shù)，調(diào)用IoCreateDriver，即可實現(xiàn)驅(qū)動的加載。
當在win2K下運行程序后，用WinObj居然打開失敗。暈，再次看IoLoadDeiver，才發(fā)現(xiàn)漏掉了一個重要地方，創(chuàng)建驅(qū)動時，驅(qū)動對象的標志Flags和所創(chuàng)建設備的標志都有限制，使用IopReadyDeviceObjects()來添加驅(qū)動DRVO_INITIALIZED標志和，去掉驅(qū)動創(chuàng)建的所有設備的DO_DEVICE_INITIALIZING標志。IopReadyDeviceObjects()函數(shù)沒有被ntoskrnl.exe導出?簡單，自己寫就行了。曾找不到問題原因時，還重寫過IopfCompleteRquest和IopCompleteRequest，那才叫痛苦呢。
Finally,搞定。為了方便，寫了一個庫，下次使用時就簡單多了
#include "DrvHlpApi.h"
NTSTATUS Driverentry(void *pDriverObject,void *pRegPath)
{
// ….IoCreateDevice()..
Return STATUS_SUCCESS;
}
Int main(int argc.char **argv)
{
x_InitRing0Utils();
x_StartDriver((ULONG)DriverEntry,0,0);
return 0;
}
使用這個方法，完全可以實現(xiàn)驅(qū)動的所有功能，同時將它與win32程序結(jié)合在一起。在XP SP2和win2k SP4下測試通過（就試過IpFilter那個）。就這么簡單。有興趣的朋友可以mail來取得代碼，頭文件和庫可以在http://icelord.bokee.com下載到。
參考文章：
1．《NT環(huán)境下進程的隱藏》
2．Win2K Source Code
3．PE文件格式詳解
4．Ring0Demo.c v1.0 by zzzEVAzzz
5．