From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-qa0-f52.google.com (mail-qa0-f52.google.com [209.85.216.52]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mail.saout.de (Postfix) with ESMTPS for ; Wed, 26 Feb 2014 16:25:01 +0100 (CET) Received: by mail-qa0-f52.google.com with SMTP id j15so2439243qaq.39 for ; Wed, 26 Feb 2014 07:25:00 -0800 (PST) MIME-Version: 1.0 Sender: dis@sigkill.net In-Reply-To: <20140226124939.GA26351@tansi.org> References: <20140226041120.GA21647@tansi.org> <20140226124939.GA26351@tansi.org> From: Dis McCarthy Date: Wed, 26 Feb 2014 10:24:38 -0500 Message-ID: Content-Type: multipart/mixed; boundary=001a113452e0d8afe404f350ce5c Subject: Re: [dm-crypt] Strange header corruption List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: dm-crypt@saout.de --001a113452e0d8afe404f350ce5c Content-Type: multipart/alternative; boundary=001a113452e0d8afe004f350ce5a --001a113452e0d8afe004f350ce5a Content-Type: text/plain; charset=ISO-8859-1 On Wed, Feb 26, 2014 at 7:49 AM, Arno Wagner 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" 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 > --001a113452e0d8afe004f350ce5a Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
On W= ed, Feb 26, 2014 at 7:49 AM, Arno Wagner <arno@wagner.name> w= rote:
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 t= here a relatively
> safe way to test? Worst case, I can make the change, set the entire de= vice
> 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 di= d result in a viewable/dumpable header, but it still won't unlock.

Keyslot checker on both images returns:
para= meters (commandline and LUKS header):
=A0 sector size: 512
=A0 threshold: =A0 0.900000
<= br>
- processing keyslot 0: =A0start: 0x001000 =A0 end: 0x03f800= =A0
- processing keyslot 1: =A0keyslot not in use
- pro= cessing keyslot 2: =A0keyslot not in use
- processing keyslot 3: =A0keyslot not in use
- processing k= eyslot 4: =A0keyslot not in use
- processing keyslot 5: =A0keyslo= t not in use
- processing keyslot 6: =A0keyslot not in use
<= div> - processing keyslot 7: =A0keyslot not in use

=A0<= br>
> 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 cas= e, it looks like they are.)

The complete/corrected= headers are attached.

