SEFS

转帖一篇文章，是因为文章中的一些话让我想起来几年前自己的抓狂。

原文链接：http://www.0ginr.com/bbs/thread-4012-1-1.html
原文作者：pk8995
未能联系到原文作者授权转帖，如有侵权，请来信删除。

国内的透明加密、文件防泄漏产品使用双缓冲、双FCB、LayeredFSD的究竟有没有商业化的产品出现？有没有实施案例？ 这些个概念喊出来不少日子了，究竟有人商业化了没有？别跟我说DMK，我说国内。且不说100W的授权费，这东西在国内很多市场是进不去的。

网上总有人说自己搞出来，但拿到的bin都是垃圾，还有用VMP处理过的，真好笑。驱动装上就死锁、蓝屏，搞这么多保护有毛用？也别跟我说这东西值多少钱，真的是值钱，垃圾不值钱。 如果说没有做出产品的，那么市面上的这么多产品都是基于清缓存技术的？我在一个小公司，我没那么大能力拿到别的厂商的BIN，我不知道他们是怎么弄的。

我想聊聊清缓存这种模型的一些硬伤。

先说清缓存的时机，还是那句话，我不知道别的厂商怎么弄的，一般的做法都是在CREATE和CLEANUP里清缓存吧。之所以清缓存是为了解决受信进程和非受信进程分别能读取到明文和密文，在受信进程和非受信进程交替访问的时候清除缓存，这样从时间上保证两个进程都能读到正确的东西。 那么考虑这种情况，A受信，B非受信，A进程irp_mj_create，清缓冲为明文，B进程IRP_MJ_CREATE,清缓冲为密文，A进程发出 IRP_MJ_READ读到密文，A报错。
有问题么？同理顺序反过来有泄密的风险。

扒了某产品其解决方法是，把文件和进程自己建立关联，A访问加密文件X 时禁止B的打开，直到A进程退出。这样是从一定程度上解决了这个问题。但是遇到多进程协作的情况呢？3个进程协作都设置为受信进程，但是有些特殊情况比如有许多守护进程，像打印服务，根本就不退出，那怎么办这个文件一直被占用着？

当然某产品没有我说的这个问题，它的实现有BUG，三进程打开同一个文件就会泄密。 如果你一根筋的要进程隔离，那仔细想想，说到底你没办法判断一个进程是不是还在“用”某个文件，无论是FO还是FCB都是进程无关的，对进程来说文件只是个句柄。而且在文件过滤驱动的角度考虑，收到的某些IO请求也不一定就是在发出请求的进程上下文里，就算可以通过簿记各种信息来判断出原始进程，但是怎么才算“用”完了呢？其实这个进程自己也不知道，也许在进程退出之后还有很多内核组件仍然在使用这个FO完成进程委托给它们的未完成的工作，呵呵。这种情况下是允许非受信进程访问呢？还是放开隔离？

你是个过滤驱动，很多事情文件系统可以做，你不能做。FSD的数据结构不知道，几大管理器的行为也不是全都能控制的。拧巴…… 不隔离吧。考虑写文件的情况呢？这种情况下怎么保证？出现坏文件、明密相间。每个做透明加密的都遇到过吧，呵呵。

OK，再找别的时机清缓、存用一些锁，不管你怎么折腾都是在时间维上处理，空间上只有一个缓存。且不说复杂度，老这么清缓存，效率上根本无法保证，造成20%的性能下降客户都嚷个没完。

为什么还有这么多产品能转呢？我不负责任的说一句，现在的这些产品估计都是针对应用做了大量的特殊处理吧，光OFFICE系列就有好多种文件读写行为方式，还有制图软件，一个一个去分析？这是个累死牛的活。就算这些都分析清楚了，你能保证软件环境么？这东西不但要和杀毒软件兼容，还要和HIPS、RK、木马、流氓软件、病毒兼容。唯一确定的事情是别指望别人跟你兼容。用户都是白痴，中个稀奇古怪的病毒天经地义的，碰到个会用HIPS我心里还发毛，能跟人家兼容么。

有幸拿到到了思XXX的产品，产品做得大而全，一看就是业务上想的很深入。满怀希望的想调试一下，找找思路。驱动装完后发现在CheckBuild的XP 下根本无法启动，总是进到内核的ASSERT里。唉，就算是发布版的不这样，就算是被你找到些投机取巧的参数。这样的东西你敢用？ 照理说有0.1%的可能坏文件，这样的产品就不能用。有多少能保证的？

呵呵。我去实施的时候真的觉得客户好可怜，抱着这么个定时炸弹，还挺美。好在他们不知道，无知就是幸福啊。

LayeredFsd也许是个圣杯。OSR弄了几年，也有这个资本卖100W，操蛋的是我TMD单枪匹马的也弄这个……自嘲一下。

