LinuxQuestions.org
Download your favorite Linux distribution at LQ ISO.
Go Back   LinuxQuestions.org > Forums > Linux Forums > Linux - Hardware
User Name
Password
Linux - Hardware This forum is for Hardware issues.
Having trouble installing a piece of hardware? Want to know if that peripheral is compatible with Linux?

Notices


Reply
  Search this Thread
Old 06-09-2017, 09:07 PM   #1
aantoonio
LQ Newbie
 
Registered: Jun 2017
Location: Belgium
Distribution: Navigatrix
Posts: 8

Rep: Reputation: Disabled
dd-ed to wrong (luks)disk


It had to happen eventually.

I dd-ed a iso to the wrong hdd.

Code:
dd if=kali-linux-2017.1-i386.iso of=/dev/sdb bs=512k
I realized my mistake after 10 seconds and hit ctrl-c to break it off but I was to late. It was a 8TB external luks-encrypted disk with one partition. At that time the 8TB disk was mounted and browsed true the files and all seems fine and i continued working on it. Until the next startup.

fdisk -l
Code:
Disk /dev/sdb: 8001.6 GB, 8001563221504 bytes
255 heads, 63 sectors/track, 972801 cylinders, total 15628053167 sectors
Units = sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 4096 bytes
I/O size (minimum/optimal): 4096 bytes / 33553920 bytes
Disk identifier: 0x62e9cf84

   Device Boot      Start         End      Blocks   Id  System
/dev/sdb1   *          64     5172287     2586112   17  Hidden HPFS/NTFS
/dev/sdb2         5172288     5173695         704    1  FAT12
fdisk -l /dev/sdb1
Code:
Disk /dev/sdb1: 2648 MB, 2648178688 bytes
255 heads, 63 sectors/track, 321 cylinders, total 5172224 sectors
Units = sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 4096 bytes
I/O size (minimum/optimal): 4096 bytes / 33553920 bytes
Disk identifier: 0x20202020
Disk /dev/sdb1 doesn't contain a valid partition table
fdisk -l /dev/sdb2
Code:
Disk /dev/sdb2: 0 MB, 720896 bytes
255 heads, 63 sectors/track, 0 cylinders, total 1408 sectors
Units = sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 4096 bytes
I/O size (minimum/optimal): 4096 bytes / 33553920 bytes
Disk identifier: 0xabaf19a0
Disk /dev/sdb2 doesn't contain a valid partition table
dumpe2fs /dev/sdb
Code:
dumpe2fs 1.42.9 (4-Feb-2014)
dumpe2fs: Bad magic number in super-block while trying to open /dev/sdb
Couldn't find valid filesystem superblock.
dumpe2fs /dev/sdb1
Code:
dumpe2fs 1.42.9 (4-Feb-2014)
dumpe2fs: Bad magic number in super-block while trying to open /dev/sdb1
Couldn't find valid filesystem superblock.
dumpe2fs /dev/sdb2
Code:
dumpe2fs 1.42.9 (4-Feb-2014)
dumpe2fs: Bad magic number in super-block while trying to open /dev/sdb2
Couldn't find valid filesystem superblock.
Info from gparted
Code:
partition       File system   Label             Size      Used    Unused       Flags
/dev/sdb1       unknown       Kali Live      2.47GiB      ---        ---     boot, hidden
/dev/sdb2       unknown                     704.00KiB     ---        ---
unallocated     unallocated                   7.27TiB     ---       ---
If I could only go back in time to yesterday while it was still mounted and accessible I could have backed up the most important files....aaah. I had about half a dozen disks and i bought that 8TB disk to back up all the others who were not encrypted to encrypt them and put the data back. So I had all these little disks encrypted when the dd-disaster happened. Everything I have on data is on that 8TB disk. Loosing that is a atomic disaster.

As a complete noob in disk-recovery it seems only the first 2GB are effected. Is that where the headers are? Do I need to buy a new $280,00 8TB disk before trying to recover anything? I there any hope of recovering something?

TIA
Anton
 
Old 06-10-2017, 02:59 PM   #2
rknichols
Senior Member
 
Registered: Aug 2009
Distribution: CentOS
Posts: 4,535

