文件過濾驅動及應用

① 文件過濾驅動和磁碟過濾驅動有什麼區別

神馬狗屁老師教的啊

② 如何設計單機版的文件過濾驅動

透明指的是用戶在操作的時候，雖然後台在自動的進行加解密，但是用戶根本就不知道加密內的存在，就像中間容隔了一層透明的玻璃一樣。透明的好處在於不改變用戶的操作，一切都和加密之前一樣，甚至在有些企業安裝加密後都無需通知所有的員工，就像加密並不存在一樣，只是加密文件到了企業安全環境的外部才會發現文件無法打開。透明的程度也是加密軟體一個很重要的方面，例如：正在編輯一個Word文件時，能否拷貝或者使用其他程序來讀取這個文件，如果不能那麼這里就不夠透明，在一些PDM的文檔管理軟體中就是文件在一個應用程序打開狀態時另一個應用程序進行檢入。透明的程度越高，用戶使用時就越是和未加密時一樣，透明程序越低用戶就會發現有越多的操作受到限制，和加密前有較大的差異。

③ 怎麼用代碼實現WDM文件過濾驅動安裝

為了讓這個驅動被系統載入，必須創建一個inf文件。由於是使用現成的例子，因此這一步也可以省下來。直接右鍵點擊例子中的inf文件，在彈出的菜單中選擇「安裝」即可。
這里要注意的是，inf中的StartType參數，它可以控制驅動被載入的方式：
SERVICE_AUTO_START (2) 安全模式下不會自動載入 SERVICE_BOOT_START (0) 在系統安全模式下啟動時 驅動也會自動載入
SERVICE_DEMAND_START(3) 則驅動不會自動載入
因為是測試，我使用SERVICE_DEMAND_START，即由手動載入驅動。例子是miniFilter驅動，因此可以在命令提示行中用「fltmc load 驅動名稱」來載入，相應的卸載是「fltmc unload」。如果是其它驅動，則用"net start 驅動名稱"來載入，相應的卸載是"net stop 驅動名稱"。注意驅動名稱不是文件名，而是inf中[Settings]的ServiceName值。驅動要發布時，也可以通過CreateService & StartService API來動態安裝。
Inf文件的寫法，可以參考例子，或者拿現成的改一改。下面的是摘自驅動開發網的
XiangXiangRen整理的Inf文件，改起來比較方便，謝謝XiangXiangRen

④ windows10文件驅動過濾

1、獲得文件全路徑以及判斷時機

除在所有 IRP_MJ_XXX 之前自己從頭創建 IRP 發送到下層設備查詢全路徑外，不要嘗試在 IRP_MJ_CREATE 以外的地方獲得全路徑，因為只有在 IRP_MJ_CREATE
中才會使用 ObCreateObject() 來建立一個有效的 FILE_OBJECT。而在 IRP_READ IRP_WRITE 中它們是直接操作 FCB (File Control Block)的。

2、從頭建立 IRP 發送關注點

無論你建立什麼樣的 IRP，是 IRP_MJ_CREATE 也好還是 IRP_MJ_DIRECTORY_CONTROL也罷，最要提醒的就是一些標志。不同的標志會代來不同的結果，有些結果是直接返回失敗。這里指的標志不光是 IRP->Flags，還要考慮 IO_STACK_LOCATION->Flags還有其它等等。尤其是你要達到一些特殊目的，這時候更需要注意，如 IRP_MN_QUERY_DIRECTORY，不同的標志結果有很大的不同。

3、從頭建立 IRP 獲取全路徑注意點

自己從頭建立一個 IRP_MJ_QUERY_INFORMATION 的 IRP 獲取全路徑時需要注意，不僅在 IRP_MJ_CREATE 要做區別處理，在 IRP_MJ_CLOSE 也要做同樣的處理，否則如果目標是 NTFS 文件系統的話可能產生 deadlock。如果是 NTFS 那麼在 IRP_MJ_CLEANUP 的時候也需要對 FO_STREAM_FILE 類型的文件做同樣處理。

4、獲得本地/遠程訪問用戶名（域名/SID）