Thanks so much for helping!
=A0
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
> > =A0 =A0or whole disk(s) before messing with anything!
> > 2. Just putting in what should be there in the first
> > =A0 =A00x2d bytes with a hex editor may be enough to get this
> > =A0 =A0working again if there is no other damage. If there
> > =A0 =A0is damage in the keyslot areas or to the salt values
> > =A0 =A0in 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 =A04c 55 4b 53 ba be 00 01 =A061 65 73 00 00 00 00 00 > |LUKS....aes.....|
> > 00000010 =A000 00 00 00 00 00 00 00 =A000 00 00 00 00 00 00 00 > |................|
> > 00000020 =A000 00 00 00 00 00 00 00 =A078 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 ar= e
> unrecognized.
> > > (See below.) The system is a mac mini running arch linux. It= has been
> > > rebooted and powercycled repeatedly since being built and ne= ver had an
> > > issue, so I hesitate to blame refit. The only thing I can se= e 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 corr= uption.
> > >
> > > 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, l= ike I said,
> I'm
> > > dumb. If I get this back, that is getting remedied immediate= ly..)
> > >
> > > Comparing with other users, it looks like some of the entrie= s are
> swapped
> > > around. I started doing a comparison to the on-disk format p= df, but I
> > > haven't had a chance to print it out and get intimate wi= th it yet
> (beyond
> > > noting that LUKS 0xba0xbe is missing of course.)
> > >
> > > Is there any hope? Here is what I've got at the beginnin= g the drives:
> > >
> > > 00000000 =A000 00 00 00 48 00 00 00 =A000 00 00 00 32 32 30 = 64
> > > =A0|....H.......220d|
> > > 00000010 =A032 30 33 64 2d 39 62 62 =A034 2d 34 35 00 00 00 = 00
> > > =A0|203d-9bb4-45....|
> > > 00000020 =A024 00 00 00 12 00 00 00 =A024 00 00 00 00 00 61 = 69
> > > =A0|$.......$.....ai|
> > > 00000030 =A06e 36 34 00 00 00 00 00 =A000 00 00 00 00 00 00 = 00
> > > =A0|n64.............|
> > > 00000040 =A000 00 00 00 00 00 00 00 =A073 68 61 32 35 36 00 = 00
> > > =A0|........sha256..|
> > > 00000050 =A000 00 00 00 00 00 00 00 =A000 00 00 00 00 00 00 = 00
> > > =A0|................|
> > > 00000060 =A000 00 00 00 00 00 00 00 =A000 00 10 00 00 00 00 = 40
> > > =A0|...............@|
> > > 00000070 =A0da 22 00 00 00 00 24 01 =A000 00 00 00 00 00 00 = 00
> > > =A0|."....$.........|
> > >
> > > and:
> > > 00000000 =A000 00 00 00 48 00 00 00 =A000 00 00 00 32 33 63 = 38
> > > =A0|....H.......23c8|
> > > 00000010 =A062 61 33 31 2d 37 61 63 =A066 2d 34 32 00 00 00 = 00
> > > =A0|ba31-7acf-42....|
> > > 00000020 =A024 00 00 00 12 00 00 00 =A024 00 00 00 00 00 61 = 69
> > > =A0|$.......$.....ai|
> > > 00000030 =A06e 36 34 00 00 00 00 00 =A000 00 00 00 00 00 00 = 00
> > > =A0|n64.............|
> > > 00000040 =A000 00 00 00 00 00 00 00 =A073 68 61 32 35 36 00 = 00
> > > =A0|........sha256..|
> > > 00000050 =A000 00 00 00 00 00 00 00 =A000 00 00 00 00 00 00 = 00
> > > =A0|................|
> > > 00000060 =A000 00 00 00 00 00 00 00 =A000 00 10 00 00 00 00 = 40
> > > =A0|...............@|
> > > 00000070 =A0de 8b 00 00 00 00 24 01 =A000 00 00 00 00 00 00 = 00
> > > =A0|......$.........|
> > >
> > > Thanks!
> >
> > > _______________________________________________
> > > dm-crypt mailing list
> > > dm-crypt@saout.de > > > http://www.saout.de/mailman/listinfo/dm-crypt
> >
> >
> > --
> > Arno Wagner, =A0 =A0 Dr. sc. techn., Dipl. Inform., =A0 =A0Email:= arno@wagner.name
> > GnuPG: ID: CB5D9718 =A0FP: 12D6 C03B 1B30 33BB 13CF =A0B774 E35C = 5FA1 CB5D
> 9718
> > ----
> > A good decision is based on knowledge and not on numbers. - =A0Pl= ato
> > _______________________________________________
> > 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, =A0 =A0 Dr. sc. techn., Dipl. Inform., =A0 =A0Email: arno@wagner.name
GnuPG: ID: CB5D9718 =A0FP: 12D6 C03B 1B30 33BB 13CF =A0B774 E35C 5FA1 CB5D = 9718
----
A good decision is based on knowledge and not on numbers. - =A0Plato
_______________________________________________
dm-crypt mailing list
dm-crypt@saout.de
http://www.saout.de/mailman/listinfo/dm-crypt