Rep: Reputation: 2077Reputation: 2077Reputation: 2077Reputation: 2077Reputation: 2077Reputation: 2077Reputation: 2077Reputation: 2077Reputation: 2077Reputation: 2077Reputation: 2077
Quote:
Originally Posted by aantoonio View Post
As a complete noob in disk-recovery it seems only the first 2GB are effected. Is that where the headers are? Do I need to buy a new $280,00 8TB disk before trying to recover anything? I there any hope of recovering something?
Don't bother even trying. The LUKS header is in the first 2 to 4 MB of its partition. Once that has been overwritten and the LUKS volume is no longer open, there is no way whatsoever of recovering the master key that actually encrypts the data. Had you not rebooted, there would have been a way to extract that master key from the running kernel, but that opportunity is gone, and without a backup of that LUKS header there is now no way to recover anything from that 8TB disk.
 
Old 06-10-2017, 07:45 PM   #3
syg00
LQ Veteran
 
Registered: Aug 2003
Location: Australia
Distribution: Lots ...
Posts: 19,580

Rep: Reputation: 3504Reputation: 3504Reputation: 3504Reputation: 3504Reputation: 3504Reputation: 3504Reputation: 3504Reputation: 3504Reputation: 3504Reputation: 3504Reputation: 3504
I think you should consider that a definitive answer - rknichols has a good history of knowledge of this field.
Do you still have your old disks ? - you may be able to recover from those, even if somewhat out of date.
 
Old 06-10-2017, 10:05 PM   #4
aantoonio
LQ Newbie
 
Registered: Jun 2017
Location: Belgium
Distribution: Navigatrix
Posts: 8

Original Poster
Rep: Reputation: Disabled
Yes I still have them.

Quote:
Don't bother even trying
Well that saves me $280,00 Thanks for answering.

Quote:
Do you still have your old disks ?
No, well .......yes, I still have them The whole point on buying that 8TB disk was (because they were not encrypted) to encrypt them and then put the data back but before I could do that the dd-disaster happened. Is it possible to remove the luks encryption from them and put the old partition back? I can’t remember with one was fat16, fat32, ext3 or ext4 partitioned. Can I try them all out without danger. Well I mean all is lost anyway so i can only gain from it? But is it possible and what course should I sail doing that?

You know it is all the fault of our stupid government, now we even have to buy a chip-reader for our id-card to go online for registering a phone-simcard. Nothing is private anymore. Osama bin laden is laughing in his grave!! And don’t even want to start about USA, NSA and globe-destroyer Trump. Sorry for my ranting. I don’t want to use Tails and encryption I just want to be left alone without the feeling someone is looking over my shoulder. Here in Belgium all your private data is connected to our personal tax-number even medical information.

And thank u for taking the time to help me.

Anton
 
Old 06-10-2017, 11:09 PM   #5
rknichols
Senior Member
 
Registered: Aug 2009
Distribution: CentOS
Posts: 4,535

Rep: Reputation: 2077Reputation: 2077Reputation: 2077Reputation: 2077Reputation: 2077Reputation: 2077Reputation: 2077Reputation: 2077Reputation: 2077Reputation: 2077Reputation: 2077
Quote:
Originally Posted by aantoonio View Post
The whole point on buying that 8TB disk was (because they were not encrypted) to encrypt them and then put the data back but before I could do that the dd-disaster happened. Is it possible to remove the luks encryption from them and put the old partition back? I can’t remember with one was fat16, fat32, ext3 or ext4 partitioned.
Exactly what have you done on those old drives? If all you've done is a luksFormat operation (without the often recommended filling the drive with random data first), then almost all of the old content should be recoverable. One good thing is that you've now got a nice 8TB drive on which to save images of those old drives so that you can work on them safely.

The testdisk utility can be your friend here. It can identify the remains of many filesystems. But first, what is the state of those drives now? The output from "lsblk -f" (wrap it in [CODE] ... [/CODE] tags, please, to preserve formatting) might be the best way to show that.
 
Old 06-11-2017, 02:22 AM   #6
aantoonio
LQ Newbie
 
Registered: Jun 2017
Location: Belgium
Distribution: Navigatrix
Posts: 8

Original Poster
Rep: Reputation: Disabled
I used the “disk utility” from Navigatrix (based on ubuntu 14.04) I’m pretty sure it did not fill the disks with random data.
In what format should I partition the 8TB disk?

The output from “lsblk -f” (wrap it in [CODE] ... tags, please, to preserve formatting) might be the best way to show that.

