本次實(shí)驗(yàn)的測試環(huán)境為Windows Server 2008 R2 X64下。

為了解決例如系統(tǒng)關(guān)鍵目錄或者業(yè)務(wù)敏感目錄被放入惡意的可執(zhí)行程序或者網(wǎng)頁文件等，一些安全軟件會(huì)使用文件過濾驅(qū)動(dòng)的技術(shù)結(jié)合一定的檢測規(guī)則來達(dá)到保護(hù)系統(tǒng)和業(yè)務(wù)安全的一些目的。

簡單地來看下Minifilter技術(shù)的介紹：

Filter管理器隨Windows一起被安裝，但它只在一個(gè)minifilter驅(qū)動(dòng)被加載時(shí)才會(huì)起作用。Filter管理器綁定到目標(biāo)卷的文件系統(tǒng)棧上。Minifilter驅(qū)動(dòng)為它要過濾的I/O操作而通過向filter管理器注冊來間接綁定到文件系統(tǒng)棧上。Filter管理器隨Windows一起被安裝，但它只在一個(gè)minifilter驅(qū)動(dòng)被加載時(shí)才會(huì)起作用。Filter管理器綁定到目標(biāo)卷的文件系統(tǒng)棧上。Minifilter驅(qū)動(dòng)為它要過濾的I/O操作而通過向filter管理器注冊來間接綁定到文件系統(tǒng)棧上。

微軟的WDK實(shí)例中存在通過使用REPARSE重定向來完成跨盤的重定向，以及通過Minifilter使用IoCreateFileSpecifyDeviceObjectHint來完成的非跨盤重定向。

所以，我們的目標(biāo)是先通過Windows部分內(nèi)核代碼來看看為何Reparse能夠完成文件重定向的功能，再通過實(shí)現(xiàn)一個(gè)能夠簡易配置監(jiān)視路徑和重定向后路徑的驅(qū)動(dòng)程序和應(yīng)用控制程序。

通過源碼查看文件創(chuàng)建源碼的關(guān)鍵部分

雖然是Windows Server 2008 x64系統(tǒng)，但是為了避免過多的逆向分析,直接以WRK為目標(biāo)（由于無法過多引用，所以盡量以文字描述），看看是否可以得到關(guān)于Reparse重定向的結(jié)論。

創(chuàng)建文件的入口為IoCreateFile時(shí)，其主要工作由IopCreateFile的ObOpenObjectByName來完成，其為一個(gè)對象管理的內(nèi)核函數(shù)。

ObOpenObjectByName函數(shù)中主要完成的2個(gè)工作是調(diào)用ObpLookupObjectName函數(shù)即對應(yīng)我們真正的文件內(nèi)核對象，并通過ObpCreateHandle完成內(nèi)核對象到指定句柄表的插入。

其實(shí)最后的答案就在這個(gè)ObpLookupObjectName函數(shù)內(nèi)，由于函數(shù)存在可選輸入?yún)?shù)RootDirectoryHandle作為搜索的目錄對象，但是類似地我們以不提供該參數(shù)的流程分析其中工作。

第一步，它會(huì)使用ObpRootDirectoryObject為搜索的根目錄對象，處理了以“??”開頭的對象名，以當(dāng)前進(jìn)程的ProcessMap為父目錄的查找。接著進(jìn)入循環(huán)依次解析對象名中的每個(gè)段，在訪問前非KernelMode的訪問必須經(jīng)過安全性檢查，進(jìn)入ObpLookupDirectoryEntry中其對當(dāng)前層對象名計(jì)算其Hash值后與Hash數(shù)組大小37取余，其存在后繼鏈表當(dāng)獲取到的對象的OBJECT_HEADER_NAME_INFO和提供的名稱一致后就返回這個(gè)這個(gè)對象的地址。直接調(diào)用其對象類型的ParseProcedure（進(jìn)入IopParseFile->IopParseDevice從而向?qū)?yīng)的卷對象發(fā)送請求）。

閱讀后發(fā)現(xiàn)返回了STATUS_REPARSE后會(huì)轉(zhuǎn)入ParseFromRoot處，完成從前面描述的DeviceMap處處理的重新解析。

