闲暇时写的透明加解密过滤驱动，只支持流加密

仅供大家参考

需要注意的问题：
1、文件名获取方式不够完善
2、不能加密整个根目录，否则该分区不能mount
3、错误处理不够完善
4、未作充分测试，如果问题，概不负责

2 解密你考虑太多了，没有用，浪费资源。
    不知道是什么地方考虑太多了

3 你为何不能加密根目录，是因为你的代码加密判定不完善，所以修改了根目录区。
    对，这个我已经在帖子里说明了，因为现在比较忙，所以没时间做，取文件名也是，

4 文件名获取参考filemon，很好的例子

5 不需要加ExReleaseFastMutex，这个影响你的性能。
    不清楚你为什么会认为不需要加ExReleaseFastMutex

    Callers of the Rtl..GenericTable routines are responsible for synchronizing access to the generic table.

以上我的个人看法，不一定对。

ExReleaseFastMutex会提高它的irpl级别。对共享的可能会有影响，系统会管理好的
你不需要这个东西啊the generic table

晕，第一次听到这种说法

不好意思，让你见笑了，哈哈，说错了
是需要在Callers of ExReleaseFastMutex must be running at IRQL = APC_LEVEL. 这个级别。
不过真的这个没有必要使用。你不信就算了。你没有必要处理the generic table 。

ExAcquireFastMutex(&DevExt->FsCtxTableMutex);

FileCtx.FsContext = FileObject->FsContext;
FileCtxPtr = RtlLookupElementGenericTable(&DevExt->FsCtxTable, &FileCtx);

ExReleaseFastMutex(&DevExt->FsCtxTableMutex);

if (!FileCtxPtr || !FileCtxPtr->DecryptOnRead)
{
IoSkipCurrentIrpStackLocation(Irp);
return IoCallDriver(DevExt->AttachedToDeviceObject, Irp);
}
根本需要的
你能说说你的理由吗，我比较菜，虚心接受你的意见的

ExReleaseFastMutex releases ownership of the given fast mutex and reenables the delivery of APCs to the current thread.


不使用FastMutex，如何保证GenericTable中内容的正确，共享资源不需要同步吗？？

用ddk编译，编译类型
TARGETTYPE=DRIVER
DRIVERTYPE=FS

抛两块砖：

1.读文件的时候在完成例程中处理用户缓冲区，这是十分危险的，因为完成例程运行在随机线程上下文中，这个问题我亲身经历过。

确实存在这个问题，应该在之前lock一下


2.在当前根目录下面创建一个隐藏目录保存加密相关信息，然后过滤掉用户模式访问，如果将过滤范围扩大到整个根目录，则自己创建的目录也在加解密范围内了，而你在Create例程当中会以内核模式调用NtCreateFile，NtWriteFile和NtReadFile访问自己创建的目录，这样是不是会造成IRP重入？


不会，因为我对目录名进行了判断，如果是隐藏目录，就直接交给下层驱动了

[编辑 -  4/15/05 by  joshua_yu]

FILE_CONTEXT 结构太大了，特别是Name，应该改为动态分配，在我的64位环境下编译报错， :o