Day 3337 Acrobat XI 使用amtlib.dll破解的后遗症

事情的起因是：最近使用WinRAR解压缩文件时，出现了一个奇怪的现象：通过双击打开压缩包中的某个文件时，无论选择的文件是什么，都会自动打开桌面上的第一个文件。我的桌面上第一个文件是1.jpg，就算双击一个exe文件，这个jpg也会冒出来，而如果用WinRAR内置的「查看」功能（右键点击文件选择「查看」菜单项），则会用WinRAR内置的文本查看器打开这个1.jpg，奇怪之极。

一开始完全不明所以，直到后来发现另一个软件也开始出问题，这个软件的中文名字叫影之袜（请自行翻译）。原本其运行良好，但最近每次在系统启动时，都会弹出一个它的异常，上书：拒绝访问。经过一番研究，发现这个软件需要向临时文件目录写一点东西才能运行，所以拒绝访问指的是向Temp目录写失败。

因为最近将UAC设置拉到了最高级别（始终通知），于是尝试降低甚至关闭UAC，没有变化，并且通过查阅资料得知，UAC拉到最高并不会影响Temp目录的写入权限，于是排除之。

问题指向Temp目录的写权限赋予，去C:\Users\{用户名}\AppData\Local下查看Temp目录的安全设置，发现变成了这样：

而同目录下其它文件夹的权限都是这样，区别就在于当前用户是否在其中（本例即为LucsiroTouka）：

于是尝试将当前用户重新加入列表，现在再使用WinRAR和影之袜（XD）都不会出现拒绝访问或解压缩后打开失败的问题了。

本以为问题就这么解决了，结果第二天重启的时候发现问题又打回了原形，不仅如此，即使在同一次启动中，也会出现权限修改后变回去的问题，这下倒是真的难住了自己，因为问题的发生似乎是毫无征兆的。

直到Google到了这样一篇文章：http://www.tomshardware.com/forum/3387-73-temp-folder-writing-permission-itself

原来在2013年就有人遇到过这个问题，并且花了两个星期才排查出原因来，而这个原因也是比较出人意料的：是使用amtlib.dll破解的Adobe Acrobat XI搞的鬼。

Amtlib.dll是Adobe系列产品中负责验证授权的一个库文件，使用修改后的该文件进行激活的原理是屏蔽了联网验证，比hosts法更进一步（因为hosts无法自动添加新服务器，一旦Adobe更新了验证服务器的域名，则当前使用的非法序列号会立即被屏蔽，并使产品进入使用乃至禁止使用的状态）。

但使用网上流行的、版本为6.2.0.42的修改版amtlib.dll对Adobe Acrobat XI进行激活存在一个奇怪的问题（其它Adobe软件不存在这个问题，至少CS6版本的Photoshop、Illustrator、LightRoom和Indesign是这样），也就是前述的、会导致temp目录可写状态变动。想到最近使用过Acrobat处理过PDF，也就验证了这个想法：首先手动为当前用户分配Temp文件夹的「完全控制」权限，然后运行Acrobat进行一些操作（例如：另存一个PDF），再回去看Temp文件夹的权限，果然有又变回了只有Everyone和Administrators的情况。

问题的根源找到了，但软件还得用，怎么办呢？

原帖中给出了一个解决方法：因为FAT32分区不支持NTFS的权限控制，所以在硬盘上开辟一个小的（如1GB）Temp专用分区，然后修改系统环境变量，将Temp目录指向那里，问题就解决了。但可能也有人跟我一样看见FAT32心里就犯嘀咕：虽然轻易遇不到，但万一哪天需要拆一个单文件大于4G（假设该分区可用空间足够）的文件到临时文件夹怎么办？

另一个解决方案是更换没有问题的6.2.0.42版的修改版amtlib.dll文件，这个似乎比较难，找了很多都不见有效，但中途发现了一个版本为7.0.0.169的文件，在其它文件不见有效的情况下，尝试将其替换到Acrobat目录下，结果问题就这么顺利解决了。因为之前看到过帖子，称如果使用旧版本（如某个版本号为3.x的amtlib.dll）会导致Acrobat的组件（如Acrobat Distiller）出错、无法启动，经测试，这个7.0.0.169也会出现这个问题，但并不影响Acrobat本身的使用，且可解决本日志的主要问题——temp文件夹权限异常变动，所以就这样用下去了。

附这个7.0.0.169版的amtlib.dll下载（点击此处）。注：本文件来自互联网，本站不对其内容负责。