Large file recovery (eCryptfs) using PhotoRec

[whr92]

Hey there,

I'm using the latest (beta-) version of PhotoRec (7.3-WIP) trying to recover a couple of .vdi (VirtualBox) files [25, 50 and >100GB large in size] that I literally JUST deleted by accidentally running rm -rf in the wrong directory.

PhotoRec is indeed able to recover thousand of files, but none of them are any bigger then a couple of MegaBytes.

Sometimes PhotoRec is writing a large file (>50 or even 100GB in size) that then collapses into small (final) .eCryptfs file. I guess that's related to the fact that PhotoRec is trying to recover fragmented files and may continue writing data until it encounters another file header or reaches what it believes to be the end of the file.

Any tips/tricks (maybe even another software/tool) regarding how to recover such large files? I just need those .vdi files back and in general they should be easy to recover as they are really large in size, but I understand that fragmentation and eCryptfs makes the progress much much harder (if not even impossible .

System Info: Ubuntu 24.04, LVM2/LUKS/eCryptfs Setup. Ext4, obviously. The system is running on a M.2 NVMe SSD, the drive has no errors. (File recovery is not possible on a NVMe? So far PhotoRec found 12236 .eCryptfs files.) I do understand eCryptfs and I'm able to decrypt all of the ones found. They are all intact.

PS: I've already tried to recover them using UFS Explorer Professional Recovery, but PhotoRec seems to be more successful finding files. Maybe I am doing something wrong here and anybody has any tips regarding UFS in such a case?

PS 2: I have not touched/written any new data ever since I was running rm -rf. I have also created an image.dd of the currently (still up and running) decrypted /dev/mapper/xxx_crypt partition (that I then used with UFS Explorer Professional Recovery).

PS 3: I've tried several approaches, e.g. I've only selected .eCryptfs files for PhotoRec to search/recover for. Before that I selected to search/recover all filetypes. I've always set the Offset to 0 and I have tried it with [ext2/ext3/ext4] as well as with [Other] FAT/NTFS/HFS+ selected as the filesystem. After several trials, I've also tested with Paranoid Yes (Brute force enabled), Keep corrupted files: Yes and Expert mode set to Yes. So far PhotoRec recovers only small files. ext4magic found only 200 and extundelete failed miserably.

I want to thank Christophe Grenier and the entire community for everything they have created! Thank You!

I'm very grateful for any answers (however if you answer e.g. that it is not possible to recover those files please be sure that that's a fact; because I will give up then).

[recuperation]

Hey there,

I'm using the latest (beta-) version of PhotoRec (7.3-WIP) trying to recover a couple of .vdi (VirtualBox) files [25, 50 and >100GB large in size] that I literally JUST deleted by accidentally running rm -rf in the wrong directory.

PhotoRec is indeed able to recover thousand of files, but none of them are any bigger then a couple of MegaBytes.

Sometimes PhotoRec is writing a large file (>50 or even 100GB in size) that then collapses into small (final) .eCryptfs file. I guess that's related to the fact that PhotoRec is trying to recover fragmented files and may continue writing data until it encounters another file header or reaches what it believes to be the end of the file.

Any tips/tricks (maybe even another software/tool) regarding how to recover such large files? I just need those .vdi files back and in general they should be easy to recover as they are really large in size, but I understand that fragmentation and eCryptfs makes the progress much much harder (if not even impossible .

This is what I fear as well. If you had not used ecryptfs your content would have been sufficiently protected by LUKS. As far as I know, LUKS simulates an unencrypted device that you could have read out completely.

System Info: Ubuntu 24.04, LVM2/LUKS/eCryptfs Setup. Ext4, obviously. The system is running on a M.2 NVMe SSD, the drive has no errors. (File recovery is not possible on a NVMe? So far PhotoRec found 12236 .eCryptfs files.)

First I was wondering, but obviously there is no TRIM pass through on your nested higher levels!

I do understand eCryptfs and I'm able to decrypt all of the ones found. They are all intact.

PS: I've already tried to recover them using UFS Explorer Professional Recovery, but PhotoRec seems to be more successful finding files.

You should consider the possibility that PhotoRec is the better carver but I cannot guarantee that for you. On the other hand, as opposed to PhotoRec, UFS Explorer probably evaluates remains of meta data. So the result may be case dependant.

Maybe I am doing something wrong here and anybody has any tips regarding UFS in such a case?

PS 2: I have not touched/written any new data ever since I was running rm -rf. I have also created an image.dd of the currently (still up and running) decrypted /dev/mapper/xxx_crypt partition (that I then used with UFS Explorer Professional Recovery).

PhotoRec operates on a device or a partition. Ecryptfs is a file oriented encryption tool. On the other hand your "/dev/mapper/xxx_crypt partition" is a virtual partition structure by which you seem to access your encrypted files. That virtual partition is not a real partition, it appears to me just as a partition that let's you access bunch of encrypted files. That does not seem to be a representation of a virtual partition, that you can look at sector-wise.

PS 3: I've tried several approaches, e.g. I've only selected .eCryptfs files for PhotoRec to search/recover for. Before that I selected to search/recover all filetypes. I've always set the Offset to 0 and I have tried it with [ext2/ext3/ext4] as well as with [Other] FAT/NTFS/HFS+ selected as the filesystem. After several trials, I've also tested with Paranoid Yes (Brute force enabled), Keep corrupted files: Yes and Expert mode set to Yes. So far PhotoRec recovers only small files. ext4magic found only 200 and extundelete failed miserably.

I want to thank Christophe Grenier and the entire community for everything they have created! Thank You!

I'm very grateful for any answers (however if you answer e.g. that it is not possible to recover those files please be sure that that's a fact; because I will give up then).

