文件透明加密這點事兒，從2001年開始出現基于APIHOOK的方式開始到現在，已經十幾年了，有細心人按技術實現的方式將其細分為4代，分別是基于APIHOOK的第一代技術、基于文件過濾驅動（加清緩存）的第二代技術、使用Layerfsd的雙緩沖第三代技術和基于微軟新一代minifilter框架的Layerfsd雙緩沖第四代技術。第一代和第二代的技術劃分基本上沒有異議，所謂的第四代很多人并不認同，認為使用minifilter框架算不上是技術突破，其技術實現仍然是基于Layerfsd的雙緩沖技術，沒有新意。

 

　　我們從2009年開始研究并實現了基于Layerfsd的雙緩沖技術，并應用于自己的產品中，這些本來都是老生長談，只是最近幾天根據用戶反饋修改了幾個BUG，忽然覺得還可以說道說道。Layerfsd的雙緩沖技術最早出現在驅網論壇上的時候，討論可謂是熱烈，隨著一些開發者逐步從理論到實踐，完成了具體的實現之后，就開始了有意無意的技術封鎖，一些技術理論和部分公開的源代碼都無影無蹤，不過從側面也可以看出來，這個技術其實還是有一定的門檻的。其門檻并不在于技術有多難，關鍵在于細節和穩定性，根據理論做出一個實現不難，網上很多號稱出售Layerfsd的雙緩沖技術實現源代碼的，叫價8－40萬的都有，不過都只能算是一個理論研究系統，穩定性都很難保證，更不用說實用性了。

 

　　為了了解同行的技術成熟度，我們經常找來同行的產品進行測試，今年上半年測試了兩個驅動，一個驅動是對VisualStudio不兼容，每次保存文件后都會提示文件被外部修改，需要再確認一次，都是做這個的，我們當然清楚這個是layerfsd層的文件時間沒有處理好，不過用VC編譯一個加密的工程源代碼時，總是藍屏，這個應該就是實現者的技術實力問題了，還有對NTFS分區還馬馬虎虎，但是只要操作FAT分區的文件系統就沒有反應，根據我們的經驗應該是內部有死鎖產生。還有一個驅動是不支持動態磁盤系統和可卸載的媒體（比如U盤），用WORD打開的文檔，在編輯狀態時居然可以從資源管理器中刪除，這個是致命的layerfsd層文件權限管理失敗，和作者溝通這個問題，作者認為這是雙緩沖驅動實現的特征，只要是使用雙緩沖技術實現的驅動都有這個問題，對此我們不敢茍同。

 

　　這樣的實現買回去也沒辦法用，想做出實用的商業軟件至少還要2－3年的時間開發功能并做好穩定性。如果有錢，可以直接購買OSR的DMK，穩定性有一定的保證，但是要在上面做二次開發實現自己的功能。pfp也公開過一份源代碼，是個半成品系統（現在驅網所有的下載鏈接都失效了），但是距離實現還有很遠的距離，當然還是有很多人的實現都是基于這個源代碼做的，這個一測試就能感覺出來。

 

　　使用第二代技術實現的商業應用很多，只要能做穩定，基本都有市場，但是這個技術有幾個致命的問題，就是文件操作效率低下，容易損壞文件，并且和反病毒軟件不兼容。文件操作效率低下的原因在于為了防止非授信進程訪問文件系統緩存的文件明文，每次打開和關閉文件時都要清理文件緩存。這對相當于屏蔽了系統文件緩存帶來的性能優化，對大文件的操作影響尤其明顯。我們測試過一個使用這種技術實現的商業軟件，用word打開一個100多M的大文件后，用另一個非授信進程每隔15－30秒鐘只讀訪問一次這個文件（這會促使驅動實現每隔15－30秒鐘就清一次緩存），結果卡的基本上沒辦法操作這個word文檔，如果是雙緩沖，就沒有這個問題。損壞文件的原因主要是對于延遲寫入的緩沖文件，用戶的寫入操作是寫入了緩存，但是負責延遲寫入的system進程還沒有將其寫入文件，此時如果有非授信進程打開文件，會導致緩存被清除，這導致用戶的修改沒有寫入，很多情況下都會造成文件數據丟失或文件格式損壞，與殺毒軟件不兼容也基本上是這個原因。

 

　　第二代技術的實現，在處理加密文件標識的問題上也很棘手，我們測試過的很多實現都是使用影子文件的方式，所謂影子文件，就是構造一個文件名與加密文件有一定的關聯的影子文件，比如在原始文件名前增加一個固定標識的前綴，或后綴，或使用一個特殊的文件擴展名。當打開一個文件時，加密驅動首先看看是否存在影子文件，如果是就說明是一個加密文件，需要做解密處理。影子文件的管理也是一個很麻煩的地方，需要在驅動中對IRP_MJ_DIRECTORY_CONTROL進行過濾處理，對上層應用過濾掉這些文件名，使得用戶在資源管理器中看不到這些影子文件，感覺不到他們的存在。但是只要用戶停止驅動，這些文件就原型畢露，一些安全軟件，比如冰刃，可以繞過驅動直接刪除影子文件，會帶來一些不穩定因素。此外，文件的復制和刪除都要考慮影子文件，維護上也挺麻煩的。也有一些商業實現將影子文件集中在某個系統目錄中進行管理，但是也要解決同名的問題，也不是完美的方案。

 

