LUKS Header crruption
A message that is not in the archive (sent off-list or not yet received): 1590255742.9.1564314256863.JavaMail.gkos@xpska
Hi List,
as a result of executing a command from the history, after a reboot, when the disk letters were changed, I have accidentally overwritten the LUKS header with the raid superblock one :(
Now I can not open the cryptodisk with the "luksOpen" as it states the "No key available with this passphrase."
However, when I run "luksDump" the header information is available
# cryptsetup luksDump /dev/sdd1 LUKS header information for /dev/sdd1
Version: 1
Cipher name: aes
Cipher mode: xts-plain64
Hash spec: sha256
Payload offset: 4096
MK bits: 256
MK digest: a6 a6 de 04 5a 19 9f 97 54 a9 79 bf f8 c1 37 89 69 44 34 76
MK salt: 7a 0b 8e cc 68 06 35 ec 09 fc 5e f9 90 e3 c9 ef
8b 11 96 10 4c 25 ab 89 a1 48 df fe 6a 88 20 96
MK iterations: 232809
UUID: 0f91c412-6f6a-405d-8040-5cc17ad17b47Key Slot 0: ENABLED
Iterations: 3724958
Salt: c4 52 ac 04 59 8a d1 4f 7a 3c 5d e8 d3 50 1a c4
11 20 0b 66 66 81 78 09 9f 7a f4 c1 dc 80 d4 40
Key material offset: 8
AF stripes: 4000Key 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
The RAID superblock that was written by mdadm is default, version 1.2 that is located 4K from the beginning of the device.
Providing that I have no backup of the original header and I know wht was written, is there a way to restore the header and get the data?
Konstantin
Hi Konstantin,
sorry, you data is gone. You overwrote the start of the first key-slot and there is no way to recover from that without backup.
One of the reasons why I think RAID superblocks at the start of the device (and even more so at 4kB offset) are messed up and a sign of clueless designers.
Regards,
Arno
Quoted 56 lines · Konstantin V. Gavrilenko
Hi List,
as a result of executing a command from the history, after a reboot, when the disk letters were changed, I have accidentally overwritten the LUKS header with the raid superblock one :(
Now I can not open the cryptodisk with the "luksOpen" as it states the "No key available with this passphrase."
However, when I run "luksDump" the header information is available
# cryptsetup luksDump /dev/sdd1 LUKS header information for /dev/sdd1Version: 1 Cipher name: aes Cipher mode: xts-plain64 Hash spec: sha256 Payload offset: 4096 MK bits: 256 MK digest: a6 a6 de 04 5a 19 9f 97 54 a9 79 bf f8 c1 37 89 69 44 34 76 MK salt: 7a 0b 8e cc 68 06 35 ec 09 fc 5e f9 90 e3 c9 ef 8b 11 96 10 4c 25 ab 89 a1 48 df fe 6a 88 20 96 MK iterations: 232809 UUID: 0f91c412-6f6a-405d-8040-5cc17ad17b47Key Slot 0: ENABLED
Iterations: 3724958 Salt: c4 52 ac 04 59 8a d1 4f 7a 3c 5d e8 d3 50 1a c4 11 20 0b 66 66 81 78 09 9f 7a f4 c1 dc 80 d4 40 Key material offset: 8 AF stripes: 4000Key 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: DISABLEDThe RAID superblock that was written by mdadm is default, version 1.2 that
is located 4K from the beginning of the device.Providing that I have no backup of the original header and I know wht was written, is there a way to restore the header and get the data?
Konstantin
_______________________________________________
dm-crypt mailing list
[email protected]
https://www.saout.de/mailman/listinfo/dm-crypt
Signature · 7 lines
Arno Wagner, Dr. sc. techn., Dipl. Inform., Email: [email protected] GnuPG: ID: CB5D9718 FP: 12D6 C03B 1B30 33BB 13CF B774 E35C 5FA1 CB5D 9718 ---- A good decision is based on knowledge and not on numbers. -- Plato If it's in the news, don't worry about it. The very definition of "news" is "something that hardly ever happens." -- Bruce Schneier
Quoted 3 lines · Arno Wagner
One of the reasons why I think RAID superblocks at the start of the device (and even more so at 4kB offset) are messed up and a sign of clueless designers.
Depending on the md metadata version, it's either at the start, at the end, or 4k from start - each with its own drawbacks. The metadata needs to reside somewhere, quite the same as with LUKS, or filesystem metadata. If you have a hint on how to get around that, please tell.. :)
Yours, Uwe
Quoted 9 lines · Uwe Menges
Quoted 3 lines · Arno Wagner
One of the reasons why I think RAID superblocks at the start of the device (and even more so at 4kB offset) are messed up and a sign of clueless designers.
Depending on the md metadata version, it's either at the start, at the end, or 4k from start - each with its own drawbacks. The metadata needs to reside somewhere, quite the same as with LUKS, or filesystem metadata. If you have a hint on how to get around that, please tell.. :)
Maybe read what I wrote, because you seem to not have done so? And yes, I am aware of the different problems.
Regards,
Arno
Signature · 7 lines
Arno Wagner, Dr. sc. techn., Dipl. Inform., Email: [email protected] GnuPG: ID: CB5D9718 FP: 12D6 C03B 1B30 33BB 13CF B774 E35C 5FA1 CB5D 9718 ---- A good decision is based on knowledge and not on numbers. -- Plato If it's in the news, don't worry about it. The very definition of "news" is "something that hardly ever happens." -- Bruce Schneier