* [dm-crypt] Strange header corruption
@ 2014-02-25 14:33 Dis McCarthy
2014-02-26 4:11 ` Arno Wagner
0 siblings, 1 reply; 6+ messages in thread
From: Dis McCarthy @ 2014-02-25 14:33 UTC (permalink / raw)
To: dm-crypt
[-- Attachment #1: Type: text/plain, Size: 2491 bytes --]
I've got 2 full-device luks devices (usb3) that somehow got corrupted
headers at the same time. They were working, I powered down the system to
move some plugs and when I brought it back up, my headers are unrecognized.
(See below.) The system is a mac mini running arch linux. It has been
rebooted and powercycled repeatedly since being built and never had an
issue, so I hesitate to blame refit. The only thing I can see is that there
was a recent update of cryptsetup (to 1.6.3-2). I'm not sure if the devices
were stopped cleanly before reboot (probably not, since its arch..) but the
volumes were unmounted and I wouldn't expect to get corruption.
I'm dumb, and do not have a backup of the headers. (Well.. there might be a
backup of one of them. Inside the encrypted volume.. yeah, like I said, I'm
dumb. If I get this back, that is getting remedied immediately..)
Comparing with other users, it looks like some of the entries are swapped
around. I started doing a comparison to the on-disk format pdf, but I
haven't had a chance to print it out and get intimate with it yet (beyond
noting that LUKS 0xba0xbe is missing of course.)
Is there any hope? Here is what I've got at the beginning the drives:
00000000 00 00 00 00 48 00 00 00 00 00 00 00 32 32 30 64
|....H.......220d|
00000010 32 30 33 64 2d 39 62 62 34 2d 34 35 00 00 00 00
|203d-9bb4-45....|
00000020 24 00 00 00 12 00 00 00 24 00 00 00 00 00 61 69
|$.......$.....ai|
00000030 6e 36 34 00 00 00 00 00 00 00 00 00 00 00 00 00
|n64.............|
00000040 00 00 00 00 00 00 00 00 73 68 61 32 35 36 00 00
|........sha256..|
00000050 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
|................|
00000060 00 00 00 00 00 00 00 00 00 00 10 00 00 00 00 40
|...............@|
00000070 da 22 00 00 00 00 24 01 00 00 00 00 00 00 00 00
|."....$.........|
and:
00000000 00 00 00 00 48 00 00 00 00 00 00 00 32 33 63 38
|....H.......23c8|
00000010 62 61 33 31 2d 37 61 63 66 2d 34 32 00 00 00 00
|ba31-7acf-42....|
00000020 24 00 00 00 12 00 00 00 24 00 00 00 00 00 61 69
|$.......$.....ai|
00000030 6e 36 34 00 00 00 00 00 00 00 00 00 00 00 00 00
|n64.............|
00000040 00 00 00 00 00 00 00 00 73 68 61 32 35 36 00 00
|........sha256..|
00000050 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
|................|
00000060 00 00 00 00 00 00 00 00 00 00 10 00 00 00 00 40
|...............@|
00000070 de 8b 00 00 00 00 24 01 00 00 00 00 00 00 00 00
|......$.........|
Thanks!
[-- Attachment #2: Type: text/html, Size: 3650 bytes --]
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [dm-crypt] Strange header corruption
2014-02-25 14:33 [dm-crypt] Strange header corruption Dis McCarthy
@ 2014-02-26 4:11 ` Arno Wagner
2014-02-26 12:13 ` Dis McCarthy
0 siblings, 1 reply; 6+ messages in thread
From: Arno Wagner @ 2014-02-26 4:11 UTC (permalink / raw)
To: dm-crypt
This is pretty strange. You seem to have lost parts of the
header, but not the hash spec. And it seems to have happened
two times.
This should not be happening at all. LUKS does not require a
"clean shutdown", unless you luksFormat or change
passphrases, cryptsetup does not write anything at all for
LUKS and even ripping out the disk directly while it
runs should not cause any header damage. (It may damage the
filesystem in the LUKS container though...).
What seems to have happened here is that some application
read the header, replaced the first 0x2d bytes (leaving
"ain64" of "xts-plain64". It seem to have put in a GUID
of sorts. I have no idea what this is. The header was not
simply overwritten, so this is something deliberately.
On the other hand, no application should write anything to
the start of a partition in normal operation.
Maybe somebody else here recognizes the pattern seen?
Maybe these are SSDs with a serious firmware bug?
Or maybe you have wrap-around because the USB3 interface
cannot handle the full disk size?
As to recovery:
1. Make a sector-wise backup of the whole LUKS containers
or whole disk(s) before messing with anything!
2. Just putting in what should be there in the first
0x2d bytes with a hex editor may be enough to get this
working again if there is no other damage. If there
is damage in the keyslot areas or to the salt values
in the header, no recovery is possible.
Hexediting the header is pretty simple, just read the
first 1024 bytes (head -c 1024 /dev/disk > hdr.img),
hexedit it and then write it back (cat hdr.img > /dev/disk).
The risk of doing more damage is high, so do not try this
without that backup.
Here is what the first 0x2d bytes should look like (defaul
parameters):
00000000 4c 55 4b 53 ba be 00 01 61 65 73 00 00 00 00 00 |LUKS....aes.....|
00000010 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................|
00000020 00 00 00 00 00 00 00 00 78 74 73 2d 70 6c 61 69 |........xts-plai|
If after that cryptsetup works, but does not accept
your passphrase, you can run the keyslot-checker from
the source package and you can post the full headers
(592 bytes long) here for more advice.
Arno
On Tue, Feb 25, 2014 at 15:33:20 CET, Dis McCarthy wrote:
> I've got 2 full-device luks devices (usb3) that somehow got corrupted
> headers at the same time. They were working, I powered down the system to
> move some plugs and when I brought it back up, my headers are unrecognized.
> (See below.) The system is a mac mini running arch linux. It has been
> rebooted and powercycled repeatedly since being built and never had an
> issue, so I hesitate to blame refit. The only thing I can see is that there
> was a recent update of cryptsetup (to 1.6.3-2). I'm not sure if the devices
> were stopped cleanly before reboot (probably not, since its arch..) but the
> volumes were unmounted and I wouldn't expect to get corruption.
>
> I'm dumb, and do not have a backup of the headers. (Well.. there might be a
> backup of one of them. Inside the encrypted volume.. yeah, like I said, I'm
> dumb. If I get this back, that is getting remedied immediately..)
>
> Comparing with other users, it looks like some of the entries are swapped
> around. I started doing a comparison to the on-disk format pdf, but I
> haven't had a chance to print it out and get intimate with it yet (beyond
> noting that LUKS 0xba0xbe is missing of course.)
>
> Is there any hope? Here is what I've got at the beginning the drives:
>
> 00000000 00 00 00 00 48 00 00 00 00 00 00 00 32 32 30 64
> |....H.......220d|
> 00000010 32 30 33 64 2d 39 62 62 34 2d 34 35 00 00 00 00
> |203d-9bb4-45....|
> 00000020 24 00 00 00 12 00 00 00 24 00 00 00 00 00 61 69
> |$.......$.....ai|
> 00000030 6e 36 34 00 00 00 00 00 00 00 00 00 00 00 00 00
> |n64.............|
> 00000040 00 00 00 00 00 00 00 00 73 68 61 32 35 36 00 00
> |........sha256..|
> 00000050 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
> |................|
> 00000060 00 00 00 00 00 00 00 00 00 00 10 00 00 00 00 40
> |...............@|
> 00000070 da 22 00 00 00 00 24 01 00 00 00 00 00 00 00 00
> |."....$.........|
>
> and:
> 00000000 00 00 00 00 48 00 00 00 00 00 00 00 32 33 63 38
> |....H.......23c8|
> 00000010 62 61 33 31 2d 37 61 63 66 2d 34 32 00 00 00 00
> |ba31-7acf-42....|
> 00000020 24 00 00 00 12 00 00 00 24 00 00 00 00 00 61 69
> |$.......$.....ai|
> 00000030 6e 36 34 00 00 00 00 00 00 00 00 00 00 00 00 00
> |n64.............|
> 00000040 00 00 00 00 00 00 00 00 73 68 61 32 35 36 00 00
> |........sha256..|
> 00000050 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
> |................|
> 00000060 00 00 00 00 00 00 00 00 00 00 10 00 00 00 00 40
> |...............@|
> 00000070 de 8b 00 00 00 00 24 01 00 00 00 00 00 00 00 00
> |......$.........|
>
> Thanks!
> _______________________________________________
> dm-crypt mailing list
> dm-crypt@saout.de
> http://www.saout.de/mailman/listinfo/dm-crypt
--
Arno Wagner, Dr. sc. techn., Dipl. Inform., Email: arno@wagner.name
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
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [dm-crypt] Strange header corruption
2014-02-26 4:11 ` Arno Wagner
@ 2014-02-26 12:13 ` Dis McCarthy
2014-02-26 12:49 ` Arno Wagner
0 siblings, 1 reply; 6+ messages in thread
From: Dis McCarthy @ 2014-02-26 12:13 UTC (permalink / raw)
To: dm-crypt
[-- Attachment #1: Type: text/plain, Size: 6284 bytes --]
Thanks for the help!
I doubt that dm-crypt had anything to do with it - your mention of guid got
me thinking that it is almost certainly something in the boot sequence.
(Not sure why it decided to hit now, but..) They are spinning disks, so no
ssd bugs but that doesn't rule out firmware or bootloader issues.
Unfortunately I don't have 7T to back up the devices. Is there a relatively
safe way to test? Worst case, I can make the change, set the entire device
ro and try, if dm-crypt can decrypt a readonly device.
I did confirm farther down the header, the keys and empty slots appear to
be present.
On Feb 25, 2014 11:11 PM, "Arno Wagner" <arno@wagner.name> wrote:
>
> This is pretty strange. You seem to have lost parts of the
> header, but not the hash spec. And it seems to have happened
> two times.
>
> This should not be happening at all. LUKS does not require a
> "clean shutdown", unless you luksFormat or change
> passphrases, cryptsetup does not write anything at all for
> LUKS and even ripping out the disk directly while it
> runs should not cause any header damage. (It may damage the
> filesystem in the LUKS container though...).
>
> What seems to have happened here is that some application
> read the header, replaced the first 0x2d bytes (leaving
> "ain64" of "xts-plain64". It seem to have put in a GUID
> of sorts. I have no idea what this is. The header was not
> simply overwritten, so this is something deliberately.
> On the other hand, no application should write anything to
> the start of a partition in normal operation.
>
> Maybe somebody else here recognizes the pattern seen?
> Maybe these are SSDs with a serious firmware bug?
> Or maybe you have wrap-around because the USB3 interface
> cannot handle the full disk size?
>
>
> As to recovery:
> 1. Make a sector-wise backup of the whole LUKS containers
> or whole disk(s) before messing with anything!
> 2. Just putting in what should be there in the first
> 0x2d bytes with a hex editor may be enough to get this
> working again if there is no other damage. If there
> is damage in the keyslot areas or to the salt values
> in the header, no recovery is possible.
>
> Hexediting the header is pretty simple, just read the
> first 1024 bytes (head -c 1024 /dev/disk > hdr.img),
> hexedit it and then write it back (cat hdr.img > /dev/disk).
> The risk of doing more damage is high, so do not try this
> without that backup.
>
> Here is what the first 0x2d bytes should look like (defaul
> parameters):
>
> 00000000 4c 55 4b 53 ba be 00 01 61 65 73 00 00 00 00 00
|LUKS....aes.....|
> 00000010 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
|................|
> 00000020 00 00 00 00 00 00 00 00 78 74 73 2d 70 6c 61 69
|........xts-plai|
>
> If after that cryptsetup works, but does not accept
> your passphrase, you can run the keyslot-checker from
> the source package and you can post the full headers
> (592 bytes long) here for more advice.
>
> Arno
>
>
>
>
>
> On Tue, Feb 25, 2014 at 15:33:20 CET, Dis McCarthy wrote:
> > I've got 2 full-device luks devices (usb3) that somehow got corrupted
> > headers at the same time. They were working, I powered down the system
to
> > move some plugs and when I brought it back up, my headers are
unrecognized.
> > (See below.) The system is a mac mini running arch linux. It has been
> > rebooted and powercycled repeatedly since being built and never had an
> > issue, so I hesitate to blame refit. The only thing I can see is that
there
> > was a recent update of cryptsetup (to 1.6.3-2). I'm not sure if the
devices
> > were stopped cleanly before reboot (probably not, since its arch..) but
the
> > volumes were unmounted and I wouldn't expect to get corruption.
> >
> > I'm dumb, and do not have a backup of the headers. (Well.. there might
be a
> > backup of one of them. Inside the encrypted volume.. yeah, like I said,
I'm
> > dumb. If I get this back, that is getting remedied immediately..)
> >
> > Comparing with other users, it looks like some of the entries are
swapped
> > around. I started doing a comparison to the on-disk format pdf, but I
> > haven't had a chance to print it out and get intimate with it yet
(beyond
> > noting that LUKS 0xba0xbe is missing of course.)
> >
> > Is there any hope? Here is what I've got at the beginning the drives:
> >
> > 00000000 00 00 00 00 48 00 00 00 00 00 00 00 32 32 30 64
> > |....H.......220d|
> > 00000010 32 30 33 64 2d 39 62 62 34 2d 34 35 00 00 00 00
> > |203d-9bb4-45....|
> > 00000020 24 00 00 00 12 00 00 00 24 00 00 00 00 00 61 69
> > |$.......$.....ai|
> > 00000030 6e 36 34 00 00 00 00 00 00 00 00 00 00 00 00 00
> > |n64.............|
> > 00000040 00 00 00 00 00 00 00 00 73 68 61 32 35 36 00 00
> > |........sha256..|
> > 00000050 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
> > |................|
> > 00000060 00 00 00 00 00 00 00 00 00 00 10 00 00 00 00 40
> > |...............@|
> > 00000070 da 22 00 00 00 00 24 01 00 00 00 00 00 00 00 00
> > |."....$.........|
> >
> > and:
> > 00000000 00 00 00 00 48 00 00 00 00 00 00 00 32 33 63 38
> > |....H.......23c8|
> > 00000010 62 61 33 31 2d 37 61 63 66 2d 34 32 00 00 00 00
> > |ba31-7acf-42....|
> > 00000020 24 00 00 00 12 00 00 00 24 00 00 00 00 00 61 69
> > |$.......$.....ai|
> > 00000030 6e 36 34 00 00 00 00 00 00 00 00 00 00 00 00 00
> > |n64.............|
> > 00000040 00 00 00 00 00 00 00 00 73 68 61 32 35 36 00 00
> > |........sha256..|
> > 00000050 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
> > |................|
> > 00000060 00 00 00 00 00 00 00 00 00 00 10 00 00 00 00 40
> > |...............@|
> > 00000070 de 8b 00 00 00 00 24 01 00 00 00 00 00 00 00 00
> > |......$.........|
> >
> > Thanks!
>
> > _______________________________________________
> > dm-crypt mailing list
> > dm-crypt@saout.de
> > http://www.saout.de/mailman/listinfo/dm-crypt
>
>
> --
> Arno Wagner, Dr. sc. techn., Dipl. Inform., Email: arno@wagner.name
> 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
> _______________________________________________
> dm-crypt mailing list
> dm-crypt@saout.de
> http://www.saout.de/mailman/listinfo/dm-crypt
[-- Attachment #2: Type: text/html, Size: 7998 bytes --]
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [dm-crypt] Strange header corruption
2014-02-26 12:13 ` Dis McCarthy
@ 2014-02-26 12:49 ` Arno Wagner
2014-02-26 15:24 ` Dis McCarthy
0 siblings, 1 reply; 6+ messages in thread
From: Arno Wagner @ 2014-02-26 12:49 UTC (permalink / raw)
To: dm-crypt
On Wed, Feb 26, 2014 at 13:13:30 CET, Dis McCarthy wrote:
> Thanks for the help!
>
> I doubt that dm-crypt had anything to do with it - your mention of guid got
> me thinking that it is almost certainly something in the boot sequence.
> (Not sure why it decided to hit now, but..) They are spinning disks, so no
> ssd bugs but that doesn't rule out firmware or bootloader issues.
>
> Unfortunately I don't have 7T to back up the devices. Is there a relatively
> safe way to test? Worst case, I can make the change, set the entire device
> ro and try, if dm-crypt can decrypt a readonly device.
There is: Copy the first 100MB or so (needed are something like 2MiB, but
better be on the safe side) and work on that via loopback file
(see FAQ Item 2.5). When you can unlock that, you have then a good
header that you can backup the header from the loopback device and
install on the disk via luksHeaderBackup/luksHeaderRestore. Keep a
copy of those first 100MB as backup on a separate device so you can
restore it and can go back to the original state if anything goes
wrong. This does protect your (at the moment broken, but nonetheless
vital) headers from errors. Unlike a full backup, it does not protect
your filesystem in the LUKS container(s), so be careful.
If you are unsure, test disk operations first on a separate disk
and see what they do to make sure you have it under control.
You need to do that for each disk separately. If you cannot get an
unlock, you can run the keyslot-checker on the loopback device
as well and do further analysis there. All that LUKS needs is in
the first 2MiB, see alos FAQ Item 6.12.
> I did confirm farther down the header, the keys and empty slots appear to
> be present.
"Present" is not enough. "Undamaged" is what you need. But
lets fix the missing bytes first and see where that gets
you.
Arno
> On Feb 25, 2014 11:11 PM, "Arno Wagner" <arno@wagner.name> wrote:
> >
> > This is pretty strange. You seem to have lost parts of the
> > header, but not the hash spec. And it seems to have happened
> > two times.
> >
> > This should not be happening at all. LUKS does not require a
> > "clean shutdown", unless you luksFormat or change
> > passphrases, cryptsetup does not write anything at all for
> > LUKS and even ripping out the disk directly while it
> > runs should not cause any header damage. (It may damage the
> > filesystem in the LUKS container though...).
> >
> > What seems to have happened here is that some application
> > read the header, replaced the first 0x2d bytes (leaving
> > "ain64" of "xts-plain64". It seem to have put in a GUID
> > of sorts. I have no idea what this is. The header was not
> > simply overwritten, so this is something deliberately.
> > On the other hand, no application should write anything to
> > the start of a partition in normal operation.
> >
> > Maybe somebody else here recognizes the pattern seen?
> > Maybe these are SSDs with a serious firmware bug?
> > Or maybe you have wrap-around because the USB3 interface
> > cannot handle the full disk size?
> >
> >
> > As to recovery:
> > 1. Make a sector-wise backup of the whole LUKS containers
> > or whole disk(s) before messing with anything!
> > 2. Just putting in what should be there in the first
> > 0x2d bytes with a hex editor may be enough to get this
> > working again if there is no other damage. If there
> > is damage in the keyslot areas or to the salt values
> > in the header, no recovery is possible.
> >
> > Hexediting the header is pretty simple, just read the
> > first 1024 bytes (head -c 1024 /dev/disk > hdr.img),
> > hexedit it and then write it back (cat hdr.img > /dev/disk).
> > The risk of doing more damage is high, so do not try this
> > without that backup.
> >
> > Here is what the first 0x2d bytes should look like (defaul
> > parameters):
> >
> > 00000000 4c 55 4b 53 ba be 00 01 61 65 73 00 00 00 00 00
> |LUKS....aes.....|
> > 00000010 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
> |................|
> > 00000020 00 00 00 00 00 00 00 00 78 74 73 2d 70 6c 61 69
> |........xts-plai|
> >
> > If after that cryptsetup works, but does not accept
> > your passphrase, you can run the keyslot-checker from
> > the source package and you can post the full headers
> > (592 bytes long) here for more advice.
> >
> > Arno
> >
> >
> >
> >
> >
> > On Tue, Feb 25, 2014 at 15:33:20 CET, Dis McCarthy wrote:
> > > I've got 2 full-device luks devices (usb3) that somehow got corrupted
> > > headers at the same time. They were working, I powered down the system
> to
> > > move some plugs and when I brought it back up, my headers are
> unrecognized.
> > > (See below.) The system is a mac mini running arch linux. It has been
> > > rebooted and powercycled repeatedly since being built and never had an
> > > issue, so I hesitate to blame refit. The only thing I can see is that
> there
> > > was a recent update of cryptsetup (to 1.6.3-2). I'm not sure if the
> devices
> > > were stopped cleanly before reboot (probably not, since its arch..) but
> the
> > > volumes were unmounted and I wouldn't expect to get corruption.
> > >
> > > I'm dumb, and do not have a backup of the headers. (Well.. there might
> be a
> > > backup of one of them. Inside the encrypted volume.. yeah, like I said,
> I'm
> > > dumb. If I get this back, that is getting remedied immediately..)
> > >
> > > Comparing with other users, it looks like some of the entries are
> swapped
> > > around. I started doing a comparison to the on-disk format pdf, but I
> > > haven't had a chance to print it out and get intimate with it yet
> (beyond
> > > noting that LUKS 0xba0xbe is missing of course.)
> > >
> > > Is there any hope? Here is what I've got at the beginning the drives:
> > >
> > > 00000000 00 00 00 00 48 00 00 00 00 00 00 00 32 32 30 64
> > > |....H.......220d|
> > > 00000010 32 30 33 64 2d 39 62 62 34 2d 34 35 00 00 00 00
> > > |203d-9bb4-45....|
> > > 00000020 24 00 00 00 12 00 00 00 24 00 00 00 00 00 61 69
> > > |$.......$.....ai|
> > > 00000030 6e 36 34 00 00 00 00 00 00 00 00 00 00 00 00 00
> > > |n64.............|
> > > 00000040 00 00 00 00 00 00 00 00 73 68 61 32 35 36 00 00
> > > |........sha256..|
> > > 00000050 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
> > > |................|
> > > 00000060 00 00 00 00 00 00 00 00 00 00 10 00 00 00 00 40
> > > |...............@|
> > > 00000070 da 22 00 00 00 00 24 01 00 00 00 00 00 00 00 00
> > > |."....$.........|
> > >
> > > and:
> > > 00000000 00 00 00 00 48 00 00 00 00 00 00 00 32 33 63 38
> > > |....H.......23c8|
> > > 00000010 62 61 33 31 2d 37 61 63 66 2d 34 32 00 00 00 00
> > > |ba31-7acf-42....|
> > > 00000020 24 00 00 00 12 00 00 00 24 00 00 00 00 00 61 69
> > > |$.......$.....ai|
> > > 00000030 6e 36 34 00 00 00 00 00 00 00 00 00 00 00 00 00
> > > |n64.............|
> > > 00000040 00 00 00 00 00 00 00 00 73 68 61 32 35 36 00 00
> > > |........sha256..|
> > > 00000050 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
> > > |................|
> > > 00000060 00 00 00 00 00 00 00 00 00 00 10 00 00 00 00 40
> > > |...............@|
> > > 00000070 de 8b 00 00 00 00 24 01 00 00 00 00 00 00 00 00
> > > |......$.........|
> > >
> > > Thanks!
> >
> > > _______________________________________________
> > > dm-crypt mailing list
> > > dm-crypt@saout.de
> > > http://www.saout.de/mailman/listinfo/dm-crypt
> >
> >
> > --
> > Arno Wagner, Dr. sc. techn., Dipl. Inform., Email: arno@wagner.name
> > 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
> > _______________________________________________
> > dm-crypt mailing list
> > dm-crypt@saout.de
> > http://www.saout.de/mailman/listinfo/dm-crypt
> _______________________________________________
> dm-crypt mailing list
> dm-crypt@saout.de
> http://www.saout.de/mailman/listinfo/dm-crypt
--
Arno Wagner, Dr. sc. techn., Dipl. Inform., Email: arno@wagner.name
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
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [dm-crypt] Strange header corruption
2014-02-26 12:49 ` Arno Wagner
@ 2014-02-26 15:24 ` Dis McCarthy
2014-02-26 16:52 ` Arno Wagner
0 siblings, 1 reply; 6+ messages in thread
From: Dis McCarthy @ 2014-02-26 15:24 UTC (permalink / raw)
To: dm-crypt
[-- Attachment #1.1: Type: text/plain, Size: 9251 bytes --]
On Wed, Feb 26, 2014 at 7:49 AM, Arno Wagner <arno@wagner.name> wrote:
> On Wed, Feb 26, 2014 at 13:13:30 CET, Dis McCarthy wrote:
> > Thanks for the help!
> >
> > Unfortunately I don't have 7T to back up the devices. Is there a
> relatively
> > safe way to test? Worst case, I can make the change, set the entire
> device
> > ro and try, if dm-crypt can decrypt a readonly device.
>
> There is: Copy the first 100MB or so (needed are something like 2MiB, but
> better be on the safe side) and work on that via loopback file
> (see FAQ Item 2.5). When you can unlock that, you have then a good
> header that you can backup the header from the loopback device and
> install on the disk via luksHeaderBackup/luksHeaderRestore. Keep a
> copy of those first 100MB as backup on a separate device so you can
> restore it and can go back to the original state if anything goes
> wrong. This does protect your (at the moment broken, but nonetheless
> vital) headers from errors. Unlike a full backup, it does not protect
> your filesystem in the LUKS container(s), so be careful.
>
> If you are unsure, test disk operations first on a separate disk
> and see what they do to make sure you have it under control.
>
> You need to do that for each disk separately. If you cannot get an
> unlock, you can run the keyslot-checker on the loopback device
> as well and do further analysis there. All that LUKS needs is in
> the first 2MiB, see alos FAQ Item 6.12.
>
>
Those changes did result in a viewable/dumpable header, but it still won't
unlock.
Keyslot checker on both images returns:
parameters (commandline and LUKS header):
sector size: 512
threshold: 0.900000
- processing keyslot 0: start: 0x001000 end: 0x03f800
- processing keyslot 1: keyslot not in use
- processing keyslot 2: keyslot not in use
- processing keyslot 3: keyslot not in use
- processing keyslot 4: keyslot not in use
- processing keyslot 5: keyslot not in use
- processing keyslot 6: keyslot not in use
- processing keyslot 7: keyslot not in use
> > I did confirm farther down the header, the keys and empty slots appear
> to
> > be present.
>
> "Present" is not enough. "Undamaged" is what you need. But
> lets fix the missing bytes first and see where that gets
> you.
>
>
Definitely. Appearances can be deceiving. (And in this case, it looks like
they are.)
The complete/corrected headers are attached.
Thanks so much for helping!
> Arno
>
>
> > On Feb 25, 2014 11:11 PM, "Arno Wagner" <arno@wagner.name> wrote:
> > >
> > > This is pretty strange. You seem to have lost parts of the
> > > header, but not the hash spec. And it seems to have happened
> > > two times.
> > >
> > > This should not be happening at all. LUKS does not require a
> > > "clean shutdown", unless you luksFormat or change
> > > passphrases, cryptsetup does not write anything at all for
> > > LUKS and even ripping out the disk directly while it
> > > runs should not cause any header damage. (It may damage the
> > > filesystem in the LUKS container though...).
> > >
> > > What seems to have happened here is that some application
> > > read the header, replaced the first 0x2d bytes (leaving
> > > "ain64" of "xts-plain64". It seem to have put in a GUID
> > > of sorts. I have no idea what this is. The header was not
> > > simply overwritten, so this is something deliberately.
> > > On the other hand, no application should write anything to
> > > the start of a partition in normal operation.
> > >
> > > Maybe somebody else here recognizes the pattern seen?
> > > Maybe these are SSDs with a serious firmware bug?
> > > Or maybe you have wrap-around because the USB3 interface
> > > cannot handle the full disk size?
> > >
> > >
> > > As to recovery:
> > > 1. Make a sector-wise backup of the whole LUKS containers
> > > or whole disk(s) before messing with anything!
> > > 2. Just putting in what should be there in the first
> > > 0x2d bytes with a hex editor may be enough to get this
> > > working again if there is no other damage. If there
> > > is damage in the keyslot areas or to the salt values
> > > in the header, no recovery is possible.
> > >
> > > Hexediting the header is pretty simple, just read the
> > > first 1024 bytes (head -c 1024 /dev/disk > hdr.img),
> > > hexedit it and then write it back (cat hdr.img > /dev/disk).
> > > The risk of doing more damage is high, so do not try this
> > > without that backup.
> > >
> > > Here is what the first 0x2d bytes should look like (defaul
> > > parameters):
> > >
> > > 00000000 4c 55 4b 53 ba be 00 01 61 65 73 00 00 00 00 00
> > |LUKS....aes.....|
> > > 00000010 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
> > |................|
> > > 00000020 00 00 00 00 00 00 00 00 78 74 73 2d 70 6c 61 69
> > |........xts-plai|
> > >
> > > If after that cryptsetup works, but does not accept
> > > your passphrase, you can run the keyslot-checker from
> > > the source package and you can post the full headers
> > > (592 bytes long) here for more advice.
> > >
> > > Arno
> > >
> > >
> > >
> > >
> > >
> > > On Tue, Feb 25, 2014 at 15:33:20 CET, Dis McCarthy wrote:
> > > > I've got 2 full-device luks devices (usb3) that somehow got corrupted
> > > > headers at the same time. They were working, I powered down the
> system
> > to
> > > > move some plugs and when I brought it back up, my headers are
> > unrecognized.
> > > > (See below.) The system is a mac mini running arch linux. It has been
> > > > rebooted and powercycled repeatedly since being built and never had
> an
> > > > issue, so I hesitate to blame refit. The only thing I can see is that
> > there
> > > > was a recent update of cryptsetup (to 1.6.3-2). I'm not sure if the
> > devices
> > > > were stopped cleanly before reboot (probably not, since its arch..)
> but
> > the
> > > > volumes were unmounted and I wouldn't expect to get corruption.
> > > >
> > > > I'm dumb, and do not have a backup of the headers. (Well.. there
> might
> > be a
> > > > backup of one of them. Inside the encrypted volume.. yeah, like I
> said,
> > I'm
> > > > dumb. If I get this back, that is getting remedied immediately..)
> > > >
> > > > Comparing with other users, it looks like some of the entries are
> > swapped
> > > > around. I started doing a comparison to the on-disk format pdf, but I
> > > > haven't had a chance to print it out and get intimate with it yet
> > (beyond
> > > > noting that LUKS 0xba0xbe is missing of course.)
> > > >
> > > > Is there any hope? Here is what I've got at the beginning the drives:
> > > >
> > > > 00000000 00 00 00 00 48 00 00 00 00 00 00 00 32 32 30 64
> > > > |....H.......220d|
> > > > 00000010 32 30 33 64 2d 39 62 62 34 2d 34 35 00 00 00 00
> > > > |203d-9bb4-45....|
> > > > 00000020 24 00 00 00 12 00 00 00 24 00 00 00 00 00 61 69
> > > > |$.......$.....ai|
> > > > 00000030 6e 36 34 00 00 00 00 00 00 00 00 00 00 00 00 00
> > > > |n64.............|
> > > > 00000040 00 00 00 00 00 00 00 00 73 68 61 32 35 36 00 00
> > > > |........sha256..|
> > > > 00000050 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
> > > > |................|
> > > > 00000060 00 00 00 00 00 00 00 00 00 00 10 00 00 00 00 40
> > > > |...............@|
> > > > 00000070 da 22 00 00 00 00 24 01 00 00 00 00 00 00 00 00
> > > > |."....$.........|
> > > >
> > > > and:
> > > > 00000000 00 00 00 00 48 00 00 00 00 00 00 00 32 33 63 38
> > > > |....H.......23c8|
> > > > 00000010 62 61 33 31 2d 37 61 63 66 2d 34 32 00 00 00 00
> > > > |ba31-7acf-42....|
> > > > 00000020 24 00 00 00 12 00 00 00 24 00 00 00 00 00 61 69
> > > > |$.......$.....ai|
> > > > 00000030 6e 36 34 00 00 00 00 00 00 00 00 00 00 00 00 00
> > > > |n64.............|
> > > > 00000040 00 00 00 00 00 00 00 00 73 68 61 32 35 36 00 00
> > > > |........sha256..|
> > > > 00000050 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
> > > > |................|
> > > > 00000060 00 00 00 00 00 00 00 00 00 00 10 00 00 00 00 40
> > > > |...............@|
> > > > 00000070 de 8b 00 00 00 00 24 01 00 00 00 00 00 00 00 00
> > > > |......$.........|
> > > >
> > > > Thanks!
> > >
> > > > _______________________________________________
> > > > dm-crypt mailing list
> > > > dm-crypt@saout.de
> > > > http://www.saout.de/mailman/listinfo/dm-crypt
> > >
> > >
> > > --
> > > Arno Wagner, Dr. sc. techn., Dipl. Inform., Email:
> arno@wagner.name
> > > 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
> > > _______________________________________________
> > > dm-crypt mailing list
> > > dm-crypt@saout.de
> > > http://www.saout.de/mailman/listinfo/dm-crypt
>
> > _______________________________________________
> > dm-crypt mailing list
> > dm-crypt@saout.de
> > http://www.saout.de/mailman/listinfo/dm-crypt
>
>
> --
> Arno Wagner, Dr. sc. techn., Dipl. Inform., Email: arno@wagner.name
> 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
> _______________________________________________
> dm-crypt mailing list
> dm-crypt@saout.de
> http://www.saout.de/mailman/listinfo/dm-crypt
>
[-- Attachment #1.2: Type: text/html, Size: 12797 bytes --]
[-- Attachment #2: luksheader-sdc.txt --]
[-- Type: text/plain, Size: 3011 bytes --]
00000000 4c 55 4b 53 ba be 00 01 61 65 73 00 00 00 00 00 |LUKS....aes.....|
00000010 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................|
00000020 00 00 00 00 00 00 00 00 78 74 73 2d 70 6c 61 69 |........xts-plai|
00000030 6e 36 34 00 00 00 00 00 00 00 00 00 00 00 00 00 |n64.............|
00000040 00 00 00 00 00 00 00 00 73 68 61 32 35 36 00 00 |........sha256..|
00000050 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................|
00000060 00 00 00 00 00 00 00 00 00 00 10 00 00 00 00 40 |...............@|
00000070 de 8b 00 00 00 00 24 01 00 00 00 00 00 00 00 00 |......$.........|
00000080 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................|
00000090 00 00 00 01 00 00 12 01 c3 00 80 00 2f 21 68 a8 |............/!h.|
000000a0 39 c4 f1 5d 00 01 3e d9 32 33 63 38 62 61 33 31 |9..]..>.23c8ba31|
000000b0 2d 37 61 63 66 2d 34 32 65 31 2d 61 63 31 66 2d |-7acf-42e1-ac1f-|
000000c0 64 30 65 31 38 66 34 32 39 38 32 65 00 00 00 00 |d0e18f42982e....|
000000d0 00 ac 71 f3 00 05 02 0d cc 13 e4 7d 28 92 49 f1 |..q........}(.I.|
000000e0 ac 89 7a a3 75 32 4d db 27 18 2d e1 93 9e 97 82 |..z.u2M.'.-.....|
000000f0 90 a6 e0 e7 7a 28 8c 0f 00 00 00 08 00 00 0f a0 |....z(..........|
00000100 00 00 de ad 00 00 00 00 00 00 00 00 00 00 00 00 |................|
00000110 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................|
00000120 00 00 00 00 00 00 00 00 00 00 02 00 00 00 0f a0 |................|
00000130 00 00 de ad 00 00 00 00 00 00 00 00 00 00 00 00 |................|
00000140 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................|
00000150 00 00 00 00 00 00 00 00 00 00 03 f8 00 00 0f a0 |................|
00000160 00 00 de ad 00 00 00 00 00 00 00 00 00 00 00 00 |................|
00000170 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................|
00000180 00 00 00 00 00 00 00 00 00 00 05 f0 00 00 0f a0 |................|
00000190 00 00 de ad 00 00 00 00 00 00 00 00 00 00 00 00 |................|
000001a0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................|
000001b0 00 00 00 00 00 00 00 00 00 00 07 e8 00 00 0f a0 |................|
000001c0 00 00 de ad 00 00 00 00 00 00 00 00 00 00 00 00 |................|
000001d0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................|
000001e0 00 00 00 00 00 00 00 00 00 00 09 e0 00 00 0f a0 |................|
000001f0 00 00 de ad 00 00 00 00 00 00 00 00 00 00 00 00 |................|
00000200 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................|
00000210 00 00 00 00 00 00 00 00 00 00 0b d8 00 00 0f a0 |................|
00000220 00 00 de ad 00 00 00 00 00 00 00 00 00 00 00 00 |................|
00000230 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................|
00000240 00 00 00 00 00 00 00 00 00 00 0d d0 00 00 0f a0 |................|
00000250 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................|
00000260
[-- Attachment #3: luksheader-sdb.txt --]
[-- Type: text/plain, Size: 3011 bytes --]
00000000 4c 55 4b 53 ba be 00 01 61 65 73 00 00 00 00 00 |LUKS....aes.....|
00000010 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................|
00000020 00 00 00 00 00 00 00 00 78 74 73 2d 70 6c 61 69 |........xts-plai|
00000030 6e 36 34 00 00 00 00 00 00 00 00 00 00 00 00 00 |n64.............|
00000040 00 00 00 00 00 00 00 00 73 68 61 32 35 36 00 00 |........sha256..|
00000050 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................|
00000060 00 00 00 00 00 00 00 00 00 00 10 00 00 00 00 40 |...............@|
00000070 da 22 00 00 00 00 24 01 00 00 00 00 00 00 00 00 |."....$.........|
00000080 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................|
00000090 00 00 00 01 00 00 12 01 c3 00 80 00 79 a3 4c be |............y.L.|
000000a0 4e 8c bc 93 00 01 47 a3 32 32 30 64 33 30 33 64 |N.....G.220d303d|
000000b0 2d 39 62 62 34 2d 34 35 31 36 2d 38 38 39 65 2d |-9bb4-4516-889e-|
000000c0 63 39 34 32 39 63 31 33 38 37 36 66 00 00 00 00 |c9429c13876f....|
000000d0 00 ac 71 f3 00 05 41 e4 0a d5 d5 92 47 f4 61 eb |..q...A.....G.a.|
000000e0 38 e0 05 57 87 34 9b e0 52 30 c9 16 21 a8 39 19 |8..W.4..R0..!.9.|
000000f0 8b cc 09 20 a1 d0 a0 c4 00 00 00 08 00 00 0f a0 |... ............|
00000100 00 00 de ad 00 00 00 00 00 00 00 00 00 00 00 00 |................|
00000110 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................|
00000120 00 00 00 00 00 00 00 00 00 00 02 00 00 00 0f a0 |................|
00000130 00 00 de ad 00 00 00 00 00 00 00 00 00 00 00 00 |................|
00000140 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................|
00000150 00 00 00 00 00 00 00 00 00 00 03 f8 00 00 0f a0 |................|
00000160 00 00 de ad 00 00 00 00 00 00 00 00 00 00 00 00 |................|
00000170 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................|
00000180 00 00 00 00 00 00 00 00 00 00 05 f0 00 00 0f a0 |................|
00000190 00 00 de ad 00 00 00 00 00 00 00 00 00 00 00 00 |................|
000001a0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................|
000001b0 00 00 00 00 00 00 00 00 00 00 07 e8 00 00 0f a0 |................|
000001c0 00 00 de ad 00 00 00 00 00 00 00 00 00 00 00 00 |................|
000001d0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................|
000001e0 00 00 00 00 00 00 00 00 00 00 09 e0 00 00 0f a0 |................|
000001f0 00 00 de ad 00 00 00 00 00 00 00 00 00 00 00 00 |................|
00000200 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................|
00000210 00 00 00 00 00 00 00 00 00 00 0b d8 00 00 0f a0 |................|
00000220 00 00 de ad 00 00 00 00 00 00 00 00 00 00 00 00 |................|
00000230 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................|
00000240 00 00 00 00 00 00 00 00 00 00 0d d0 00 00 0f a0 |................|
00000250 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................|
00000260
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [dm-crypt] Strange header corruption
2014-02-26 15:24 ` Dis McCarthy
@ 2014-02-26 16:52 ` Arno Wagner
0 siblings, 0 replies; 6+ messages in thread
From: Arno Wagner @ 2014-02-26 16:52 UTC (permalink / raw)
To: dm-crypt
On Wed, Feb 26, 2014 at 16:24:38 CET, Dis McCarthy wrote:
[...]
> Those changes did result in a viewable/dumpable header, but it still won't
> unlock.
That means there must be damage to the keyslot or salts.
> Keyslot checker on both images returns:
> parameters (commandline and LUKS header):
> sector size: 512
> threshold: 0.900000
>
> - processing keyslot 0: start: 0x001000 end: 0x03f800
> - processing keyslot 1: keyslot not in use
> - processing keyslot 2: keyslot not in use
> - processing keyslot 3: keyslot not in use
> - processing keyslot 4: keyslot not in use
> - processing keyslot 5: keyslot not in use
> - processing keyslot 6: keyslot not in use
> - processing keyslot 7: keyslot not in use
So not obvious damage. There still could be damage though,
the method used requires something like 20 non-random bytes
to lock-on. (Cannot really be done much better in a generic
fashion.)
> > > I did confirm farther down the header, the keys and empty slots appear
> > to
> > > be present.
> >
> > "Present" is not enough. "Undamaged" is what you need. But
> > lets fix the missing bytes first and see where that gets
> > you.
> >
> >
> Definitely. Appearances can be deceiving. (And in this case, it looks like
> they are.)
>
> The complete/corrected headers are attached.
What I see here is that your mk-digest-salt (32 Bytes) is partially
zeroed and partially replaced with structured data:
00000080 00 00 00 00 00 00 00 00 00 00 00 00 |................|
00000090 00 00 00 01 00 00 12 01 c3 00 80 00 2f 21 68 a8 |............/!h.|
000000a0 39 c4 f1 5d |9..]..>.23c8ba31|
Before that, the mk-digest is also damaged/overwritten:
00000070 de 8b 00 00 00 00 24 01 00 00 00 00 00 00 00 00 |......$.........|
00000080 00 00 00 00
Basically, something wrote structured data to your LUKS headers,
with some areas unchanged.
I am sorry, but the mk-digest-salt is absolutely critical
for deriving the master key. This means your data is
irretrivably gone.
> Thanks so much for helping!
You are welcome!
Arno
>
> > Arno
> >
> >
> > > On Feb 25, 2014 11:11 PM, "Arno Wagner" <arno@wagner.name> wrote:
> > > >
> > > > This is pretty strange. You seem to have lost parts of the
> > > > header, but not the hash spec. And it seems to have happened
> > > > two times.
> > > >
> > > > This should not be happening at all. LUKS does not require a
> > > > "clean shutdown", unless you luksFormat or change
> > > > passphrases, cryptsetup does not write anything at all for
> > > > LUKS and even ripping out the disk directly while it
> > > > runs should not cause any header damage. (It may damage the
> > > > filesystem in the LUKS container though...).
> > > >
> > > > What seems to have happened here is that some application
> > > > read the header, replaced the first 0x2d bytes (leaving
> > > > "ain64" of "xts-plain64". It seem to have put in a GUID
> > > > of sorts. I have no idea what this is. The header was not
> > > > simply overwritten, so this is something deliberately.
> > > > On the other hand, no application should write anything to
> > > > the start of a partition in normal operation.
> > > >
> > > > Maybe somebody else here recognizes the pattern seen?
> > > > Maybe these are SSDs with a serious firmware bug?
> > > > Or maybe you have wrap-around because the USB3 interface
> > > > cannot handle the full disk size?
> > > >
> > > >
> > > > As to recovery:
> > > > 1. Make a sector-wise backup of the whole LUKS containers
> > > > or whole disk(s) before messing with anything!
> > > > 2. Just putting in what should be there in the first
> > > > 0x2d bytes with a hex editor may be enough to get this
> > > > working again if there is no other damage. If there
> > > > is damage in the keyslot areas or to the salt values
> > > > in the header, no recovery is possible.
> > > >
> > > > Hexediting the header is pretty simple, just read the
> > > > first 1024 bytes (head -c 1024 /dev/disk > hdr.img),
> > > > hexedit it and then write it back (cat hdr.img > /dev/disk).
> > > > The risk of doing more damage is high, so do not try this
> > > > without that backup.
> > > >
> > > > Here is what the first 0x2d bytes should look like (defaul
> > > > parameters):
> > > >
> > > > 00000000 4c 55 4b 53 ba be 00 01 61 65 73 00 00 00 00 00
> > > |LUKS....aes.....|
> > > > 00000010 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
> > > |................|
> > > > 00000020 00 00 00 00 00 00 00 00 78 74 73 2d 70 6c 61 69
> > > |........xts-plai|
> > > >
> > > > If after that cryptsetup works, but does not accept
> > > > your passphrase, you can run the keyslot-checker from
> > > > the source package and you can post the full headers
> > > > (592 bytes long) here for more advice.
> > > >
> > > > Arno
> > > >
> > > >
> > > >
> > > >
> > > >
> > > > On Tue, Feb 25, 2014 at 15:33:20 CET, Dis McCarthy wrote:
> > > > > I've got 2 full-device luks devices (usb3) that somehow got corrupted
> > > > > headers at the same time. They were working, I powered down the
> > system
> > > to
> > > > > move some plugs and when I brought it back up, my headers are
> > > unrecognized.
> > > > > (See below.) The system is a mac mini running arch linux. It has been
> > > > > rebooted and powercycled repeatedly since being built and never had
> > an
> > > > > issue, so I hesitate to blame refit. The only thing I can see is that
> > > there
> > > > > was a recent update of cryptsetup (to 1.6.3-2). I'm not sure if the
> > > devices
> > > > > were stopped cleanly before reboot (probably not, since its arch..)
> > but
> > > the
> > > > > volumes were unmounted and I wouldn't expect to get corruption.
> > > > >
> > > > > I'm dumb, and do not have a backup of the headers. (Well.. there
> > might
> > > be a
> > > > > backup of one of them. Inside the encrypted volume.. yeah, like I
> > said,
> > > I'm
> > > > > dumb. If I get this back, that is getting remedied immediately..)
> > > > >
> > > > > Comparing with other users, it looks like some of the entries are
> > > swapped
> > > > > around. I started doing a comparison to the on-disk format pdf, but I
> > > > > haven't had a chance to print it out and get intimate with it yet
> > > (beyond
> > > > > noting that LUKS 0xba0xbe is missing of course.)
> > > > >
> > > > > Is there any hope? Here is what I've got at the beginning the drives:
> > > > >
> > > > > 00000000 00 00 00 00 48 00 00 00 00 00 00 00 32 32 30 64
> > > > > |....H.......220d|
> > > > > 00000010 32 30 33 64 2d 39 62 62 34 2d 34 35 00 00 00 00
> > > > > |203d-9bb4-45....|
> > > > > 00000020 24 00 00 00 12 00 00 00 24 00 00 00 00 00 61 69
> > > > > |$.......$.....ai|
> > > > > 00000030 6e 36 34 00 00 00 00 00 00 00 00 00 00 00 00 00
> > > > > |n64.............|
> > > > > 00000040 00 00 00 00 00 00 00 00 73 68 61 32 35 36 00 00
> > > > > |........sha256..|
> > > > > 00000050 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
> > > > > |................|
> > > > > 00000060 00 00 00 00 00 00 00 00 00 00 10 00 00 00 00 40
> > > > > |...............@|
> > > > > 00000070 da 22 00 00 00 00 24 01 00 00 00 00 00 00 00 00
> > > > > |."....$.........|
> > > > >
> > > > > and:
> > > > > 00000000 00 00 00 00 48 00 00 00 00 00 00 00 32 33 63 38
> > > > > |....H.......23c8|
> > > > > 00000010 62 61 33 31 2d 37 61 63 66 2d 34 32 00 00 00 00
> > > > > |ba31-7acf-42....|
> > > > > 00000020 24 00 00 00 12 00 00 00 24 00 00 00 00 00 61 69
> > > > > |$.......$.....ai|
> > > > > 00000030 6e 36 34 00 00 00 00 00 00 00 00 00 00 00 00 00
> > > > > |n64.............|
> > > > > 00000040 00 00 00 00 00 00 00 00 73 68 61 32 35 36 00 00
> > > > > |........sha256..|
> > > > > 00000050 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
> > > > > |................|
> > > > > 00000060 00 00 00 00 00 00 00 00 00 00 10 00 00 00 00 40
> > > > > |...............@|
> > > > > 00000070 de 8b 00 00 00 00 24 01 00 00 00 00 00 00 00 00
> > > > > |......$.........|
> > > > >
> > > > > Thanks!
> > > >
> > > > > _______________________________________________
> > > > > dm-crypt mailing list
> > > > > dm-crypt@saout.de
> > > > > http://www.saout.de/mailman/listinfo/dm-crypt
> > > >
> > > >
> > > > --
> > > > Arno Wagner, Dr. sc. techn., Dipl. Inform., Email:
> > arno@wagner.name
> > > > 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
> > > > _______________________________________________
> > > > dm-crypt mailing list
> > > > dm-crypt@saout.de
> > > > http://www.saout.de/mailman/listinfo/dm-crypt
> >
> > > _______________________________________________
> > > dm-crypt mailing list
> > > dm-crypt@saout.de
> > > http://www.saout.de/mailman/listinfo/dm-crypt
> >
> >
> > --
> > Arno Wagner, Dr. sc. techn., Dipl. Inform., Email: arno@wagner.name
> > 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
> > _______________________________________________
> > dm-crypt mailing list
> > dm-crypt@saout.de
> > http://www.saout.de/mailman/listinfo/dm-crypt
> >
> 00000000 4c 55 4b 53 ba be 00 01 61 65 73 00 00 00 00 00 |LUKS....aes.....|
> 00000010 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................|
> 00000020 00 00 00 00 00 00 00 00 78 74 73 2d 70 6c 61 69 |........xts-plai|
> 00000030 6e 36 34 00 00 00 00 00 00 00 00 00 00 00 00 00 |n64.............|
> 00000040 00 00 00 00 00 00 00 00 73 68 61 32 35 36 00 00 |........sha256..|
> 00000050 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................|
> 00000060 00 00 00 00 00 00 00 00 00 00 10 00 00 00 00 40 |...............@|
> 00000070 de 8b 00 00 00 00 24 01 00 00 00 00 00 00 00 00 |......$.........|
> 00000080 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................|
> 00000090 00 00 00 01 00 00 12 01 c3 00 80 00 2f 21 68 a8 |............/!h.|
> 000000a0 39 c4 f1 5d 00 01 3e d9 32 33 63 38 62 61 33 31 |9..]..>.23c8ba31|
> 000000b0 2d 37 61 63 66 2d 34 32 65 31 2d 61 63 31 66 2d |-7acf-42e1-ac1f-|
> 000000c0 64 30 65 31 38 66 34 32 39 38 32 65 00 00 00 00 |d0e18f42982e....|
> 000000d0 00 ac 71 f3 00 05 02 0d cc 13 e4 7d 28 92 49 f1 |..q........}(.I.|
> 000000e0 ac 89 7a a3 75 32 4d db 27 18 2d e1 93 9e 97 82 |..z.u2M.'.-.....|
> 000000f0 90 a6 e0 e7 7a 28 8c 0f 00 00 00 08 00 00 0f a0 |....z(..........|
> 00000100 00 00 de ad 00 00 00 00 00 00 00 00 00 00 00 00 |................|
> 00000110 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................|
> 00000120 00 00 00 00 00 00 00 00 00 00 02 00 00 00 0f a0 |................|
> 00000130 00 00 de ad 00 00 00 00 00 00 00 00 00 00 00 00 |................|
> 00000140 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................|
> 00000150 00 00 00 00 00 00 00 00 00 00 03 f8 00 00 0f a0 |................|
> 00000160 00 00 de ad 00 00 00 00 00 00 00 00 00 00 00 00 |................|
> 00000170 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................|
> 00000180 00 00 00 00 00 00 00 00 00 00 05 f0 00 00 0f a0 |................|
> 00000190 00 00 de ad 00 00 00 00 00 00 00 00 00 00 00 00 |................|
> 000001a0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................|
> 000001b0 00 00 00 00 00 00 00 00 00 00 07 e8 00 00 0f a0 |................|
> 000001c0 00 00 de ad 00 00 00 00 00 00 00 00 00 00 00 00 |................|
> 000001d0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................|
> 000001e0 00 00 00 00 00 00 00 00 00 00 09 e0 00 00 0f a0 |................|
> 000001f0 00 00 de ad 00 00 00 00 00 00 00 00 00 00 00 00 |................|
> 00000200 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................|
> 00000210 00 00 00 00 00 00 00 00 00 00 0b d8 00 00 0f a0 |................|
> 00000220 00 00 de ad 00 00 00 00 00 00 00 00 00 00 00 00 |................|
> 00000230 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................|
> 00000240 00 00 00 00 00 00 00 00 00 00 0d d0 00 00 0f a0 |................|
> 00000250 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................|
> 00000260
> 00000000 4c 55 4b 53 ba be 00 01 61 65 73 00 00 00 00 00 |LUKS....aes.....|
> 00000010 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................|
> 00000020 00 00 00 00 00 00 00 00 78 74 73 2d 70 6c 61 69 |........xts-plai|
> 00000030 6e 36 34 00 00 00 00 00 00 00 00 00 00 00 00 00 |n64.............|
> 00000040 00 00 00 00 00 00 00 00 73 68 61 32 35 36 00 00 |........sha256..|
> 00000050 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................|
> 00000060 00 00 00 00 00 00 00 00 00 00 10 00 00 00 00 40 |...............@|
> 00000070 da 22 00 00 00 00 24 01 00 00 00 00 00 00 00 00 |."....$.........|
> 00000080 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................|
> 00000090 00 00 00 01 00 00 12 01 c3 00 80 00 79 a3 4c be |............y.L.|
> 000000a0 4e 8c bc 93 00 01 47 a3 32 32 30 64 33 30 33 64 |N.....G.220d303d|
> 000000b0 2d 39 62 62 34 2d 34 35 31 36 2d 38 38 39 65 2d |-9bb4-4516-889e-|
> 000000c0 63 39 34 32 39 63 31 33 38 37 36 66 00 00 00 00 |c9429c13876f....|
> 000000d0 00 ac 71 f3 00 05 41 e4 0a d5 d5 92 47 f4 61 eb |..q...A.....G.a.|
> 000000e0 38 e0 05 57 87 34 9b e0 52 30 c9 16 21 a8 39 19 |8..W.4..R0..!.9.|
> 000000f0 8b cc 09 20 a1 d0 a0 c4 00 00 00 08 00 00 0f a0 |... ............|
> 00000100 00 00 de ad 00 00 00 00 00 00 00 00 00 00 00 00 |................|
> 00000110 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................|
> 00000120 00 00 00 00 00 00 00 00 00 00 02 00 00 00 0f a0 |................|
> 00000130 00 00 de ad 00 00 00 00 00 00 00 00 00 00 00 00 |................|
> 00000140 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................|
> 00000150 00 00 00 00 00 00 00 00 00 00 03 f8 00 00 0f a0 |................|
> 00000160 00 00 de ad 00 00 00 00 00 00 00 00 00 00 00 00 |................|
> 00000170 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................|
> 00000180 00 00 00 00 00 00 00 00 00 00 05 f0 00 00 0f a0 |................|
> 00000190 00 00 de ad 00 00 00 00 00 00 00 00 00 00 00 00 |................|
> 000001a0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................|
> 000001b0 00 00 00 00 00 00 00 00 00 00 07 e8 00 00 0f a0 |................|
> 000001c0 00 00 de ad 00 00 00 00 00 00 00 00 00 00 00 00 |................|
> 000001d0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................|
> 000001e0 00 00 00 00 00 00 00 00 00 00 09 e0 00 00 0f a0 |................|
> 000001f0 00 00 de ad 00 00 00 00 00 00 00 00 00 00 00 00 |................|
> 00000200 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................|
> 00000210 00 00 00 00 00 00 00 00 00 00 0b d8 00 00 0f a0 |................|
> 00000220 00 00 de ad 00 00 00 00 00 00 00 00 00 00 00 00 |................|
> 00000230 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................|
> 00000240 00 00 00 00 00 00 00 00 00 00 0d d0 00 00 0f a0 |................|
> 00000250 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................|
> 00000260
> _______________________________________________
> dm-crypt mailing list
> dm-crypt@saout.de
> http://www.saout.de/mailman/listinfo/dm-crypt
--
Arno Wagner, Dr. sc. techn., Dipl. Inform., Email: arno@wagner.name
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
^ permalink raw reply [flat|nested] 6+ messages in thread
end of thread, other threads:[~2014-02-26 16:52 UTC | newest]
Thread overview: 6+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2014-02-25 14:33 [dm-crypt] Strange header corruption Dis McCarthy
2014-02-26 4:11 ` Arno Wagner
2014-02-26 12:13 ` Dis McCarthy
2014-02-26 12:49 ` Arno Wagner
2014-02-26 15:24 ` Dis McCarthy
2014-02-26 16:52 ` Arno Wagner
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.