Windows 10: How to open EFS encrypted files on an HDD that came from Windows XP?

I had my old Windows XP machine die. I am now setting up a new desktop that came with Windows 10 Pro. The old system had 2 hard drives: c: - system and d: - data. The main hard drive unexpected died, so I didn't have time to prepare for a migration.

When I plug in the data HDD into my new Win10 machine, it can't open some files that were originally encrypted with NTFS own EFS (Encrypting File System) encryption. If you remember on XP it would show those files with green:





So my question is how to decrypt or open those files on my new Windows 10 machine?

:)

 

Can I recover encrypted files with EFS without having key.pfx file ?

There is no solution available without the encryption key.

Might you be able to run
Recuva or similar on the old drive to undelete the old key [there is some information about its location in

http://www.tomshardware.co.uk/forum/278973-45-decryption-encrypted-file]? If you can get at the old key then the procedure used here should be able to help you -

How to open EFS encrypted files on an HDD that came from Windows XP

Without the key you are not going to recover those files. EFS is too good for that.

Denis

 

encryption file system in windows 10 pro

New question, same topic. I have 2 windows 10 machines, equivalent accounts on both, and file sharing works fine. EXCEPT when I copy an EFS file from one machine to another, windows decrypts the copy. How do I copy an EFS file and retain the encryption (note:
I already imported the keys just fine and can open the EFS file over the network)? I get no error messages at all. The copy is fast, but decrypted.

NEW OBSERVATION: When I push the file, the copy stays encrypted. It's when I pull that the copy is unencrypted. Is this by-design behavior?

 

From Recover Encrypted Files From An Old Hard Drive | PCWorld

Read the whole page, doesn't look promising.
More pages found:
open EFS encrypted files from another computer at DuckDuckGo

 

EFS encrypted files are accessible only by the account that encrypted them or the designated recovery agent, usually the system Administrator account. Neither of those exist anymore and neither can be recreated. Even an account with the same name and password on the same computer would be a completely different account with no access to the files.

There are 2 accepted methods of recovering files in such a case but both require precautions while the previous OS was running.
1. Export the encryption certificate from the previous OS and import it into the current OS.
2. Recover the files from your backups. All files of any importance should have at least one backup copy, 2 or more backup copies if the files are of particular importance. Encrypted files are no exception, you just need to take precautions with the backup media.

I will not talk about any other methods, if such exist.

 

Appreciate it, guys.

Thanks to this post I was able to retrieve the certificate file from the old XP hard drive from this location w/o access to the OS itself:

Code: "C:\Documents and Settings\<username>\Application Data\Microsoft\SystemCertificates\My\Certificates"[/quote]



I then went to certmgr.msc and imported it into Certificates - Current User > Personal > Certificates.

But when I try to open encrypted files it still gives me access denied error, and when I try to check EFS properties it gives me this message and no way to select any certificates from the list like it says:





Any idea what am I doing wrong here?

 

OK. I got it. I'm posting a solution here in case someone else gets into the same situation.

The easiest solution was, of course, to export the EFS certificate from the source system if you have any EFS encrypted files. (Make sure to include the private key when exporting though.) And then save that exported certificate file in some safe location (not on the same computer, obviously.)

But, like in my case, if system dies so that the old OS is unbootable, here's the steps to perform (look for accepted answer.) For consistency, I'll copy it below. I'll add also that I would do this in a virtual machine, if you have access to a Virtual Box or VMWare Workstation, as the following steps can seriously mess up your working system by changing the machine SID!!!

--------------------------------------------------------------

access and backup following folders from the old HDD:

c:\documents and settings\{username}\application data\microsoft\crypto\
c:\documents and settings\{username}\application data\microsoft\protect\
c:\documents and settings\{username}\application data\microsoft\systemcertificates\

then i found this article with detailed instructions that helped me to decript my files: http://www.beginningtoseethelight.org/efsrecovery/
the article is quite comprehensive, i will try to summarize the basics steps you need to do:

1) get copy of the above 3 directories from the old machine
2) identify SID of your old machine and user:
Quote from original article:
"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 (user-id): 1003"
3) download NewSID (NewSID - Download - CHIP), download from microsoft is no longer available *Sad -- I'll also attach that file to this post, so you can download NewSID itself from here & don't have to deal with their installer.
4) run NewSID and set your machine SID to the old one, reboot
5) Make sure that your user-id, name and password are identical to the old one
Quote from original article:
"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 to 6) otherwise see article
6) copy above 3 folders into your current profile, overwrite everything
7) reboot
8) now you should be able to access encrypted files.

--------------------------------------------------------------

That post refers to this fuller description with more technical steps.

In my case after running NewSID to set the machine's SID, I had to adjust its RID (or last number.) For instance, my needed full SID was S-1-5-21-1078081533-1606980848-854245398-1003 but after I changed the machine SID and created new user account its SID became S-1-5-21-1078081533-1606980848-854245398-1007 which was not OK, as the RID was 1007 and not 1003. So I followed steps from the full description to tweak the next RID of a user account before creating it. I'll copy it here as well:

--------------------------------------------------------------

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.

--------------------------------------------------------------

After I did that and created a new test user account with the same name & password and account type as my original account, I also made sure that its SID & RID matched, by running this from command line:

Code: wmic useraccount get name,sid[/quote] That showed that I had the correct SID.

After that I was able to run certmgr.msc and export the private key from Certificates - Current User > Personal > Certificates > username and then imported it into a new computer.

Then I was able to copy files and un-encrypt them! Wow! I wish Windows XP showed some warning to backup the cert before using that EFS encryption!