--001a113452e0d8afe004f350ce5a-- --001a113452e0d8afe404f350ce5c Content-Type: text/plain; charset=US-ASCII; name="luksheader-sdc.txt" Content-Disposition: attachment; filename="luksheader-sdc.txt" Content-Transfer-Encoding: base64 X-Attachment-Id: f_hs4qv3ug0 MDAwMDAwMDAgIDRjIDU1IDRiIDUzIGJhIGJlIDAwIDAxICA2MSA2NSA3MyAwMCAwMCAwMCAwMCAw MCAgfExVS1MuLi4uYWVzLi4uLi58CjAwMDAwMDEwICAwMCAwMCAwMCAwMCAwMCAwMCAwMCAwMCAg MDAgMDAgMDAgMDAgMDAgMDAgMDAgMDAgIHwuLi4uLi4uLi4uLi4uLi4ufAowMDAwMDAyMCAgMDAg MDAgMDAgMDAgMDAgMDAgMDAgMDAgIDc4IDc0IDczIDJkIDcwIDZjIDYxIDY5ICB8Li4uLi4uLi54 dHMtcGxhaXwKMDAwMDAwMzAgIDZlIDM2IDM0IDAwIDAwIDAwIDAwIDAwICAwMCAwMCAwMCAwMCAw MCAwMCAwMCAwMCAgfG42NC4uLi4uLi4uLi4uLi58CjAwMDAwMDQwICAwMCAwMCAwMCAwMCAwMCAw MCAwMCAwMCAgNzMgNjggNjEgMzIgMzUgMzYgMDAgMDAgIHwuLi4uLi4uLnNoYTI1Ni4ufAowMDAw MDA1MCAgMDAgMDAgMDAgMDAgMDAgMDAgMDAgMDAgIDAwIDAwIDAwIDAwIDAwIDAwIDAwIDAwICB8 Li4uLi4uLi4uLi4uLi4uLnwKMDAwMDAwNjAgIDAwIDAwIDAwIDAwIDAwIDAwIDAwIDAwICAwMCAw MCAxMCAwMCAwMCAwMCAwMCA0MCAgfC4uLi4uLi4uLi4uLi4uLkB8CjAwMDAwMDcwICBkZSA4YiAw MCAwMCAwMCAwMCAyNCAwMSAgMDAgMDAgMDAgMDAgMDAgMDAgMDAgMDAgIHwuLi4uLi4kLi4uLi4u Li4ufAowMDAwMDA4MCAgMDAgMDAgMDAgMDAgMDAgMDAgMDAgMDAgIDAwIDAwIDAwIDAwIDAwIDAw IDAwIDAwICB8Li4uLi4uLi4uLi4uLi4uLnwKMDAwMDAwOTAgIDAwIDAwIDAwIDAxIDAwIDAwIDEy IDAxICBjMyAwMCA4MCAwMCAyZiAyMSA2OCBhOCAgfC4uLi4uLi4uLi4uLi8haC58CjAwMDAwMGEw ICAzOSBjNCBmMSA1ZCAwMCAwMSAzZSBkOSAgMzIgMzMgNjMgMzggNjIgNjEgMzMgMzEgIHw5Li5d Li4+LjIzYzhiYTMxfAowMDAwMDBiMCAgMmQgMzcgNjEgNjMgNjYgMmQgMzQgMzIgIDY1IDMxIDJk IDYxIDYzIDMxIDY2IDJkICB8LTdhY2YtNDJlMS1hYzFmLXwKMDAwMDAwYzAgIDY0IDMwIDY1IDMx IDM4IDY2IDM0IDMyICAzOSAzOCAzMiA2NSAwMCAwMCAwMCAwMCAgfGQwZTE4ZjQyOTgyZS4uLi58 CjAwMDAwMGQwICAwMCBhYyA3MSBmMyAwMCAwNSAwMiAwZCAgY2MgMTMgZTQgN2QgMjggOTIgNDkg ZjEgIHwuLnEuLi4uLi4uLn0oLkkufAowMDAwMDBlMCAgYWMgODkgN2EgYTMgNzUgMzIgNGQgZGIg IDI3IDE4IDJkIGUxIDkzIDllIDk3IDgyICB8Li56LnUyTS4nLi0uLi4uLnwKMDAwMDAwZjAgIDkw IGE2IGUwIGU3IDdhIDI4IDhjIDBmICAwMCAwMCAwMCAwOCAwMCAwMCAwZiBhMCAgfC4uLi56KC4u Li4uLi4uLi58CjAwMDAwMTAwICAwMCAwMCBkZSBhZCAwMCAwMCAwMCAwMCAgMDAgMDAgMDAgMDAg MDAgMDAgMDAgMDAgIHwuLi4uLi4uLi4uLi4uLi4ufAowMDAwMDExMCAgMDAgMDAgMDAgMDAgMDAg MDAgMDAgMDAgIDAwIDAwIDAwIDAwIDAwIDAwIDAwIDAwICB8Li4uLi4uLi4uLi4uLi4uLnwKMDAw MDAxMjAgIDAwIDAwIDAwIDAwIDAwIDAwIDAwIDAwICAwMCAwMCAwMiAwMCAwMCAwMCAwZiBhMCAg fC4uLi4uLi4uLi4uLi4uLi58CjAwMDAwMTMwICAwMCAwMCBkZSBhZCAwMCAwMCAwMCAwMCAgMDAg MDAgMDAgMDAgMDAgMDAgMDAgMDAgIHwuLi4uLi4uLi4uLi4uLi4ufAowMDAwMDE0MCAgMDAgMDAg MDAgMDAgMDAgMDAgMDAgMDAgIDAwIDAwIDAwIDAwIDAwIDAwIDAwIDAwICB8Li4uLi4uLi4uLi4u Li4uLnwKMDAwMDAxNTAgIDAwIDAwIDAwIDAwIDAwIDAwIDAwIDAwICAwMCAwMCAwMyBmOCAwMCAw MCAwZiBhMCAgfC4uLi4uLi4uLi4uLi4uLi58CjAwMDAwMTYwICAwMCAwMCBkZSBhZCAwMCAwMCAw MCAwMCAgMDAgMDAgMDAgMDAgMDAgMDAgMDAgMDAgIHwuLi4uLi4uLi4uLi4uLi4ufAowMDAwMDE3 MCAgMDAgMDAgMDAgMDAgMDAgMDAgMDAgMDAgIDAwIDAwIDAwIDAwIDAwIDAwIDAwIDAwICB8Li4u Li4uLi4uLi4uLi4uLnwKMDAwMDAxODAgIDAwIDAwIDAwIDAwIDAwIDAwIDAwIDAwICAwMCAwMCAw NSBmMCAwMCAwMCAwZiBhMCAgfC4uLi4uLi4uLi4uLi4uLi58CjAwMDAwMTkwICAwMCAwMCBkZSBh ZCAwMCAwMCAwMCAwMCAgMDAgMDAgMDAgMDAgMDAgMDAgMDAgMDAgIHwuLi4uLi4uLi4uLi4uLi4u fAowMDAwMDFhMCAgMDAgMDAgMDAgMDAgMDAgMDAgMDAgMDAgIDAwIDAwIDAwIDAwIDAwIDAwIDAw IDAwICB8Li4uLi4uLi4uLi4uLi4uLnwKMDAwMDAxYjAgIDAwIDAwIDAwIDAwIDAwIDAwIDAwIDAw ICAwMCAwMCAwNyBlOCAwMCAwMCAwZiBhMCAgfC4uLi4uLi4uLi4uLi4uLi58CjAwMDAwMWMwICAw MCAwMCBkZSBhZCAwMCAwMCAwMCAwMCAgMDAgMDAgMDAgMDAgMDAgMDAgMDAgMDAgIHwuLi4uLi4u Li4uLi4uLi4ufAowMDAwMDFkMCAgMDAgMDAgMDAgMDAgMDAgMDAgMDAgMDAgIDAwIDAwIDAwIDAw IDAwIDAwIDAwIDAwICB8Li4uLi4uLi4uLi4uLi4uLnwKMDAwMDAxZTAgIDAwIDAwIDAwIDAwIDAw IDAwIDAwIDAwICAwMCAwMCAwOSBlMCAwMCAwMCAwZiBhMCAgfC4uLi4uLi4uLi4uLi4uLi58CjAw MDAwMWYwICAwMCAwMCBkZSBhZCAwMCAwMCAwMCAwMCAgMDAgMDAgMDAgMDAgMDAgMDAgMDAgMDAg IHwuLi4uLi4uLi4uLi4uLi4ufAowMDAwMDIwMCAgMDAgMDAgMDAgMDAgMDAgMDAgMDAgMDAgIDAw IDAwIDAwIDAwIDAwIDAwIDAwIDAwICB8Li4uLi4uLi4uLi4uLi4uLnwKMDAwMDAyMTAgIDAwIDAw IDAwIDAwIDAwIDAwIDAwIDAwICAwMCAwMCAwYiBkOCAwMCAwMCAwZiBhMCAgfC4uLi4uLi4uLi4u Li4uLi58CjAwMDAwMjIwICAwMCAwMCBkZSBhZCAwMCAwMCAwMCAwMCAgMDAgMDAgMDAgMDAgMDAg MDAgMDAgMDAgIHwuLi4uLi4uLi4uLi4uLi4ufAowMDAwMDIzMCAgMDAgMDAgMDAgMDAgMDAgMDAg MDAgMDAgIDAwIDAwIDAwIDAwIDAwIDAwIDAwIDAwICB8Li4uLi4uLi4uLi4uLi4uLnwKMDAwMDAy NDAgIDAwIDAwIDAwIDAwIDAwIDAwIDAwIDAwICAwMCAwMCAwZCBkMCAwMCAwMCAwZiBhMCAgfC4u Li4uLi4uLi4uLi4uLi58CjAwMDAwMjUwICAwMCAwMCAwMCAwMCAwMCAwMCAwMCAwMCAgMDAgMDAg MDAgMDAgMDAgMDAgMDAgMDAgIHwuLi4uLi4uLi4uLi4uLi4ufAowMDAwMDI2MAo= --001a113452e0d8afe404f350ce5c Content-Type: text/plain; charset=US-ASCII; name="luksheader-sdb.txt" Content-Disposition: attachment; filename="luksheader-sdb.txt" Content-Transfer-Encoding: base64 X-Attachment-Id: f_hs4qv3uq1 MDAwMDAwMDAgIDRjIDU1IDRiIDUzIGJhIGJlIDAwIDAxICA2MSA2NSA3MyAwMCAwMCAwMCAwMCAw MCAgfExVS1MuLi4uYWVzLi4uLi58CjAwMDAwMDEwICAwMCAwMCAwMCAwMCAwMCAwMCAwMCAwMCAg MDAgMDAgMDAgMDAgMDAgMDAgMDAgMDAgIHwuLi4uLi4uLi4uLi4uLi4ufAowMDAwMDAyMCAgMDAg MDAgMDAgMDAgMDAgMDAgMDAgMDAgIDc4IDc0IDczIDJkIDcwIDZjIDYxIDY5ICB8Li4uLi4uLi54 dHMtcGxhaXwKMDAwMDAwMzAgIDZlIDM2IDM0IDAwIDAwIDAwIDAwIDAwICAwMCAwMCAwMCAwMCAw MCAwMCAwMCAwMCAgfG42NC4uLi4uLi4uLi4uLi58CjAwMDAwMDQwICAwMCAwMCAwMCAwMCAwMCAw MCAwMCAwMCAgNzMgNjggNjEgMzIgMzUgMzYgMDAgMDAgIHwuLi4uLi4uLnNoYTI1Ni4ufAowMDAw MDA1MCAgMDAgMDAgMDAgMDAgMDAgMDAgMDAgMDAgIDAwIDAwIDAwIDAwIDAwIDAwIDAwIDAwICB8 Li4uLi4uLi4uLi4uLi4uLnwKMDAwMDAwNjAgIDAwIDAwIDAwIDAwIDAwIDAwIDAwIDAwICAwMCAw MCAxMCAwMCAwMCAwMCAwMCA0MCAgfC4uLi4uLi4uLi4uLi4uLkB8CjAwMDAwMDcwICBkYSAyMiAw MCAwMCAwMCAwMCAyNCAwMSAgMDAgMDAgMDAgMDAgMDAgMDAgMDAgMDAgIHwuIi4uLi4kLi4uLi4u Li4ufAowMDAwMDA4MCAgMDAgMDAgMDAgMDAgMDAgMDAgMDAgMDAgIDAwIDAwIDAwIDAwIDAwIDAw IDAwIDAwICB8Li4uLi4uLi4uLi4uLi4uLnwKMDAwMDAwOTAgIDAwIDAwIDAwIDAxIDAwIDAwIDEy IDAxICBjMyAwMCA4MCAwMCA3OSBhMyA0YyBiZSAgfC4uLi4uLi4uLi4uLnkuTC58CjAwMDAwMGEw ICA0ZSA4YyBiYyA5MyAwMCAwMSA0NyBhMyAgMzIgMzIgMzAgNjQgMzMgMzAgMzMgNjQgIHxOLi4u Li5HLjIyMGQzMDNkfAowMDAwMDBiMCAgMmQgMzkgNjIgNjIgMzQgMmQgMzQgMzUgIDMxIDM2IDJk IDM4IDM4IDM5IDY1IDJkICB8LTliYjQtNDUxNi04ODllLXwKMDAwMDAwYzAgIDYzIDM5IDM0IDMy IDM5IDYzIDMxIDMzICAzOCAzNyAzNiA2NiAwMCAwMCAwMCAwMCAgfGM5NDI5YzEzODc2Zi4uLi58 CjAwMDAwMGQwICAwMCBhYyA3MSBmMyAwMCAwNSA0MSBlNCAgMGEgZDUgZDUgOTIgNDcgZjQgNjEg ZWIgIHwuLnEuLi5BLi4uLi5HLmEufAowMDAwMDBlMCAgMzggZTAgMDUgNTcgODcgMzQgOWIgZTAg IDUyIDMwIGM5IDE2IDIxIGE4IDM5IDE5ICB8OC4uVy40Li5SMC4uIS45LnwKMDAwMDAwZjAgIDhi IGNjIDA5IDIwIGExIGQwIGEwIGM0ICAwMCAwMCAwMCAwOCAwMCAwMCAwZiBhMCAgfC4uLiAuLi4u Li4uLi4uLi58CjAwMDAwMTAwICAwMCAwMCBkZSBhZCAwMCAwMCAwMCAwMCAgMDAgMDAgMDAgMDAg MDAgMDAgMDAgMDAgIHwuLi4uLi4uLi4uLi4uLi4ufAowMDAwMDExMCAgMDAgMDAgMDAgMDAgMDAg MDAgMDAgMDAgIDAwIDAwIDAwIDAwIDAwIDAwIDAwIDAwICB8Li4uLi4uLi4uLi4uLi4uLnwKMDAw MDAxMjAgIDAwIDAwIDAwIDAwIDAwIDAwIDAwIDAwICAwMCAwMCAwMiAwMCAwMCAwMCAwZiBhMCAg fC4uLi4uLi4uLi4uLi4uLi58CjAwMDAwMTMwICAwMCAwMCBkZSBhZCAwMCAwMCAwMCAwMCAgMDAg MDAgMDAgMDAgMDAgMDAgMDAgMDAgIHwuLi4uLi4uLi4uLi4uLi4ufAowMDAwMDE0MCAgMDAgMDAg MDAgMDAgMDAgMDAgMDAgMDAgIDAwIDAwIDAwIDAwIDAwIDAwIDAwIDAwICB8Li4uLi4uLi4uLi4u Li4uLnwKMDAwMDAxNTAgIDAwIDAwIDAwIDAwIDAwIDAwIDAwIDAwICAwMCAwMCAwMyBmOCAwMCAw MCAwZiBhMCAgfC4uLi4uLi4uLi4uLi4uLi58CjAwMDAwMTYwICAwMCAwMCBkZSBhZCAwMCAwMCAw MCAwMCAgMDAgMDAgMDAgMDAgMDAgMDAgMDAgMDAgIHwuLi4uLi4uLi4uLi4uLi4ufAowMDAwMDE3 MCAgMDAgMDAgMDAgMDAgMDAgMDAgMDAgMDAgIDAwIDAwIDAwIDAwIDAwIDAwIDAwIDAwICB8Li4u Li4uLi4uLi4uLi4uLnwKMDAwMDAxODAgIDAwIDAwIDAwIDAwIDAwIDAwIDAwIDAwICAwMCAwMCAw NSBmMCAwMCAwMCAwZiBhMCAgfC4uLi4uLi4uLi4uLi4uLi58CjAwMDAwMTkwICAwMCAwMCBkZSBh ZCAwMCAwMCAwMCAwMCAgMDAgMDAgMDAgMDAgMDAgMDAgMDAgMDAgIHwuLi4uLi4uLi4uLi4uLi4u fAowMDAwMDFhMCAgMDAgMDAgMDAgMDAgMDAgMDAgMDAgMDAgIDAwIDAwIDAwIDAwIDAwIDAwIDAw IDAwICB8Li4uLi4uLi4uLi4uLi4uLnwKMDAwMDAxYjAgIDAwIDAwIDAwIDAwIDAwIDAwIDAwIDAw ICAwMCAwMCAwNyBlOCAwMCAwMCAwZiBhMCAgfC4uLi4uLi4uLi4uLi4uLi58CjAwMDAwMWMwICAw MCAwMCBkZSBhZCAwMCAwMCAwMCAwMCAgMDAgMDAgMDAgMDAgMDAgMDAgMDAgMDAgIHwuLi4uLi4u Li4uLi4uLi4ufAowMDAwMDFkMCAgMDAgMDAgMDAgMDAgMDAgMDAgMDAgMDAgIDAwIDAwIDAwIDAw IDAwIDAwIDAwIDAwICB8Li4uLi4uLi4uLi4uLi4uLnwKMDAwMDAxZTAgIDAwIDAwIDAwIDAwIDAw IDAwIDAwIDAwICAwMCAwMCAwOSBlMCAwMCAwMCAwZiBhMCAgfC4uLi4uLi4uLi4uLi4uLi58CjAw MDAwMWYwICAwMCAwMCBkZSBhZCAwMCAwMCAwMCAwMCAgMDAgMDAgMDAgMDAgMDAgMDAgMDAgMDAg IHwuLi4uLi4uLi4uLi4uLi4ufAowMDAwMDIwMCAgMDAgMDAgMDAgMDAgMDAgMDAgMDAgMDAgIDAw IDAwIDAwIDAwIDAwIDAwIDAwIDAwICB8Li4uLi4uLi4uLi4uLi4uLnwKMDAwMDAyMTAgIDAwIDAw IDAwIDAwIDAwIDAwIDAwIDAwICAwMCAwMCAwYiBkOCAwMCAwMCAwZiBhMCAgfC4uLi4uLi4uLi4u Li4uLi58CjAwMDAwMjIwICAwMCAwMCBkZSBhZCAwMCAwMCAwMCAwMCAgMDAgMDAgMDAgMDAgMDAg MDAgMDAgMDAgIHwuLi4uLi4uLi4uLi4uLi4ufAowMDAwMDIzMCAgMDAgMDAgMDAgMDAgMDAgMDAg MDAgMDAgIDAwIDAwIDAwIDAwIDAwIDAwIDAwIDAwICB8Li4uLi4uLi4uLi4uLi4uLnwKMDAwMDAy NDAgIDAwIDAwIDAwIDAwIDAwIDAwIDAwIDAwICAwMCAwMCAwZCBkMCAwMCAwMCAwZiBhMCAgfC4u Li4uLi4uLi4uLi4uLi58CjAwMDAwMjUwICAwMCAwMCAwMCAwMCAwMCAwMCAwMCAwMCAgMDAgMDAg MDAgMDAgMDAgMDAgMDAgMDAgIHwuLi4uLi4uLi4uLi4uLi4ufAowMDAwMDI2MAo= --001a113452e0d8afe404f350ce5c--