layerfsd

jiedengye

为什么论坛里没有人讨论文件加解密,最近需要这方面东西，有一点不明白，特请教大家。对于文件映射方式的读请求，怎么处理。查找资料请教高人获知是资源管理器预读到内存中，然后其他进程直接在内存中读信息，根本不会经过缓存更不用说fsd了，但是这样我们怎么加密啊，高人指教

Tesla.Angela

https://github.com/xiao70/X70FSD
这里有个开源的LAYERFSD。

ywledoc

文件在读入到内存之前，终归是要经过IRP_MJ_READ的～给你讲流程。
当你打开偶的电脑，并且双击了你要的那个文件的时候，会有一个IRP_MJ_READ发送给NTFS驱动。以下的流程是：
NTFS!NtfsFsdRead ->NTFS!NtfsCommonRead-> CcInitializeCacheMap->CcCopyRead。在CcInitializeCacheMap时候，就映射进了内存了。
当有别的程序先于你的驱动打开了这个文件的时候，这个文件就会保存在内存里了。这个时候，我们自然就捕捉不到IRP_MJ_READ操作了。
当对文件进行修改后，文件在内存中被修改～然后这是缓冲管理器会有一个延迟写的技术～把修改后的文件保存在备用列表或者修改列表中，这取决于文件是否被改，最后再由一个系统线程写入硬盘。
当文件要写入硬盘的时候，一定要经过IRP_MJ_WRITE的。
所以，我们只要解决文件的内存映像就可以了。
有关于内存映像的结构在_file_object里面。具体如下：
kd> dt _file_object
nt!_FILE_OBJECT
   +0x000 Type             : Int2B
   +0x002 Size             : Int2B
   +0x004 DeviceObject     : Ptr32 _DEVICE_OBJECT
   +0x008 Vpb              : Ptr32 _VPB
   +0x00c FsContext        : Ptr32 Void
   +0x010 FsContext2       : Ptr32 Void
   +0x014 SectionObjectPointer : Ptr32 _SECTION_OBJECT_POINTERS
   +0x018 PrivateCacheMap  : Ptr32 Void //用来控制预读等操作的。dt _private_cache_map

kd> dt _SECTION_OBJECT_POINTERS
nt!_SECTION_OBJECT_POINTERS
   +0x000 DataSectionObject : Ptr32 Void //数据的内存信息，PTE之类的。dt _control_area
   +0x004 SharedCacheMap   : Ptr32 Void //就是这个啦～本文件相关的Cache信息。dt _share_cache_map
   +0x008 ImageSectionObject : Ptr32 Void //运行程序的映像。这个是什么结构笔者不知道。

再提供一个清缓存的函数：CcFlushCache。
再提供一份清空磁盘缓存的代码：
HANDLE hFile = CreateFile("\\\\.\\X:", GENERIC_WRITE|GENERIC_READ, FILE_SHARE_READ, NULL, OPEN_EXISTING, FILE_ATTRIBUTE_NORMAL, 0);

ywledoc

再补充下，你单击文件的时候，会有IRP_MJ_CREATE，你双击的时候，也是先产生IRP_MJ_CREATE再产生IRP_MJ_WRITE的。

马大哈

我曾经看过文件系统加密方面的资料,只是大部分看不懂....

这个帮顶顶!

jiedengye

当有别的程序先于你的驱动打开了这个文件的时候，这个文件就会保存在内存里了  如果这个别的程序是非可信的他读取的是内存的内容，我怎么保证内存数据是加密的非加密的？请缓存这个方法太多弊端了

jiedengye

用filemon监控，你打开一个记事本文件，是拦截不到任何read 请求，包括fsd 的read irp和缓存的fast io read，因为这是后文件已经在内存中了(文件映射),直接操作内存了

ywledoc

再补充下，你单击文件的时候，会有IRP_MJ_CREATE，你双击的时候，也是先产生IRP_MJ_CREATE再产生IRP_MJ_WRITE的。