I don’t understand what you mean by this. What exactly do you want me to wrap in code tags? The output of lsblk -f (perhaps lsblk -f /dev/***) but how would that preserve formatting?
 
Old 06-11-2017, 02:51 AM   #7
pan64
LQ Guru
 
Registered: Mar 2012
Location: Hungary
Distribution: debian/ubuntu/suse ...
Posts: 16,232

Rep: Reputation: 5450Reputation: 5450Reputation: 5450Reputation: 5450Reputation: 5450Reputation: 5450Reputation: 5450Reputation: 5450Reputation: 5450Reputation: 5450Reputation: 5450
the wrapping means what did you do in your original post, I think.
The partition depends on you, you need to know how do you want to use that.
 
Old 06-11-2017, 10:31 AM   #8
rknichols
Senior Member
 
Registered: Aug 2009
Distribution: CentOS
Posts: 4,535

Rep: Reputation: 2077Reputation: 2077Reputation: 2077Reputation: 2077Reputation: 2077Reputation: 2077Reputation: 2077Reputation: 2077Reputation: 2077Reputation: 2077Reputation: 2077
Quote:
Originally Posted by aantoonio View Post
I used the “disk utility” from Navigatrix (based on ubuntu 14.04) I’m pretty sure it did not fill the disks with random data.
Just saying that you used some tool without saying what you did with it is not telling me very much. I can't download Navigatrix without registering, so I can't tell just what that distro is calling "disk utility". However, if you formatted a partition with a selection like "Encrypted + ext4", that would be very bad. Writing the initial metadata for an ext4 filesystem would seriously mutilate whatever had been on the disk before.
 
Old 06-11-2017, 03:18 PM   #9
aantoonio
LQ Newbie
 
Registered: Jun 2017
Location: Belgium
Distribution: Navigatrix
Posts: 8

Original Poster
Rep: Reputation: Disabled
Now I come to think of it, I think I just deleted the files (not shredded) and changed the luks-passphrase on most of them . Maybe there is one where I deleted the partitions and made it one luks partition. I can't remember using "gnome-disk-utility 3.10.0-1ubuntu3" or "GParted 0.18.0" for deleting the partitions but I do remember to use disk-utility for creating luks and changing passphrase. Don't know if it matters but my system is 32bit.
But before we go any further I would like to setup this 8TB disk so I can use that for copying the other disks in to it. I will open a new thread for that for it is only sidelings related and others my benefit from it.

Anton
 
Old 06-11-2017, 06:07 PM   #10
rknichols
Senior Member
 
Registered: Aug 2009
Distribution: CentOS
Posts: 4,535

Rep: Reputation: 2077Reputation: 2077Reputation: 2077Reputation: 2077Reputation: 2077Reputation: 2077Reputation: 2077Reputation: 2077Reputation: 2077Reputation: 2077Reputation: 2077
The only "disk utility"-like tool I find in Ubuntu 14 (and it's got to be the worst "disk utility" tool I've ever encountered) has only one action for setting up an encrypted partition, and that is, "Encrypted, compatible with Linux systems (LUKS + Ext4)". That does, in addition to setting up the encryption, format an ext4 filesystem in the container. Writing the blocks of ext4 metadata that are at the start of each block group in the filesystem is like firing a shotgun loaded with small birdshot at the data that was previously there. If you did that in addition to deleting the files, I don't hold out much hope for recovery. Merely using that tool to change a passphrase would not cause that problem, but back in post #4 you said:
Quote:
The whole point on buying that 8TB disk was (because they were not encrypted) to encrypt them and then put the data back ...
Again, if you would post the output from "lsblk -f" (it needs to be run as "root"), it would at least allow me to see what you have now. I think the best bet right now would be to use hexedit to obscure the LUKS header on any newly-created LUKS partitions (the first 4 bytes are ASCII "LUKS" -- perhaps change that to "SUKS") and then let testdisk see what remains of filesystems it can find on the drives. There's no point in doing that on partitions (if any) that really were previously encrypted.
 
Old 06-12-2017, 12:00 AM   #11
aantoonio
LQ Newbie
 
Registered: Jun 2017
Location: Belgium
Distribution: Navigatrix
Posts: 8

Original Poster
Rep: Reputation: Disabled
lsblk -f
Code:
sdb                                                             
└─luks-50bba0ea-aef8-4b41-9d71-d3e8474868a0 (dm-2)              /media/anton/New Volume
sr0
cryptsetup luksDump /dev/sdb
Code:
LUKS header information for /dev/sdb

Version:       	1
Cipher name:   	aes
Cipher mode:   	cbc-essiv:sha256
Hash spec:     	sha1
Payload offset:	4096
MK bits:       	256
MK digest:     	31 38 ea 21 18 80 73 c9 39 e5 40 a5 4a 23 41 44 08 45 73 5a 
MK salt:       	b7 bc 35 79 a6 74 11 4a 54 4d 8d 66 ef 64 69 dc 
               	ee d2 4a 9a 35 6b 0a 7c 35 a3 e1 cd 58 6b 64 d4 
MK iterations: 	28375
UUID:          	50bba0ea-aef8-4b41-9d71-d3e8474868a0

Key Slot 0: ENABLED
	Iterations:         	113648
	Salt:               	cc 9d 34 86 d2 9f b3 0a c4 4c 1b 0d 51 15 66 50 
	                      	af cc 5e 11 8b 88 1a fb ad 99 27 fb 6e a2 87 a7 
	Key material offset:	8
	AF stripes:            	4000
Key Slot 1: DISABLED
Key Slot 2: DISABLED
Key Slot 3: DISABLED
Key Slot 4: DISABLED
Key Slot 5: DISABLED
Key Slot 6: DISABLED
Key Slot 7: DISABLED
fdisk -l /dev/sdb
Code:
Disk /dev/sdb: 160.0 GB, 160041885696 bytes
255 heads, 63 sectors/track, 19457 cylinders, total 312581808 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
Disk identifier: 0x08040000

Disk /dev/sdb doesn't contain a valid partition table
 
Old 06-12-2017, 09:23 AM   #12
rknichols
Senior Member
 
Registered: Aug 2009
Distribution: CentOS
Posts: 4,535

Rep: Reputation: 2077Reputation: 2077Reputation: 2077Reputation: 2077Reputation: 2077Reputation: 2077Reputation: 2077Reputation: 2077Reputation: 2077Reputation: 2077Reputation: 2077
Quote:
Originally Posted by aantoonio View Post
lsblk -f
Code:
sdb                                                             
└─luks-50bba0ea-aef8-4b41-9d71-d3e8474868a0 (dm-2)              /media/anton/New Volume
sr0

fdisk -l /dev/sdb
Code:
Disk /dev/sdb: 160.0 GB, 160041885696 bytes
255 heads, 63 sectors/track, 19457 cylinders, total 312581808 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
Disk identifier: 0x08040000

Disk /dev/sdb doesn't contain a valid partition table
That is showing that you set up encryption on the entire device (/dev/sdb) and not just the partition (/dev/sdb1). Doing that wipes out the primary copy of the GPT partition table. Somehow this is not the same as what you posted in your other thread, where gparted is showing a valid encrypted partition /dev/sdb1 starting at sector 34 on the drive (the normal starting sector for the first partition on a GPT drive).
 
  


Reply


Thread Tools Search this Thread
Search this Thread:

Advanced Search

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is Off
HTML code is Off



Similar Threads
Thread Thread Starter Forum Replies Last Post
LUKS & LVM initialization when things go wrong xenmaster Ubuntu 2 03-22-2015 03:20 PM
Lost LUKS partition and recoverd with Testdisk but with wrong size Alexian Linux - Newbie 11 09-16-2014 05:38 PM
Luks disk encryption balaji2219@gmail.com Linux - Newbie 2 08-06-2014 02:51 PM
LUKS and changed disk orders orasis Slackware 4 07-03-2014 01:11 PM
13 2.6.29.6 cryptsetup luks wrong device name in /dev/mapper/* TheSoftRock Slackware 1 03-04-2010 05:51 PM

LinuxQuestions.org > Forums > Linux Forums > Linux - Hardware

All times are GMT -5. The time now is 03:44 PM.

Main Menu
Advertisement
My LQ
Write for LQ
LinuxQuestions.org is looking for people interested in writing Editorials, Articles, Reviews, and more. If you'd like to contribute content, let us know.
Main Menu
Syndicate
RSS1  Latest Threads
RSS1  LQ News
Twitter: @linuxquestions
Open Source Consulting | Domain Registration