Your case is interesting because it involves 3 levels of abstraction, 1x LVM and 2x encryption.
Please report how you are doing - what you will do and what the outcome is. Even a failure report is totally OK (not for you, I know).

Good luck!

[whr92]

Dear recuperation, thank you for your immediate answer. I do see you are very active here and there is nothing more disappointing then getting no answer whatsoever. Thank you for your warm welcome into this forum. I will try to be more active here. I did read a lot of posts/answers from you in here. Loosing data is indeed a real emotional challenge for the most of us - and most of the (new) users here might be techies, but being a techie is (in most of the cases) not enough to actually understand data recovery. It's a quite complex sphere (that takes a lot of time getting into, #not everybody has even the time to go through the testdisk/PhotoRec manual and I can totally understand that). Especially once there are emotions involved, it can be a real pain in the a**. My unquestioned yet good-hearted advise: Consider, Think over and Be kind to all those humans trying to recover their data. This forum might be their last hope...

With that being said, please overlook my detailed response. I give more details in the hope some other (new) users might find it helpful:

______________________

If you had not used ecryptfs your content would have been sufficiently protected by LUKS.

When a user chooses LVM with full disk encryption during a Linux distribution installation, the system sets up a layered structure for disk management and encryption with 3 partitions in place:

/dev/nvmeXn1
mounted at /boot/efi
This is the EFI System Partition (ESP) required for UEFI boot. It's not encrypted and is typically formatted as FAT32.

/dev/nvmeXn2
mounted at /boot/
This is the /boot partition, which contains the kernel and initial ramdisk. It's often left unencrypted to allow the system to boot.

/dev/nvmeXn3
This is the "main disk" that has been encrypted using LUKS (Linux Unified Key Setup).
It's not directly mounted because it needs to be decrypted first.

Marginal note: In Linux, NVMe drives are typically named as /dev/nvmeXnY, where X is the drive number and Y is the partition number.

As far as I know, LUKS simulates an unencrypted device that you could have read out completely.

Once a user enters the correct LUKS password during the system boot, LVM (Logical Volume Management - a storage management technology that provides a layer of abstraction between physical storage devices and the file system) then "creates" a virtual partition (/dev/mapper/nvmeXn3_crypt) which is the decrypted version of the /dev/nvmeXn3 partition (that has been initialized as a physical volume for use with LVM).

eCryptfs itself is just a kernel module, which means it operates at the filesystem level and unlike any full-disk encryption solutions, eCryptfs de/en-crypts individual files. In most cases a users /home directory.

Marginal note: eCryptfs is quite outdated, yet still being offered by Ubuntu and other Linux distributions as a home directory encryption method to be used on top of [or] instead of dm-crypt/LUKS.

______________________

• So yes, I am able to read out the entire device. eCryptfs does not interfere here. The image.dd I took from /dev/mapper/nvmeXn3_crypt (using testdisk) is completely decrypted/readable. So is the /home dir (even tho eCryptfs is not decrypted yet within the image itself, but this can be easily done once mounted somewhere).
  
  Since I run rm -rf in my "VirtualBox" directory (which is part of my /home directory that is getting de/en-crypted by eCryptfs in real-time), those deleted files should indeed be detectable as .eCryptfs files by PhotoRec.

My questions:

• Sometimes PhotoRec is writing a large file (>50 or even 100GB in size) that then collapses into small (final) .eCryptfs file.

  1. Is this normal, what is going on here? Is this PhotoRec actually hitting on an .eCryptfs file that might be a (once decrypted) .vdi (VirtualBox) file but then PhotoRec keeps going on and the file collapses? Anybody with a hint?

