General discussion


Recovering Encryption Keys from Windows XP

By amitpjjain ·
I was using Winodws XP with the admin rights. And have used the NTFS encryption to encrypt files on local HDD as well as external.
Now that the system is not booting up - I have replace the HDD form the system and connect the olh HDD though USB port.
The drive is browsable. And I believe atleast my user account will be saved.

My base concern is to recover the encryption key form the systemand install it on the new OS loaded.

Regarding this -

1) The error while booting is " system32/ config/system file missing or corrupted" I have been advised to replace the same files with theones in the i386 folder. Will this effect my user account or my password. OR shoulf I refrain form trying this.

2) If there is a way to take image of the partition so that we can try to experiment on the HDD and in case of any problem we can restore back.

3) If there is a way to access my previous user account profile and load it onto my new system - will it solve the problem.

4) If the file is located at some particular system folder - is there any way to just copy and paste those files

5) The MS site talks about Recovery agent - can we find out if there is any recovery agent created for my profile and then again - where to look for the keys.

6) Where to look for the system information - computer name, adminstrator , user name, display name - so that I can reload windws onto another HDD with same settings.

This conversation is currently closed to new comments.

Thread display: Collapse - | Expand +

All Comments

Collapse -

Try here..

I hope this helps you.

This is copied from:,289483,sid68_gci1224652,00.html

Recovering encrypted files from an NTFS partition

Expert advice on Windows-based systems and hardware

Data recovery revealed some techniques for recovering data from an NTFS partition. This article builds on that concept by showing how to recover encrypted files from an NTFS partition.

But first you need to understand how the encryption process works. The Encryption File System (EFS) encrypts files on the NTFS file system. The NTFS file system actually contains an encryption attribute that can be set for files and folders. When a file's encryption attribute is enabled, the NTFS file system stores the file as an encrypted cipher.

When a user with permission to access the file opens the file, NTFS performs a decryption transparently in the background. But the file itself is not actually decrypted; that would leave it vulnerable to others while it is being accessed. Instead, the EFS creates a decrypted copy of the file and hands it to the application that opened the file. Any changes made to the decrypted copy of the file are automatically passed on to the encrypted copy. When the user closes the file, all that remains is the encrypted copy.

EFS encryption is based on Public Key Infrastructure (PKI), which itself is based on the concept of key pairs. Each user is given a public key and a private key. A user's public key is available to anyone who asks for it; the private key is accessible only to the user who owns it.

When a user tells Windows he wants to encrypt a file, EFS generates a file encryption key. Windows uses this randomly generated key in conjunction with the Data Extended Standard X (DESX) algorithm to encrypt the file. (3DES encryption became an option in Windows XP SP1). The encrypted file is written to disk.

DESX is a standard algorithm used by anyone who attempts to decrypt the file. The trick is that DESX doesn't work without a file encryption key. Since the file encryption key actually resides on the same system as the encrypted files, this key is vulnerable to compromise. To help protect the file encryption key, EFS encrypts it using the user's public key.

This means that the file is encrypted, but the key to the file is also encrypted using a different key. So two keys are needed to open the file. The first is the private key of the user who encrypted the file. Only the user's private key can decrypt something encrypted using the user's public key. Once the file encryption key has been decrypted, it can be used to decrypt the encrypted file.

To recover encrypted files, you must know who encrypted the file in the first place. Because the encryption process is certificate-based, only a user with the appropriate certificate is allowed to decrypt the file. For example, if someone who is an administrator, but not a designated recovery agent, were to open a file's properties sheet and remove the encryption attribute, he would be unable to actually write that change to disk. Even though the administrator has full rights to the file system, he does not have the necessary certificate in this case, so Windows does not allow him to decrypt the file. In other word, even an administrator can not decrypt the file unless they have a copy of the certificate.

The good news is that it is pretty easy to find out who encrypted a file. Just because a file is encrypted, it doesn't mean that Windows hides the file's existence. You can still see the file's icon, even if you don't have the necessary certificate to decrypt the file.

To see who encrypted a file:

1. Right-click on the file.
2. Select the Properties command from the resulting shortcut menu.
3. When the file's properties sheet appears, click the Advanced button found on the General tab.
4. When you see the Advanced Attributes dialog box, click the Details button.
5. You will now see the Encryption Details dialog box, which lists the users who can transparently access the encrypted file.