　　從理論上所，使用雙緩沖技術可以回避上面提到的清緩存問題，同時，雙緩沖也可以解決文件加密標識的存放問題。雙緩沖技術可以將加密信息構造成一個特殊的數據塊直接存放在文件中，至于是放在文件頭部還是文件尾部（從理論上說，也可以放在文件中間某個位置，不過是自找麻煩），不同意見還是很多的，各有各的理論依據，有人認為放在文件頭部容易破壞文件，不過這是沒有根據的，如果驅動實現不成熟，這塊信息放在什么地方都可能破壞文件。傾向于將這塊信息放在文件尾部的人覺得文件完成最后的寫入，關閉之前補上一塊加密信息是順理成章的事情，傾向于將這塊信息放在文件頭部的人則是秉承傳統的思想，畢竟很多文件格式都是將文件的特殊信息構造成一個特殊的文件頭存放的，不過就實現而言，這二者沒有優劣之分。

 

　　雙緩沖技術需要在一個layerfsd層訪問真實文件，這就帶來一個驅動的（IRP_MJ_CREATE）重入問題，這個解決不好就直接遞歸到棧溢出了。防止重入有多重方法，使用minifilter框架的有個優勢，就是可以直接使用FltCreateFile系列函數繞開驅動直接打開和讀寫文件，這個后面再說。如果不使用minifilter框架，常用的兩種方法就是構造影子卷進行文件訪問，或直接構造IRP進行文件操作。構造影子卷的原理就是通過影子卷重定向文件的訪問，因為過濾驅動不會attach影子卷，因此就規避了重入問題。使用影子卷的好處是可以使用ZwCreateFile等內核API直接操作文件，方便、安全。但是attach物理卷的時候要避開影子卷，一旦不小心attach了影子卷就會死的很慘。直接構造IRP進行文件操作應該是一個很優雅的方案，但是實現起來需要考慮比較多的細節，網上也有一些現成的源代碼實現，不過或多或少都有一些問題，需要修改一下才能用。關于這方面的資料首先是OSR的“RollingYourOwn-BuildingIRPstoPerformI/O”一文，此外，還有baiyuanfan的“Windows平臺內核級文件訪問”一文也有很不錯的介紹。

 

　　minifilter是微軟引入的一個輕量級微過濾驅動模型，簡化了文件過濾驅動的實現細節，使得微過濾驅動可以忽略一些細枝末節的東西，將注意力集中在業務實現上。這比采用遺留驅動模型的sfilter框架有一定的優勢，但是就透明加密驅動而言，并沒有進步到說使用minifilter框架就比sfilter技術先進的程度，要知道，第二代透明加密技術的驅動也可以用minifilter框架實現，所以鼓吹minifilter+layerfsd更先進是沒有依據的，重要的還是誰的驅動更穩定，畢竟動不動就藍屏，或者損壞文件是用戶最不能接受的。

 

　　最后要說一些細節問題，比如雙緩沖，所謂的雙緩沖就是對同一個文件的訪問形成兩個cache緩存，對于授信進程，可以使用解密數據的明文cache，對于非授信進程，則使用密文的cache，二者共存且互相不干擾。使用雙緩沖對系統內存的使用肯定是會增加的，但是帶來的安全性和文件訪問效率的提升是不言而喻的。至于cache的實現方式，可以使用windows的文件緩存系統，也可以自己實現文件緩存系統，據我所知，很多數據庫軟件就沒有使用windows的文件緩存系統，而是根據需求自己實現的緩存系統。極端的說，你甚至可以不實現緩存，所有加密文件的讀寫都是實時操作實際文件，不支持一切緩存讀寫和fastio，我們在測試時遇到過這樣的實現，也號稱是支持layerfsd的雙緩沖技術，雖然沒有雙緩沖的文件訪問效率，但是也算是回避了第二代驅動技術的幾個難題。還有比如授信進程的識別問題，簡單地根據程序文件名稱進行識別是非常幼稚的做法，對程序改個名字就可以欺騙加密驅動得到解密后的明文。還有授信進程的識別問題，對于有的應用程序，通常是一個圖形的前端加上幾個沒有界面的后臺程序配合工作，如果授信進程只有前端的UI進程，還是無法訪問加密文件，對這種情況也要做進程父子關系的識別和處理。當然還有經典的線程注入問題，通過遠程線程注入，可以在授信進程中啟動一個線程訪問加密文件，并將解密的明文通過共享內存或socket接口傳遞給另一個非授信進程。解決之道就是阻止線程注入，內核和應用層都可以做，當然也會對正常需要線程注入的程序產生影響，比如本人的TabSiPlus外掛插件，需要注入到SourceInsight進程內部啟動一個tab標簽欄，就因為這個原因與加密軟件產生沖突。對于一些支持插件的軟件，比如office，還需要對插件進行識別和屏蔽，方法也很多，方式也很流氓，經常弄得用戶莫名其妙。我的建議是對這種支持插件的軟件不要做特殊處理，安全性由用戶自己管理，用戶有時候并不是那么傻，不要什么事情都替用戶做了。