方法只有在 IRP_MJ_CREATE 中才可用，那是因為 IO_SECURITY_CONTEXT 只有在 IO_STACK_LOCATION->Parameters.Create.SecurityContext 才會有效。這樣你才有可能從 IO_SECURITY_CONTEXT->SecurityContext->AccessState->SubjectSecurityContext.XXXToken 中獲得訪問 TOKEN，從而進一步得到用戶名或 SID。記得 IFS 中有一個庫，它的 LIB 導出一個函數可以讓你在獲得以上信息後得到用戶名與域名。但如果你想兼容 NT4 的話，只能自己分析來得出本地和遠程的 SID。

5、文件與目錄的判斷

正確的方法在楚狂人的文檔里已經說過了，再補充一句。如果你的文件過濾驅動要兼容所有文件系統，那麼不要十分相信從 FileObject->FsContext 里取得的數據。正確的方法還是在你傳遞下去 IRP_MJ_CREATE 後從最下層文件系統延設備棧返回到你這里後再獲得。

6、加/解密中判斷點

只判斷 IRP_PAGING_IO，IRP_SYNCHRONOUS_PAGING_IO，IRP_NOCACHE 是沒錯的。如果有問題，相信是自己的問題。關於有人提到在 FILE_OBJECT->Flags中的 FO_NO_INTERMEDIATE_BUFFERING 是否需要判斷，對此問題的回答是只要你判斷了 IRP_NOCACHE 就不用再判斷 FILE_OBJECT 中的，因為它最終會設置 IRP->Flags 為 IRP_NOCACHE。關於你看到的諸如 IRP_DEFER_IO_COMPLETION 等 IRP 不要去管它，因為它只是一個過程。最終讀寫還是如上所介紹。至於以上這些 IRP 哪個是由 CC MGR 發送的，哪些是由 I/O MGR 發送和在什麼時候發送的，這個已經有很多討論了，相信可以找到。

7、舉例說明關於 IRP 傳遞與完成注意事項

只看 Walter Oney 的那本 《Programming the Microsoft Windows driver model》里介紹的流程，自己沒有實際的體會還是不夠的，那裡只介紹了基礎概念，讓自己有了知識。知道如何用，在什麼情況下用，用哪種方法，能夠用的穩定這叫有了技術。我們從另一個角度出發，把問題分為兩段來看，這樣利於總結。一個 IRP 在過濾驅動中，把它分為需要安裝 CompleteRoutine 的與無需安裝 CompleteRoutine 的。那麼在不需要安裝 CompleteRoutine 的有以下幾類情況。

(1) 拿到這個 IRP 後什麼都不做，直接調用 IoCompleteRequest() 來返回。
(2) 拿到這個 IRP 後什麼都不做，直接傳遞到底層設備，使用IoSkipCurrentIrpStackLocation() 後調用 IoCallDriver() 傳遞。
(3) 使用 IoBuildSynchronousFsdRequest() 或 IoBuildDeviceIoControlRequest()來建立 IRP 的。

以上幾種根據需要直接使用即可，除了一些參數與標志需要注意外，沒有什麼系統機制相關的東西需要注意了。那麼再來看需要安裝 CompleteRoutine 的情況。我們把這種情況再細分為兩種，一是在 CompleteRoutine 中返回標志為STATUS_MORE_PROCESSING_REQUIRED 的情況。二是返回處這個外的標志，需要使用函數IoMarkIrpPending() 的情況。在 CompleteRoutine 中絕大多數就這么兩種情況，你需要使用其中的一種情況。那麼為什麼需要安裝 CompleteRoutine 呢？那是因為我們對其 IRP 從上層驅動，經過我們驅動，在經過底層設備棧返回到我們這一層驅動時需要得到其中內容作為參考依據的，還有對其中內容需要進行修改的。再有一種情況是沒有經過上層驅動，而 IRP 的產生是在我們驅動直接下發到底層驅動，而經過設備棧後返回到我們這一層，且我們不在希望它繼續向上返回的，因為這個 IRP 本身就不是從上層來的。綜上所述，先來看下 IoMarkIrpPending() 的情況。

