Sfilter能否透明加解密网络文件?由于缓冲问题是否会导致文件被破坏?

  这两天事少，读了一下Sfilter的代码，有一下几个疑问，而且在论坛上搜不到答案

1.好象要mount了才能得到Irp,那么网络文件(别的机共享的，映射的网络驱动器)Sfilter能否透明加解密?

2.假设一个文件F.xxx大小为1兆，一个可以解密文件的进程A读取了这个文件前面的4KB(缓存中解密了4KB)，并不关闭文件，然后一个不可解密文件的进程B来读取F.xxx的整个文件内容。问题：F.xxx的前面4KBWindows会从缓存中取出明文，后面的部分从磁盘得到是密文，那么这个文件不就坏掉了？
例如：Word打开F.xxx后不关，资源管理器把F.xxx拷贝成NewF.xxx，那么这个NewF.xxx不就是个被破坏的文件?

3.加密标示问题：加密标示应该放在文件身上，如果把文件变大，会导致什么难以解决的技术问题?

问题1
能。网络文件没有Volume,所有请求直接发给控制设备。用控制设备过滤即可。sfilter已经做到这一点，如果显示所有访问文件路径，你就会看到网络文件的路径。
问题2
好长，没认真看。
问题3
文件加密解迷的额外信息如果保存在文件内容中，无论如何保存都会带来非常麻烦的问题：
1.保存在文件头部。这导致后面的所有内容的实际偏移和操作系统认同的偏移都不相同。每次文件操作都必须更改偏移。更重要的是操作系统在 FileObject中也用一个字段保存“当前偏移”，这个字段不是微软文档推荐可以随意修改的字段，而且文件读写方式花样繁多，一一应付起来困难无穷。当然也不是完全不能解决。但我认为即便暂时解决了，未来的兼容性也是一个疑问。
2.保存在文件尾部。这面临同样的问题。因为每给文件追加一个字节，你可能都得不移动文件后面追加文件尾，除了操作的效率，编程的麻烦程度，有时还得考虑非法断电的文件可恢复性的问题。
3.除了以上之外，文件的大小已经改变。如果要求反映给操作系统的大小不能改变，...又有一系列的东西要进行小心的处理。

可以选择的一种方便方法是把这些信息保存在另一个地方，并用简单的结构把他们对应起来。而不保存在文件内容中。

引用第1楼XiangXiangRen于2007-03-12 09:06发表的“”:

问题3更重要的是操作系统在 FileObject中也用一个字段保存“当前偏移”，这个字段不是微软文档推荐可以随意修改的字段，而且文件读写方式花样繁多，一一应付起来困难无穷。当
.......

文件头扩展，当前偏移是由系统维护的。过滤驱动不会直接在太岁头上冻土。所以没有问题。
过滤驱动做加解密才是核心问题。如何处理明文泄密问题和内存映射访问是最麻烦的。

引用第2楼我最老实于2007-03-12 09:41发表的“”:


文件头扩展，当前偏移是由系统维护的。过滤驱动不会直接在太岁头上冻土。所以没有问题。
过滤驱动做加解密才是核心问题。如何处理明文泄密问题和内存映射访问是最麻烦的。

我不知道你是否实际开发过加密解密的文件过滤驱动。我没有实际做过加密与解密的透明过滤，所以对这个问题考虑并不是很周全。
但是过滤驱动不需要维护当前偏移这显然是不对的。一些读请求完全可能依赖于当前文件偏移。虽然这些请求并不常见。举个简单的例子：
现连续读取文件数据，每次读取1K.第一次开始位置为0，经过你的过滤后变成1K（因为你跳过1K的附加文件头）,长度为1K,读完后，文件当前偏移为2K.
下一个操作本来要从1K开始读取，但是由于当前文件偏移为2K,当第二个依赖文件偏移的请求发生的时候，这个请求的开始偏移就成了2K,错误就发生了。
在平时的操作中，依赖文件当前偏移产生的操作并不常见。但是一些媒体播放软件却是经常用到的。

引用第3楼XiangXiangRen于2007-03-12 13:12发表的“”:


