Lost LUKS partition and recoverd with Testdisk but with wrong size
 

Hi there all, I present myself with the usual demand for help... I know it's not that polite, but I'm in pain for what I've done with my SSD that is a terrible mistake.

I start from the beginning. I changed the SSD in my laptop and I tried to mount the old one externally. The old SSD had a LUKS partition where I got some important data (you don't say?!). However I wasn't able to do so, since everytime I plugged the external drive, the popup came up asking for the passphrase, but it wasn't able to mount it.

So I started to search for a correct step-by-step tutorial for mounting it and I found this: https://help.ubuntu.com/community/En...lesystemHowto3. However I executed the wrong command: "sudo mke2fs -j -O dir_index,filetype,sparse_super /dev/mapper/home" that you can find in Encrypted Home.

(In other words I followed the wrong tutorial... yeah don't tell anything, I'm feeling pretty stupid for 2 days.)

The result was something strange, since I still had the LUKS header (everytime I plugged the disk I had to insert the old passphrase), but the shown partition was totally empty.

Then I started to search for recover it and I found Testdisk, and I recover something. I recovered a partition very little, just 2Mb and it's not possible to mount it with cryptsetup, since it gave me the following error: "Requested offset is beyond real size of device".

I dunno if everything is clear, but do you think it's possible to restore my data? If you need more info just tell me (telling me how-to also :) ).

Thanks in advance for any reply.

If you ran the "cryptsetup ... luksFormat ..." command from the tutorial on that partition, then your data is forever gone since the old LUKS header and its master key have been destroyed. If you did not do that, please state exactly which commands you did run, and we'll see if some of your data might be recoverable.

FWIW, testdisk has no way to determine the size of a LUKS container, so it will always report the minimum size (just the LUKS header).

No I didn't ran "cryptsetup luksFormat", I just ran the following commands:

- sudo cryptsetup luksOpen /dev/sdb3 enc
- sudo mke2fs -j -O dir_index,filetype,sparse_super /dev/mapper/enc
- sudo mount -t ext3 /dev/mapper/enc /mnt

= empty parition

then I just used:

- testdisk by using beginner mode I analyzed the disk.

Nothing more nothing less. I did not touched the empty partition by adding files or something else, I just mounted it a couple of times before what I've done with testdisk.

Thanks for the help.

Something is missing. You must have opened a lux partition to get: Then it appears you wrote a new file system, but mke2fs just went ahead and wrote over the volume, without any warning, which it should not do! If the encrypted partition is open--that is, it exists in: then it looks like an unmounted partition.

mkfs is not supposed to silently format partitions that already have a file system! But the lux header might be misinterpreted as the possible beginning of a formatted partition, which it would not appear to be at all to mkfs, so then it might mistakenly format it. I've heard of strange happenings occurring with low-level disk utilities on cryptsetup volumes.

I would try: It doesn't care about partitions or file systems. It just scans the raw disk and carves out the files. But they don't have the same names after recovery. I hope this helps.

Yes I infact did "cryptsetup luksOpen /dev/sdb3 enc" as you can see in the list of my commands, then the "mke2fs" commands followed. Ya I think the last command has formatted the partition and with testdisk I tried to recover it, but as I explained above there's something wrong with the size of partition. Any suggestion about it?

Don't worry about the size. Your LUKS container is fine. The LUKS header does not contain anything that indicates the size of the container, so testdisk always reports the minimum possible size.

When you run testdisk on the whole drive, it cannot look inside the LUKS container. You would need to unlock the LUKS container and run testdisk on the /dev/mapper/enc device, selecting "None" (Non partitioned media) as the partition table type. But I'll tell you right now, all testdisk is going to find there is the empty filesystem that you just created.

You might have some success with photorec, again run on the /dev/mapper/enc device. Recovery depends on file types and degree of fragmentation, but I fear you will mostly end up with a mess -- a lot of partially recovered files and fragments, none with their original names. Reformatting with the same type of filesystem that was there before does the worst sort of damage, since it guarantees that all of the old filesystem's metadata gets overwritten.

I missed a step. Before running testdisk I used Clonezilla to make an image of the whole disk after the "mke2fs" command (for precaution before anything). Is there any chance then to recover my files by using 'dd' on the empty partition after restoring the disk image? I ask before to do anything with photorec.

The damage was done by mke2fs, and you haven't done anything to that partition other than mounting it and seeing that the filesystem was empty, so I don't see any reason that photorec (or any other recovery software) would see any difference between the current contents and the cloned copy. BTW, photorec does not write to the volume it is trying to recover.

Well I'm trying to recover the files with photorec, but it will take a lot of time (it gave me 40h to complete). There's no way to instruct it of the right folder to recover? Maybe with scalpel?

There is no direct correspondence between directories ("folders") and regions on the disk. The directory structure got pretty much wiped out by the "mke2fs". The most that could be recovered of the directory structure would be along the lines of, "This looks like it once was a directory block containing this list of names {BookImWriting.odt, McDougalContract.pdf, MapToBuriedTreasure,jpg, MyPhotoCollection, ...}," but with no useful indication of where those items might be stored on the disk. Perhaps that would be of interest to a forensic analyst looking for evidence that you one had insider information about the McDougal enterprise, but not of much use otherwise.

OK thanks, I just thought it was a trivial and idiot question, but I wanted to give a try...

So far I was able to restore some files, but most of them have the extension eCryptFS, what is it? Still encrypted files? There's any chance to decrypting them (I know the passphrase)?

Did you run photorec on the decrypted device, /dev/mapper/enc, as I instructed, or did you mistakenly run it on the encrypted /dev/sdb3? If the latter, I would be surprised that photorec recovered anything at all, and in any event you won't get anything useful.

You didn't actually have any eCryptFS files or directories inside that /dev/sdb3 encrypted container, did you? If not, then what you are seeing are old, long deleted files (or fragments thereof) from a time when you were using eCryptFS on that device. According to the manpage, eCryptFS stores all the needed metadata in each file's header, do decryption with the passphrase should work.