LinuxQuestions.org
Help answer threads with 0 replies.
Go Back   LinuxQuestions.org > Forums > Linux Forums > Linux - General
User Name
Password
Linux - General This Linux forum is for general Linux questions and discussion.
If it is Linux Related and doesn't seem to fit in any other forum then this is the place.

Notices

Reply
 
Search this Thread
Old 10-21-2013, 09:49 PM   #1
cavig5
LQ Newbie
 
Registered: Nov 2010
Posts: 6

Rep: Reputation: 0
Is it possible to recover a LUKS partiton after deleting it with gparted


In a late night session I inadvertently deleted my LUKS /home partition thinking I was working on a different disk. I recreated the partition but now can't open it. I have the disk in another system and am trying to figure out if I can get at the data. Most of the data was backed up but I'd really like to recover the odd and ends that weren't.

The LUKS header seems to be intact (see dump below) but the pass phrase isn't accepted when I try to open it.

Is there something missing that I can fix or is the data gone for good?

Thanks!


----------------------------------
root@lnx03:/# cryptsetup luksDump /dev/sdb2
LUKS header information for /dev/sdb2

Version: 1
Cipher name: aes
Cipher mode: cbc-essiv:sha256
Hash spec: sha1
Payload offset: 2056
MK bits: 256
MK digest: ff cd a6 0e 26 9c ae c0 dd ab c9 1e fd fd 48 d9 71 28 31 ff
MK salt: 25 97 d8 0f 21 77 3b cc 08 11 ed b2 d7 68 00 b8
46 9d bb ce 4d 71 8c fc a7 19 06 3e 5c e4 9a 9b
MK iterations: 10
UUID: b9777258-03c6-4ed7-bed9-c3e7f19252f2

Key Slot 0: ENABLED
Iterations: 278529
Salt: 58 25 71 fd 72 63 be b9 0f 8e 95 d7 da 0c 2f 8f
a0 b1 e9 e2 de 51 1f b6 46 7d cc b9 bd d9 0a 43
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
 
Old 10-22-2013, 05:24 AM   #2
cyberpatrol
Member
 
Registered: Dec 2012
Posts: 75

Rep: Reputation: Disabled
Quote:
Originally Posted by cavig5 View Post
Is there something missing that I can fix or is the data gone for good?
Well, I'm a bit in a dilemma here.

I can tell you this much. It looks like your LUKS container resp. the data in it can be fully recovered, if the header is really intact, and the LUKS container hasn't been overwritten.

But I actually have to refer you to a certain data recovery laboratory of which I know that they know how to recover it. There are reasons, why I don't want to explain it in detail publicly, even if I'm not related to this company.
 
Old 10-22-2013, 11:39 AM   #3
rknichols
Senior Member
 
Registered: Aug 2009
Distribution: CentOS
Posts: 1,434

Rep: Reputation: 599Reputation: 599Reputation: 599Reputation: 599Reputation: 599Reputation: 599
I fear I can't be as optimistic. If all you did was delete and re-create the partition, the LUKS header and payload should have been undamaged. The luksDump action only looks at the LUKS partition header, and that will look good even if the key material that follows it has been overwritten. There is a LUKS keyslot checker that will examine the key material and report any sectors that have less entropy than would be expected from encrypted key material, but to get that keyslot checker you have to download the cryptsetup source and build that piece (it isn't part of the default build). If the key material has been damaged, your data is unrecoverable unless you have a backup of the entire (~.5MB) LUKS header.

You might post a query on the cryptsetup mailing list for help.
 
Old 10-22-2013, 12:07 PM   #4
cyberpatrol
Member
 
Registered: Dec 2012
Posts: 75

Rep: Reputation: Disabled
@rknichols: It would be nice if you wouldn't spread FUD. It's not the first time you did this in this context.

1. cryptsetup luksDump /dev/sdb2 doesn't necessarily give the real LUKS header, since the original partition /dev/sdb2 doesn't exist anymore due to the repartitioning of the drive.

2. Every partitioning tool, incl. gparted usually only overwrites the partition table (MBR or GPT) but usually not the paritions themselves. They quasi only set a pointer to the beginning of the partition.

3. The LUKS headers are in the partitions not in the partition table. The keys are stored in the LUKS headers. So if the partition itself hasn't been overwritten, and you know the password, you CAN recover the data in the LUKS container.

I DO know how to recover the data. But since I found this out together with a certain data recovery lab (I was their customer with exactly the same problem, not their employee), I can't or don't want to post the solution publicly here for obvious reasons. That's the dilemma I'm in.

I can tell you the name of this company, but this would probably understood as advertising which is usually not allowed in such forums. And there's no PM here, otherwise I could send the OP a PM.

Again: The data recovery is only possible, if the LUKS container incl. its header wasn't overwritten.

