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