[SOLVED] Make testdisk read an encrypted home folder

anon091 · 09-18-2019, 07:47 PM

Trying to use testdisk to hopefully recover a stupid delete. Going into the encrypted home folder though, it doesn't show the contents but just a few random things.
I'm sure I'm doing something wrong, just not sure what

Firerat · 09-18-2019, 09:03 PM

well, if the home is encrypted testdisk is only going to see 'random' things

In all honesty I have never played with encrypted filesystems, so I don't know if this will work.

I assume you are currently working with unmounted filesystems

if /home is a partition which is encrypted
take note of

Code:

ls /dev/mapper/

can you decrypt/mount home read only?
If you can you should see new things in /dev/mapper

what you then need to do is run testdisk/photorec on the decrypted blockdevice that appeared. Since it is decrypted testdisk/photorec should be able to see things clearly and be able to recover the deleted file{s}

I am assuming the encryption is on the filesystem and not per file. I imagine per-file would be a whole lot more complicated.

if you can't mount read only
do not login with anything that will write to /home
and make sure you save the deleted files to somewhere that is *not* in /home

syg00 · 09-19-2019, 01:06 AM

For some-one who has been a member that long the question is appallingly short on necessary detail.
What type of encryption - you list RHEL/CentOS, but that sounds like eCryptfs as used on Ubuntu and derivatives. Not LUKS as would be the expected norm for RH.
Be (much) more specific and you might get better replies.

anon091 · 09-19-2019, 07:20 AM

Sorry to offend syg, had a few brief moments of great signal on a train so fired it off when I could, plus didn't have the machine near me. But you were able to correctly surmise it is indeed eCryptfs I'm talking about. I believe the only two files it showed were a read me then one other file that made it sound like it might unencrypt the directory for you. Sorry, still don't have access to the machine.
And as you probably also correctly surmised, my experience with eCryptfs is zero and testdisk is barely above that

jefro · 09-19-2019, 04:39 PM

If you boot to a live media can you access that folder? I don't mean the contents, I mean does the folder show as available to the native filesystem?

anon091 · 09-19-2019, 05:49 PM

Hi jefro. I did boot off a Linux mint USB and install testdisk there and was and was able to navigate down to the folder itself. Folder itself also accessible just from a simple mount and clicking through

Firerat · 09-19-2019, 06:53 PM

Quote:

Originally Posted by rjo98

Hi jefro. I did boot off a Linux mint USB and install testdisk there and was and was able to navigate down to the folder itself. Folder itself also accessible just from a simple mount and clicking through

I imagine it will be difficult since the deleted file{s} will be just random garbage that testdisk won't be able to parse

or maybe those few random things you found are the files
try recovering those and see if they decrypt

from what I've read ( briefly ) eCryptfs is a filesystem on a filesystem

I guess the folder is like a file that has been treated like a block device and mounted loopback.
so it should end up in /dev/mapper at some point

jefro · 09-19-2019, 07:28 PM

"Folder itself also accessible just from a simple mount and clicking through"

I'm guessing here but when you do mount it and you are able to view the current contents then try photorec maybe?

Based on Firerat's suggestion then I can't say if the mounted virtual filesystem will be available to the recovery program or not. Might peek at mount command to see if that encryption mounts while executing it's task.

anon091 · 09-19-2019, 07:38 PM

Had access to the machine a bit earlier. Even if I boot to the Linux Mint OS itself, which I can see the data through the GUI and CLI for /home/username, but if i run testdisk or photorec, once i get into /home/username through that, i see actually 5 things but three start with dot: .encryptfs, .Private, README.txt, Access-Your-Private-Data.desktop, and .cache

Whereas if I just do a ls /home/username normally, i see all the "real" stuff like all the dot directories, folders like Desktop, Documents, etc.

Almost seems like I need a way to tell testdisk to use the encryption or what the key is for it, so it can read it maybe? or maybe testdisk just doesn't work on encryptfs home folders.

Worst part is, they had no real reason to encrypt their home folder other than they could

anon091 · 09-19-2019, 07:41 PM

firerat, missed a question earlier from you i think. in /dev/mapper via testdisk all i see is control, but i don't see the cryptswap1 that i do from a normal ls of it.

Firerat · 09-19-2019, 08:18 PM

form the eCryptfs manpage

Code:

DESCRIPTION
       eCryptfs  is  a POSIX-compliant enterprise-class stacked cryptographic filesystem for Linux. It is derived from Erez
       Zadok's Cryptfs, implemented through the FiST framework for generating stacked filesystems. eCryptfs extends Cryptfs
       to  provide  advanced  key  management and policy features.  eCryptfs stores cryptographic metadata in the header of
       each file written, so that encrypted files can be copied between hosts; the file will be decryptable with the proper
       key,  and  there  is no need to keep track of any additional information aside from what is already in the encrypted
       file itself. Think of eCryptfs as a sort of "gnupgfs."

from ecryptfs-setup-private manpage

Code:

FILES
       ~/.ecryptfs/auto-mount

       ~/.Private - underlying directory containing encrypted data

       ~/Private - mountpoint containing decrypted data (when mounted)

       ~/.ecryptfs/Private.sig - file containing signature of mountpoint passphrase

       ~/.ecryptfs/Private.mnt - file containing path of the private directory mountpoint

       ~/.ecryptfs/wrapped-passphrase - file containing the mount passphrase, wrapped with the login passphrase

       ~/.ecryptfs/wrapping-independent - this file exists if the wrapping passphrase is independent from login passphrase

so the deleted files *should* be on the "normal" filesystem
photorec lists eCryptfs
https://www.cgsecurity.org/wiki/File...ed_By_PhotoRec

the filenames won't make sense
but they should be under ~/.Private/

it looks like the filename won't matter, as it is all in the metadata

syg00 · 09-19-2019, 08:30 PM

Yes, testdisk would seem the wrong tool. Photorec run on free space within that filesystem might do the job - presuming nothing has been written to it in the interim.

anon091 · 09-20-2019, 07:17 AM

Ah ha. Will try looking in ~/.Private today both with testdesk and photorec, thanks.

Firerat · 09-20-2019, 07:19 AM

Quote:

Originally Posted by rjo98

Ah ha. Will try looking in ~/.Private today both with testdesk and photorec, thanks.

you may need to configure photorec to look for .ecr .ecrfs
( check on the photorec link I gave )

anon091 · 09-20-2019, 07:31 AM

Understood. Have photorec running now with the eCrytpfs option checked (I only saw the one), looks like it's recovering stuff. So now i'll just need to let it run, figure out how to decrypt them, and see if any are what they deleted

thanks for the help!