XP folder encryption restore denied access

You can read and write NTFS partitions using Ntfsdos (the latest can, if you've tried, you can create a delete file) or Linux. Take those files to the FAT32 section and you can pull them. FAT32 is not encrypted. EFS encryption is only available in NTFS format. FAT32 is not. 　　One but copied to the FAT32 format is automatically lost. The above is a friend from the network method, specifically not tested. You can try, if you are not very familiar with the computer, you can ask a familiar friend to help try.

If the type of title is EFS-encrypted, it's basically impossible to recover. Because cracking requires a security certificate.

EFS cracking on the internet is basically trying to restore the system disk, in the hope that it can find the information of the system encrypted.

And then to crack.

Attach some methods found on the Internet, you can try it on your own.

EFS-encrypted chance-encrypted account deleted remedy (original topic)

Introduction: See the News Group so many netizens "crying" EFS problem, has long wanted to write an article on EFS. But suffer from too little information on hand, many concepts have not yet rounded through, hastily grass under, this fraught guilt, afraid to escape.

Statement: This article refers to a foreign "cow" article, because to master this foreign article, the reader must have some basic knowledge of NTFS, otherwise difficult to peep its Dongo. Therefore, the author around the information, plus Shan, I hope to help readers more convenient to understand this article, the Dance good EFS this double-edged sword.

Here's a reminder: this is not to prove that Microsoft's EFS is "flawed", nor is it a "regret pill" designed for careless. In fact, if you don't export the EFS certificate and private key, EFS encrypted files don't belong to you once you delete the user or reload the system.

Tip This article applies to Windows XP Professional stand-alone environments and assumes that there are no recovery agents (DRF) and shared access accounts (multiple DDF).

Task description

If a user deletes their login account, other users will not be able to access their EFS encrypted files. What's worse, once a user in a company has a grudge, maliciously encrypting an important file that belongs to another user will cause serious problems. In general, these EFS encrypted files have been sentenced to death, but in fact, as long as the following conditions are met, we can open the escape before the end of the skylight:

(1) The password of the deleted account must be known.

(2) The configuration file of the deleted account must exist. If you delete an account by using the Local Users and Groups snap-in, the configuration file retains a large opportunity, and if you delete the account by using the user Accounts Control Panel, you have half the opportunity to retain the profile. If the configuration file is deleted Unfortunately, you can only pray for recovery with data recovery tools such as easy recovery.

Some friends may feel that these two conditions are more stringent, here sell a word of the first ...

EFS encryption principle

As you know, EFS encryption actually combines symmetric and asymmetric encryption:

(1) Randomly generate a file encryption key (called FEK), used to encrypt and decrypt files.

(2) This FEK is encrypted by the public key of the current account, and the encrypted FEK copy is saved in the DDF field of the file $efs property.

(3) To decrypt the file, you must first use the current user's private key to decrypt the FEK, and then use FEK to decrypt the file.

Seeing this, it seems that the context of EFS is clear, but it's not enough to ensure EFS security. The system also adds two layers of protection to EFS:

(1) Windows encrypts the private key with a 64-byte master key (master), and the encrypted private key is saved in the following folder:

%userprofile%application Datamicrosoftcryptorsasid

Prompts the various private keys in the Windows system to be encrypted with the corresponding master key. The BitLocker encryption for Windows Vista also encrypts the Fvek (full volume encryption key) with its master key.

(2) In order to protect the master key, the system encrypts the master key itself (the key used is derived from the account password), and the encrypted master key is saved in the following folder:

%userprofile%application Datamicrosoftprotectsid

The key schema for the entire EFS encryption.

Tip The structure portion of the EFS key, referenced from chapter 12th of Windows Internals 4th.

Back to the two conditions described in the "Task description" section, now we should understand why:

(1) The password of the deleted account must be known: The master key cannot be decrypted without an account password. Because the encryption key is derived from the account password.

Tip No wonder Windows XP differs from 2000, and the administrator resets the account password and cannot decrypt the EFS file.

(2) The deleted account profile must exist: the encrypted private key and master key (also including certificates and public key), are stored in the configuration file, so the configuration file should not be lost, otherwise it will be completely "devil can not enter the village." After reloading the system, the original configuration file must be deleted, and it is certainly not possible to recover the EFS file.

Perhaps a user would want to just create a new user account with the same name, and then copy the original profile to the new account, and not decrypt the EFS file? The reason is the SID of the account because the SID of the new user is unlikely to be the same as the old account, so the conventional method is unlikely to work We have to do something different to make the system reinvent a sid!.

Recovery steps

To facilitate the description, it is assumed that the user name of the deleted account is admin,windows installed in the C disk.

1. Rebuilding SID

Note that this method is taken from the article mentioned in the "Declaration" section.

First confirm the SID of the deleted account, and here you can go to the following folder:

C:documents and Settingsadminapplication Datamicrosoftcryptorsa

There should be a folder with the name of the SID of the deleted account, for example, s-1-5-21-4662660629-873921405-788003330-1004 (RID is 1004)

Now we're going to try to get the new account to have a 1004 rid, so that we can achieve our goal.

In Windows, the RID assigned by the next new account is determined by the F key value of the Hkey_local_machinesamsamdomainsaccount registry key. The F key value is a binary type of data that defines the rid of the next account at four bytes at offset 0048. So that means you just need to modify the four bytes at 0048 to achieve the goal (let the new account get a 1004 RID)

When you are sure, do not forget to transfer the Admin account profile to another location!

(1) By default, only the system account has access to Hkey_local_machinesam, and here at the cmd Command Prompt window, run the following command to open Registry Editor as the SYSTEM account:

Pexec-i-d-s%windir%regedit.exe

Tip You can download psexec at the following Web site:

Http://www.sysinternals.com/Utilities/PsExec.html

(2) Navigate to the Hkey_local_machinesamsamdomainsaccount registry key and double-click to open the F key value on the right.

(3) To illustrate here, Windows is a RID that saves the next account in the form of 16, and in reverse. What does that mean? In other words, if it is a 1004 rid, the hexadecimal is 03EC, but we have to invert it into EC03, then expand to 4 bytes, which is EC 03 00 00.

So, we should take the 0048 offset of the F key value and change the four bytes to "EC 03 00 00", as shown in Figure 2.

(4) Important: Don't forget to reboot the computer!

(5) After the reboot, create a new account admin with the same name, and its SID should be exactly the same as before. If you do not believe, you can use GetSID or PsGetSid and other tools to test.

2. "Cracking" EFS

The next method is very simple, with the new Admin account login system, random encryption of a file, and then log off, with the Administrator account login system, the original retention of the configuration file copied to the C:documents and Settingsadmin folder.

You can now decrypt the original EFS file by logging into the system with the admin account.

Troubleshoot

1. What if the system has been reloading?

The article mentioned in the "Declaration" section mentions that if you remember the password for the original account and the configuration file is not deleted, there is hope. You can then use the Sysinternals NewSID tool to reset the system's computer SID to its original value, and then construct the desired RID using the method described previously, thus obtaining the required account SID. The remaining steps are exactly the same.

2. A user has encountered such a problem: Log on to the system when you are prompted to say that the password expired, need to reset, reset password after logging in to open EFS file.

KB890951 mentioned the problem. This is explained by the fact that the system has not loaded the configuration file (somewhat vague) when the password was modified, as follows:

This problem occurs because of the user profile for the "current" not "loaded correctly after your change the password.

What does the configuration file have to do with EFS? After reading this article, you should know that EFS's private key and master key are all stored in the configuration file. Because the configuration file is not loaded, the encrypted version of the master key is not updated (no changes to the account password), resulting in the master key not being decrypted properly, thus unable to decrypt the private key and FEK. That is the real reason for the problem.

This KB provides an internal patch to solve this problem. KB890951 's links are as follows:

http://support.microsoft.com/kb/890951

3. Issues relating to public key

To be easy to understand, the author deliberately ignores the public key. The public key save is also saved in the account's configuration file:

%userprofile%application datamicrosoftsystemcertificatesmycertificates

In an EFS recovery operation, you must ensure that the public key is also copied to the new account's configuration file. Although it appears that the public key has nothing to do with EFS decryption (it is responsible for encryption).

In addition to the DDF field of the encrypted File $efs property, there is the account SID and the encrypted FEK copy, as well as the fingerprint information (public key thumbprint) and the private key GUID information (a hash value of the private key).

When the system scans the DDF field in the $efs property of the encrypted file, depending on the public key fingerprint and the private key GUID contained in the user profile, and of course the SID of the account, the account has a corresponding DDF field to determine whether the user is a legitimate EFS file owner.

So the public key is also important.

Of course the public key can be "forged" (you can forge the required public key fingerprint and the private key GUID) to deceive the EFS system, the specific method can refer to the foreign manuscript, here no longer repeat.

Enhance EFS's security

Because EFS keeps all the relevant keys in the Windows partition, this may pose a security risk to EFS. At present, some third-party tools claim to be able to crack EFS, these tools attack the SAM hive file first, try to crack account password, thus cracked account password → master key encryption key → Master key →efs private key →fek "key chain."

To prevent attackers from peering into our EFS files, you can use the following three ways:

1. Export Delete private key

You can use the Certificate Wizard to export the EFS encryption certificate and private key, and in the Certificate Export Wizard dialog box, select Remove the private key.

After the private key is removed, the attacker will have no way to access the EFS encrypted file, and when we need access, we simply import the previously backed up certificate and private key.

2.System Key provides additional protection

System Key provides additional protection for Sam Hive files and EFS private keys. Windows XP's system key is saved locally by default: First, make sure that you are using EFS encryption or ACL user Rights control. If you select "Use this folder as a private", the ACL user Rights control is used, and the ACL user Rights control method is as follows: Open Control Panel → folder Options, clear the duplicate options in front of the "Use simple sharing" option under the View tab, and click the OK button. Then right click on c:documents and Settings username My Documents, select the Security tab, in the Group and users to add their own account. If you are using attribute → advanced → encryption to protect data, then you are using EFS encryption technology. EFS encryption technology encrypts files with a digital certificate. To unlock EFS encryption, you need to log on with an account that is operating with encryption, and then perform the reverse operation of the encryption operation. If you reinstall the system, the decryption operation cannot be performed without importing a certificate that was created by the system prior to the encryption operation.