EFS加密技术概念详解与一次解密实例

EFS加密（全称 Encrypting File System）是一种基于 NTFS 文件系统的加密技术，其核心机制采用公钥策略。具体工作流程如下：当您加密某个文件或文件夹时，系统会随机生成一把“文件加密密钥”（FEK），然后利用该密钥结合特定加密算法将文件转为密文并存储到硬盘上，同时删除原始文件。接着，系统会使用您的公钥对该 FEK 进行加密，一并存入同一个加密文件中。当您本人再次打开该文件时，系统会调用您的私钥解密出 FEK，再用 FEK 解开文件内容。如果您是首次使用 EFS，系统会先为您生成一套公钥/私钥对。若处于域环境，这套密钥由域控制器管理；若仅在本地机器上，则由本机自行生成。

您可能会问，过程听起来复杂，实际使用是否麻烦？事实上，EFS 对用户而言是透明的。只要登录 Windows，您就能直接打开任何被授权访问的加密文件。换句话说，您自己加密的数据，访问时完全感觉不到障碍。但如果是其他非授权用户试图打开，系统会直接返回“访问拒绝”。这一设计初衷很好，但问题也恰恰出在这里。

回到正题。很多人习惯电脑几乎只有自己使用，系统重装是家常便饭，备份密钥？根本不存在的。我以前也是如此，所以几乎从未用过 EFS。直到最近看到不少求助帖，说重装系统后，之前加密的文件全变成乱码，数据恢复无望。这让我突然来了兴趣，想探究在特定条件下，能否找到一种“非正统”的方法来读取这些加密数据。

我搭建了一个测试环境：Windows XP Pro SP2 系统，在一个 NTFS 分区上创建了 test 文件夹，启用 EFS 加密，里面只放了一个加密的文本文件 1.txt。测试路线分两步：先看本地用另一个账户能否搞定，再模拟重装系统（更换系统盘）的情况观察效果。

第一步：尝试本地账户与系统级读取

首先，我启用了系统里的 GUEST 账户。不出所料，从资源管理器直接访问 test 文件夹会报错。接着，我使用命令行工具 PsExec，尝试以 SYSTEM 账户身份登录。结果显示进程创建失败，权限不足。这条路在本地账户下似乎行不通。

然后，我新建了一个管理员账户“test”并登录。在该账户下，资源管理器可以打开 test 文件夹，但无法读取 1.txt 文件。这时，我再次尝试用 PsExec 以 SYSTEM 账户登录。这次成功了！打开那个文件时，内容虽然显示为乱码，但这一步非常关键。

真正的突破来自系统工具 IceSword（冰刃）。我在 IceSword 的“文件”功能里定位到 test 文件夹，右键点击 1.txt，选择“复制到桌面”，文件名随意，后缀不变。神奇的事情发生了：双击桌面上这个“复制品”，文件内容竟然正常读取了出来！这是第一次成功绕过 EFS 加密。

第二步：模拟系统重装（跨系统环境）

接下来，我尝试模拟重装系统的情况。将电脑切换到装有 Windows Server 2003 SP1 的系统（以管理员身份登录）。用同样的方法，通过 IceSword 复制 1.txt 到桌面。打开后，显示的全是乱码，与用 SYSTEM 账户读取时的结果一模一样。第二种尝试宣告失败。

说回这次测试，虽然没能解决密钥丢失后彻底恢复数据这一终极难题，但它揭示了几个有意思的现象，也为我们理解系统安全机制提供了独特的视角。

本次探索的意义与局限

目前这个方法的实际应用范围比较有限，它主要适用于查看当前系统中，由其他用户使用 EFS 加密过的文件——前提是这个被加密的文件对应的密钥仍在系统里。请务必注意，这种方法不应被用于任何违法或侵害他人权益的行为。

本次实验使用了两个工具：PsExec 和 IceSword。前者是国外主流的命令行远程控制工具，后者则是国内著名的隐藏进程查看软件，由 PJF 开发。

成功的关键与待解的谜题

这个方法能奏效，推测需要满足两个前提：第一，您必须有足够的权限来运行上述两个软件（结合 net user 等命令应该不难获得，这里只是一个思路，读者还请自律）。第二，也是我初步推测的核心点：系统内必须还保留着那个 EFS 加密文件对应的密钥。

至于为什么能成功，原因猜测有两点：

一是利用了 SYSTEM 账户特有的内核级权限，这可能让它能够绕过常规的用户权限限制，读取到管理员或其他用户的密钥。

二就是 IceSword 本身读取加密文件的技术。这一点是我最百思不得其解的地方。它是如何绕过 EFS 的加密层，直接读取原始数据的？这背后的实现原理非常值得探讨，真希望能听到 PJF 本人亲自讲讲其中的门道。