你可捕捉到IRP_MJ_CREATE的，再从中导出_File_object，从而判断是否是你保护的文件，然后再判断是否是可信进程，再从下面红色那行做文章，更可以把irp和_io_stack_location中的file_object给换掉，换成别的文件的～
kd> dt _file_object
nt!_FILE_OBJECT
   +0x000 Type             : Int2B
   +0x002 Size             : Int2B
   +0x004 DeviceObject     : Ptr32 _DEVICE_OBJECT
   +0x008 Vpb              : Ptr32 _VPB
   +0x00c FsContext        : Ptr32 Void
   +0x010 FsContext2       : Ptr32 Void
   +0x014 SectionObjectPointer : Ptr32 _SECTION_OBJECT_POINTERS
   +0x018 PrivateCacheMap  : Ptr32 Void //用来控制预读等操作的。dt _private_cache_map

kd> dt _SECTION_OBJECT_POINTERS
nt!_SECTION_OBJECT_POINTERS
   +0x000 DataSectionObject : Ptr32 Void //数据的内存信息，PTE之类的。dt _control_area
   +0x004 SharedCacheMap   : Ptr32 Void //就是这个啦～本文件相关的Cache信息。dt _share_cache_map
   +0x008 ImageSectionObject : Ptr32 Void //运行程序的映像。这个是什么结构笔者不知道。

ywledoc

回复 jiedengye 的帖子

如果说过滤驱动不能捕捉到read操作的话，我用dispatch hook ntfs的方法，可以在每次记事本打开txt文件的时候，即使是在加载驱动前，还用了一次记事本打开，并不关闭的前提下，都可以捕捉到read操作。

ywledoc

堆栈如下：
00 f7981c40 fa03056e f7981c6c 818e61e8 00160014 nt!DbgBreakPoint (FPO: [0,0,0])
01 f7981c6c 804eefe3 81bc33c0 818fae70 806d12d0 ntfs_create!fake_create_dispatch+0xbe (FPO: [Non-Fpo]) (CONV: stdcall) ---------->我用Dispatch hook后的fake read例程，不是create
02 f7981c7c 80574dce 818fafb8 818fae70 818e61b8 nt!IopfCallDriver+0x31 (FPO: [0,0,0])
03 f7981c90 80571e16 81bc33c0 818fae70 818e61b8 nt!IopSynchronousServiceTail+0x60 (FPO: [7,0,4])
04 f7981d38 8053da28 000000e4 00000000 00000000 nt!NtReadFile+0x580 (FPO: [Non-Fpo])
05 f7981d38 7c92eb94 000000e4 00000000 00000000 nt!KiFastCallEntry+0xf8 (FPO: [0,0] TrapFrame @ f7981d64)
想必是nt!IopSynchronousServiceTail或者IopfCallDriver中把过滤驱动跳过了吧～

虚拟机中如下：

其中的hello.txt是先于驱动加载打开的，无标题则是驱动加载完后再打开的，这个时候中断了，所以是无标题。

jiedengye

ywledoc   我明白你的意思 但是notepad是文件映射，数据已经在内存中了。数据是资源管理器预读的时候通过文件映射加载到内存中的，你可以用filemon看一下

jiedengye

C:\Documents and Settings\Administrator\桌面\12.bmp

jiedengye

这是我打开文件的时候 notepad的irp 操作，是没有read请求的

马大哈

回复 jiedengye 的帖子

file:///C://Documents%20and%20Settings//Administrator//桌面//12.bmp

这个只有你自己能看到.....汗.

保存为JPG或GIF等小一点的格式,上传上来吧.....

ywledoc

回复 马大哈 的帖子

我说框了半天没框出来～

jiedengye

哈哈 sorry

ywledoc

回复 jiedengye 的帖子

what i most want to know is：
你自己用自己的文件过滤驱动做过实验了吗？为什么ntfs可以捕捉到IRP_MJ_READ操作，过滤驱动却不行。而且我查资料也只是说是在内存中操作，但是过滤驱动却是可以捕捉到IRP_MJ_READ操作的。只要能捕捉到IRP_MJ_READ操作，就可以找到文件在系统缓存中的内容，你也就可以加密了。

ywledoc

回复 jiedengye 的帖子

或许你的问题我没理解明白，为了避免我们接下来会讨论不一样的要点，我说下我对你的问题的理解：
1.是否会有IRP_MJ_READ发到过滤驱动中？当然你用filemon试过了，但是我的NTFS驱动实实在在的收到了IRP_MJ_READ！
2.内存中已经保存了文件的非加密内容，就算我的过滤驱动可以收到IRP_MJ_READ，那么内存中的数据还是非加密的，怎么处理？