Last edited by cyberpatrol; 10-22-2013 at 12:10 PM.
 
Old 10-22-2013, 02:31 PM   #5
rknichols
Senior Member
 
Registered: Aug 2009
Distribution: CentOS
Posts: 1,434

Rep: Reputation: 599Reputation: 599Reputation: 599Reputation: 599Reputation: 599Reputation: 599
Quote:
Originally Posted by cyberpatrol View Post
1. cryptsetup luksDump /dev/sdb2 doesn't necessarily give the real LUKS header, since the original partition /dev/sdb2 doesn't exist anymore due to the repartitioning of the drive.
So, are you suggesting that the re-created /dev/sdb2 just happened to begin with a valid LUKS partition header (as displayed by luksDump) that was not the actual LUKS partition header? The only way I can see that happening would be if the disk had been previously used with LUKS while partitioned in a slightly different way, and the re-created partition happened to match that old configuration and not the most recent one. OK, not impossible, just unlikely, and recovery shouldn't require professional assistance. testdisk should be able to find the other candidate for the start of the LUKS partition.

I agree completely that simple deletion and re-creation of the partition should not have damaged the contents, but it appears that something more than a simple partition table change occurred. In particular, a tool like gparted that, in one operation, can create the new partition and format it to ext2/3/4 would cause exactly the result seen -- an intact LUKS partition header with the key material overwritten.

Lacking evidence to the contrary, I suspect horses, not zebras.
 
Old 10-22-2013, 03:55 PM   #6
cyberpatrol
Member
 
Registered: Dec 2012
Posts: 75

Rep: Reputation: Disabled
Quote:
Originally Posted by rknichols View Post
So, are you suggesting that the re-created /dev/sdb2 just happened to begin with a valid LUKS partition header (as displayed by luksDump) that was not the actual LUKS partition header? The only way I can see that happening would be if the disk had been previously used with LUKS while partitioned in a slightly different way, and the re-created partition happened to match that old configuration and not the most recent one. OK, not impossible, just unlikely, and recovery shouldn't require professional assistance. testdisk should be able to find the other candidate for the start of the LUKS partition.
I just said that this alleged LUKS header can't be trusted. It's possible that the new partition /dev/sdb2 starts coincidentally at the same sector the old one started. But to verify this you needed to know the old and the new partition scheme. But even if it started at the same sector, it doesn't mean that the LUKS container can be accessed this way again.

But that totally doesn't lead you to the solution for the data recovery. You're totally on a wrong way. And forget testdisk. It can't handle LUKS partitions.

Quote:
Originally Posted by rknichols View Post
I agree completely that simple deletion and re-creation of the partition should not have damaged the contents, but it appears that something more than a simple partition table change occurred. In particular, a tool like gparted that, in one operation, can create the new partition and format it to ext2/3/4 would cause exactly the result seen -- an intact LUKS partition header with the key material overwritten.
He said, he had repartitioned, not reformatted the disk. If he had formatted the disk, then the LUKS container would most likely be destroyed, and the data is lost. But that's usual. If data is overwritten it usually can't be recovered.

But I still won't tell you how the data can be recovered publicly for some reasons. I just wanted to tell the OP that his data is not lost if the LUKS container and its header hasn't been overwritten, and that he doesn't need to be panicked. If there was a PM here I probably could help him better.

Last edited by cyberpatrol; 10-22-2013 at 03:59 PM.
 
Old 10-22-2013, 04:13 PM   #7
rknichols
Senior Member
 
Registered: Aug 2009
Distribution: CentOS
Posts: 1,434

Rep: Reputation: 599Reputation: 599Reputation: 599Reputation: 599Reputation: 599Reputation: 599
Quote:
Originally Posted by cyberpatrol View Post
And forget testdisk. It can't handle LUKS partitions.
Quote from the testdisk home page:
TestDisk can find lost partitions for all of these file systems:
.
.
  • Linux LUKS encrypted partition
.
.
 
Old 10-22-2013, 05:00 PM   #8
cyberpatrol
Member
 
Registered: Dec 2012
Posts: 75

Rep: Reputation: Disabled
Quote:
Originally Posted by rknichols View Post
Quote from the testdisk home page:
TestDisk can find lost partitions for all of these file systems:
.
.
  • Linux LUKS encrypted partition
.
.
Then this must be new. Otherwise it doesn't work (always). For me it gave me only garbage, except for the size of the most important of my lost partitions. Nevertheless testdisk isn't needed for this case.
 
Old 10-22-2013, 05:39 PM   #9
rknichols
Senior Member
 
Registered: Aug 2009
Distribution: CentOS
Posts: 1,434

