关于PDF文件加密器内存截取虚拟文件的一点想法

PDF文件加密器是利用acrobat SDK开发的一款APP。用这个APP加密的文件有好几种情况，我说的是知道了阅读密码，但是有阅读次数限制和阅读时间限制的情况，加密后的文件为一个exe文件，exe文件运用了BoxedAppSDK把解密后的pdf文件释放到内存中而不是硬盘上，下面细细说来。

先说下我对BoxedAppSDK的一些理解吧。"BoxedAppSDK能够创建虚拟文件和虚拟注册表，你的应用程序会认为这些虚拟的文件确实存在，在运行过程中不会有临时文件生成",这是官方网站上面说的。什么是虚拟文件呢，简单的说就是这个文件并不存在于你的硬盘上，比如你电脑里面没有M盘，但是某程序却能对M:\asdfsrewer\123\334455.exe这样的一个文件进行数据的读写，而且能读写正确。那么这个文件我们就说它是一个虚拟文件。虚拟文件系统就是对虚拟文件句柄的分配管理、虚拟文件数据存储的管理等，根据我这几天调试的一些经验，我觉得这个虚拟文件其实和硬盘上实实在在的文件也没有多大区别，虚拟文件不再硬盘上而直接在内存中，从虚拟文件中读取数据是把内存当做数据的来源，把数据写入到虚拟文件是把内存当做存储介质，相当于把内存当做硬盘用了。要想创建虚拟文件必须先调用BoxedAppSDK_Init，猜测这个函数的主要功能就是HOOK一些文件操作函,然后调用BoxedAppSDK_CreateVirtualFile创建一个虚拟文件，虚拟文件系统返回一个虚拟文件的hFile，这个hFile的值通常是0x600000XX，和我们常见的hFile的值极为不同，由于WriteFile和ReadFile等很多文件操作的API都被BoxedAppSDK给Hook了，所以这些函数对于一个实际上不存在的hFile进行操作并不会产生无效句柄这类错误，最终对数据的读写操作都在内存中而不是硬盘中。内存中虚拟文件数据存储并不是连续的，而是类似链表，一块数据，然后末尾是下一块数据的地址，所以想要在内存中根据文件的特征码搜索文件是行不通的，试想下，你知道了一个pdf文件格式的开头标志是%PDF,结尾标志是%%EOF，然后你用WINHEX打开硬盘，你觉得你能找到这个pdf文件吗？很明显不行，除非你知道了文件的组织格式，内存中的虚拟文件也是这个道理，话说我之前还傻呵呵的以为虚拟文件是连续存储的，想要通过文件格式的标志来dump文件，虚拟文件系统和真机的文件系统都是有组织格式的，只不过前者的格式简单点。

 

上面说的是理论。下面是应用。

凡是用PDF加密器加密过的文件，打开的时候都会出现一个如下所示的对话框：

 

 

我们输入正确的阅读密码经过一系列的验证之后，会创建一个类似Y:\d27b9\70c445ee64b.pdf的虚拟文件，这个文件确实在内存中，由于虚拟文件的数据组织格式我们又不能根据pdf的文件格式的特征码搜索pdf文件并把它dump出来，怎么办呢？经过调试发现，不管你前期把文件怎么处理，最终都要把这个文件交给AcroPDF.dll来处理，所以我们可以patch AcroPDF.dll，等到它CreateFile拿到虚拟文件的hFile之后，我们把这个hFile保存起来然后malloc（GetFileSize（hFile，0）），然后ReadFile，然后把输出到一个文件中，这样我们就获得了pdf文件的内容了。

0012E834 10029563 /CALL 到 CreateFileA 来自 AcroPDF.1002955D
0012E838 0012E880 |FileName = "Y:\d27b9\70c445ee64b.pdf"
0012E83C 80000000 |Access = GENERIC_READ
0012E840 00000000 |ShareMode = 0
0012E844 00000000 |pSecurity = NULL
0012E848 00000003 |Mode = OPEN_EXISTING
0012E84C 00000080 |Attributes = NORMAL
0012E850 00000000 \hTemplateFile = NULL

 

可是AcroPDF可能会调用很多次CreateFile打开各种类型的文件，怎么确定它打开的文件就正好是我们想要的那个pdf文件呢？ 很简单，我们把每次调用的FileName保存起来，检测文件后缀是否为pdf即可。

转载于:https://www.cnblogs.com/shremie/archive/2012/08/17/2644478.html