(1) 在 CompleteRoutine 中判斷 Irp->PendingReturned 並使用 IoMarkIrpPending()然後返回。這種方法在沒有使用 KeSetEvent() 的情況下，且不是自建 IRP 發送到底層驅動返回時使用。也就是說有可能我所做的工作都是在 CompleteRoutine 中進行的。比如加/解密時，我在這里對下層驅動返回數據的判斷並修改。修改後因為沒有使用 STATUS_MORE_PROCESSING_REQUIRED 標志，它會延設備堆一直向上返回並到用戶得到數據為止。這里一定要注意，在這種情況下 CompleteRoutine返回後，不要在碰這個 IRP。也就是說如果這個時候你使用了 IoCompleteRequest()的話會出現一個 MULTIPLE_IRP_COMPLIETE_REQUEST 的 BSOD 錯誤。

(2) 在 CompleteRoutine 中直接返回 STATUS_MORE_PROCESSING_REQUIRED 標志。這種情況在使用了 KeSetEvent() 的函數下出現。這里又有兩個小小的分之。

1) 出現於上層發送到我這里，當我這里使用 IoCallDriver() 後，底層返回數據經過我這一層時，我想讓它暫時停止繼續向上傳遞，讓這個 IRP 稍微歇息一會，等我對這個 IRP 返回的數據操作完成後（一般是沒有在 CompleteRoutine中對返回數據進行操作情況下，也就是說等到完成常式返回後再進行操作），由我來調用 IoCompleteRequest() 讓它延著設備棧繼續返回。這里要注意，我們是想讓它返回的，所以調用了 IoCompleteRequest()。這個可不同於下面所講的自己從頭分配 IRP 時在 CompleteRoutine 中已經調用 IoFreeIrp() 釋放了當前IRP 的情況。比如我在做一個改變文件大小，向文件頭寫入加密標志的驅動時，在上層發來了 IRP_MJ_QUERY_INFORMATION 查詢文件，我想在這個時候獲得文件信息進行判斷，然後根據我的判斷結果再移動文件指針。注意：上面是兩步，第一步是先獲得文件大小，那麼在這個時候我就需要用到上述辦法，先讓這個 IRP傳遞下去，得到我想要的東西後在進行對比。等待適當時機完成這個 IRP，讓數據繼續傳遞，直到用戶收到為止。第二步我會結合下面小節來講。

2) 出現於自己從頭建立 IRP，當使用 IoAllocate() 或 IoBuildAsynchronousFsdRequest()創建 IRP 調用 IoCallDriver() 後，底層返回數據到我這一層時，我不想讓這個 IRP 繼續向上延設備棧傳遞。因為這個 IRP 就是在我這層次建立的，上層本就不知道有這么一個 IRP。那麼到這里我就要在 CompleteRoutine 中使用 IoFreeIrp()來釋放掉這個 IRP，並不讓它繼續傳遞。這里一定要注意，在 CompleteRoutine函數返回後，這個 IRP 已經釋放了，如果這個時候在有任何關於這個 IRP 的操作那麼後果是災難性的，必定導致 BSOD 錯誤。前面 1) 小節給出的例子只完成了第一步這里繼續講第二步，第一步我重用這個 IRP 得到了文件大小，那麼這個時候雖然知道大小，但我還是無法知道這個文件是否被我加過密。這時，我就需要在這里自己從頭建立一個 IRP_MJ_READ 的 IRP 來讀取文件來判斷是否我加密過了的文件，如果是，則要減少相應的大小，然後繼續返回。注意：這里的返回是指讓第一步的IRP 返回。而不是我們自己創建的。我們創建的都已經在CompleteRoutine 中銷毀了。

8、關於完成 IRP 的動作簡介

當一個底層驅動調用了 IoCompleteRequest() 函數時，基本上所有設備棧相關 IRP 處理工作都是在它那裡完成的。包括 IRP->Flags 的一些標志的判斷，對 APC 的處理，拋出MULTIPLE_IRP_COMPLETE_REQUESTS 錯誤等。當它延設備棧一直調用驅動所安裝的 CompleteRoutine時，如果發現 STATUS_MORE_PROCESSING_REQUIRED 這個標志，則會停止向上繼續回滾。這也是為什麼在 CompleteRoutine 中使用這個標志即可暫停 IRP 的原因。

9、關於 ObQueryNameString 的使用

