by abolibibelot » Fri Oct 06, 2017 3:47 pm
Did you enable encryption on the disks the recovered files were saved to? If not, that is why those files appeared. When you copy those files on an NTFS disk with encryption enabled, they'll disappear and the files will become encrypted.
As I said in the first post, “the HDD is not mine so I don't know how it was configured”. The owner is as computer-illiterate as you can imagine, so I don't think that he enabled any kind of encryption himself. (He should have made backups before that, so that he wouldn't need me to save his ass with a little help from ddrescue, R-Studio and a few other brilliant tools ! :^p The HDD was in a really bad condition, clicking and whirring and bleeping every now and then, yet I managed to recover almost 100% of the personal files.) The machine on which that HDD was installed is apparently an integrated PC from Hewlett-Packard (there is a “hp” directory at the root), so maybe it was configured by the manufacturer with EFS encryption enabled. The strange thing in that case is that only some kinds of files have .$efs files associated to them, and I can't identify a specific pattern. Most of them are in the “Windows” directory, but there are also a few in the Program* directories, or even the Users directory ; there are many .dll or .exe files, but not all of them, and there are almost no .jpg files but there are some of them...
I made a list with the command :
Code: Select all
FOR /R %F in (*.$efs) do echo S:%~pF%~nF%~xF >>T:\liste_efs.txt
There are 15947 .$efs files in total in this recovery. The client will still be happy (I guess), anyway the “Windows” directory can later be deleted entirely, as it normally doesn't contain personal files, but I'd like to understand the issue, in case this happens again.
Also, could it be related to the
other issue I asked about yesterday, regarding the “invalid data to decompress” error ? Does that error imply that the affected files were encrypted ? How could I verify this ? I still have the ddrescue image of the original HDD. If for instance I check the “dwusplay.exe” file (see the screenshot in the first post) in R-Studio's data analyzer, it says that it begins at sector 31305504, and then if I open the image file in WinHex and go to sector 31305504 of that partition, it displays the actual content of that file with the correct executable header, and no apparent encryption that should (I think) be apparent when accessing the volume at “low level” like this. (The very same content is displayed in R-Studio's own hexadecimal viewer, by the way, I just wanted to double-check, in case R-Studio would have somehow decrypted the file on the fly.)
[quote]Did you enable encryption on the disks the recovered files were saved to? If not, that is why those files appeared. When you copy those files on an NTFS disk with encryption enabled, they'll disappear and the files will become encrypted.[/quote]
As I said in the first post, “the HDD is not mine so I don't know how it was configured”. The owner is as computer-illiterate as you can imagine, so I don't think that he enabled any kind of encryption himself. (He should have made backups before that, so that he wouldn't need me to save his ass with a little help from ddrescue, R-Studio and a few other brilliant tools ! :^p The HDD was in a really bad condition, clicking and whirring and bleeping every now and then, yet I managed to recover almost 100% of the personal files.) The machine on which that HDD was installed is apparently an integrated PC from Hewlett-Packard (there is a “hp” directory at the root), so maybe it was configured by the manufacturer with EFS encryption enabled. The strange thing in that case is that only some kinds of files have .$efs files associated to them, and I can't identify a specific pattern. Most of them are in the “Windows” directory, but there are also a few in the Program* directories, or even the Users directory ; there are many .dll or .exe files, but not all of them, and there are almost no .jpg files but there are some of them...
I made a list with the command :
[code]FOR /R %F in (*.$efs) do echo S:%~pF%~nF%~xF >>T:\liste_efs.txt[/code]
There are 15947 .$efs files in total in this recovery. The client will still be happy (I guess), anyway the “Windows” directory can later be deleted entirely, as it normally doesn't contain personal files, but I'd like to understand the issue, in case this happens again.
Also, could it be related to the [url=https://forum.r-tt.com/viewtopic.php?f=13&t=9596]other issue[/url] I asked about yesterday, regarding the “invalid data to decompress” error ? Does that error imply that the affected files were encrypted ? How could I verify this ? I still have the ddrescue image of the original HDD. If for instance I check the “dwusplay.exe” file (see the screenshot in the first post) in R-Studio's data analyzer, it says that it begins at sector 31305504, and then if I open the image file in WinHex and go to sector 31305504 of that partition, it displays the actual content of that file with the correct executable header, and no apparent encryption that should (I think) be apparent when accessing the volume at “low level” like this. (The very same content is displayed in R-Studio's own hexadecimal viewer, by the way, I just wanted to double-check, in case R-Studio would have somehow decrypted the file on the fly.)