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里获取一个文件大小的方法有很多,常规的做法是直接获取文件大小;偏冷门的做法是某些软件使用Windows未公开方法(没有编程接口,但是通过某些特殊手段调用)快速获取一个目录里所有文件的大小。加密核心默认针对直接获取文件大小的行为默认做了透明化处理,但是对于冷门的做法,我们给了一个开关,即加密规则高级设置里的过滤目录查询请求。勾选开启,那么这种冷门方法获取的是透明化处理的大小,即理论未加密大小;未开启,则这种冷门方式获取到的是磁盘上文件的真实大小。

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

未启用过滤目录查询请求

启用过滤目录查询请求

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

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

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