我不知道你是否实际开发过加密解密的文件过滤驱动。我没有实际做过加密与解密的透明过滤，所以对这个问题考虑并不是很周全。
但是过滤驱动不需要维护当前偏移这显然是不对的。一些读请求完全可能依赖于当前文件偏移。虽然这些请求并不常见。举个简单的例子：
现连续读取文件数据，每次读取1K.第一次开始位置为0，经过你的过滤后变成1K（因为你跳过1K的附加文件头）,长度为1K,读完后，文件当前偏移为2K.
.......

    

下面的数据来自播放 mp3 通过过滤驱动解密(包含文件头的加密文件)

[Msg][PostCreate] ProcessName: wmplayer.exe
[Msg][PreRead] Length:8192  ByteOffset:131072
[Msg][Encrypt] DataLen = 8192
[Msg][PreRead] Length:4096  ByteOffset:139264
[Msg][Encrypt] DataLen = 4096
[Msg][PreRead] Length:8192  ByteOffset:143360
[Msg][Encrypt] DataLen = 8192
[Msg][PreRead] Length:4096  ByteOffset:151552
[Msg][Encrypt] DataLen = 4096
[Msg][PreRead] Length:8192  ByteOffset:155648
[Msg][Encrypt] DataLen = 8192
[Msg][PreRead] Length:4096  ByteOffset:163840
[Msg][Encrypt] DataLen = 4096
[Msg][PreRead] Length:8192  ByteOffset:167936
[Msg][Encrypt] DataLen = 8192
[Msg][PreRead] Length:8192  ByteOffset:176128
[Msg][Encrypt] DataLen = 8192
[Msg][PreRead] Length:4096  ByteOffset:184320
[Msg][Encrypt] DataLen = 4096
[Msg][PreRead] Length:8192  ByteOffset:188416

请教一下我最老实兄台，
1 关于偏移量，是否可以在收到IRP_MJ_READ请求后，自己重新发修改过偏移量的IRP到下层驱动，解决这个问题？
2 内存映射访问是什么问题？如何解决呢？
新手上路，对此还没什么概念，望指教。

引用第4楼我最老实于2007-03-12 14:27发表的“”:

    

下面的数据来自播放 mp3 通过过滤驱动解密(包含文件头的加密文件)

.......

感谢你的实际数据。我之所以考虑这个问题，是因为，我曾经在一个文件过滤中自己完成一个IRP的时候，由于FileObject->CurrentByteOffset没有设置，而发生错误。
所以我认为有一些操作可能是要依赖FileObject->CurrentByteOffset值的。这可能发生于，系统调用
ZwCreateFile时，指定了FILE_SYNCHRONOUS_IO_ALERT或FILE_SYNCHRONOUS_IO_NONALERT，DDK说此时IO管理器会自己维护文件偏移。我怀疑此时IO管理器会去读取FileObject->CurrentByteOffset作为当前偏移。
但是其他情况下，只要ZwReadFile调用的时候指定了Offset,那么就不会有问题，无论你用的是不是媒体播放软件。
当然如果本来就不是这样，这个问题完全不存在，那是最好不过的了。

引用第6楼XiangXiangRen于2007-03-12 15:59发表的“”:


感谢你的实际数据。我之所以考虑这个问题，是因为，我曾经在一个文件过滤中自己完成一个IRP的时候，由于FileObject->CurrentByteOffset没有设置，而发生错误。
所以我认为有一些操作可能是要依赖FileObject->CurrentByteOffset值的。这可能发生于，系统调用
ZwCreateFile时，指定了FILE_SYNCHRONOUS_IO_ALERT或FILE_SYNCHRONOUS_IO_NONALERT，DDK说此时IO管理器会自己维护文件偏移。我怀疑此时IO管理器会去读取FileObject->CurrentByteOffset作为当前偏移。
.......

楼上的坛友误会了。你说的完全没有问题。我没有说不要考虑CurrentOffset，我只是说不要在文件过滤中"修改"它。所以处理读写的时候要记录流的状态。

不过，我从来不认为修改文件长度是一个合格的产品应该采用的方案。在过滤层做加解密也一样！

引用第5楼youngwinter于2007-03-12 15:19发表的“”:
请教一下我最老实兄台，
1 关于偏移量，是否可以在收到IRP_MJ_READ请求后，自己重新发修改过偏移量的IRP到下层驱动，解决这个问题？
2 内存映射访问是什么问题？如何解决呢？
新手上路，对此还没什么概念，望指教。