The information shown in this dialog box is valuable. If you had a disgruntled employee that encrypted a bunch of files and then quit, you could see what account they used for the encryption and then reset the password on that account, log in and decrypt the files.

The Encryption Details dialog box also lists a recovery agent -- another user who is authorized to decrypt the files. When a user is logged into a computer running Windows 2000 or XP as a domain user, the domain administrator automatically becomes a recovery agent.

This means if the authorized recovery agent were to log into the machine, they could transparently decrypt the files, even if the user who had encrypted the files had lost or destroyed their file encryption key.

Note: It is only the domain's Administrator account that is an authorized recovery agent, not accounts that are members of the Domain Admins group. Likewise, the domain Administrator is only an authorized recovery agent if the user was logged in with a domain account at the time that the files were encrypted.

In Windows 2000, if a user encrypted files while logged in locally to a machine (using a computer account, not a domain account), then the computer administrator was automatically designated as a recovery agent. I have seen Microsoft documentation indicating that machines running XP do not automatically designate a local recovery agent unless those machines were upgraded from Win2k. However, I have not been able to verify this.

Remember: The trick to recovering an encrypted file is that you must have an authorized private key and a file encryption key that was encrypted using the corresponding public key. Without these keys, there is no way to recover encrypted files.

Please post back if you have anymore problems or questions.

Collapse -

Decrypting folders using decipher.exe

by Kryptonytee In reply to Try here..

Decrypting files/folders as you explained will probably not work for me because I encrypted the files when I was logged in as the admin. But the problem lays on the fact that I changed my password in an unusual and improper way. One evening, about a year ago, I had a little too much to drink and when I logged in, my virus scan program notified me that a it had found a trojan and that it had been quarantine. But since is always recommended to run full scan after those findings, I decided to run a virus scan from Safe Mode. When I tried to log back in, my password did not work (I realize now I probably missed a character or two)but I panic and thought that my password had been somehow compromised by a virus. I then turned off the system and tried to log in normally but I still could not log in. I wanted to make sure my files were not gone or I don't know what I thought but I had an admin acct that I had created for a new Intern with admin rights but I password had not been created yet. I access windows through that acct and obviously I could not access my files. Then, desperately trying to access my account I went to USERS and is when I made the mistake of deleting my user name's password and create a new one with the same user name, instead of changing the password, but then again that option was not available after logging into Windows the way I did. With the new password, even as a domain admin I was not able to access my files/folders, I can see the icon and the folder/file names, but will not open, cannot move it, copy it or even delete it. I have files in Word, Adobe, Paperport and other programs, but My Documents folder is encrypted. After realizing there was no compromised password because of a virus, but trying to log in with the wrong one and that I had change my user's name password the wrong way, I thought that if I can remember the correct password and change it I would be able to access my files. I changed it 2 or 3 times to what I thought it was the correct one. I know one of them was the correct one but still I could not open the files. I was recommended to use decipher.exe by my son who studies Network Communications at DeVry, but even through DOS, access to the folders/files is denied. I was under the understanding that DOS overrides Windows, but I guess we are wrong, unless you know something we don,t, or there is another way to decrypt them in Windows.
Thank you
Mario Lopez

Collapse -

System Volume Information folder

by joey3000 In reply to Recovering Encryption Key ...

The SAM, SECURITY, SYSTEM, SOFTWARE, and DEFAULT files in the i386 folder are the registry from when you first installed windows (from the install CD). If system restore has been running, it backs up these files. Go to C:\System Volume Information Folder and there will be a folder named _restore... and inside that are your RP### (restore point) folders, and inside THOSE is a snapshot folder, and inside THAT are your registry backup files named the same as the five files i mentioned earlier that are in the C:\windows\system2\config folder (probably when hooked up as a second hard drive). The files in the snapshot folder will begin with "_REGISTRY_MACHINE_". Grab the ones from a fairly recent restore point so the registry won't be that different from when the registry got corrupted. Rename and copy them to the config folder after backing up the ones already in there, and try to boot off the drive. That usually works for me. Sorry for the run-on paragraph, but i'm in a hurry. Busy day. But I hope that fixes you. You got a better-than-50% chance with that fix, in my experience.

Oh yeah! You won't be able to get into the system volume information folder! Oops. You gotta go to properties for the folder and add yourself and give yourself full control while logged in as a local admin. If you don't see a security tab in the folder properties, turn off simple file sharing. I'll let you look that one up. :)

Related Discussions

Related Forums