但是SXXX放出来的那个实在是太那啥了，安装包还密码，我费事巴力的把SYS弄出来，好像有4个sys都不大，看上去是区分不同的文件系统还是怎么着，装上，刚加载就断到调试器里了……时间久远了，好象是个字符串函数的参数写错了，RtlCopyUnicodeString还是什么的，又崩溃了，汗啊。搞得的我兴趣全无……

我的技术不怎么样，说的也不一定对，大家就当听个乐。也许早就有做得很好的了，也许人家不说话，不像我在这瞎咋呼。白天做了一天很失败的实验，弄的郁闷了。发发牢骚。 拧巴……

为sefs3平台下的应用开发商更快速的开发出商用产品，现提供一个应用层泄密控制的Demo下载。

实现功能：

1、剪切板加密。
a、非授权进程间的拷贝、黏贴正常操作。
b、授权进程间的拷贝、黏贴正常操作。
C、非授权进程->授权进程的的拷贝、黏贴正常操作。
d、授权进程->非授权进程的的拷贝、黏贴将显示密文乱码。

2、打印控制。可限制授权进程打印功能。 水印显示稍后提供。

3、授权进程可阻断网络链接。

操作系统支持：
32位/64位
2k/xp/2003/vista/win7/win2008

sefs3客户可索取Demo的源代码，admin@sefs.net

基本的需求是：授权进程操作的文件需要加解密：如word进程操作 doc文件 就需要加解密，而非授权进程 比如 explorer.exe 在拷贝文件的时候 就不需要加解密。这样在普通的文件拷贝和黏贴操作中 加密的文件就始终保持密文状态，从而防止文件的泄密。

但是Windows操作系统的设计中，为了提高效率，对文件的读写使用了缓存。这样一个加密文件如 a.doc 在被 授权进程 如 word.exe 打开过一次后 文件的内容就已经解密后被缓存到了操作的缓存管理器（CM）。此后任何进程对该文件的读写都首先检查缓存是否有该文件的内容。如果应用程序使用FileMaping（一种对文件读写抽象技术）来读取文件的话，甚至不会发出任何的IRP请求包，这样基于文件过滤器的透明加密产品根本没有机会去处理。

这样就不能满足刚才我们所说的基本要求，在osr的ntfsd新闻组 你会经常看到国内的程序员在咨询这样的技术问题。在单纯的文件过滤驱动中 最迅速的解决方式就是 不断的刷新文件的缓存，使得任何进程对加密文件的访问都发出 非缓存方式的IRP读写，然后根据进程的不同，授权进程的读写就加解密，而非授权进程的读写不加解密。

貌似这样的方案是能够很快的解决问题，但直到有一天 我看到有个英国的老外回复了一句很有深意的话，大意是这样：”用2分钟的时间 完成了这个需求 但是你得用10年的时间来解决由此带来的问题”。

此后在基于MiniFiler的SEFS2..0系列的项目实施过程中发现，尽管你通宵达旦的熬夜去解决某个问题，而且似乎问题也得到了解决。但其实另一个问题同时又产生了。

由此我们开始反思技术路线，尽管此时 osr 的 dmk 已经发布了 3 年之久。但在这以前我们一直认为 dmk 的存在只是为了展示技术的先进性，而不能想到 dmk 为什么要做LayeredFSD。

待续。。。。。

利用VisualDDK我们可以像普通的应用程序一样调试在虚拟机里运行的驱动，而且vs2008的调试界面远比WinDBG来的友好和舒服。

测试环境：
–VisualDDK1.3.2 http://visualddk.sysprogs.org 下载
–VC2008 Sp1
–VM Ware WorkStation 6.5.0

主机上配置：
1、安装VisualDDK1.3.2
2、利用VisualDDK的驱动生成向导生成一个驱动.(生成的驱动似乎有点问题)。可以用本人修改的 TestWDM (vc2008工程) 下载在此

虚拟机配置：
1、Copy VisualDDK安装目录下的 \target 到虚拟机 执行 vminstall.exe 安装。
2、虚拟机重新启动后，DDKLaunchMonitor.exe 将会自动运行接受主机的命令请求。

测试开始：

1、启动虚拟机，执行安装目录下的 vmmon.exe 可以到已经启动已经启动的VM。

2、打开TestWDM工程 编译，点击“调试、Start Debugging Driver”，

3、此时会让你设置你的驱动的名字，如何启动等信息。一定要填上虚拟机的IP地址

4、点击“Lancer” 一路稀里哗啦 如果幸运的话 你可以看到代码停在了 “_asm int 3‘

4、恭喜,现在可以像普通的应用程序调试一般查看变量等信息。

Enjoy it！

不是很稳定，经常导致VC2008 IDE错误。

推荐使用VisualKD + VMWate + WinDBG 的组合调试驱动。