這個函數的使用，在有些環境下會有問題。它的上層函數是 ZwQueryObject()。在某些情況下會導致系統掛起，或者直接 BSOD。它是從 對象管理器中的 ObpRootDirectoryObject開始遍歷，通過 OBJECT_HEADER_TO_NAME_INFO 獲得對象名稱。今天問了下 PolyMeta好象是在處理 PIPE 時會掛啟，這個問題出現在 2000 系統。在 XP 上好象補丁了。

10、關於重入問題

其實這個問題在很久前的 IFS FAQ 里已經介紹的很清楚，包括處理方法以及每種方法可能帶來的問題。IFS FAQ 里的 Q34 一共介紹了四種方法，包括自己從頭建立 IRP發送，使用 ShadowDevice，使用特徵字元串，根據線程 ID，在 XP 下使用() 函數。並且把以上幾種在不同環境下使用要處理的問題也做了簡單的介紹。且在 Q33 里介紹了在 CIFS 碰到的 FILE_COMPLETE_IF_OPLOCKED 問題的解決方法。

⑤ 《Windows文件系統過濾驅動開發教程(第二版)》最新txt全集下載

Windows文件系統過濾驅動開發教程(第二版) txt全集小說附件已上傳到網路網盤，點擊免費下載：

⑥ 請教用文件過濾驅動的方式透明加密linux中的文件

文件系統過濾驅動是一種可選的，為文件系統提供具有附加值功能的驅動程序。文件系統回過濾驅動答是一種核心模式組件，它作為Windows NT執行體的一部分運行。 文件系統過濾驅動可以過濾一個或多個文件系統或文件系統卷的I/O操作。按不同的種類劃分，...

⑦ 過濾驅動中打開文件時如何避免重入

