實戰(zhàn)：環(huán)境搭建、API體系與安全防御)
1. 從零開始驅動開發(fā)環(huán)境搭建與簽名預檢先說個很多人容易忽略的前提寫內核驅動不是打開Visual Studio寫幾行代碼就能跑的測試簽名模式、WDK版本匹配、目標系統(tǒng)版本這三件事沒對齊后面全是坑。我見過不少人SDK和WDK版本不匹配編譯出來一加載直接藍屏連錯誤日志都沒來得及看。1.1 開發(fā)機環(huán)境WDK與Visual Studio的版本對齊Windows驅動開發(fā)的標準組合是Visual Studio WDKWindows Driver Kit。這里的關鍵不是裝最新版而是版本對齊。比如你用VS 2022那就選WDK 10.0.22621或對應你目標系統(tǒng)的SDK版本別混搭。我個人的建議是開發(fā)機用Windows 11或Windows Server 2022x64架構Visual Studio 2022 Community版即可安裝時勾選“使用C的桌面開發(fā)”工作負載下載并安裝與SDK版本匹配的WDK安裝后VS里會自動出現(xiàn)“內核模式驅動程序”的項目模板啟用測試簽名模式bcdedit /set testsigning on或者配置好簽名證書二者選一但千萬別兩個都跳過如果你是剛開始接觸建議直接在虛擬機里搭開發(fā)環(huán)境。內核驅動開發(fā)過程中藍屏是常態(tài)實機上每藍一次屏都要重啟等半天虛擬機里快照一還原效率高太多。我自己的開發(fā)機就是VMware里開的Windows 11分配4核8G編譯和測試都夠用。1.2 驅動簽名測試簽名與正式簽名的取舍驅動簽名是新手最容易卡住的地方。64位Windows默認只加載有有效數(shù)字簽名的內核驅動要么是微軟WHQL簽名要么是EV代碼簽名證書簽的。作為個人開發(fā)者或安全研究者這兩條路成本都很高。替代方案是測試簽名模式# 管理員權限下執(zhí)行 bcdedit /set testsigning on # 重啟后桌面右下角會出現(xiàn)“測試模式”水印然后在驅動項目的“驅動程序簽名”設置里選“測試簽名”用WDK自帶的MakeCert工具生成自簽名證書再簽名驅動。具體命令# 生成測試證書 makecert -r -pe -ss PrivateCertStore -n CNMyDriverTestCert MyDriverTestCert.cer # 對驅動文件簽名 signtool sign /s PrivateCertStore /n MyDriverTestCert /t http://timestamp.digicert.com mydriver.sys這樣做出來的驅動只能在開啟了測試簽名的系統(tǒng)上加載。對學習研究和內部工具來說夠了但想分發(fā)或商用就必須走正式的EV簽名流程。實測下來測試簽名模式下開發(fā)調試基本無感唯一要記住的是每次重裝系統(tǒng)或關閉測試簽名后驅動必須重新簽名。提示千萬別在生產環(huán)境比如公司服務器、客戶機器上開測試簽名模式這個操作本身會觸發(fā)Windows Defender和EDR的告警在嚴格的安全策略下甚至會被直接拉黑。2. 驅動安裝與卸載的底層機制SCM與INF的配合驅動寫好了只是第一步怎么把它“裝”進系統(tǒng)才是關鍵。Windows驅動安裝不是簡單的文件復制而是通過**服務控制管理器SCM, Service Control Manager**注冊成一個內核服務再由I/O管理器按需加載。新手常見的誤解是把.sys文件丟進C:\Windows\System32\drivers就完事了。實際上這只是文件的存放位置系統(tǒng)并不會自動加載它。必須通過SCM創(chuàng)建服務把驅動和服務的啟動類型、依賴關系綁定在一起。2.1 手工安裝sc create與INF文件的區(qū)別驅動的安裝方式主要有兩種方式一通過INF文件自動安裝INF文件是個設備安裝腳本里面描述了驅動支持哪些硬件ID、復制哪些文件、創(chuàng)建什么服務。右鍵INF文件選擇“安裝”Windows會調用SetupAPI來執(zhí)行安裝過程。這種方式適合有真實硬件設備PCI設備、USB設備等的驅動或者需要向設備管理器注冊的驅動比如虛擬網(wǎng)卡、虛擬顯示設備。方式二通過SCM工具手工創(chuàng)建服務對內核服務型驅動如過濾驅動、文件系統(tǒng)過濾驅動、網(wǎng)絡過濾驅動等來說更常見的安裝方式是直接用命令行創(chuàng)建服務# 以管理員身份運行 sc create MyDriver type kernel binPath C:\Windows\System32\drivers\MyDriver.sys start demand sc start MyDriver # 卸載 sc stop MyDriver sc delete MyDriver這兩種方式的本質區(qū)別在于INF方式綁定的是“設備”和“驅動”的關系適合PnP設備驅動SCM方式綁定的是“服務”和“驅動”的關系適合非PnP的啟動型驅動。理解了這個區(qū)別你就不會在面對一個驅動時糾結該用哪種方式安裝了。2.2 驅動生命周期加載、初始化與卸載的完整時序驅動從被加載到被卸載整個生命周期里有幾個關鍵回調函數(shù)必須搞清楚階段回調/行為說明加載DriverEntry驅動入口初始化各種分發(fā)例程、對象、設備運行DispatchCreate/Close/Read/Write等處理來自應用層的IRP請求運行IOCTL分發(fā)例程處理DeviceIoControl控制碼卸載DriverUnload清理資源、刪除設備對象、注銷符號鏈接DriverEntry函數(shù)里最重要的一件事是設置DriverUnload指針。有些驅動開發(fā)者在測試時偷懶不寫DriverUnload結果驅動加載后手動停止時直接藍屏這就是典型的資源泄漏導致的問題。來看一個典型的驅動卸載函數(shù)void DriverUnload(PDRIVER_OBJECT DriverObject) { UNICODE_STRING deviceLink RTL_CONSTANT_STRING(L\\??\\MyDriverLink); // 刪除符號鏈接 IoDeleteSymbolicLink(deviceLink); // 刪除設備對象 if (DriverObject-DeviceObject) { IoDeleteDevice(DriverObject-DeviceObject); } // 打印日志方便DebugView觀察 DbgPrint(MyDriver: DriverUnload called successfully.\n); }注意這里的刪除順序有講究先刪符號鏈接再刪設備對象。順序反了的話符號鏈接會指向一個已經(jīng)不存在的設備對象輕則訪問報錯重則系統(tǒng)藍屏。2.3 實操一個完整的驅動安裝-通信-卸載流程C代碼拿一個標準的內核驅動來說完整的操作流程應該是這樣。假設你寫了一個名為MyDriver的內核驅動應用程序通過DeviceIoControl與它通信驅動側MyDriver.sys核心代碼框架#include ntddk.h #define MYDRIVER_IOCTL_TEST \ CTL_CODE(FILE_DEVICE_UNKNOWN, 0x800, METHOD_BUFFERED, FILE_ANY_ACCESS) NTSTATUS DriverEntry(PDRIVER_OBJECT DriverObject, PUNICODE_STRING RegistryPath) { NTSTATUS status; PDEVICE_OBJECT deviceObject NULL; UNICODE_STRING deviceName; UNICODE_STRING deviceLink; // 設置卸載例程 DriverObject-DriverUnload DriverUnload; // 設置分發(fā)例程 DriverObject-MajorFunction[IRP_MJ_CREATE] MyDriverCreate; DriverObject-MajorFunction[IRP_MJ_CLOSE] MyDriverClose; DriverObject-MajorFunction[IRP_MJ_DEVICE_CONTROL] MyDriverIoctl; // 創(chuàng)建設備對象 RtlInitUnicodeString(deviceName, L\\Device\\MyDriverDevice); status IoCreateDevice(DriverObject, 0, deviceName, FILE_DEVICE_UNKNOWN, 0, FALSE, deviceObject); if (!NT_SUCCESS(status)) return status; // 創(chuàng)建符號鏈接 RtlInitUnicodeString(deviceLink, L\\??\\MyDriverLink); status IoCreateSymbolicLink(deviceLink, deviceName); if (!NT_SUCCESS(status)) { IoDeleteDevice(deviceObject); return status; } DbgPrint(MyDriver: DriverEntry loaded.\n); return STATUS_SUCCESS; }應用層Client.exe通信代碼核心片段#include windows.h #include stdio.h int main() { HANDLE hDevice CreateFileA(\\\\.\\MyDriverLink, GENERIC_READ | GENERIC_WRITE, FILE_SHARE_READ | FILE_SHARE_WRITE, NULL, OPEN_EXISTING, 0, NULL); if (hDevice INVALID_HANDLE_VALUE) { printf(Failed to open device. Error: %d\n, GetLastError()); return 1; } DWORD bytesReturned 0; ULONG input 123; ULONG output 0; BOOL success DeviceIoControl(hDevice, MYDRIVER_IOCTL_TEST, input, sizeof(input), output, sizeof(output), bytesReturned, NULL); if (success) { printf(IOCTL succeeded. Returned value: %lu\n, output); } CloseHandle(hDevice); return 0; }這套流程下來你就完整跑通了一個“創(chuàng)建設備→應用層open→通信→close→卸載”的閉環(huán)。在實際調試時要用DebugView勾選Kernel Verbose來觀察DbgPrint輸出這樣DriverEntry是否執(zhí)行、各個分發(fā)例程是否被調用、卸載流程是否干凈一眼就能看出來。3. 內核API分類體系從內存操作到對象管理的知識地圖Windows內核API數(shù)量龐大API分布在ntoskrnl.exe、hal.dll、ndis.sys等多個模塊里沒有任何人能全部背下來。真正有用的是按照“功能域”建立自己的知識體系知道什么時候該用哪類API、去哪查文檔。下面是我按實踐場景整理的分類地圖。3.1 內存管理類API分配/釋放/鎖頁內核編程最大的特點是不能隨便用malloc/free必須用內核專用API。這個差距是剛接觸驅動的人最容易出bug的地方。API用途注意事項ExAllocatePool2 / ExAllocatePoolWithTag分配非分頁/分頁內存Windows 10 2004之后推薦ExAllocatePool2帶PoolTag便于排查泄漏ExFreePoolWithTag釋放內存必須與分配時的Tag一致MmProbeAndLockPages鎖定用戶模式內存頁處理用戶空間緩沖區(qū)時必須先探測再鎖定MmUnlockPages解鎖內存頁鎖定后務必在結束路徑上解鎖這里必須給新手強調一個坑在內核驅動里處理用戶傳入的緩沖區(qū)時絕對不能直接解引用用戶模式指針。攻擊者可以傳入一個無效地址你解引用就直接藍屏。正確做法是先用ProbeForRead/ProbeForWrite探測或者依賴METHOD_BUFFERED方式讓I/O管理器幫你處理緩沖。用ExAllocatePool2舉個例子// 分配非分頁內存大小為1024字節(jié)Tag為Myd1 PVOID buffer ExAllocatePool2(POOL_FLAG_NON_PAGED, 1024, Myd1); if (buffer NULL) { DbgPrint(Failed to allocate memory.\n); return STATUS_INSUFFICIENT_RESOURCES; } // 使用完畢釋放 ExFreePoolWithTag(buffer, Myd1);注意ExAllocatePool2在返回NULL前不會像老API那樣拋異常所以判斷NULL是必須的。另外非分頁內存的大小要克制內核地址空間雖然大但非分頁池耗盡會導致整個系統(tǒng)進入內存壓力狀態(tài)后果就是卡頓甚至崩潰。3.2 進程與線程上下文類API獲取進程信息與句柄操作這類API是安全軟件、ARK工具的?？汀１热缒阆氡闅v進程列表或者根據(jù)PID獲取進程對象通常需要用到API用途PsLookupProcessByProcessId根據(jù)PID獲取EPROCESS對象PsGetCurrentProcess獲取當前進程的EPROCESSPsGetProcessImageFileName獲取進程鏡像文件名ObDereferenceObject釋放對象引用KeStackAttachProcess附加到目標進程上下文KeUnstackDetachProcess從目標進程上下文中脫離一個常見的場景我們需要判斷當前進程是不是某個特定進程然后執(zhí)行特殊邏輯。示例代碼如下NTSTATUS GetProcessNameByPid(HANDLE pid, char* buffer, SIZE_T maxLen) { PEPROCESS process NULL; NTSTATUS status PsLookupProcessByProcessId(pid, process); if (!NT_SUCCESS(status)) return status; // 獲取進程名 const char* name (const char*)PsGetProcessImageFileName(process); if (name) { strncpy(buffer, name, maxLen - 1); buffer[maxLen - 1] \0; } // 注意必須釋放引用 ObDereferenceObject(process); return STATUS_SUCCESS; }新手同樣高頻踩坑的地方PsGetProcessImageFileName返回的只是一個內部指針不是拷貝出來的新的字符串。如果你要長期保存這個字符串必須自己拷貝到安全的緩沖區(qū)如果直接引用后續(xù)可能EProcess被釋放輕則亂碼重則指針失效崩潰。3.3 對象管理與APC分發(fā)類API對象管理相關的API在安全防御中也很常用比如監(jiān)控進程創(chuàng)建、監(jiān)控句柄操作等。尤其是注冊Callback這種方式可以在不改動內核代碼的前提下實現(xiàn)監(jiān)控也是目前EDR最常用的手法之一API用途PsSetCreateProcessNotifyRoutineEx注冊進程創(chuàng)建/退出回調PsSetCreateThreadNotifyRoutine注冊線程創(chuàng)建/退出回調PsSetLoadImageNotifyRoutine注冊模塊加載回調DLL/驅動ObRegisterCallbacks注冊句柄操作回調權限提升防護這類API的特點是理論上它們本身沒有惡意能力但可以被用來做安全監(jiān)控也可以用來做信息竊取。所以我多說一句這些API的使用最好配合驅動簽名和明確的安全目的否則容易被安全軟件標記為可疑行為。在Windows 10較新版本以后微軟逐步用PsSetCreateProcessNotifyRoutineEx的第二個版本替代了舊版?zhèn)鲄⒅卸嗔艘粋€PSCREATEPROCESSNOTIFYINFO結構能拿到父進程PID、創(chuàng)建標志等更豐富的信息對溯源監(jiān)控非常有幫助。3.4 IRP與派遣函數(shù)設備通信的分發(fā)邏輯每個驅動由I/O管理器管理著一組IRPI/O Request Packet上層調用ReadFile、WriteFile、DeviceIoControl時最終都會轉換成相應的IRP并被分發(fā)到驅動注冊的派遣函數(shù)里。內核驅動的通信核心架構可以用一張表來說明IRP主功能碼分發(fā)函數(shù)注冊位應用層對應操作IRP_MJ_CREATEMajorFunction[0]CreateFileIRP_MJ_CLOSEMajorFunction[2]CloseHandleIRP_MJ_READMajorFunction[3]ReadFileIRP_MJ_WRITEMajorFunction[4]WriteFileIRP_MJ_DEVICE_CONTROLMajorFunction[14]DeviceIoControl實操中大部分自定義驅動只實現(xiàn)CREATE、CLOSE、DEVICE_CONTROL三個派遣函數(shù)就夠了。數(shù)據(jù)交互用IOCTL需要在驅動的頭文件里用CTL_CODE宏定義控制碼。注意IOCTL控制碼的DeviceType字段需要自定義時盡量使用大于0x8000的值避免與系統(tǒng)預留的設備類型沖突?？刂拼a定義如下#define MYDRIVER_IOCTL_TEST \ CTL_CODE(FILE_DEVICE_UNKNOWN, 0x800, METHOD_BUFFERED, FILE_ANY_ACCESS)METHOD_BUFFERED是默認推薦方式I/O管理器會分配一個系統(tǒng)緩沖區(qū)把用戶輸入復制進來、把輸出復制出去。這種方式的上下層緩沖區(qū)拷貝對安全性最友好不容易因為用戶進程結束了導致野指針。它的代價就是性能略低但好在大部分安全工具和控制類的驅動對性能要求沒那么苛刻。反而在高吞吐的網(wǎng)絡過濾或文件系統(tǒng)過濾驅動里你會用到METHOD_NEITHER或METHOD_IN_DIRECT等方式來減少拷貝那又是另一套處理上行了。4. 安全防御實戰(zhàn)從rootkit手法看對抗思路把標題里的“安全防御”單獨拿出來因為這部分如果你只想安安靜靜寫個業(yè)務驅動確實不太會接觸到但只要涉及到安全產品、EDR、反外掛、數(shù)字版權保護這些知識和前面講的是完全不同的能力要求。4.1 常見惡意驅動手段與防御視角在內核層面“攻”和“防”其實是同一套API的兩面。不懂這些經(jīng)典手法你就不知道敵方在什么地方下手自然也不知道該防什么。下面列幾個必須了解的套路手法原理典型案例防御手段驅動保護/反調試用驅動讀取或修改進程的DebugPort等字段阻止調試器附加游戲反外掛、惡意軟件反分析監(jiān)控敏感API調用校驗關鍵結構完整性強制修改SSDT/Inline Hook直接修改內核函數(shù)頭部的字節(jié)跳轉到自己的代碼攔截系統(tǒng)調用老式Rootkit、文件隱藏使用PatchGuard檢測或定期校驗代碼段完整性進程隱藏從EPROCESS鏈表摘除目標進程木馬隱藏自身進程監(jiān)控進程鏈表或使用無回調枚舉方式交叉驗證內核對象劫持修改對象頭中的進程/線程指針權限維持定期校驗對象類型做交叉驗證驅動加載后被截獲控制權偽造IOCTL指令讓驅動執(zhí)行任意操作無文件攻擊驅動層對IOCTL輸入做嚴格校驗增加白名單機制這里強調一個思路真正的安全不僅是靠驅動簽名更是靠“我能想到你會用哪招”的預設能力。如果你自己就動手重現(xiàn)過這些攻擊手法你自然會對驅動的對應用例在腦子里有防御預案。4.2 驅動自我保護技術Callback機制與PGPatchGuard長期運行的安全類驅動一個現(xiàn)實痛點是自己別被干掉。自我保護的核心有幾點優(yōu)先注冊回調而不是去掛鉤子。微軟提供的進程、線程、鏡像回調都是正規(guī)API只要做到驅動注冊殺軟一般不會主動警告盡量避免在驅動代碼里做敏感字符串拼接。很多惡意驅動喜歡把“readme”等無關字符串硬編碼成常量來偽裝而安全產品掃描驅動文件時會看導入表和字符串能在用戶態(tài)解決的事別放內核態(tài)。內核驅動的每一條路徑都是高權限入口暴露面越大漏洞風險越高同時Windows內核有一個特殊的保護機制叫Kernel Patch Protection業(yè)界俗稱KPP或PatchGuard。從64位Vista開始微軟就通過周期性檢測防止內核關鍵結構被修改比如SSDT、IDT、GDT、MSR等。如果檢測到被篡改系統(tǒng)直接藍屏這對傳統(tǒng)的內核掛鉤Inline Hook手段是個巨大的威懾。所以在現(xiàn)代Windows系統(tǒng)上任何嘗試修改關鍵系統(tǒng)結構的內核代碼都注定是危險且短命的。更可持續(xù)的防御是“合規(guī)的偵查”也就是通過微軟公開的回調機制了解系統(tǒng)里正在發(fā)生什么把自己放在“監(jiān)測者”的位置而不是“篡改者”的位置。這也是安全行業(yè)現(xiàn)在的主流做法。4.3 如何排查和檢測可疑驅動的加載防御視角的另一半是“識別出有問題的驅動”。從系統(tǒng)管理員的角度你可以用這些內置工具快速摸查# 查看所有內核驅動服務及狀態(tài) driverquery /v # 查看已加載驅動列表包括路徑 sc query type driver sc queryex MyDriver # 查看驅動的數(shù)字簽名狀態(tài) Get-AuthenticodeSignature C:\Windows\System32\drivers\*.sys如果需要自動化排查可以用PowerShell腳本來枚舉所有驅動文件的簽名# 找出未簽名或被篡改的驅動以管理員身份運行 $unsignedDrivers Get-ChildItem C:\Windows\System32\drivers\*.sys | Where-Object { (Get-AuthenticodeSignature $_.FullName).Status -ne Valid } $unsignedDrivers | Select-Object Name, FullName這腳本的價值在于異常驅動往往在簽名狀態(tài)上露出馬腳。比如一個自稱來自微軟的驅動簽名狀態(tài)卻是“NotSigned”或“HashMismatch”那基本可以懷疑是被植入了。如果擔心惡意驅動通過直接修改內存的方式隱藏自己更深層的檢測方法就是枚舉內核模塊的加載列表然后與文件系統(tǒng)中的.sys文件做交叉比對。正常驅動都會在模塊列表里而那些只靠手動映射不經(jīng)過正常加載路徑的惡意代碼就不會出現(xiàn)在這里——這就是隱蔽與檢測之間的攻防戰(zhàn)場。4.4 實際檢測中的踩坑PatchGuard誤報藍屏在介紹這些防御機制后我不得不分享一個真實踩過的坑。有次我在測試一款安全工具的驅動時用WinDbg在調試機上嘗試修改SSDT里一個函數(shù)的首字節(jié)本意是模擬惡意行為看EDR能不能檢測到。結果系統(tǒng)在幾分鐘后毫無征兆地藍屏了dump分析顯示就是PatchGuard被觸發(fā)。調試時觸發(fā)KPP藍屏幾乎是每個內核安全研究者必經(jīng)的經(jīng)歷。這個坑的核心教訓不是“不要用補丁”而是在Windows 10/11上任何針對內核關鍵結構的修改都極其危險可能當場藍屏也可能在隨機延遲后藍屏藍屏的bugcheck代碼通常是0x109CRITICAL_STRUCTURE_CORRUPTION即使你的目的是安全檢查這種操作也必須放在隔離的測試機上進行別拿主力開發(fā)機當場實驗從那以后我再做內核完整性校驗測試都會用兩種方式替代硬改一是通過WinDbg的寫內存指令臨時測試重啟即恢復二是在測試虛擬機里做快照實驗前先打個快照點藍屏了直接還原。5. 總結但可能不是你想的那種總結我見過太多人學內核驅動第一步就卡死在“編譯通過但加載失敗”的報錯里于是放棄了。實際上這個領域的入門并沒有想象中那么難難的是對每一步背后的機制缺乏耐心去琢磨。如果你現(xiàn)在正要開始動手我的建議很簡單先把開發(fā)環(huán)境搭穩(wěn)、測試簽名打開、寫一個什么都不做的空驅動、跑通加載和卸載、依賴DebugView看到日志。這套流程走通了你才算真正邁進了內核驅動的門檻。后面無論是研究內核API還是做安全防御都是在“能控制和理解加載周期”這個地基上蓋樓。地基越穩(wěn)后面越不容易被那些抽象的概念勸退。 Windows內核驅動開發(fā)實戰(zhàn)：環(huán)境搭建、API體系與安全防御
1. 從零開始驅動開發(fā)環(huán)境搭建與簽名預檢先說個很多人容易忽略的前提寫內核驅動不是打開Visual Studio寫幾行代碼就能跑的測試簽名模式、WDK版本匹配、目標系統(tǒng)版本這三件事沒對齊后面全是坑。我見過不少人SDK和WDK版本不匹配編譯出來一加載直接藍屏連錯誤日志都沒來得及看。1.1 開發(fā)機環(huán)境WDK與Visual Studio的版本對齊Windows驅動開發(fā)的標準組合是Visual Studio WDKWindows Driver Kit。這里的關鍵不是裝最新版而是版本對齊。比如你用VS 2022那就選WDK 10.0.22621或對應你目標系統(tǒng)的SDK版本別混搭。我個人的建議是開發(fā)機用Windows 11或Windows Server 2022x64架構Visual Studio 2022 Community版即可安裝時勾選“使用C的桌面開發(fā)”工作負載下載并安裝與SDK版本匹配的WDK安裝后VS里會自動出現(xiàn)“內核模式驅動程序”的項目模板啟用測試簽名模式bcdedit /set testsigning on或者配置好簽名證書二者選一但千萬別兩個都跳過如果你是剛開始接觸建議直接在虛擬機里搭開發(fā)環(huán)境。內核驅動開發(fā)過程中藍屏是常態(tài)實機上每藍一次屏都要重啟等半天虛擬機里快照一還原效率高太多。我自己的開發(fā)機就是VMware里開的Windows 11分配4核8G編譯和測試都夠用。1.2 驅動簽名測試簽名與正式簽名的取舍驅動簽名是新手最容易卡住的地方。64位Windows默認只加載有有效數(shù)字簽名的內核驅動要么是微軟WHQL簽名要么是EV代碼簽名證書簽的。作為個人開發(fā)者或安全研究者這兩條路成本都很高。替代方案是測試簽名模式# 管理員權限下執(zhí)行 bcdedit /set testsigning on # 重啟后桌面右下角會出現(xiàn)“測試模式”水印然后在驅動項目的“驅動程序簽名”設置里選“測試簽名”用WDK自帶的MakeCert工具生成自簽名證書再簽名驅動。具體命令# 生成測試證書 makecert -r -pe -ss PrivateCertStore -n CNMyDriverTestCert MyDriverTestCert.cer # 對驅動文件簽名 signtool sign /s PrivateCertStore /n MyDriverTestCert /t http://timestamp.digicert.com mydriver.sys這樣做出來的驅動只能在開啟了測試簽名的系統(tǒng)上加載。對學習研究和內部工具來說夠了但想分發(fā)或商用就必須走正式的EV簽名流程。實測下來測試簽名模式下開發(fā)調試基本無感唯一要記住的是每次重裝系統(tǒng)或關閉測試簽名后驅動必須重新簽名。提示千萬別在生產環(huán)境比如公司服務器、客戶機器上開測試簽名模式這個操作本身會觸發(fā)Windows Defender和EDR的告警在嚴格的安全策略下甚至會被直接拉黑。2. 驅動安裝與卸載的底層機制SCM與INF的配合驅動寫好了只是第一步怎么把它“裝”進系統(tǒng)才是關鍵。Windows驅動安裝不是簡單的文件復制而是通過**服務控制管理器SCM, Service Control Manager**注冊成一個內核服務再由I/O管理器按需加載。新手常見的誤解是把.sys文件丟進C:\Windows\System32\drivers就完事了。實際上這只是文件的存放位置系統(tǒng)并不會自動加載它。必須通過SCM創(chuàng)建服務把驅動和服務的啟動類型、依賴關系綁定在一起。2.1 手工安裝sc create與INF文件的區(qū)別驅動的安裝方式主要有兩種方式一通過INF文件自動安裝INF文件是個設備安裝腳本里面描述了驅動支持哪些硬件ID、復制哪些文件、創(chuàng)建什么服務。右鍵INF文件選擇“安裝”Windows會調用SetupAPI來執(zhí)行安裝過程。這種方式適合有真實硬件設備PCI設備、USB設備等的驅動或者需要向設備管理器注冊的驅動比如虛擬網(wǎng)卡、虛擬顯示設備。方式二通過SCM工具手工創(chuàng)建服務對內核服務型驅動如過濾驅動、文件系統(tǒng)過濾驅動、網(wǎng)絡過濾驅動等來說更常見的安裝方式是直接用命令行創(chuàng)建服務# 以管理員身份運行 sc create MyDriver type kernel binPath C:\Windows\System32\drivers\MyDriver.sys start demand sc start MyDriver # 卸載 sc stop MyDriver sc delete MyDriver這兩種方式的本質區(qū)別在于INF方式綁定的是“設備”和“驅動”的關系適合PnP設備驅動SCM方式綁定的是“服務”和“驅動”的關系適合非PnP的啟動型驅動。理解了這個區(qū)別你就不會在面對一個驅動時糾結該用哪種方式安裝了。2.2 驅動生命周期加載、初始化與卸載的完整時序驅動從被加載到被卸載整個生命周期里有幾個關鍵回調函數(shù)必須搞清楚階段回調/行為說明加載DriverEntry驅動入口初始化各種分發(fā)例程、對象、設備運行DispatchCreate/Close/Read/Write等處理來自應用層的IRP請求運行IOCTL分發(fā)例程處理DeviceIoControl控制碼卸載DriverUnload清理資源、刪除設備對象、注銷符號鏈接DriverEntry函數(shù)里最重要的一件事是設置DriverUnload指針。有些驅動開發(fā)者在測試時偷懶不寫DriverUnload結果驅動加載后手動停止時直接藍屏這就是典型的資源泄漏導致的問題。來看一個典型的驅動卸載函數(shù)void DriverUnload(PDRIVER_OBJECT DriverObject) { UNICODE_STRING deviceLink RTL_CONSTANT_STRING(L\\??\\MyDriverLink); // 刪除符號鏈接 IoDeleteSymbolicLink(deviceLink); // 刪除設備對象 if (DriverObject-DeviceObject) { IoDeleteDevice(DriverObject-DeviceObject); } // 打印日志方便DebugView觀察 DbgPrint(MyDriver: DriverUnload called successfully.\n); }注意這里的刪除順序有講究先刪符號鏈接再刪設備對象。順序反了的話符號鏈接會指向一個已經(jīng)不存在的設備對象輕則訪問報錯重則系統(tǒng)藍屏。2.3 實操一個完整的驅動安裝-通信-卸載流程C代碼拿一個標準的內核驅動來說完整的操作流程應該是這樣。假設你寫了一個名為MyDriver的內核驅動應用程序通過DeviceIoControl與它通信驅動側MyDriver.sys核心代碼框架#include ntddk.h #define MYDRIVER_IOCTL_TEST \ CTL_CODE(FILE_DEVICE_UNKNOWN, 0x800, METHOD_BUFFERED, FILE_ANY_ACCESS) NTSTATUS DriverEntry(PDRIVER_OBJECT DriverObject, PUNICODE_STRING RegistryPath) { NTSTATUS status; PDEVICE_OBJECT deviceObject NULL; UNICODE_STRING deviceName; UNICODE_STRING deviceLink; // 設置卸載例程 DriverObject-DriverUnload DriverUnload; // 設置分發(fā)例程 DriverObject-MajorFunction[IRP_MJ_CREATE] MyDriverCreate; DriverObject-MajorFunction[IRP_MJ_CLOSE] MyDriverClose; DriverObject-MajorFunction[IRP_MJ_DEVICE_CONTROL] MyDriverIoctl; // 創(chuàng)建設備對象 RtlInitUnicodeString(deviceName, L\\Device\\MyDriverDevice); status IoCreateDevice(DriverObject, 0, deviceName, FILE_DEVICE_UNKNOWN, 0, FALSE, deviceObject); if (!NT_SUCCESS(status)) return status; // 創(chuàng)建符號鏈接 RtlInitUnicodeString(deviceLink, L\\??\\MyDriverLink); status IoCreateSymbolicLink(deviceLink, deviceName); if (!NT_SUCCESS(status)) { IoDeleteDevice(deviceObject); return status; } DbgPrint(MyDriver: DriverEntry loaded.\n); return STATUS_SUCCESS; }應用層Client.exe通信代碼核心片段#include windows.h #include stdio.h int main() { HANDLE hDevice CreateFileA(\\\\.\\MyDriverLink, GENERIC_READ | GENERIC_WRITE, FILE_SHARE_READ | FILE_SHARE_WRITE, NULL, OPEN_EXISTING, 0, NULL); if (hDevice INVALID_HANDLE_VALUE) { printf(Failed to open device. Error: %d\n, GetLastError()); return 1; } DWORD bytesReturned 0; ULONG input 123; ULONG output 0; BOOL success DeviceIoControl(hDevice, MYDRIVER_IOCTL_TEST, input, sizeof(input), output, sizeof(output), bytesReturned, NULL); if (success) { printf(IOCTL succeeded. Returned value: %lu\n, output); } CloseHandle(hDevice); return 0; }這套流程下來你就完整跑通了一個“創(chuàng)建設備→應用層open→通信→close→卸載”的閉環(huán)。在實際調試時要用DebugView勾選Kernel Verbose來觀察DbgPrint輸出這樣DriverEntry是否執(zhí)行、各個分發(fā)例程是否被調用、卸載流程是否干凈一眼就能看出來。3. 內核API分類體系從內存操作到對象管理的知識地圖Windows內核API數(shù)量龐大API分布在ntoskrnl.exe、hal.dll、ndis.sys等多個模塊里沒有任何人能全部背下來。真正有用的是按照“功能域”建立自己的知識體系知道什么時候該用哪類API、去哪查文檔。下面是我按實踐場景整理的分類地圖。3.1 內存管理類API分配/釋放/鎖頁內核編程最大的特點是不能隨便用malloc/free必須用內核專用API。這個差距是剛接觸驅動的人最容易出bug的地方。API用途注意事項ExAllocatePool2 / ExAllocatePoolWithTag分配非分頁/分頁內存Windows 10 2004之后推薦ExAllocatePool2帶PoolTag便于排查泄漏ExFreePoolWithTag釋放內存必須與分配時的Tag一致MmProbeAndLockPages鎖定用戶模式內存頁處理用戶空間緩沖區(qū)時必須先探測再鎖定MmUnlockPages解鎖內存頁鎖定后務必在結束路徑上解鎖這里必須給新手強調一個坑在內核驅動里處理用戶傳入的緩沖區(qū)時絕對不能直接解引用用戶模式指針。攻擊者可以傳入一個無效地址你解引用就直接藍屏。正確做法是先用ProbeForRead/ProbeForWrite探測或者依賴METHOD_BUFFERED方式讓I/O管理器幫你處理緩沖。用ExAllocatePool2舉個例子// 分配非分頁內存大小為1024字節(jié)Tag為Myd1 PVOID buffer ExAllocatePool2(POOL_FLAG_NON_PAGED, 1024, Myd1); if (buffer NULL) { DbgPrint(Failed to allocate memory.\n); return STATUS_INSUFFICIENT_RESOURCES; } // 使用完畢釋放 ExFreePoolWithTag(buffer, Myd1);注意ExAllocatePool2在返回NULL前不會像老API那樣拋異常所以判斷NULL是必須的。另外非分頁內存的大小要克制內核地址空間雖然大但非分頁池耗盡會導致整個系統(tǒng)進入內存壓力狀態(tài)后果就是卡頓甚至崩潰。3.2 進程與線程上下文類API獲取進程信息與句柄操作這類API是安全軟件、ARK工具的?？汀１热缒阆氡闅v進程列表或者根據(jù)PID獲取進程對象通常需要用到API用途PsLookupProcessByProcessId根據(jù)PID獲取EPROCESS對象PsGetCurrentProcess獲取當前進程的EPROCESSPsGetProcessImageFileName獲取進程鏡像文件名ObDereferenceObject釋放對象引用KeStackAttachProcess附加到目標進程上下文KeUnstackDetachProcess從目標進程上下文中脫離一個常見的場景我們需要判斷當前進程是不是某個特定進程然后執(zhí)行特殊邏輯。示例代碼如下NTSTATUS GetProcessNameByPid(HANDLE pid, char* buffer, SIZE_T maxLen) { PEPROCESS process NULL; NTSTATUS status PsLookupProcessByProcessId(pid, process); if (!NT_SUCCESS(status)) return status; // 獲取進程名 const char* name (const char*)PsGetProcessImageFileName(process); if (name) { strncpy(buffer, name, maxLen - 1); buffer[maxLen - 1] \0; } // 注意必須釋放引用 ObDereferenceObject(process); return STATUS_SUCCESS; }新手同樣高頻踩坑的地方PsGetProcessImageFileName返回的只是一個內部指針不是拷貝出來的新的字符串。如果你要長期保存這個字符串必須自己拷貝到安全的緩沖區(qū)如果直接引用后續(xù)可能EProcess被釋放輕則亂碼重則指針失效崩潰。3.3 對象管理與APC分發(fā)類API對象管理相關的API在安全防御中也很常用比如監(jiān)控進程創(chuàng)建、監(jiān)控句柄操作等。尤其是注冊Callback這種方式可以在不改動內核代碼的前提下實現(xiàn)監(jiān)控也是目前EDR最常用的手法之一API用途PsSetCreateProcessNotifyRoutineEx注冊進程創(chuàng)建/退出回調PsSetCreateThreadNotifyRoutine注冊線程創(chuàng)建/退出回調PsSetLoadImageNotifyRoutine注冊模塊加載回調DLL/驅動ObRegisterCallbacks注冊句柄操作回調權限提升防護這類API的特點是理論上它們本身沒有惡意能力但可以被用來做安全監(jiān)控也可以用來做信息竊取。所以我多說一句這些API的使用最好配合驅動簽名和明確的安全目的否則容易被安全軟件標記為可疑行為。在Windows 10較新版本以后微軟逐步用PsSetCreateProcessNotifyRoutineEx的第二個版本替代了舊版?zhèn)鲄⒅卸嗔艘粋€PSCREATEPROCESSNOTIFYINFO結構能拿到父進程PID、創(chuàng)建標志等更豐富的信息對溯源監(jiān)控非常有幫助。3.4 IRP與派遣函數(shù)設備通信的分發(fā)邏輯每個驅動由I/O管理器管理著一組IRPI/O Request Packet上層調用ReadFile、WriteFile、DeviceIoControl時最終都會轉換成相應的IRP并被分發(fā)到驅動注冊的派遣函數(shù)里。內核驅動的通信核心架構可以用一張表來說明IRP主功能碼分發(fā)函數(shù)注冊位應用層對應操作IRP_MJ_CREATEMajorFunction[0]CreateFileIRP_MJ_CLOSEMajorFunction[2]CloseHandleIRP_MJ_READMajorFunction[3]ReadFileIRP_MJ_WRITEMajorFunction[4]WriteFileIRP_MJ_DEVICE_CONTROLMajorFunction[14]DeviceIoControl實操中大部分自定義驅動只實現(xiàn)CREATE、CLOSE、DEVICE_CONTROL三個派遣函數(shù)就夠了。數(shù)據(jù)交互用IOCTL需要在驅動的頭文件里用CTL_CODE宏定義控制碼。注意IOCTL控制碼的DeviceType字段需要自定義時盡量使用大于0x8000的值避免與系統(tǒng)預留的設備類型沖突?？刂拼a定義如下#define MYDRIVER_IOCTL_TEST \ CTL_CODE(FILE_DEVICE_UNKNOWN, 0x800, METHOD_BUFFERED, FILE_ANY_ACCESS)METHOD_BUFFERED是默認推薦方式I/O管理器會分配一個系統(tǒng)緩沖區(qū)把用戶輸入復制進來、把輸出復制出去。這種方式的上下層緩沖區(qū)拷貝對安全性最友好不容易因為用戶進程結束了導致野指針。它的代價就是性能略低但好在大部分安全工具和控制類的驅動對性能要求沒那么苛刻。反而在高吞吐的網(wǎng)絡過濾或文件系統(tǒng)過濾驅動里你會用到METHOD_NEITHER或METHOD_IN_DIRECT等方式來減少拷貝那又是另一套處理上行了。4. 安全防御實戰(zhàn)從rootkit手法看對抗思路把標題里的“安全防御”單獨拿出來因為這部分如果你只想安安靜靜寫個業(yè)務驅動確實不太會接觸到但只要涉及到安全產品、EDR、反外掛、數(shù)字版權保護這些知識和前面講的是完全不同的能力要求。4.1 常見惡意驅動手段與防御視角在內核層面“攻”和“防”其實是同一套API的兩面。不懂這些經(jīng)典手法你就不知道敵方在什么地方下手自然也不知道該防什么。下面列幾個必須了解的套路手法原理典型案例防御手段驅動保護/反調試用驅動讀取或修改進程的DebugPort等字段阻止調試器附加游戲反外掛、惡意軟件反分析監(jiān)控敏感API調用校驗關鍵結構完整性強制修改SSDT/Inline Hook直接修改內核函數(shù)頭部的字節(jié)跳轉到自己的代碼攔截系統(tǒng)調用老式Rootkit、文件隱藏使用PatchGuard檢測或定期校驗代碼段完整性進程隱藏從EPROCESS鏈表摘除目標進程木馬隱藏自身進程監(jiān)控進程鏈表或使用無回調枚舉方式交叉驗證內核對象劫持修改對象頭中的進程/線程指針權限維持定期校驗對象類型做交叉驗證驅動加載后被截獲控制權偽造IOCTL指令讓驅動執(zhí)行任意操作無文件攻擊驅動層對IOCTL輸入做嚴格校驗增加白名單機制這里強調一個思路真正的安全不僅是靠驅動簽名更是靠“我能想到你會用哪招”的預設能力。如果你自己就動手重現(xiàn)過這些攻擊手法你自然會對驅動的對應用例在腦子里有防御預案。4.2 驅動自我保護技術Callback機制與PGPatchGuard長期運行的安全類驅動一個現(xiàn)實痛點是自己別被干掉。自我保護的核心有幾點優(yōu)先注冊回調而不是去掛鉤子。微軟提供的進程、線程、鏡像回調都是正規(guī)API只要做到驅動注冊殺軟一般不會主動警告盡量避免在驅動代碼里做敏感字符串拼接。很多惡意驅動喜歡把“readme”等無關字符串硬編碼成常量來偽裝而安全產品掃描驅動文件時會看導入表和字符串能在用戶態(tài)解決的事別放內核態(tài)。內核驅動的每一條路徑都是高權限入口暴露面越大漏洞風險越高同時Windows內核有一個特殊的保護機制叫Kernel Patch Protection業(yè)界俗稱KPP或PatchGuard。從64位Vista開始微軟就通過周期性檢測防止內核關鍵結構被修改比如SSDT、IDT、GDT、MSR等。如果檢測到被篡改系統(tǒng)直接藍屏這對傳統(tǒng)的內核掛鉤Inline Hook手段是個巨大的威懾。所以在現(xiàn)代Windows系統(tǒng)上任何嘗試修改關鍵系統(tǒng)結構的內核代碼都注定是危險且短命的。更可持續(xù)的防御是“合規(guī)的偵查”也就是通過微軟公開的回調機制了解系統(tǒng)里正在發(fā)生什么把自己放在“監(jiān)測者”的位置而不是“篡改者”的位置。這也是安全行業(yè)現(xiàn)在的主流做法。4.3 如何排查和檢測可疑驅動的加載防御視角的另一半是“識別出有問題的驅動”。從系統(tǒng)管理員的角度你可以用這些內置工具快速摸查# 查看所有內核驅動服務及狀態(tài) driverquery /v # 查看已加載驅動列表包括路徑 sc query type driver sc queryex MyDriver # 查看驅動的數(shù)字簽名狀態(tài) Get-AuthenticodeSignature C:\Windows\System32\drivers\*.sys如果需要自動化排查可以用PowerShell腳本來枚舉所有驅動文件的簽名# 找出未簽名或被篡改的驅動以管理員身份運行 $unsignedDrivers Get-ChildItem C:\Windows\System32\drivers\*.sys | Where-Object { (Get-AuthenticodeSignature $_.FullName).Status -ne Valid } $unsignedDrivers | Select-Object Name, FullName這腳本的價值在于異常驅動往往在簽名狀態(tài)上露出馬腳。比如一個自稱來自微軟的驅動簽名狀態(tài)卻是“NotSigned”或“HashMismatch”那基本可以懷疑是被植入了。如果擔心惡意驅動通過直接修改內存的方式隱藏自己更深層的檢測方法就是枚舉內核模塊的加載列表然后與文件系統(tǒng)中的.sys文件做交叉比對。正常驅動都會在模塊列表里而那些只靠手動映射不經(jīng)過正常加載路徑的惡意代碼就不會出現(xiàn)在這里——這就是隱蔽與檢測之間的攻防戰(zhàn)場。4.4 實際檢測中的踩坑PatchGuard誤報藍屏在介紹這些防御機制后我不得不分享一個真實踩過的坑。有次我在測試一款安全工具的驅動時用WinDbg在調試機上嘗試修改SSDT里一個函數(shù)的首字節(jié)本意是模擬惡意行為看EDR能不能檢測到。結果系統(tǒng)在幾分鐘后毫無征兆地藍屏了dump分析顯示就是PatchGuard被觸發(fā)。調試時觸發(fā)KPP藍屏幾乎是每個內核安全研究者必經(jīng)的經(jīng)歷。這個坑的核心教訓不是“不要用補丁”而是在Windows 10/11上任何針對內核關鍵結構的修改都極其危險可能當場藍屏也可能在隨機延遲后藍屏藍屏的bugcheck代碼通常是0x109CRITICAL_STRUCTURE_CORRUPTION即使你的目的是安全檢查這種操作也必須放在隔離的測試機上進行別拿主力開發(fā)機當場實驗從那以后我再做內核完整性校驗測試都會用兩種方式替代硬改一是通過WinDbg的寫內存指令臨時測試重啟即恢復二是在測試虛擬機里做快照實驗前先打個快照點藍屏了直接還原。5. 總結但可能不是你想的那種總結我見過太多人學內核驅動第一步就卡死在“編譯通過但加載失敗”的報錯里于是放棄了。實際上這個領域的入門并沒有想象中那么難難的是對每一步背后的機制缺乏耐心去琢磨。如果你現(xiàn)在正要開始動手我的建議很簡單先把開發(fā)環(huán)境搭穩(wěn)、測試簽名打開、寫一個什么都不做的空驅動、跑通加載和卸載、依賴DebugView看到日志。這套流程走通了你才算真正邁進了內核驅動的門檻。后面無論是研究內核API還是做安全防御都是在“能控制和理解加載周期”這個地基上蓋樓。地基越穩(wěn)后面越不容易被那些抽象的概念勸退。