EFS加密的一线生机－加密帐户被删的补救方法
EFS加密此文声明：本文并非本人原创，只是看到比较好，希望能够给大家学习带来帮助。引子：看到新闻组里那么多网友“哭诉”EFS问题，早就想写一篇EFS的文章。但是苦于手头资料太少，很多概念尚未圆润贯通，匆匆草就之下，这误人子弟的罪责，怕是逃不过的。
作者声明：本文参考了国外一篇“牛”文，由于要掌握这篇国外文章，读者必须具备一些NTFS底层知识，否则难窥其堂奥。故此笔者四处网罗资料，加上穿凿附会，希望能帮助读者诸君更方便省时地领会这篇文章，舞好EFS这把双刃剑。英文原文请看一楼；
这里需要提醒用户注意：本文并非为了证明微软的EFS存在 “漏洞”，也不是专为马大哈们准备的包治百病的“后悔药”。事实上如果没有导出EFS证书和私钥，那么一旦删除用户、或者重装系统，EFS加密文件就不属于你了。
提示 本文适用于Windows XP Professional单机环境，并假设没有恢复代理(DRF)和共享访问帐户(多个DDF)。
EFS解密任务描述
如果某个用户把自己的登录帐户删除，那么其他用户将无法访问其EFS加密文件。更可恶的是，一旦公司里的某个用户心怀怨气，恶意加密了本属于别的用户的重要文件，将会导致严重问题。一般情况下，这些EFS加密文件已经被判了死刑，但是实际上只要满足以下条件的话，我们还是可以在末日来临之前打开逃生的天窗：
(1) 必须知道该被删帐户的密码。
(2) 该被删帐户的配置文件必须存在。如果使用“本地用户和组”管理单元删除帐户，则配置文件保留的机会很大，如果使用“用户帐户”控制面板删除帐户，则有一半机会保留配置文件。如果配置文件不幸被删，则只能祈祷可以借助Easy Recovery之类的数据恢复工具进行恢复。
可能有些朋友会觉得这两个条件比较苛刻，此处卖个关子先……
EFS加密原理
大家知道，EFS加密实际上综合了对称加密和不对称加密：
(1) 随机生成一个文件加密密钥(叫做FEK)，用来加密和解密文件。
(2) 这个FEK会被当前帐户的公钥进行加密，加密后的FEK副本保存在文件$EFS属性的DDF字段里。
(3) 要想解密文件，首先必须用当前用户的私钥去解密FEK，然后用FEK去解密文件。
看到这里，似乎EFS的脉络已经很清晰，其实不然，这样还不足于确保EFS的安全性。系统还会对EFS添加两层保护措施：
(1) Windows会用64字节的主密钥(Master Key)对私钥进行加密，加密后的私钥保存在以下文件夹：
%UserProfile%\Application Data\Microsoft\Crypto\RSA\SID
提示 Windows系统里的各种私有密钥，都用相应的主密钥进行加密。Windows Vista的BitLocker加密，也用其主密钥对FVEK(全卷加密密钥)进行加密。
(2) 为了保护主密钥，系统会对主密钥本身进行加密(使用的密钥由帐户密码派生而来)，加密后的主密钥保存在以下文件夹：
%UserProfile%\Application Data\Microsoft\Protect\SID
整个EFS加密的密钥架构如图1所示。
提示 EFS密钥的结构部分，参考自《Windows Internals 4th》的第12章。
回到“任务描述”部分所述的两个条件，现在我们应该明白原因了：
(1) 必须知道该被删帐户的密码：没有帐户密码，就无法解密主密钥。因为其加密密钥是由帐户密码派生而来的。
提示 难怪Windows XP和2000不同，管理员重设帐户密码，也不能解密EFS文件。
(2) 该被删帐户的配置文件必须存在：加密后的私钥和主密钥(还包括证书和公钥)，都保存在配置文件里，所以配置文件万万不可丢失，否则就会彻底“鬼子不能进村”。重装系统后，原来的配置文件肯定被删，这时候当然不可能恢复EFS文件。
可能有用户会想，只需新建一个同名的用户帐户，然后把原来配置文件复制给新帐户，不就可以解密EFS文件了？原因在于帐户的SID，因为新建用户的SID不可能和老帐户一样，所以常规方法是不可能奏效的。我们必须另辟蹊径，让系统再造一个完全一样的SID！
EFS加密恢复步骤
为了方便描述，这里假设被删帐户的用户名为Admin，Windows安装在C盘。
1．再造SID
注意 本方法取自“声明”部分提到的那篇文章。
首先确认被删帐户的SID，这里可以进入以下文件夹：
C:\Documents and Settings\Admin\Application Data\Microsoft\Crypto\RSA
在其下应该有一个以该被删帐户的SID为名的文件夹，例如是S-1-5-21-4662660629-873921405-788003330-1004(RID为1004)
现在我们要设法让新建帐户同样具有1004的RID，这样就能达到目的。
在Windows中，下一个新建帐户所分配的RID是由HKEY_LOCAL_MACHINE\SAM\SAM\Domains\Account注册表项的F键值所确定的。F键值是二进制类型的数据，在偏移量0048处的四个字节，定义下一个帐户的RID。那么也就是说，只需要修改0048处的四个字节，就能达到目的(让新建帐户获得1004的RID)！
确认好以后，别忘记把Admin帐户的配置文件转移到别的地方！
(1) 默认情况下，只有system帐户才有权限访问HKEY_LOCAL_MACHINE\SAM，这里在CMD命令提示符窗口，运行以下命令，以system帐户身份打开注册表编辑器：
psexec -i -d -s %windir%\regedit.exe
提示 可以在以下网站下载psexec：
http://www.sysinternals.com/Utilities/PsExec.html
(2) 定位到HKEY_LOCAL_MACHINE\SAM\SAM\Domains\Account注册表项，双击打开右侧的F键值。
(3) 这里要说明一下，Windows是以十六进制、而且以反转形式保存下一个帐户的RID。什么意思呢？也就是说，如果是1004的RID，对应十六进制就是03EC，但是我们必须把它反转过来变成EC03，再扩展为4个字节，就是EC 03 00 00。
所以，我们应该把F键值的0048偏移量处，把其中四个字节改为“EC 03 00 00”，如图2所示。
(4) 重要：别忘了重启计算机！
(5) 重启以后，新建一个同名帐户Admin，它的SID应该和以前是完全一样。如果不相信的话，可以借助GetSID或者PsGetSID等工具测试一下。
2．“破解”EFS
接下来的方法就非常简单了，用新建的Admin帐户身份登录系统，随便加密一个文件，然后注销，用管理员帐户登录系统，把原来保留的配置文件复制到C:\Documents and Settings\Admin文件夹下。
再用Admin帐户登录系统，现在可以解密原来的EFS文件了。
EFS加密疑难解答
1．如果已经重装系统，那怎么办？
“声明”部分提到的那篇文章里提到，如果还记得原来帐户的密码，并且配置文件没有被删除的话，还有希望。这时候可以借助sysinternals的NEWSID工具把系统的计算机SID重设为原来的值，再用前面描述的方法构造所需的RID，这样就可以获得所需的帐户SID。剩余步骤完全一样。
http://www.sysinternals.com/Utilities/NewSid.html
2．有用户曾经遇到这样的问题：登录系统时收到提示说密码过期，需要重设，重设密码登录后发现打开EFS文件。
KB890951提到这个问题。其解释是因为在修改密码时，系统还没有加载配置文件(有点语焉不详)，原文如下：
This problem occurs because the user profile for the current user is not loaded correctly after you change the password.
配置文件和EFS有何相干？看完本文，大家应该知道，EFS的私钥和主密钥都是保存在配置文件里的。由于配置文件没有加载，所以主密钥的加密版本没有得到更新(没有跟上帐户密码的变化)，导致主密钥无法正确解密，从而无法解密私钥和FEK。这就是问题的真正原因。
该KB提供了一个内部补丁，可以解决这个问题。KB890951的链接如下：
http://support.microsoft.com/kb/890951
3．有关公钥的问题
为了容易理解，笔者故意忽略了公钥。公钥保存也保存在帐户的配置文件里：
%UserProfile%\Application Data\Microsoft\SystemCertificates\My\Certificates
在EFS恢复的操作中，必须确保公钥也要复制到新帐户的配置文件里。尽管看起来公钥与EFS解密无关(它负责加密)。
原来，加密文件$EFS属性的DDF字段里除了有帐户SID和加密的FEK副本外，还有公钥的指纹信息(Public Key Thumbprint)和私钥GUID信息(私钥的某种散列值)。
系统在扫描加密文件$EFS属性中的DDF字段时，根据用户配置文件里的公钥中所包含的公钥指纹和私钥GUID信息，当然还有帐户的SID，来判断该帐户是否具有对应的DDF字段，从而判断该用户是否属于合法的EFS文件拥有者。
所以公钥也很重要。
当然公钥是可以“伪造”的(可以伪造出所需的公钥指纹和私钥GUID)，以欺骗EFS系统，具体方法可以参考国外的那篇原稿，此处不再赘述。
加强EFS的安全
由于EFS把所有的相关密钥都保存在Windows分区，所以这可能给EFS带来一定的安全隐患。目前有一些第三方工具号称可以破解EFS，这些工具首先攻击SAM配置单元文件，尝试破解帐户密码，从而破解帐户密码→主密钥的加密密钥→主密钥→EFS私钥→FEK的“密钥链”。
为了防止攻击者窥视我们的EFS文件，可以借助以下三种方法：
1．导出删除私钥
可以用证书向导导出EFS加密证书和私钥，并且在“证书导出向导”对话框里选择删除私钥，如图3所示。
删除私钥以后，攻击者就没有办法访问EFS加密文件了，而我们需要访问时，只需导入先前备份的证书和私钥即可。
2．System Key提供额外的保护
System Key可以对SAM配置单元文件和EFS私钥提供额外保护。Windows XP的System Key默认保存在本地，我们可以运行syskey命令，强制系统将System Key保存在软盘里，或者用启动密码(startup password)来生成System Key。
由于EFS“密钥链”的根密钥(System Key)没有保存在本地计算机中， 所以攻击者将更加难以破解EFS加密。
提示 BitLocker加密的recovery key，类似于syskey的startup password，都是借助启动时所输入的一串密码来生成所需的密钥。
3．BitLocker提供更彻底的保护
本方法仅适用于Windows Vista(Enterprise和Ultimate Edition)。
最彻底的保护方法，首推Windows Vista新引入的BitLocker加密，这时候Windows分区的所有内容全部被加密(包括SAM配置单元、EFS密钥)。
BitLocker(TPM1.2)加密可以看成是Windows启动保护器。在系统启动时，TPM芯片会负责分析各个重要的启动组件，以判断自己是否位于原来的计算机环境。如果是的话，就依次释放BitLocker加密所需的密钥链，我们才能顺利地访问Windows，才能访问EFS文件。
如果攻击者企图把硬盘挂接到别的计算机上，系统就会拒绝释放密钥，整个Windows Vista分区处于加密状态。
如果攻击者窃取了计算机，并且窃取了BitLocker所需所有条件(TPM芯片自不必说，假设也获得密钥U盘)。这时候系统能够顺利引导，并且成功释放BitLocker密钥链。但是攻击者还必须想办法知道帐户的密码，否则无法登录系统，Windows分区依然处于加密状态。
EFS额外保护的原理如图4所示。
4．题外话：为什么释放BitLocker密钥以后，Windows分区依然处于加密状态？
所以尽管BitLocker密钥已经释放，但是Windows分区并没有被立即全部解密。否则每次启动，都要解密整个Windows分区，得花多少时间(笔者的Vista分区完全解密，共花3小时)！
原来BitLocker加密是以一个FVE Filter Driver来实现加密和解密，该Filter Driver处于文件系统驱动的下层。登录系统以后，用户需要访问文件时，文件系统会自动请求FVE Filter Driver进行解密，猜想应该是一次解密一个Block，每个Block可能是512字节(和EFS一样)，不敢确定。对于用户来说，这个过程是完全透明的，同时对性能的影响很小，几乎可以忽略不计。EFS加密的情况有点类似。
写在最后
这里非常敬佩国外微软技术爱好者的执着，事实上该作者还有一篇经典的文章(描述SAM配置单元文件的二进制结构)，链接如下，非常值得推荐。
很难想象，要编写这样的文章，得花费多少的人力和时间，要做多少的实验才能在SAM数据库逐个字节地找出其对应的含义！
本文的目的，也是为了向这些国外的作者致敬。
introduction
this article updates the quick writeup that started in the temp directory of this domain detailing how to import users encrypted file system (efs) keys from an old offline profile into a new system in order to gain authorized access to previously inaccessible encrypted data.
note well that this method is for advanced users. there are some programs/services out there that maybe better suited for you.
if method 02 or 04, there is a chance that the reinstall has not overwritten the orginal efs keys. most formats only wipe the file structure and since all file are copied and the pagefile is created before profile creation and encryption keys even further on, it is possible that on reinstall the orginal encryption keys have not been overwritten and are still on the disk somewhere. it is possible to search the volume for this key data and if present, recover it - if you are serious about attemping this, power down the machine as soon as possible, because as reinstall uptime increases the chances of this key data being overwritten also increases.
recovery with the orginal profile in the file system
you can do this procedure on the current install, however the more cautious may want to use a second test install. backup all changes if you use the current.
you will need a user account of the same user and machine number as the orginal. check this orginal folder name: c:\documents and settings\%username%\application data\microsoft\crypto\rsa\s-1-5-21-1078081533-1606980848-854245398-1003
machine is: 1078081533-1606980848-854245398
useracc is: 1003
converted into hex the machine sid is: fd374240 f094c85f 16c0ea32
(convert each block into hex and reverse bytes for each section) useracc is: 3eb
goto: hklm\sam\sam\domains\account\users\%usernumbers%
check if a user account is already present of the orginal account number. if there is, check the username (\v) logon and create a profile and change the password to the one from the orginal machine. if there is not a user account of the same number, create one that is, you may want to modify hklm\sam\sam\domains\account\f offset 48 to the required number before you create. add the user to the admin group.
goto: hklm\sam\sam\domains\builtin\aliases\00000220\c and modify the machine sid prefixing your orginal user number. (towards the end)
goto: hklm\sam\sam\domains\account\v and modify the machine sid at the end to your orginal number.
goto: hklm\software\microsoft\windows nt\currentversion\profilelist\ select key called your machine number suffixed by your user number, export, modify the key to the orginal machine/user number and import.
copy the orginal three folders into:
c:\documents and settings\%username%\application data\microsoft\
restart - login using the orginal password. access to your files should be possible. decrypt.
NOTE: this method is slightly brief and advanced. I have not written up a newer version of this article yet, which will include a simpler step by step. In the meantime if you get stuck, try following this procedure instead:
first set the orginal sid. probably easier if you run newsid than editing hex values in the registry, download here: http://www.sysinternals.com/ntw2k/source/newsid.shtml make sure that you are using a test install or backedup setup or specifically not using efs since on changing the sid you will not have access to your currently encrypted files. set the new sid to be the one in your old profile directory eg: c:\documents and settings\%username%\application data\microsoft\crypto\rsa\s-1-5-21-1078081533-1606980848-854245398-1003 -> newsid would be s-1-5-21-1078081533-1606980848-854245398 - after this is done, reboot if not automatic. ignore any further reference to the sid in the article since this is now correct.
encrypt a test file, then browse to c:\documents and settings\%username%\application data\microsoft\crypto\rsa\ - is the number on the end of the sid eg 1003 the same as the previous number? if it is the same, skip this next part.
if not, check the other accounts on the computer else you either need to create a user that does have the same user or modify your existing user to have the orginal number - probably easier if you create new user. user numbers increment, since they are linked with security, no two users must ever have the same number, if the orginal usernumber is higher than the current one, create some new accounts, logon, encrypt a test file and check the number untill you have a correct user number. if orginal number is lower than the current one you will need to reset the usernumber counter, run regedit -> default registry permissions deny access to hklm\sam\sam\... select the hkey_local_machine\security\ key and right-click(if xp/2003srv) or use regedt32 and do security -> permissions(if 2k) check the allow full control while selecting the admistrators group -> advanced -> check reset permissions on all child objects and enable propagation of inhertitable permissions -> ok/yes/ok. since the sam hive is setup as a link folder with sam, you should now be able to access hklm\sam\sam\domains\account\ - double click the f value, at offset 0048 there is 4 bytes that state the next created usernumber, make a note of this, so you can restore later. you need to convert the orginal usernumber into hex. run calc -> view: scientific -> type in the user number eg, 1003 and then change the base (top left) from dec to hex. the number should now read 3eb, now what is really means is 00,00,03,eb reverse these byte so it reads: eb,03,00,00 this is the new value to enter in at offset 48. after editing you will need to restart the machine. now when you create a new user it should have the correct number. remember to reset the counter back to what it was before.
once you have a user, with the correct user number and the machine has the correct sid number, copy the old folders from c:\documents and settings\%username%\application data\microsoft\ into the current users folders. set the users password to the one that was used before and try to access the files. check ntfs permissions also if denied.
CHECK!! - updates soon
note if you are restoring a 2k efs access and still get errors, it is possible that the locking file was not updated on a password change - since efs on 2k(only) relies primarily on the syskey (major weakness if syskey is stored locally) you may have to import the orginal syskey - details of this are listed on the ntsecurity page or email me for a more step-by-step process.
recovery with the orginal profile not in the file system
it is _highly_ recommended to mount the disk containing the volume with the orginal install on as slave on a second machine as your recovery activities may overwrite the key data. - if you are using a laptop, get a 2.5" to 3.5" ide cable. avoid all data writes to the orginal volume.
you will need a decent hex editor (winhex recommended) and filemon from sysinternals or equivalent.
first some key pieces of information need to be optained from the encrypted files themselves. you can either jump on the ntfs to the efs header or (recommended) use ntbackup to backup one of the encrypted files you cannot access. open the backup with a hex editor and scroll down untill you see something like this.
green = the machine sid and usernumber in hex
fd374240 f094c85f 16c0ea32 eb030000 -> reverse
404237fd 5fc894f0 32eac016 000003eb -> convert to decimal
1078081533-1606980848-854245398-1003 -> prefix with s-1-5-21- for full sid/userno.
red = the public key thumbprint
79B73C0C5A501E06B9EC0A6EF4A3B8CB23BF84E9 - this is the filename of the public key
blue = the private key guid - this section maynot be present if other users have been added.
now to search the orginal volume for the data of the two critical files - the private key and the locking file.
within the private key the guid(blue) is stored, the difference between the efs header is that it is stored in ascii, not unicode. if the private key guid was not present in the efs header you can search for "cryptoapi private key" in unicode, some results maynot be the correct ones, but this will be obvious on sight. the private key should look some thing like this. recover and name "privatekey" for now.
note well - if you do not find this private key, this method will not work and specialist methods must be used.
blue = private key guid - mentioned before
cyan = the locking file name and also mentioned within.
9f7479dc ea80 924a b41f 6392c4e3b72d -> some reversing
dc79749f-80ea-4a92-b41f-6392c4e3b72d
do a search for this string in unicode. the locking file should look something like this. recover and name as pictured in cyan in ascii.
note well again - if you do not find this locking file, this method will not work and specialist methods must be used.
cyan = the locking file name - mentioned before
yellow = a hex string required for the credhist file
dc42a7eeac5b104481336024113992ff - as is.
if you have just successfully recovered these two pieces of data, things are looking very good!! no further data needs to be recovered from the orginal install.
create a file called credhist so it looks like this:
yellow = as is, taken from the locking file - mentioned before
create a file called preferred so it looks like this:
on the second installation that you are running, encypyt a file so that you create a set of efs keys. copy out the public key from c:\documents and settings\foo\application data\microsoft\systemcertificates\my\certificates\ and rename to the public key thumbprint mentioned in the efs header - mentioned before. open in the hex editor and update the following sections.
blue = private key guid - mentioned before
red = public key thumbprint - mentioned before
follow the method "recovery with the orginal profile in the file system" detailed in the previous section and place the files into their correct locations. reboot.
c:\documents and settings\foo\application data\microsoft\
\crypto\rsa\s-1-5-21-1078081533-1606980848-854245398-1003\privatekey
\protect\credhist
\protect\s-1-5-21-1078081533-1606980848-854245398-1003\ (2files)
dc42a7eeac5b104481336024113992ff
preferred
\systemcertificates\my\certificates\79b73c0c5a501e06b9ec0a6ef4a3b8cb23bf84e9
the privatekey needs the correct name, this is determined from the private key guid by some unknown hashing process, however filemon can record the system request and thus the correct file name can be resolved. run filemon and simply select one of the encrypted files, stop filemon and apply a highlighting filter of "file not found" scroll up untill you see highlight entry by the process lsass. you should see the complete folder name request with the correct file name - something like this: bb1c31a261eed4c09b0a92ad011aae21_904f931f-4993-4059-ab65-e3961044d535 - you can ignore the second half, it is merely the machine guid querried from the registry - hklm\software\microsoft\cryptography\machineguid - you can just used the resolved hash followed by an underscore - bb1c31a261eed4c09b0a92ad011aae21_
now try accessing the encrypted file - it should all matchup. decrypt.
recovery with no information at all - specialist methods.
even if the key data has been overwritten it can still be recovered, unsure of companies and price, but this page details the technique - interesting to read, aside from efs.
the other way is matching the fek - if you scroll backup to the efs header image you will notice there is a section of size 128bytes, after username@machinename - within this block are the keys for decrypting the data, plus probably some user verifying entries. without the correct efs key this cannot be decrypted. although the encryption process appears to work on a 512 bytes basis, it really encrypts/decrypts in 8 bytes blocks. many popular file formats have standard headers of 8bytes and more, thus for these files, the plain text is already know, and thus can be matched against all fek keys for the correct key, once found the key can be applied to the remaining file. the first step in this process would be to determine the key format from a working system and then apply the correct encryption algorithm to the encrypted data. the time taken to get a match would vary greatly on the hardware and algorithm used and since the fek is different for each file, it could take along time to decrypt all the files - though not impossible...
in closing - backup your efs keys properly!!
you must get permission from the respective author before reproduction 先谢了 怎么有鸟语，看不懂啊 高级文章.呵呵 绝对的上乘之作，有时间要好好拜读下 好东西，虽然看不太懂，还是先保存起来 有时间要好好拜读下 高，实在是高！ 我们好菜呀
,看不懂,还是谢谢楼主