【文章內容簡介】 有Ring0的權限才能訪問，低2GB為每個進程所獨有，沒有權限限制（若系統(tǒng)啟動時啟用了/3GB選項，則共享空間為1GB，進程的專有地址空間為3GB）。因為此方法在用戶態(tài)下進行，所以所有的修改只對某一進程有效。對每一個進程都進行一次修改，效率不高，也會影響系統(tǒng)的運行速度。(2)Windows中調用DLL中的函數不僅可以直接使用導入表，也可以在程序運行時使用GetModuleHandle與GetProcAddress函數動態(tài)獲取函數地址。若木馬程序采用了VB等默認采用此種方式調用API函數的語言，則可能出現(xiàn)漏報的情況。共享地址空間專有地址空間2GB04GB共享地址空間專有地址空間2GB04GB物理內存共享地址空間圖 Windows進程的地址空間部局l 方案二優(yōu)點：(1)不依賴系統(tǒng)中已有的跳轉指令，對任何函數，任何程序均適用。(2)此步驟為API函數調用的最后一步，最為底層。缺點：(1)同一函數的前幾條指令可能會隨著程序版本的更新發(fā)生變化，對“執(zhí)行被覆蓋的指令”這一步提出了較高的要求。(2)因x86指令是變長指令，在返回原函數時，一旦跳轉的地址不正確，將引起后續(xù)指令解釋錯誤，進而引起程序崩潰。對被覆蓋的指令相對于跳轉指令多余的部分，一般使用nop指令進行填充，但這樣仍不能消除跳轉失敗的危險?！盎ㄖ噶睢笔莤86指令的此項特性正面利用，通過在程序中加入跳轉指令和無用字節(jié)來防止程序被反匯編。l 方案三優(yōu)點：(1)系統(tǒng)服務分派表在共享內存區(qū)，對所有進程均有效(2)僅服務ID對應的函數地址，不覆蓋任何指令，不存在跳轉失敗的危險缺點：每一次Windows版本的更新，內核都會增加新的函數，服務ID也會相應發(fā)生變化，因此需要對不同的Windows版本進行不同的處理。綜上所述，本程序采用了方案三實現(xiàn)行為監(jiān)控。 具體實現(xiàn) 修改系統(tǒng)服務分派表修改系統(tǒng)服務分派表的目的在于將API函數調用引至驅動模塊中自定義的函數而非默認情況下系統(tǒng)內核的函數。但兩處獲取的結果卻有所不同，，否則將會因無效地址引起藍屏。，需要通過GUI線程ETHREAD結構的ServiceTable獲取指針。與系統(tǒng)服務分派表有關的數據結構如下圖所示：ETHREADServiceTableSYSTEM_SERVICE_TABLEServiceTableCounterTableServiceLimitArgumentTableServiceTableCounterTableServiceLimitArgumentTableNULLServiceTableCounterTableServiceLimitArgumentTableNULLServiceTableCounterTableServiceLimitArgumentTable18h2Ch2Ch2Ch4Ch…………………………08h0Ch10h04h0hKiArgumentTableNtAcceptConnectPortNtAccessCheckNtAccessCheckAndAuditAlarmNtAccessCheckByType………………………………NtOpenChannelNtReplyWaitSendChannelNtSendWaitReplyChannelNtSetContextChannelNtYieldExecutionKiServiceTable圖 系統(tǒng)中共有4張分派表，其服務ID范圍為0h——FFFh，服務ID的范圍為1000h——1FFFh。SYSTEM_SERVICE_TABLE結構的ServiceTable和ArgumentTable分別指向一個數組，以服務ID為索引，對應處即為相應函數的地址或參數大小。本程序接管的API函數可參考表 。 構建自己的API函數驅動模塊修改系統(tǒng)服務分派表成功后，若某一程序再對已接管的API函數進行調用，將直接轉到驅動模塊指定的函數。在指定的函數中，驅動模塊完成了以下過程（如圖 ）：用戶程序調用收集信息是否是跨進程操作允許操作阻止操作將信息發(fā)送給用戶態(tài)程序是否圖 (1)收集發(fā)起操作的進程和目標進程的信息(2)將收集的信息發(fā)送到用戶態(tài)的程序(3)阻塞當前線程，等待用戶態(tài)程序規(guī)則匹配的結果(4)根據結果決定執(zhí)行此操作或阻止此操作 下面以NtUserMessageCall函數為例進行說明。 我們自己的API函數的定義最好與原API函數相同，以便與系統(tǒng)服務參數表中的參數大小一致。NtUserMessageCall函數的定義如下（其定義與用戶態(tài)的SendMessage稍有不同）：NtUserMessageCall proc hWnd:HANDLE,lngMessage:DWORD,wParam:DWORD,lParam:DWORD,xParam:DWORD,pProc:PVOID,blnAnsi:BOOLhWnd：接收消息的窗口lngMessage：要發(fā)送的消息wParam，lParam：與消息有關的兩個參數blnAnsi：字符串是否為ANSI編碼在上述的4個步驟中，需要注意的是通過hWnd參數判斷目標窗口所在的進程這一步。因為Native API與Win32 API并不一定存在一一對應的關系，因此不能使用GetWindowThreadProcessId函數。下表列出了本程序使用的Native API與Win32 API間的關系：Native APIWin32 APINtUserQueryWindowGetWindowThreadProcessIdGetActiveWindowIsHungAppWindowNtCreateSectionCreateFileMappingNtCloseCloseHandle此處使用了NtUserQueryWindow函數代替了GetWindowThreadProcessId，NtUserQueryWindow的定義如下：NtUserQueryWindow proc hWnd:HANDLE,lngWindowInfoClass:DWORDhWnd：窗口句柄lngWindowInfoClass：要查詢的信息類型，為下列值：WindowProcessId0窗口所在進程的IDWindowThreadId1窗口所在的線程IDWindowActiveWindow2獲取進程內活動窗口句柄WindowIsHung4窗口是否已掛起此處使用WindowsProcessId來查詢窗口所在進程。 與用戶態(tài)程序間的通訊 背景：線程同步與數據傳輸的問題在驅動程序收集了足夠的信息后，需要將信息傳遞給用戶態(tài)程序，或是提示用戶，或是根據已定的行為規(guī)則進行判斷。此時驅動程序所在地虛擬地址空間為調用者的地址空間，因此數據傳遞是一個跨進程的數據傳遞。同時，對某些操作，需要由用戶選擇是否允許，此時，就需要把調用者當前的線程暫停下來，等待用戶選擇后再繼續(xù)執(zhí)行，讓調用者與本程序的線程間保持同步。圖 ，需要用戶進行選擇 方案比較 線程同步：事件/事件對 對于暫停一個線程，等待另一個線程通知再繼續(xù)執(zhí)行的情況，可以使用事件對線程進行同步，下圖表示了以事件作為同步機制的核心態(tài)與用戶態(tài)程序間通訊的過程。調用者的某線程監(jiān)控程序的驅動模塊調用者監(jiān)控程序的處理線程在事件1上等待在事件2上等待將事件設置為信號態(tài)，喚醒線程進行規(guī)則匹配返回結果將事件設置為信號態(tài)，喚醒線程繼續(xù)執(zhí)行圖 ，與用戶態(tài)程序通訊的過程使用線程作為同步機制最為簡單，但僅對同一時刻只有一個程序調用較容易實現(xiàn)，若同時有多個程序調用，而監(jiān)控程序只有一個處理線程時，則很有可能出現(xiàn)線程被死鎖等問題。 數據傳輸：進程地址空間切換如前文所述，調用者調用某函數時，驅動模塊所處的虛擬地址空間為調用者的地址空間。要將數據傳遞給用戶態(tài)程序，最簡單的方式為直接使用KeAttachProcess函數將進程的地址空間切換到用戶態(tài)程序的地址空間。但此方法有一定的危險性，若用戶態(tài)程序因某種原因異常結束，而驅動模塊沒有得到通知，仍然嘗試進行切換，則有可能藍屏。同時，在多個調用者同時進行調用，而用戶態(tài)程序只有一個緩沖區(qū)時，可能出現(xiàn)后來的信息將之前的信息覆蓋的情況。 LPC(本地過程調用)的優(yōu)勢LPC作為Windows中客戶程序與子系統(tǒng)間的通訊機制，以端口（Port）對象作為工具，同時具備了線程同步與數據傳輸的能力。端口對象內部使用事件作為同步機制，但在多個客戶端同時向端口發(fā)送消息時，可以自動形成LPC消息隊列，使服務端能對消息逐一進行處理。對于小于512字節(jié)的數據，LPC機制直接復制消息，對于較大塊的數據，則通過內存映射的方式將數據共享。LPC機制的錯誤處理相對成熟，若服務端程序異常結束，能及時的通知客戶端程序，不會出現(xiàn)線程在某一事件上“死等”以及因嘗試切換到已結束進程的地址空間而造成藍屏。綜上所述，本程序采用了LPC機制作為驅動模塊與用戶態(tài)程序通訊的工具。 LPC機制的具體實現(xiàn)LPC通過端口對象進行通訊，通訊的進程一方作為服務器，一方作為客戶端。對于小于394字節(jié)的消息，可直接嵌入LPC的數據結構中，通過復制完成傳遞。對于大于394字節(jié)的消息，Windows通過將共享內存區(qū)域映射到通訊的兩個進程的地址空間中完成數據傳遞。完成LPC通訊的步驟如下：(1)服務端創(chuàng)建端口對象(2)客戶端請求連接(3)服務端接受/拒絕連接(4)客戶端請求，服務端響應(5)通訊完畢，雙方關閉端口本程序將驅動程序一方作為客戶端，將用戶態(tài)程序一方作為服務端。 客戶端操作在連接LPC端口的過程中，Windows將完成共享內存區(qū)的映射，因此需要在連接之前準備好共享內存區(qū)?？蛻舳伺c服務端均可創(chuàng)建共享內存區(qū)，但只有創(chuàng)建的一方可以寫入，另一方則只讀。通過NtCreateSection函數可以創(chuàng)建內存區(qū)。定義：NTSTATUSNtCreateSection ( OUT PHANDLE SectionHandle, IN ACCESS_MASK DesiredAccess, IN POBJECT_ATTRIBUTES ObjectAttributes OPTIONAL, IN PLARGE_INTEGER MaximumSize OPTIONAL, IN ULONG SectionPageProtection, IN ULONG AllocationAttributes, IN HANDLE FileHandle OPTIONAL )參數：SectionHandle：返回內存區(qū)句柄DesiredAccess：訪問權限，可為EXECUTE/READ/WRITEObjectAttributes：內存區(qū)的屬性，可設置其名稱MaximumSize：最大大小，為64位的整數。SectionPageProtection：對該內存區(qū)內頁面的保護，可為PAGE_READ/PAGE_READWRITE/PAGE_EXECUTE/PAGE_WRITECOPY/PAGE_NOCACHEAllocationAttributes：分配方式，可為SEC_RESERVE/SEC_COMMIT/SEC_IMAGE/SEC_FILE/SEC_NO_CHANGEFileHandle：設置映射到該內存區(qū)的文件。共享內存區(qū)創(chuàng)建完成后，客戶端應該向其中寫入要傳遞的數據并通過NtConnectPort發(fā)出連接請求。定義：NTSTATUSNTAPINtConnectPort ( OUT PHANDLE PortHandle, IN PUNICODE_STRING PortName, IN PSECURITY_QUALITY_OF_SERVICE SecurityQos, IN OUT PPORT_VIEW ClientView OPTIONAL, IN OUT PREMOTE_PORT_VIEW ServerView OPTIONAL, OUT PULONG MaxMessageLength OPTIONAL, IN OUT PVOID ConnectionInformation OPTIONAL, IN OUT PULONG ConnectionInformationLength OPTIONAL)參數：PortHandle：返回用于通訊的端口句柄PortName：要連接的端口名稱SecurityQos：服務質量的信息，可查閱MSDN中有關RPC的章節(jié)ClientView：由客戶端創(chuàng)建的要共享的內存區(qū)信息，客戶端可讀寫ServerView：接收服務端共享的內存區(qū)信息，客戶端只讀MaxMessageLength：消息的最大長度ConnectionInformation、ConnectionInformationLength：連接信息及長度對創(chuàng)建內存區(qū)的一方，內存區(qū)的信息由LpcSectionOwnerMemory結構保存。用戶程序需填寫_Length與SectionHandleLpcSectionOwnerMemory STRUCT _Length dd ? 。