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