马大哈

jiedengye 发表于 2011-3-30 16:17
为什么论坛里没有人讨论文件加解密,最近需要这方面东西，有一点不明白，特请教大家。对于文件映射方式的读请 ...

"查找资料请教高人获知是资源管理器预读到内存中"
//
我在想,既然资源管理器也需要读,那肯定也会有相关的机制可使用的吧.

实际上文件系统自己也支持压缩驱动器(FAT32/NTFS都支持),压缩驱动器这个功能本质上可以看作是一种透明加密对吧?

它是如何实现的,又是如何处理例如楼主所说的"文件映射方式"打开文件的情况的呢?

jiedengye

我自己实验了 的确有read请求 但是进程是explorer，到了notepad的时候没有了read请求。文件映射就是explorer加载一份映射到内存，notepad发现映射存在，就直接操作这块映射。这是一块内存，读取直接操作内存了。不会经过fsd，但是写肯定走write

jiedengye

回复 ywledoc 的帖子

第二个问题：现在的请缓存的方法，把文件映射对应的内存也清楚了。所以当notepad再打开文件读取时，会重新读取磁盘。这样所有的东西都在你的控制中了

jiedengye

jiedengye

这次能看到了吧  这是我第一次打开这个文件 根本没有read

jiedengye

我想到一个例子，大家可以试一下，你运行notepad的时候，dll的加载是通过文件映射的因为已经在内存中了，那时候你可以看看是否有读请求，肯定没有 ，当然是系统的dll或者是已经加载的

ywledoc

回复 马大哈 的帖子

压缩机制不用判断进程～在内存里的内容用CcCopyRead读出，不在内存里的内容下发到磁盘驱动读出。直接解压就是了。

ywledoc

回复 jiedengye 的帖子

1.不是notepad发现映射存在。explorer下发IRP_MJ_READ后，NTFS调用CcCopyRead函数把映射返回给explorer，explorer再返回给notepad。
2.既然可以接收到read了，那么就可以加密了。你只要放过你想要保护的程序，再加密其它所有程序就可以了吧。

jiedengye

回复 ywledoc 的帖子

对  这就是问题 这块文件我是应该存明文还是密文？加入notepad是可信的，又有一个进程非可信也是文件映射，怎么办？岂不是读到明文了吗

ywledoc

回复 jiedengye 的帖子


在假设能够得到notepad进程，而不是explorer进程的情况下，有三种办法。
1.记事本打开后，不再让别的进程对此文件进行操作。别的进程打开后，也不让记事本来操作。
2.双缓冲，判断是否是记事本，是则用明文的缓冲，不是则用密文的缓冲。我只是知道有这种方法，但是没有去实现过，因为涉及太多细节的东西，不做商用软件，没必要。
3.完成例程里尝试加密解密。只是想法。

上面都不是难事。
最难的是得到notepad的进程了，如果有一个也是内存映射的进程，如果也是用explorer来下发read，很难判断。
想想在ring3有什么办法？看你的描述流程应该是这样：
notepad->explorer->irp下发，在irp里置一个特殊位？或者注入到notepad进程里？更或者，你可以在内核中，一步一步的还原下堆栈，看下能不能还原到notepad？

jiedengye

1.第一个这个肯定不行 ，违背了文件系统的原理 不人性化
2.第二种方法就是layerfsd，这个需要自己创建fcb，做一套自己的系统
3.这个直接不可行

ywledoc

回复 jiedengye 的帖子

那不就选第二种喽～

ywledoc

回复 jiedengye 的帖子

其实这些讨论已经让我们了解了很多，何必要做出来呢？那些细节，烦的吐血。我跟过一次NTFS的XCB结构，直接无语，太繁琐了。凡事求完美没错，但是要量力啊，看layerfsd多贵，就知道作者花了多少心血在里面了。

jiedengye

对 不过现在国内好多人弄出来了 只是大家不公布罢了 起始layerfsd原理还好 主要是实现

ywledoc

回复 jiedengye 的帖子

搞出来的是团队～但是个人比较难啊～FCB里面小打小闹下还行～双FCB啊这是～同步啊，VMM啊～
也谢谢楼主这个帖子，把好多以前没深入的地方，再仔细看了一次。不知道_share_cache_map里面乱搞下会是什么结果。