Rep: Reputation: 599Reputation: 599Reputation: 599Reputation: 599Reputation: 599Reputation: 599
It can identify the start of a LUKS partition just fine, but it has no way to know the size of the payload. So, it always reports the size as the minimum possible, which is the size of the LUKS header, typically 1033 512-byte sectors.

Just to be sure, I tried it out with a fairly old version (6.12, May 2011), and it found both LUKS partitions on a disk with a zeroed partition table.
 
Old 10-22-2013, 06:29 PM   #10
cyberpatrol
Member
 
Registered: Dec 2012
Posts: 75

Rep: Reputation: Disabled
Quote:
Originally Posted by rknichols View Post
Just to be sure, I tried it out with a fairly old version (6.12, May 2011), and it found both LUKS partitions on a disk with a zeroed partition table.
Then you were lucky. It didn't find mine. So I wouldn't rely on testdisk when recovering a LUKS partition.
 
Old 10-28-2013, 08:55 PM   #11
cavig5
LQ Newbie
 
Registered: Nov 2010
Posts: 6

Original Poster
Rep: Reputation: 0
Thanks for the comments so far. I installed and tried testdisk. It finds the two partitions I expected. This disk was originally from a Debian install with the /home partition split out in an encrypted LV. Snips from the log file are below.

From its initial look at the disk
---------------
Current partition structure:
1 * Linux 0 1 1 30 254 63 497952
2 P Linux 31 0 1 121600 254 63 1953022050
---------------

and from its analysis looking for partitions
---------------
Results
* Linux 0 1 1 30 254 63 497952
EXT2 Sparse superblock, 254 MB / 243 MiB
P Linux 31 0 1 31 254 63 16065
LUKS 1 (Data size unknown), 8225 KB / 8032 KiB
---------------

There seems to be something going on with the size of the second (LUKS) partition. Could that be part of the issue?
 
Old 10-28-2013, 10:25 PM   #12
rknichols
Senior Member
 
Registered: Aug 2009
Distribution: CentOS
Posts: 1,434

Rep: Reputation: 599Reputation: 599Reputation: 599Reputation: 599Reputation: 599Reputation: 599
Quote:
Originally Posted by cavig5 View Post
From its initial look at the disk
---------------
Current partition structure:
1 * Linux 0 1 1 30 254 63 497952
2 P Linux 31 0 1 121600 254 63 1953022050
---------------

and from its analysis looking for partitions
---------------
Results
* Linux 0 1 1 30 254 63 497952
EXT2 Sparse superblock, 254 MB / 243 MiB
P Linux 31 0 1 31 254 63 16065
LUKS 1 (Data size unknown), 8225 KB / 8032 KiB
---------------

There seems to be something going on with the size of the second (LUKS) partition. Could that be part of the issue?
There is no information in the LUKS header about the size of the data section (payload), so testdisk is just reporting that fact. Not knowing the size of the data that follows, testdisk is suggesting a small size for the partition, which is actually much larger. The starting point that testdisk found agrees with what is currently in your partition table. That sounds good, but if there really is no other LUKS header present, that would mean the problem is with damaged key material.

When you ran testdisk, did you go into the "Options" settings and change "Align partition" to "No"? That would be important if the real LUKS header was at a location not aligned on a cylinder or 1MiB boundary. (Yes, that makes testdisk really slow.)

Back when you accidentally deleted that LUKS partition, exactly what did you do? What tool did you use? What did you tell it to do?

Here is something to try. Take a look at what I believe would be the first block of key material beginning at sector offset 8 (according to the LUKS header):
Code:
dd if=/dev/sdb2 skip=8 count=250 | hexdump -C | less
and see if there is anything in there that does not look like random bits. That's all 4000 stripes of the first key slot for a 256-bit key. The damage would most likely be near the beginning.
 
Old 10-28-2013, 11:18 PM   #13
cyberpatrol
Member
 
Registered: Dec 2012
Posts: 75

Rep: Reputation: Disabled
Quote:
Originally Posted by cavig5 View Post
There seems to be something going on with the size of the second (LUKS) partition. Could that be part of the issue?
Again: Don't trust testdisk when using dm-crypt/LUKS, and particularly not when using it together with LVM. I mean it. And testdisk is really not necessary to recover your data. In fact it can do a lot more damage.

And you should make an image of your harddisk with dd at first, before doing anything else, particularly with such tools like testdisk.

That said, testdisk is generally a very good tool for data recovery, but not in this case.