在處理IRP_MJ_CREATE請求時，過濾驅動可能會使用不同的屬性/許可權等打開這個文件。這種情況經常發生在第二次調用ZwCreatefile時。這會導致生成一個對FSD 過濾驅動的回調(就是重入了).因而，正常的過濾驅動就要有能力檢測這種重入的問題。
There are several ways of dealing with reentrancy ring an IRP_MJ_CREATE operation, and the appropriate solution for your particular driver will depend upon the circumstances. In addition, there are a number of techniques that might work for a single file system filter driver, but that fail when used in a multi-filter environment.
在處理IRP_MJ_CREATE操作過程中，有幾種方法可以處理重入，處理你的驅動(中的重入)的適當方法取決於你的環境。另外，有許多種技術可以在單個文件系統過濾驅動上工作，但在多層過濾的環境下可能會失效。
For Windows XP and newer versions of Windows, the best mechanism for opening a file within the filter is to use . A filter driver can call this function and specify a given device object. The IRP_MJ_CREATE that is built will be passed to the specified device object. This technique avo
ids reentrancy issues and is the best mechanism available for a filter to open a file.
對Windows xp或者更新版的Windows來說，在過濾驅動中打開一個文件的最好方法是使用.文件過濾驅動可以調用這個函數並且指定一個給定的設備對象。
For versions of Windows prior to Windows XP, this mechanism is not available. The best mechanism in this environment is to implement your own functional equivalent of . This can be done by creating a second device object for each device you are filtering.
對Windows xp以前的Windows操作系統,這種方法無效。在這種環境下最好的方法是實現你自己的與等價的功能。這可以通過給你要過濾的設備創建第二個設備對象來實現。
For example, suppose you decide to filter some given file system device object, FSDVolumeDeviceObject. You then create a device object MyFilterDeviceObject and attach it using IoAttachDeviceToDeviceStack (of course, in Windows XP you would use instead). In addition, you create a second device object MyFilterShadowDeviceObject. This device object must be assigned a name ("DeviceMyFilterDevice27", for example). The name can be anything, but it must obviously be unique. In your device extension for your two device objects, you need to track this name, and you need to maintain pointers to the respective device objects (that is, the device extension for MyFilterShadowDeviceObject should point to MyFilterDeviceObject and the device object extension for MyFilterDeviceObject should point to yFilterShadowDeviceObject). Don't forget to set the StackSize field of the device object correctly!)
例如，假設你要過濾某個特定的文件系統設備對象,FSDVolumeDeviceObject(文件系統卷設備對象).這時你要創建一個設備對象MyFilterDeviceObject 並且使用IoAttachDeviceToDeviceStack 函數(在windows xp下使用 )來掛接它。另外，你還要創建第二個設備對象yFilterShadowDeviceObject.這個設備對象必須被指定一個名字(例如"DeviceMyFilterDevice27",注: 這里指的第二個設備對象,即Shadow device object )。名字可以是任意的，但必須唯一的。在這兩個設備的設備擴展結構中,你需要跟蹤這個名字
(注，其實就是做標志，你要知道你當前是處在哪個設備中,是第一個設備對象還是Shadow object )你需要維護一些指向相應的設備對象的指針(也就是說,MyFilterShadowDeviceObject的設備擴展要指向MyFilterDeviceObject，MyFilterDeviceObject的設備擴展對象要指向MyFilterShadowDeviceObject.不要忘了正確設置設備對象的StackSize成員變數。
Now, an IRP_MJ_CREATE request arrives in your filter, specifying MyFilterDeviceObject. To open the file without experiencing reentrancy problems, you call IoCreateFile (or ZwCreateFile). Since you must pass the name of the file being opened, you construct that by using both the name you gave MyFilterShadowDeviceObject and the name that is in the FileObject of the I/O stack Location (IoGetCurrentIr
pStackLocation(Irp)->FileObject).
現在,當IRP_MJ_CREATE 請求到達你的過濾驅動時,指定了 MyFilterDeviceObject.你調用IoCreateFile(或ZwCreateFile) 打開文件就沒有重入的問題了.以後，你必須傳遞這個打開的文件的名字,這個名字是用你設置在MyFilterShadowDeviceObject中的名字和從I/O 堆棧區域中得到的文件對象中的名字一起構造的。
Since you are passing a name in that points to your second device object, the I/O Manager will build the IRP_MJ_CREATE and pass the resulting I/O request packet to your driver, but specifying MyFilterShadowDeviceObject.

當你傳遞一個指向你的第二個設備對象的名字,I/O管理器會構建IRP_MJ_CREATE 並且傳遞I/O請求的結果到你的驅動，但指定了MyFilterShadowDeviceObject.
In your IRP_MJ_CREATE dispatch handler you must detect that this is a "shadow" device object, rather than a typical filter device object. In this case, you should send the IRP_MJ_CREATE operation down to the device being filtered by MyFilterDeviceObject. Indeed, since you should not need to do any further processing, you can use IoSkipCurrentIrpStackLocation (rather than ).
在你的IRP_MJ_CREATE 分發常式處理函數中，你必須檢測它是一個"Sahdow"設備對象而不是是一個典型的過濾設備對象。在這種情況下，你必須將IRP_MJ_CREATE操作下傳到已經被 MyFilterDeviceObject過濾了的設備中。確實,此後你不需要作進一步的處理，你可以用IoSkipCurrentIrpStackLocation函數(不是).

⑧ linux怎樣載入文件過濾驅動

文件系統過濾驅動是一種可選的，為文件系統提供具有附加值功能的驅動程序。文件系統過濾驅動是一種核心模式組件，它作為Windows NT執行體的一部分運行。
文件系統過濾驅動可以過濾一個或多個文件系統或文件系統卷的I/O操作。按不同的種類劃分，文件系統過濾驅動可以分成日誌記錄、系統監測、數據修改或事件預防幾類。通常，以文件系統過濾驅動為核心的應用程序有防毒軟體、加密程序、分級存儲管理系統等。
二、文件系統過濾驅動並不是設備驅動
設備驅動是用來控制特定硬體I/O設備的軟體組件。例如：DVD存儲設備驅動是一個DVD驅動。
相反，文件系統過濾驅動與一個或多個文件系統協同工作來處理文件I/O操作。這些操作包括：創建、打開、關閉、枚舉文件和目錄；獲取和設置文件、目錄、卷的相關信息；向文件中讀取或寫入數據。另外，文件系統過濾驅動必須支持文件系統特定的功能，例如緩存、鎖定、稀疏文件、磁碟配額、壓縮、安全、可恢復性、還原點和卷裝載等。
下面兩部分詳細的闡述了文件系統過濾驅動和設備驅動之間的相似點與不同點。

三、安裝文件系統過濾驅動
對於Windows XP和後續操作系統來說，可以通過INI文件或安裝應用程序來安裝文件系統過濾驅動（對於Windows 2000和更早的操作系統，過濾驅動通常通過服務控制管理器Service Control Manager來進行安裝）。
四、初始化文件系統過濾驅動
與設備驅動類似，文件系統過濾驅動也使用DriverEntry常式進行初始化工作。在驅動程序載入後，載入驅動相同的組件將通過調用驅動程序的 DriverEntry常式來對驅動程序進行初始化工作。對於文件系統過濾驅動來說，載入和初始化過濾驅動的系統組件為I/O管理器。
DriverEntry常式運行於系統線程上下文中，其IRQL = PASSIVE_LEVEL。本常式可分頁，詳細信息參見MmLockPagableCodeSection。
DriverEntry常式定義如下：
NTSTATUS
DriverEntry (
IN PDRIVER_OBJECT DriverObject,
IN PUNICODE_STRING RegistryPath
)
本常式有兩個輸入參數。第一個參數，DriverObject為系統在文件系統過濾驅動載入時所創建的驅動對象；第二個參數，RegistryPath為包含驅動程序注冊鍵路徑的Unicode字元串。
文件系統過濾驅動按如下順序執行DriverEntry常式：

01、創建控制設備對象：

文件系統過濾驅動的DriverEntry常式通常以創建控制設備對象作為該常式的起始。創建控制設備對象的目的在於允許應用程序即使在過濾驅動載入到文件系統或卷設備對象之前也能夠直接與過濾驅動進行通信。
注意：文件系統也會創建控制設備對象。當文件系統過濾驅動將其自身附加到文件系統之上時（而不是附加到某一特定文件系統卷），過濾驅動同樣將其自身附加到文件系統的控制設備對象之上。

在FileSpy驅動範例中，控制設備對象按如下方式創建：

RtlInitUnicodeString(&nameString, FILESPY_FULLDEVICE_NAME);
status = IoCreateDevice(
DriverObject, //DriverObject
0, //DeviceExtensionSize
&nameString, //DeviceName
FILE_DEVICE_DISK_FILE_SYSTEM, //DeviceType
FILE_DEVICE_SECURE_OPEN, //DeviceCharacteristics
FALSE, //Exclusive
&gControlDeviceObject); //DeviceObject

RtlInitUnicodeString(&linkString, FILESPY_DOSDEVICE_NAME);
status = IoCreateSymbolicLink(&linkString, &nameString);

與文件系統不同，文件系統過濾驅動並不是一定要為其控制設備對象命名。如果傳遞給DeviceName參數一個非空（Non-NULL）值，該值將作為控制設備對象的名稱。接下來，在前面的代碼範例中DriverEntry可以調用IoCreateSymbolicLink常式來將該對象的核心模式名稱與應用程序可見的用戶模式名稱關聯到一起（同樣可以通過調用IoRegisterDeviceInterface來使設備對象對應用程序可見）。
注意：由於控制設備對象是唯一不會附加到設備堆棧中的設備對象，因此控制設備對象是唯一的可安全命名的設備對象。由此，是否為文件系統過濾驅動的控制設備對象是否命名是可選的。
注意：文件系統的控制設備對象必須命名。過濾設備對象從不命名。

⑨ 基於 IFS文件過濾驅動 編程

這個主要要看SDK，以及windows驅動編程

⑩ 如何在文件過濾驅動中啟動一個應用層進程

一般來說，那些復在你電腦上安裝的應用製程序在後台運行的進程是可以關閉的，而那些windows自動運行的服務程序/進程是萬萬不可關閉的（可以在進程中的描述一欄中找到）。但是，這並不意味著所有後台運行的應用程序/進程（你所安裝的）都可以關閉，比如的數據傳輸通道，殺毒的後台防護程序等等，這些也不能關閉。還有一些進程，比如音效卡等。其實，如果你是想關閉某個後台程序以用來釋放內存的話，可以用殺毒自帶的釋放內存工具來實現，一般來說，還是不要直接通過任務管理器關閉後台進程，這樣可能會讓電腦崩潰，也可能會丟失那些被你關閉的應用程序的數據。