這說明了STATUS_REPARSE確實(shí)可以幫助我們完成一個(gè)文件位置到另一個(gè)文件位置的重定向（比如某類目錄總是STATUS_REPARSE，而且STATUS_REPARSE在ObpLookupObjectName有次數(shù)限制），第二由于交還給對象管理器時(shí)會(huì)完完整整地重新解析，所以這確實(shí)可以完成跨盤的操作。

實(shí)現(xiàn)可配置文件的文件系統(tǒng)跨盤重定向

我們目標(biāo)是實(shí)現(xiàn)一個(gè)應(yīng)用程序?qū)⒈O(jiān)控配置發(fā)送給驅(qū)動(dòng)，驅(qū)動(dòng)將需要重定向文件的結(jié)果報(bào)告給應(yīng)用程序。其中驅(qū)動(dòng)完成將在監(jiān)控文件夾內(nèi)的新建文件全部轉(zhuǎn)移到目標(biāo)文件夾下的操作。

首先我們主要關(guān)心如何截獲特定路徑下的文件創(chuàng)建操作。我們先完成對卷實(shí)例的綁定工作。這個(gè)回調(diào)例程在新的卷被掛載后以及注冊后已經(jīng)掛載卷后被調(diào)用。在這個(gè)回調(diào)中主要通過FltGetVolumeName和完成卷的設(shè)備名稱和卷標(biāo)名稱的獲取，并通過FltAllocateContext從內(nèi)存池或者lookaside表種得到獲取保存上下文的內(nèi)存，F(xiàn)ltSetInstanceContext來完成設(shè)置到實(shí)例中，為了滿足程序能夠跨盤重定向后以DOS風(fēng)格名稱發(fā)送給應(yīng)用程序故加入雙鏈表中以便獲取其他盤的信息。

對于綁定后InstanceQueryTeardownCallback，InstanceTeardownStartCallback，InstanceTeardownCompleteCallback3類回調(diào)的處理，值得注意的是InstanceQueryTeardownCallback，因?yàn)槠鋵?yīng)手工的解綁定，我們簡單地直接返回STATUS_FLT_DO_NOT_DETACH以拒絕。

現(xiàn)在我們來看對應(yīng)主功能號為IRP_MJ_CREATE的處理，而主功能號（Minifilter中）為IRP_MJ_NETWORK_QUERY_OPEN的請求，我們也請求處理到了這里，由于其是一個(gè)Fast I/O操作，所以返回FLT_PREOP_DISALLOW_FASTIO來拒絕。我們使用了FltGetFileNameInformation和FltParseFileNameInformation來得到其文件名信息，后者是為了方便獲得卷設(shè)備名以轉(zhuǎn)換成DOS風(fēng)格名。

這個(gè)過程中，我們根據(jù)實(shí)例上下文鏈表及配置生成2個(gè)名稱，一個(gè)是DOS風(fēng)格文件名及完整文件名，前者以發(fā)送給應(yīng)用程序，后者設(shè)置到FileObject中（使用IoReplaceFileObjectName），并在I/O請求包中返回STATUS_REPARSE以完成第一部分分析讓這個(gè)創(chuàng)建操作再重新根據(jù)新名稱重新從對象管理處開始處理。對于回調(diào)函數(shù)返回FLT_PREOP_COMPLETE來完成這個(gè)I/O請求，并不往下發(fā)送請求。

IRP_MJ_CREATE的操作IRP_MJ_SET_INFORMATION的FileInformationClass為FileRenameInformation的處理，因?yàn)閷τ诜强绫P的移動(dòng)會(huì)通過這個(gè)請求來完成操作，所以使用同IRP_MJ_CREATE一樣的操作。

最后提一下Minifilter中由應(yīng)用程序向驅(qū)動(dòng)的信息發(fā)送和驅(qū)動(dòng)主動(dòng)向應(yīng)用程序發(fā)送的處理。應(yīng)用程序以通過FilterConnectCommunicationPort向命名的通信端口請求連接。驅(qū)動(dòng)內(nèi)部通過PFLT_MESSAGE_NOTIFY MessageNotifyCallback回調(diào)接受收監(jiān)控的目錄和重定向后的目錄。最后，完成重定向后驅(qū)動(dòng)使用FltSendMessage發(fā)送消息，應(yīng)用程序使用FilterGetMessage獲取。