dd'ed on an external HDD Luks partition, recover possible?

nr765 · 12-19-2015, 07:38 PM

Hello,

So.. I guess it had to happen one day.
I have a 2TB external hard drive with a single encrypted partition (ext4). It's generally on /dev/sdb. I mount it with

Code:

cryptsetup create backup /dev/sdb1

, I input password, this then creates /dev/mapper/backup (and also /dev/dm-0)

At the same I was creating a Pi sd-card (Raspbian, 1.5Go) ... I though it was /dev/dm-0). So I did a

Code:

dd bs=4M if=2015-11-21-raspbian-jessie.img of=/dev/dm-0

So the hdd is now inaccessible, I get the following when trying to mount it

Code:

mount: wrong fs type, bad option, bad superblock on /dev/mapper/backup,
       missing codepage or helper program, or other error

       In some cases useful info is found in syslog - try
       dmesg | tail or so.

fdisk -l /dev/mapper/backup

Code:

Disk /dev/mapper/backup: 2 MiB, 2097152 bytes, 4096 sectors
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disklabel type: dos
Disk identifier: 0x0a60a5a1

fdisk -l /dev/sdb1

Code:

Disk /dev/sdb1: 2 MiB, 2097152 bytes, 4096 sectors
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes

fdisk -l /dev/sdb

Code:

Disk /dev/sdb: 1.8 TiB, 2000365289472 bytes, 3906963456 sectors
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disklabel type: dos
Disk identifier: 0x77e8a5da

Device     Boot Start   End Sectors Size Id Type
/dev/sdb1  *     2048  6143    4096   2M 83 Linux

dumpe2fs /dev/sdb1

Code:

dumpe2fs 1.42.12 (29-Aug-2014)
dumpe2fs: Bad magic number in super-block while trying to open /dev/sdb1
Couldn't find valid filesystem superblock.

photorec and testdisk don't help much since they scan the partition very quickly and don't find anything.

Have the encryption been damaged?
Would there be a way to create a new partition table? since I know what it's supposed to be (single partition ext4)?

Thanks,
Nr

unSpawn · 12-20-2015, 12:19 PM

Quote:

Originally Posted by nr765

Hello,

Welcome to LQ, hope you enjoy it, sad to see it is on such an occasion.

Quote:

Originally Posted by nr765

Have the encryption been damaged?

Yes.

Quote:

Originally Posted by nr765

Would there be a way to create a new partition table?

A partition table is only a static list of addresses, partition boundaries, and changing it doesn't affect the actual contents of the partition. You overwrote the disks partition table and one or more partitions with other data. The original data is lost.

rknichols · 12-20-2015, 02:05 PM

Quote:

Originally Posted by nr765

fdisk -l /dev/sdb

Code:

Disk /dev/sdb: 1.8 TiB, 2000365289472 bytes, 3906963456 sectors
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disklabel type: dos
Disk identifier: 0x77e8a5da

Device     Boot Start   End Sectors Size Id Type
/dev/sdb1  *     2048  6143    4096   2M 83 Linux

That looks like you overwrite the first 3MB (2048+4096 sectors) of sdb. Fortunately you are not using LUKS, so there is no issue with an overwritten LUKS header, which would be unrecoverable. Most of your filesystem should be OK, but you first need to find the correct starting point so that it will decrypt correctly.

If your partition was created with fairly recent tools it probably begins at sector 2048, so I would first try setting up partiton 1 to start at sector 2048 and extend to the end of the disk. Then, unlock the encryption and see if fsck can find a backup superblock in /dev/mapper backup.

Note: I strongly recommend you save a complete image of the disk before you let fsck actually fix anything. It's entirely possible for those "fixes" to make a bad situation unrecoverably worse. (Playing around with the partition table for primary partitions (or GPT partitions, for that matter) is entirely safe.)

syg00 · 12-20-2015, 07:46 PM

The dd was done to /dev/sdb1 (mapped as dm-0), so 2048 certainly looks the correct spot.
Maybe try dumpe2fs with -o rather than fsck to see if there are any valid backup superblocks.

rknichols · 12-20-2015, 09:07 PM

Quote:

Originally Posted by syg00

The dd was done to /dev/sdb1 (mapped as dm-0), so 2048 certainly looks the correct spot.

Something is very strange, then, because that would not have touched the partition table. That would mean that the whole 2 TB disk had just a single 2 MiB encrypted partition on it. That's just not believable. Something else went on beyond what has been reported thus far.

syg00 · 12-20-2015, 09:41 PM

Given that the dm-crypt volume was open and active, maybe dm-crypt recognised a close event when the dd finished and truncated the volume.
Guess-work of course.

rknichols · 12-21-2015, 08:25 AM

dm-crypt does not adjust partition tables and does not even attempt to track the size of the encrypted volume. Attempts to read/write/seek past the end of the underlying volume result in the same I/O error you would get with a non-encrypted volume.

syg00 · 12-21-2015, 11:29 PM

You are correct.
I just tested this scenario. The dd completes fine, even with the dm-crypt volume open. umount/mount shows the iso copied, not the original filesystem. But parted shows the partition as its initial (correct) size as you suggested.
I eventually found a backup superblock I could use, but using it with fsck trashed everything. I <ctrl>-<c>'d it after a while, and the next mount found "too many file systems".
Didn't bother with testdisk as I didn't have much data on the initial filesystem - for me this is broken beyond repair. I would recommend the OP only use something like photorec/testdisk, and not attempt a fsck.

rknichols · 12-22-2015, 09:16 AM

That 2015-11-21-raspbian-jessie.img file is only about 3.9GB, so most of the data on that 2TB drive is intact and probably worth saving. It's still an issue of finding the right starting point for the encrypted volume so that correct sector IVs will be calculated, and just an ordinary recovery issue after that. The root directory is almost certainly trashed, so everything will end up in lost+found after an fsck, but with luck, most of the subdirectories will be intact and still contain original file names.

As I said before, a full backup of the image is strongly recommended before recovery efforts.