WinXP System folder after the recovery system, Access denied solution

[Using Ntfsdos (the latest can, have tried to, create a delete file) or Linux software can read and write NTFS partition. Take those files to the FAT32 partition and you can pull them. There is no encryption function for FAT32. EFS encryption is only available in NTFS format. The FAT32 is not. Once it is copied to the FAT32 format, it is automatically lost. ]

Above is the method of friends from the network, specifically not tested. You can try, if you are not familiar with the computer, you can ask a familiar friend to help try.

If the title of the kind is EFS encryption, basically, it is impossible to recover. Because the hack requires a security certificate.

On the internet, the EFS hack basically tries to restore the system disk, hoping to find the information of the system when it is encrypted.

and then hack.

Attach some of the methods found on the Internet, you can try it yourself.

EFS encrypted Chance-the remediation method of encrypted account deletion (original title)

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

Statement: This article refers to a foreign article "Niu", because to master this foreign article, the reader must have some NTFS knowledge, otherwise difficult to see its tidbits. Therefore, the author around the information, coupled with expands, hoping to help readers gentlemen more convenient to understand this article, the Dance good EFS this double-edged sword. Article links are as follows:

http://www.beginningtoseethelight.org/efsrecovery/index.php

Note to users here: This article is not to prove that Microsoft's EFS has a "loophole", nor is it specially prepared for careless "regret medicine" for the treatment of all ills. In fact, if you do not export the EFS certificate and the private key, EFS encrypted files will not belong to you once the user is removed or the system is re-installed.

Tip This article applies to the Windows XP Professional standalone environment, and assumes there are no recovery agents (DRF) and shared access accounts (multiple DDF).

Task description

If a user deletes his or her login account, other users will not be able to access their EFS encrypted files. Even worse, once a user in the company is resentful, malicious encryption of important files belonging to other users can lead to 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 still open the escape before the end of the skylight:

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

(2) The profile of the deleted account must be present. If you use the Local Users and Groups snap-in to delete an account, there is a high chance that the profile will be retained, and if you delete the account by using the user Accounts Control Panel, you will have half the opportunity to keep the profile. If the configuration file is unfortunately deleted, you can only pray for recovery with data recovery tools like easy recovery.

Maybe some friends will think these two conditions are more harsh, here sell a Xiaoguanzi first ...

EFS encryption principle

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

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

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

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

Seen here, it seems that the context of EFS is already clear, but it is not, it is not enough to ensure the security of EFS. The system also adds two layers of protection to EFS:

(1) Windows encrypts the private key with a 64-byte master key (master key), 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. Windows Vista's BitLocker encryption 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 entire EFS-encrypted key schema is shown in Figure 1.

Figure 1

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

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

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

Tip No wonder Windows XP and 2000 are different, administrators reset the account password, and cannot decrypt EFS files.

(2) The deleted account configuration file must exist: the encrypted private key and the master key (also including the certificate and public key), are saved 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, it is of course not possible to restore EFS files.

There may be users who would like to create a new user account with the same name, and then copy the original profile to the new account, then you can decrypt the EFS file? The reason for this is the SID of the account because the SID of the new user cannot be the same as the old account, so the conventional approach is unlikely to work. We have to reinvent the system to recreate an exact sid!.

Recovery steps

For convenience of description, it is assumed that the user name of the deleted account is admin,windows installed on the C drive.

1. Rebuilding SIDs

Note This method is taken from the article mentioned in the "Declarations" section.

First confirm the SID of the deleted account, here you can enter the following folder:

C:documents and Settingsadminapplication Datamicrosoftcryptorsa

There should be a folder under which the SID of the deleted account is named, 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 too, so we can do it.

In Windows, the RID that is 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, at an offset of 0048 at four bytes, which defines the rid of the next account. That is to say, you only need to modify the four bytes at 0048, you can achieve the goal (let the new account get 1004 of the RID)

When you are sure, don't forget to transfer the Admin account profile to another location!

(1) By default, only the system account has access to Hkey_local_machinesam, 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 on the following Web site:

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

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

(3) To illustrate here, Windows is the RID that saves the next account in 16 binary, and in reverse form. What do you mean? That is, if the RID is 1004, the hexadecimal is 03EC, but we have to invert it to EC03 and then expand to 4 bytes, which is EC 03 00 00.

Therefore, we should put the F-key value of 0048 offset, the four byte is changed to "EC 03 00 00", as shown in Figure 2.

Figure 2

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

(5) After restarting, create a new account with the same name admin, its SID should be exactly the same as before. If you don't believe it, you can test it with tools like GetSID or PsGetSid.

2. "Hack" EFS

The next method is very simple, with the new Admin account login system, arbitrarily encrypt a file, and then log off, log in with the Administrator account system, the original reserved configuration file copied to the C:documents and Settingsadmin folder.

Then log into the system with the admin account, you can now decrypt the original EFS file.

Troubleshooting

1. What if the system has been re-installed?

The article mentioned in the "Declaration" section mentions that if you remember the password of the original account and the configuration file was 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, so that the required account SID can be obtained. The remaining steps are exactly the same.

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

2. There are users who have encountered such a problem: when logging on to the system is prompted to say that the password expires, need to reset, reset password after login found to open the EFS file.

KB890951 mentioned the problem. The explanation is that the system has not yet loaded the configuration file (a bit vague) when changing the password, as follows:

This problem occurs because the user profiles for the current user are not loaded correctly after your change the password.

What is the relevance of the profile and EFS? After reading this article, you should know that EFS's private key and master key are stored in the configuration file. Because the configuration file is not loaded, the encrypted version of the master key is not updated (without keeping up with the changes in the account password), causing the master key to not be decrypted correctly, and the private key and FEK cannot be decrypted. This is the real reason for the problem.

The KB provides an internal patch that resolves this issue. KB890951 's links are as follows:

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

3. Questions about the 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 the 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 is unrelated to EFS decryption (it is responsible for encryption).

Originally, in the DDF field of Encrypting File $efs attribute, in addition to the account SID and encrypted FEK copy, there is also the thumbprint information (public key thumbprint) and the private key GUID information (some hash value of the private key).

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

So the public key is also important.

Of course, the public key can be "forged" (can forge the required public key fingerprint and private key GUID) to deceive the EFS system, the specific method can refer to the foreign manuscript, which is not mentioned here.

Enhancing the security of EFS

Because EFS keeps all the relevant keys in the Windows partition, this may pose a security risk to EFS. There are currently some third-party tools that can hack EFS, which first attack the SAM hive file, try to crack the account password, and then crack the account password → master key encryption key → Master key →efs private key →fek "keychain."

To prevent attackers from peering into our EFS files, there are three ways to do this:

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, choose to delete the private key, as shown in Figure 3.

Figure 3

After the private key is removed, there is no way for an attacker 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 the SAM hive file and the EFS private key. Windows XP System Key is saved locally by default

　　Attention:

The

First to understand whether you are using EFS encryption or ACL user Rights control. If you choose to "Use this folder as a private", then the ACL User Rights control, the ACL user Rights control method is as follows: Open "Control Panel → folder Options", under the View tab, clear the "Use simple sharing" front of the complex options, click the OK button. Then right-click the c:documents and Settings username My Documents, select the Security tab, and add your own account to the group and user. If you are using properties → advanced → encryption to protect your data, then you are using EFS encryption technology. EFS encryption uses digital certificates to encrypt files. To unlock EFS encryption, you need to log in with an account that operates with encryption, and then perform the inverse operation of the cryptographic operation. If you reinstall the system, you cannot decrypt the certificate that was created when the previous encryption operation was not imported.