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