Ping32文档加密软件的“过滤目录查询请求”参数

在之前文章中，我们详细讲解了文档加密是如何透明加密\解密一个文件。文档透明加密中，对“透明”一此的理解，不止可以从用户无感知的角度理解，还需从授信软件，感知一个文件的属性（大小、只读、压缩、NTFS安全属性等），读写一个文件的内容等角度进行理解。

读写文件进行解密、加密很好理解，因为这是透明加密的核心，即原始数据写入磁盘时，被我们的加密中间层进行加密；从磁盘读取加密的内容时；被我们的逻辑解密。透明加密核心就像是一个虚拟机一样，作用在系统底层，第三方应用是感知不到它的存在。

下面将要讲的是：感知一个文件的属性的透明化处理。

一个前置背景知识是，一个文件被加密后，文件在磁盘上的真实大小，要比原本理论大小大。举个例子，一个ANSI编码(每个ASCII字符是一个字节)的txt文件，里面的内容是1234567890十个数字，那么这个txt文件大小就是10字节。但是经过加密后，这个txt在磁盘上的大小要大于10字节（因为包含了加密文件头，以及加密算法的影响）。

程序读取文件内容的简化逻辑一般是：

1.获取文件大小，按照文件大小申请内存缓冲区；
2.读取文件大小的数据；
3.将读到的数据放入缓冲区。

假设，一个未加密的文件大小是10字节，那么程序即可获取到10字节这个值，申请的缓冲区大小也是10字节，然后程序从文件头读取10个字节的内容放到缓冲区里，最终也成功读取到了10个字节（因为大小确实是10字节），一切都很和谐。

但是如果透明加密介入，就会引入一些问题。假设，一个未加密时大小是10字节，但是被加密过的txt文件，加密后大小是100字节。那么记事本获取文件大小时，获取到的这个文件大小该是多少，是10还是100。假设是100（也就是加密文件在磁盘上的真实大小），那么按照读取文件的逻辑进行操作，申请100字节的缓冲区，然后试图读取100个字节，但是很遗憾，由于加密中间层的存在，读到的数据是被透明解密的，透明解密的大小只有10，那么只能读取到10个字节的数据。这时，程序认为文件有100个字节，但是只读取到了10个字节，这时就会认为可能出现了错误，进而出现一些不可预知的错误。

所以，这就是开头提到的，一个授信软件不仅读写文件数据是被透明加解密的，除此之外，感知文件属性也应该是透明的。也就是说，记事本感知加密文件的大小，应该是文件的理论未加密大小，而不是磁盘上的真实大小。

Windows里获取一个文件大小的方法有很多，

常规的做法是直接获取文件大小（GetFileAttributes, GetFileAttributesEx, GetFileSize等函数），这些函数在底层实现上，都会打开一个文件内核对象，然后获取文件的大小等属性，此类操作都会被透明加密逻辑默认处理。

偏冷门的做法是调用FindFirstFile的系列函数，甚至某些软件会使用Windows未公开方法（没有编程接口，但是通过某些特殊手段调用）快速获取一个目录里所有文件的大小。

加密核心默认针对直接获取文件大小的行为默认做了透明化处理，但是对于冷门的做法，我们给了一个开关，即加密规则高级设置里的过滤目录查询请求。勾选开启，那么这种冷门方法获取的是透明化处理的大小，即理论未加密大小；未开启，则这种冷门方式获取到的是磁盘上文件的真实大小。

此处可以做一个实验，即explorer.exe，建立一个规则可以透明加解密*.txt，分别启用、关闭过滤目录查询请求得到的结果如下图（这几个文件理论未加密大小只有几十个字节）。

未启用过滤目录查询请求

启用过滤目录查询请求

最后留两个问题：
假设某备份软件备份某个目录里所有文件时，获取文件大小使用的是这种冷门方法。

1.如果我希望，备份软件备份某目录的加密文件到云端是解密（未加密状态）的，该如何设置策略。
2.如果我希望，备份软件备份某目录加密txt到云端是解密的，备份加密jpg则依然是加密状态，我们现有的规则是否支持，为什么？

如果你对其他技术细节也感兴趣，也可以和我们取得联系。