• I'm trying to recover a couple of .vdi (VirtualBox) files [25, 50 and >100GB large in size] that I literally JUST delete

  2. Is this even possible (taking fragmentation and eCryptfs into account)?

• I've tried several approaches (...)

  3. Can I shutdown my PC (since I have already taken an image.dd of /dev/mapper/nvmeXn3_crypt) or should I better keep it running for now? In other words: Do I have any advantage keeping my (LUKS & eCryptfs decrypted) PC running for now?

Any advise is more then appreciated.

[recuperation]

As far as my Linux knowledge goes, you missed out the LVM layer in your description which I would expect on top of the encryption layer.

• So yes, I am able to read out the entire device. eCryptfs does not interfere here. The image.dd I took from /dev/mapper/nvmeXn3_crypt (using testdisk) is completely decrypted/readable. So is the /home dir (even tho eCryptfs is not decrypted yet within the image itself, but this can be easily done once mounted somewhere).
  
  Since I run rm -rf in my "VirtualBox" directory (which is part of my /home directory that is getting de/en-crypted by eCryptfs in real-time), those deleted files should indeed be detectable as .eCryptfs files by PhotoRec.

My questions:

• Sometimes PhotoRec is writing a large file (>50 or even 100GB in size) that then collapses into small (final) .eCryptfs file.

  1. Is this normal, what is going on here? Is this PhotoRec actually hitting on an .eCryptfs file that might be a (once decrypted) .vdi (VirtualBox) file but then PhotoRec keeps going on and the file collapses? Anybody with a hint?

I have no idea.

• I'm trying to recover a couple of .vdi (VirtualBox) files [25, 50 and >100GB large in size] that I literally JUST delete

  2. Is this even possible (taking fragmentation and eCryptfs into account)?

It is possible but less probable. It depends on the file system as well. If you had FAT32 you would have a big consecutive area on a freshly formated partition where such a large file could fit in without interruptions. In ext4 there is a series of superblocks which would prevent a continuous storage of large files. Other factors diminishing your success would possible be dynamic growth of your vdi-files leading to defragmentation. If your file system is already in use and the operating system has to split your vdi-files to fit into existing smaller areas of free space you are facing the same problem of fragmented storage.

• I've tried several approaches (...)

  3. Can I shutdown my PC (since I have already taken an image.dd of /dev/mapper/nvmeXn3_crypt) or should I better keep it running for now? In other words: Do I have any advantage keeping my (LUKS & eCryptfs decrypted) PC running for now?

You said:

"creates" a virtual partition (/dev/mapper/nvmeXn3_crypt) which is the decrypted version of the /dev/nvmeXn3 partition

I can't answer this question because I don't understand how a bunch of encrypted files suddenly form a partition. A partition contains more space than a bunch of files. Where does this space come from?

Furthermore, your encrypted files are stored in an encrypted state. If you delete such an encrypted file it should reside where all the other encrypted files are. As it is deleted, your virtual ecrypt translation device won't show it as it is deleted.

PhotoRec operates on disks, partitions and devices.
Disks are physical disks, partitions are parts of a disk and a device is everything that PhotoRec lists in the device list. This could be p.e. a RAID disk device which is a logical construct that is backed by two or more other devices, typically physical disks.

[recuperation]

After doing some research I found that ext4magic claims to recover deleted ext4 files. It evaluates the journal. A detailed recipe can be found in the German journal "c't", issue 10/2023.

You need to buy that issue of the journal to be able to read the article, maybe you can buy only the article but that won't make a big difference.

https://www.heise.de/select/ct/2023/10 on page 164.

[recuperation]

With regards to the recommended computer journal:

The Heise edition is located in Hannover, Germany, where I reside. I am not affiliated with the journal, but I have subscribed to that journal from 2000 or 2001 until today.
These are the folks that uncovered the "RAMDOUBLER" spam. This is the journal where I first learnt about a software called TestDisk, a software package where a part runs from a command prompt instead of a GUI.

This journal provided and still provides a wealth about storage devices, interfaces, logical structures such as partition tables and file systems and storage related software.
These matters, however, were only a part of their whole content that they delivered.

One of their former editors (Harald Bögeholz) programmed the storage test software h2testw which was a model for the later appearing linux program f3 (fight flash fraud).

I owe a lot of knowledge I acquired to this journal. In this case I felt that I had read an article in c't about that matter. The one I was thinking about, though, is much older than the article I found.