If there was a PM here I probably could help you a bit better. rknichols is still on a totally wrong way. I just say: Think differently. (I don't mean this fruit company.)

Last edited by cyberpatrol; 10-28-2013 at 11:24 PM.
 
Old 10-29-2013, 09:42 AM   #14
rknichols
Senior Member
 
Registered: Aug 2009
Distribution: CentOS
Posts: 1,434

Rep: Reputation: 599Reputation: 599Reputation: 599Reputation: 599Reputation: 599Reputation: 599
Quote:
Originally Posted by cyberpatrol View Post
Again: Don't trust testdisk when using dm-crypt/LUKS, and particularly not when using it together with LVM. I mean it.
Why are you bringing LVM into this? There has been no previous mention of LVM in this thread.

Look, there is either a LUKS partition header present, or there is not. That header is either followed by undamaged key material, or it is not. If either one is missing/corrupted, there is no hope of recovery. You need both the 32 bytes of salt in the header plus all stripes of undamaged key material to recover the master key. Neither one can be reconstructed.

A LUKS partition header is pretty easy to find. It is a sector beginning with the ASCII characters "LUKS". If you don't trust testdisk to do that, it's easy enough to code up something yourself to do the search.

And, testdisk won't write anything to the device it is analyzing unless you tell it to.

Last edited by rknichols; 10-29-2013 at 09:44 AM.
 
Old 10-29-2013, 11:28 AM   #15
cyberpatrol
Member
 
Registered: Dec 2012
Posts: 75

Rep: Reputation: Disabled
Quote:
Originally Posted by rknichols View Post
Why are you bringing LVM into this? There has been no previous mention of LVM in this thread.
Why don't you stay with the facts? LVM was brought into by the OP, not by me. And testdisk has a problem with LUKS. If LVM comes into play it gets even worse.

Quote:
Originally Posted by rknichols View Post
Look, there is either a LUKS partition header present, or there is not.
And where is the LUKS header (There is no LUKS partition header!) stored? Right, at the beginning of the LUKS container. What did I say? Right, the data can be recovered if the partition hasn't been overwritten. What's the difference between overwriting the LUKS header and overwriting the partition? Right, there is no.

Apart from LUKS and LVM, is it possible to recover data, that has been overwritten? No, in no case.

So what are you discussing here? Just to be in the right?

Quote:
Originally Posted by rknichols View Post
That header is either followed by undamaged key material, or it is not.
No, the keys are stored in the header.

Quote:
Originally Posted by rknichols View Post
If either one is missing/corrupted, there is no hope of recovery.
What did I say before? There is no chance of data recovery, if the data has been overwritten. And what did I say in my very first posting? Right, I said: "It looks like your LUKS container resp. the data in it can be fully recovered, if the header is really intact, and the LUKS container hasn't been overwritten."

Read the if clause?

Quote:
Originally Posted by rknichols View Post
You need both the 32 bytes of salt in the header plus all stripes of undamaged key material to recover the master key. Neither one can be reconstructed.
Who said, that the OP's LUKS header has been overwritten? He didn't say anything like that.

If the LUKS header wasn't overwritten you just need your usual LUKS key, you're always using, for the data recovery. And if the header was overwritten the salt and the master key won't help you either. Like I said, you're totally on the wrong way.

Maybe an encryption expert can reconstruct the one or the other if only parts of the LUKS partition incl. the LUKS header have been overwritten. But this is pretty unlikely here.

Quote:
Originally Posted by rknichols View Post
A LUKS partition header is pretty easy to find. It is a sector beginning with the ASCII characters "LUKS". If you don't trust testdisk to do that, it's easy enough to code up something yourself to do the search.
Now we're getting a bit closer. Btw., you heard about hex editors? Well, that was almost more than I wanted to say.

Quote:
Originally Posted by rknichols View Post
And, testdisk won't write anything to the device it is analyzing unless you tell it to.
And if you trust testdisk's analysis on a LUKS partition, what you shouldn't, and let testdisk try to recover the partition, what you shouldn't do still less, or accidentally hit the wrong key, your data can easily be destroyed.

Search for the difference between a partition and a LUKS container, and find out what testdisk is for and doing. So with the wrong values testdisk will write a wrong partition table and likely destroy your data completely, because it doesn't find all the correct values, it needs to recover a LUKS partition and write a correct partition table.
 
  


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 On
HTML code is Off


Similar Threads
Thread Thread Starter Forum Replies Last Post
create a partiton-table with Gparted - HowTo sayhello_to_the_world Linux - Newbie 3 05-23-2013 04:24 PM
How To Recover Files Form JFS Partiton dofod Linux - Hardware 5 01-18-2011 10:21 AM
Deleting Partion with Gparted Help hotborad Linux - Hardware 3 08-05-2010 10:05 AM
Recover encrypted LUKS partition itinlopez Linux - General 3 11-30-2008 02:20 AM
injury to partiton table??how to recover farhan Linux - General 4 10-05-2003 08:08 PM


All times are GMT -5. The time now is 09:17 AM.

Main Menu
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
identi.ca: @linuxquestions
Facebook: linuxquestions Google+: linuxquestions
Open Source Consulting | Domain Registration