1、文件加了头肯定要在I/O的时候配合适当的偏移。
2、内存影射问题就是，一旦数据被影射到内存后，我们就对它失控了。不知道谁有对此比较好的处理方法，来讨论讨论。

引用第8楼我最老实于2007-03-12 16:24发表的“”:


1、文件加了头肯定要在I/O的时候配合适当的偏移。
2、内存影射问题就是，一旦数据被影射到内存后，我们就对它失控了。不知道谁有对此比较好的处理方法，来讨论讨论。

1.能再解释详细一些吗？如何配合适当的偏移？我刚才跟踪了一下发现在Read完成前后FileObject的CurrentOffset好像是不变的，一直是0，这个偏移量是不是应该指IrpSp->Parameters.Read.ByteOffset？是说在读之前先加上文件头的偏移量，读完成后再减回来吗？

2.做文件加密的话，无非是控制内容和控制途径两条路，如果内容失控了，就想办法控制文件的传播途径，比如不让写入U盘、光驱、软驱，或者在写入时自动加密。这是我的简单想法。还有好像就是在应用层上做手脚了吧，限制ReadProcessMemory，限制CreateRemoteThread，禁止剪贴板操作等等，挺复杂的，也值得研究一下。

对于xiangxiangren坛友的关于current position的顾虑，我在此做一个说明：
current position只在CachedIO中才起作用。对于NonCacheIo必须给定偏移量。一般在过滤驱动加解密中，只处理NonchachedIO，所以可以打消这个顾虑。

引用第9楼youngwinter于2007-03-12 19:02发表的“”:


1.能再解释详细一些吗？如何配合适当的偏移？我刚才跟踪了一下发现在Read完成前后FileObject的CurrentOffset好像是不变的，一直是0，这个偏移量是不是应该指IrpSp->Parameters.Read.ByteOffset？是说在读之前先加上文件头的偏移量，读完成后再减回来吗？

NoncacheIo典型是由内存管理器为了构建失败的访问页而产生的。而页的数据具体来自文件，所以你要跳过文件头，就必须让文件头数据不出现在页中。注意构建页的时候必须发起Sector对齐的I/O。

引用第10楼我最老实于2007-03-12 20:00发表的“”:
对于xiangxiangren坛友的关于current position的顾虑，我在此做一个说明：
current position只在CachedIO中才起作用。对于NonCacheIo必须给定偏移量。一般在过滤驱动加解密中，只处理NonchachedIO，所以可以打消这个顾虑。

如果改变大小，必须处理current position，否则播放歌曲解密失败！！！！

引用第8楼我最老实于2007-03-12 16:24发表的“”:


1、文件加了头肯定要在I/O的时候配合适当的偏移。
2、内存影射问题就是，一旦数据被影射到内存后，我们就对它失控了。不知道谁有对此比较好的处理方法，来讨论讨论。

对于内存映射文件的问题，其实主要是写的时候会稍微麻烦点

引用第13楼coolw于2007-03-13 16:30发表的“”:


对于内存映射文件的问题，其实主要是写的时候会稍微麻烦点

可否进一步说明？

文件加密标识的处理有两个方面的内容：
1>读处理；
2>写处理；

其中读处理比较简单，但是写的情况尤为复杂；

引用第15楼devia于2007-03-15 09:05发表的“”:
文件加密标识的处理有两个方面的内容：
1>读处理；
2>写处理；

其中读处理比较简单，但是写的情况尤为复杂；

能否具体谈谈！

引用第15楼devia于2007-03-15 09:05发表的  :
文件加密标识的处理有两个方面的内容：
1>读处理；
2>写处理；

其中读处理比较简单，但是写的情况尤为复杂；

devia 大哥： 你能大致讲一下读和写的大致处理过程么，小弟被这个东西折磨惨了！

从现在的情况看，透明文件加密如果在中间层文件驱动还是比较困难的。
内存影射是不经过I/O管理器的，而是直接使用页控制相关内核代码。还在研究中！

现在正在分析转移到磁盘驱动上处理。