* Re: [dm-crypt] yet another header reconstruction question
[not found] <mailman.1.1455706801.5962.dm-crypt@saout.de>
@ 2016-02-18 8:51 ` Florian Dotzer
2016-02-18 9:34 ` Michael Kjörling
2016-02-18 12:53 ` Robert Nichols
0 siblings, 2 replies; 12+ messages in thread
From: Florian Dotzer @ 2016-02-18 8:51 UTC (permalink / raw)
To: dm-crypt
[-- Attachment #1: Type: text/html, Size: 3805 bytes --]
^ permalink raw reply [flat|nested] 12+ messages in thread* Re: [dm-crypt] yet another header reconstruction question
2016-02-18 8:51 ` [dm-crypt] yet another header reconstruction question Florian Dotzer
@ 2016-02-18 9:34 ` Michael Kjörling
2016-02-18 10:26 ` Sven Eschenberg
2016-02-18 12:53 ` Robert Nichols
1 sibling, 1 reply; 12+ messages in thread
From: Michael Kjörling @ 2016-02-18 9:34 UTC (permalink / raw)
To: dm-crypt
On 18 Feb 2016 09:51 +0100, from florian.dotzer@web.de (Florian Dotzer):
> <html><head></head><body><div style="font-family: Verdana;font-size: 12.0px;"><div><br/>
Please resend as not HTML.
> @Michael , Arno , Sven :<br/>
> <br/>
> Thanks for your replies and the help you are offering . Thats real support compared to experience with QNAP support ;-))<br/>
> I *can* login as root to the QNAP box - but I am not a shell guru .<br/>
> I hope I will be able to unlock my LUKS Copntainer without losing my Data .<br/>
> <br/>
> I used the graphical GUI of QNAP which offered this possibility to add a disk to an existing RAID ,<br/>
> e.g. I clicked a Button named "Add hard drive" in the RAID Management Section ,<br/>
> selected the newly added disk, and waited for the desaster to complete<br/>
> <br/>
> (german slang : mausi klickibunti ) .<br/>
> <br/>
> Somehow the command output was written to the Device and not elsewhere (/dev / null or shell )<br/>
> <br/>
> Michael wrote :<br/>
> > What was the exact device layout?<br/>
> > Physical storage then MD RAID<br/>
> Yes. I have the box not at my desk here. Sorry.<br/>
> <br/>
> > then LUKS<br/>
> At least I found a corrupted LUKSHeader there in /dev/md0<br/>
> <br/>
> > then some file system,<br/>
> I hope so , thats where my data lives .<br/>
> <br/>
> YESS Sir<br/>
> <br/>
> > or physical storage then LUKS then MD RAID<br/>
> >then some file system, or some other arrangement?<br/>
> No<br/>
> <br/>
> >What was the exact command used to "add a disk"?<br/>
> QNAP may know it , I not. I didnt find anything in dmesg / kernel log or elsewhere .<br/>
> <br/>
> From the best of my limited knowledge as I interpret the findings when I login as root in the cli ,<br/>
> I see the RAID created with mdadm as built dirctly on the disk partitions sd[d|e|f|g|h|c]3<br/>
> <br/>
> where /dev/sdc is the disk I added .<br/>
> the raid itself is up with all disks , (all disks 'U' ) , valid / valid superblock<br/>
> I can get and read data from the block device /dev/md0<br/>
> as you have seen in my last email.<br/>
> <br/>
> <br/>
> <br/>
> @ Arno :<br/>
> <br/>
> > What did you do?<br/>
> > Did you pipe the output from mdadm into /dev/md0?<br/>
> No.<br/>
> > If so, there might be a chance to recover this.<br/>
> <br/>
> > First, make that header backup now, if you have not already.<br/>
> <br/>
> I have at least the first 64 MB of /dev/md0 extracted with dd if=/dev/md0 of=of=file_with_first_64_MB_of_md0 bs=1024 count=65535<br/>
> The hex Dump was extracted from this .<br/>
> I hope that is enough for a header backup (approx. 2MiB + xxx as stated in the FAQ) ?<br/>
> <br/>
> > The data that is missing depends on the QNAP device.<br/>
> SS839 PRO<br/>
> > Defaults can be changed on compile.<br/>
> I only have binaries , no sources , no compiler<br/>
> > Easiest option is<br/>
> > likely to make a new LUKS container on it and try what<br/>
> > is in there. You should be able to use the loop-device<br/>
> > procedure from FAQ Item 2.6 from the commandline for<br/>
> > that. If those values do not work, next option is to<br/>
> > have the QNAP create a LUKS container on a new disk<br/>
> > and see what it does.<br/>
> <br/>
> I'll try it that weekend or next when I have time to do it .<br/>
> <br/>
> <br/>
> @Sven :<br/>
> <br/>
> >btw: I agree, if just the short output of mdadm was written to the disk<br/>
> >chances are quite good for recovery.<br/>
> <br/>
> I hope so. I tried dd on files to replace the first 512 bytes of a file , but<br/>
> the target file was completely replaced with this command :<br/>
> <br/>
> dd if=512_bytes_with_fixed_header of=file_with_first_64_MB_of_md0 bs=512 count=1<br/>
> <br/>
> Now I dont know if dd's behaviour is different on block device level ,<br/>
> or is there another better way to replace / correct the first bytes of /dev/md0 ?<br/>
> <br/>
> <br/>
> Greetings , Florian<br/>
> </div></div></body></html>
--
Michael Kjörling • https://michael.kjorling.se • michael@kjorling.se
“People who think they know everything really annoy
those of us who know we don’t.” (Bjarne Stroustrup)
^ permalink raw reply [flat|nested] 12+ messages in thread* Re: [dm-crypt] yet another header reconstruction question
2016-02-18 9:34 ` Michael Kjörling
@ 2016-02-18 10:26 ` Sven Eschenberg
0 siblings, 0 replies; 12+ messages in thread
From: Sven Eschenberg @ 2016-02-18 10:26 UTC (permalink / raw)
To: dm-crypt
Florian,
While at it (resending in plain text) make sure to include the output of
lsblk if possible. This should give us an idea of the layout as
currently being used.
Regards
-Sven
Am 18.02.2016 um 10:34 schrieb Michael Kjörling:
> On 18 Feb 2016 09:51 +0100, from florian.dotzer@web.de (Florian Dotzer):
>> <html><head></head><body><div style="font-family: Verdana;font-size: 12.0px;"><div><br/>
>
> Please resend as not HTML.
>
>> @Michael , Arno , Sven :<br/>
>> <br/>
>> Thanks for your replies and the help you are offering . Thats real support compared to experience with QNAP support ;-))<br/>
>> I *can* login as root to the QNAP box - but I am not a shell guru .<br/>
>> I hope I will be able to unlock my LUKS Copntainer without losing my Data .<br/>
>> <br/>
>> I used the graphical GUI of QNAP which offered this possibility to add a disk to an existing RAID ,<br/>
>> e.g. I clicked a Button named "Add hard drive" in the RAID Management Section ,<br/>
>> selected the newly added disk, and waited for the desaster to complete<br/>
>> <br/>
>> (german slang : mausi klickibunti ) .<br/>
>> <br/>
>> Somehow the command output was written to the Device and not elsewhere (/dev / null or shell )<br/>
>> <br/>
>> Michael wrote :<br/>
>> > What was the exact device layout?<br/>
>> > Physical storage then MD RAID<br/>
>> Yes. I have the box not at my desk here. Sorry.<br/>
>> <br/>
>> > then LUKS<br/>
>> At least I found a corrupted LUKSHeader there in /dev/md0<br/>
>> <br/>
>> > then some file system,<br/>
>> I hope so , thats where my data lives .<br/>
>> <br/>
>> YESS Sir<br/>
>> <br/>
>> > or physical storage then LUKS then MD RAID<br/>
>> >then some file system, or some other arrangement?<br/>
>> No<br/>
>> <br/>
>> >What was the exact command used to "add a disk"?<br/>
>> QNAP may know it , I not. I didnt find anything in dmesg / kernel log or elsewhere .<br/>
>> <br/>
>> From the best of my limited knowledge as I interpret the findings when I login as root in the cli ,<br/>
>> I see the RAID created with mdadm as built dirctly on the disk partitions sd[d|e|f|g|h|c]3<br/>
>> <br/>
>> where /dev/sdc is the disk I added .<br/>
>> the raid itself is up with all disks , (all disks 'U' ) , valid / valid superblock<br/>
>> I can get and read data from the block device /dev/md0<br/>
>> as you have seen in my last email.<br/>
>> <br/>
>> <br/>
>> <br/>
>> @ Arno :<br/>
>> <br/>
>> > What did you do?<br/>
>> > Did you pipe the output from mdadm into /dev/md0?<br/>
>> No.<br/>
>> > If so, there might be a chance to recover this.<br/>
>> <br/>
>> > First, make that header backup now, if you have not already.<br/>
>> <br/>
>> I have at least the first 64 MB of /dev/md0 extracted with dd if=/dev/md0 of=of=file_with_first_64_MB_of_md0 bs=1024 count=65535<br/>
>> The hex Dump was extracted from this .<br/>
>> I hope that is enough for a header backup (approx. 2MiB + xxx as stated in the FAQ) ?<br/>
>> <br/>
>> > The data that is missing depends on the QNAP device.<br/>
>> SS839 PRO<br/>
>> > Defaults can be changed on compile.<br/>
>> I only have binaries , no sources , no compiler<br/>
>> > Easiest option is<br/>
>> > likely to make a new LUKS container on it and try what<br/>
>> > is in there. You should be able to use the loop-device<br/>
>> > procedure from FAQ Item 2.6 from the commandline for<br/>
>> > that. If those values do not work, next option is to<br/>
>> > have the QNAP create a LUKS container on a new disk<br/>
>> > and see what it does.<br/>
>> <br/>
>> I'll try it that weekend or next when I have time to do it .<br/>
>> <br/>
>> <br/>
>> @Sven :<br/>
>> <br/>
>> >btw: I agree, if just the short output of mdadm was written to the disk<br/>
>> >chances are quite good for recovery.<br/>
>> <br/>
>> I hope so. I tried dd on files to replace the first 512 bytes of a file , but<br/>
>> the target file was completely replaced with this command :<br/>
>> <br/>
>> dd if=512_bytes_with_fixed_header of=file_with_first_64_MB_of_md0 bs=512 count=1<br/>
>> <br/>
>> Now I dont know if dd's behaviour is different on block device level ,<br/>
>> or is there another better way to replace / correct the first bytes of /dev/md0 ?<br/>
>> <br/>
>> <br/>
>> Greetings , Florian<br/>
>> </div></div></body></html>
>
^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: [dm-crypt] yet another header reconstruction question
2016-02-18 8:51 ` [dm-crypt] yet another header reconstruction question Florian Dotzer
2016-02-18 9:34 ` Michael Kjörling
@ 2016-02-18 12:53 ` Robert Nichols
1 sibling, 0 replies; 12+ messages in thread
From: Robert Nichols @ 2016-02-18 12:53 UTC (permalink / raw)
To: dm-crypt
On 02/18/2016 02:51 AM, Florian Dotzer wrote:
> I tried dd on files to replace the first 512 bytes of a file , but
> the target file was completely replaced with this command :
>
> dd if=512_bytes_with_fixed_header of=file_with_first_64_MB_of_md0 bs=512 count=1
When the target is a file, you need to include "conv=notrunc" so
that the file will not be truncated to zero length when it is
opened. That is not an issue when the target is a block device,
but there is no harm in using "conv=notrunc" there, too.
--
Bob Nichols "NOSPAM" is really part of my email address.
Do NOT delete it.
^ permalink raw reply [flat|nested] 12+ messages in thread
[parent not found: <mailman.1.1455879602.30698.dm-crypt@saout.de>]
* Re: [dm-crypt] yet another header reconstruction question
[not found] <mailman.1.1455879602.30698.dm-crypt@saout.de>
@ 2016-02-24 8:43 ` Florian Dotzer
2016-02-24 16:24 ` Arno Wagner
0 siblings, 1 reply; 12+ messages in thread
From: Florian Dotzer @ 2016-02-24 8:43 UTC (permalink / raw)
To: dm-crypt
On 02/18/2016 02:51 AM, Florian Dotzer wrote:
>> I tried dd on files to replace the first 512 bytes of a file , but
>> the target file was completely replaced with this command :
>>
>> dd if=512_bytes_with_fixed_header of=file_with_first_64_MB_of_md0 bs=512 count=1
> When the target is a file, you need to include "conv=notrunc" so
> that the file will not be truncated to zero length when it is
> opened. That is not an issue when the target is a block device,
> but there is no harm in using "conv=notrunc" there, too.
Thanks to Bob , Arno , Sven and all others. I was able to remount
with the corrected LUKS Header .
Now I have a backup of the header and a backup of the key.
currently I am backing up all data
Please enjoy a virtual drink of your choice ;-))
Sorry lsblk command was not available so I cannot report any output of that.
best wishes to all , Florian
^ permalink raw reply [flat|nested] 12+ messages in thread* Re: [dm-crypt] yet another header reconstruction question
2016-02-24 8:43 ` Florian Dotzer
@ 2016-02-24 16:24 ` Arno Wagner
0 siblings, 0 replies; 12+ messages in thread
From: Arno Wagner @ 2016-02-24 16:24 UTC (permalink / raw)
To: dm-crypt
Excellent. Also, thank you for the feedback!
Regards,
Arno
On Wed, Feb 24, 2016 at 09:43:02 CET, Florian Dotzer wrote:
>
>
> On 02/18/2016 02:51 AM, Florian Dotzer wrote:
> >> I tried dd on files to replace the first 512 bytes of a file , but
> >> the target file was completely replaced with this command :
> >>
> >> dd if=512_bytes_with_fixed_header of=file_with_first_64_MB_of_md0 bs=512 count=1
>
> > When the target is a file, you need to include "conv=notrunc" so
> > that the file will not be truncated to zero length when it is
> > opened. That is not an issue when the target is a block device,
> > but there is no harm in using "conv=notrunc" there, too.
>
> Thanks to Bob , Arno , Sven and all others. I was able to remount
> with the corrected LUKS Header .
>
> Now I have a backup of the header and a backup of the key.
>
> currently I am backing up all data
>
> Please enjoy a virtual drink of your choice ;-))
>
>
> Sorry lsblk command was not available so I cannot report any output of that.
>
> best wishes to all , Florian
> _______________________________________________
> 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
If it's in the news, don't worry about it. The very definition of
"news" is "something that hardly ever happens." -- Bruce Schneier
^ permalink raw reply [flat|nested] 12+ messages in thread
* [dm-crypt] yet another header reconstruction question
@ 2016-02-16 11:32 Florian Dotzer
2016-02-16 12:01 ` Michael Kjörling
2016-02-16 15:01 ` Arno Wagner
0 siblings, 2 replies; 12+ messages in thread
From: Florian Dotzer @ 2016-02-16 11:32 UTC (permalink / raw)
To: dm-crypt
sent again as text. sorry for HTML input. hopefully it is more readable now .
Dear Readers of the List .
I had a encrypted RAID 5 on my QNAP Device in /dev/md0.
It worked without any problems for about 6 years .
But space went low and desaster began.
After adding a disk , mdadm had overwritten the
header (block device /dev/md0 ) like this :
6d 64 61 64 6d 3a 20 61 64 64 65 64 20 2f 64 65 mdadm: added /de
76 2f 73 64 63 33 0a 00 00 00 00 00 00 00 00 00 v/sdc3..........
00 00 00 00 00 00 00 00 63 62 63 2d 70 6c 61 69 ........cbc-plai
6e 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 n...............
00 00 00 00 00 00 00 00 73 68 61 31 00 00 00 00 ........sha1....
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
00 00 00 00 00 00 00 00 00 00 08 08 00 00 00 20 ...............
bc 31 80 6d da a4 f0 5c ed 9f 24 96 fc 1b 72 6a
According to the documentation on-disk-format ,
magic (LUKS 0xba 0xbe ) , version and cipher name
seem to be overwritten.
I'd like to know the possible versions ( 00 01 ? ) and cipher names
(aes ?) in order to be able to reconstruct the header (fingers crossed )
user support from vendor QNAP tried an hour claiming
'fs super block could not be found'
and finally redirected me to 'commercial $$$upport' .
QNAP advertised my Box with
'Disks can be AES-encrypted with 256 bit " so
I suspect its something related with aes .
(And no , I had no header backup, Ahhh !)
Any helpful reply is welcome .
And yes , I will make backups in the future . ;-))
Greetings , Florian
^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: [dm-crypt] yet another header reconstruction question
2016-02-16 11:32 Florian Dotzer
@ 2016-02-16 12:01 ` Michael Kjörling
2016-02-16 15:01 ` Arno Wagner
1 sibling, 0 replies; 12+ messages in thread
From: Michael Kjörling @ 2016-02-16 12:01 UTC (permalink / raw)
To: dm-crypt
On 16 Feb 2016 12:32 +0100, from florian.dotzer@web.de (Florian Dotzer):
> I had a encrypted RAID 5 on my QNAP Device in /dev/md0.
Insufficient data for meaningful answer.
> It worked without any problems for about 6 years .
> But space went low and desaster began.
> After adding a disk , mdadm had overwritten the
> header (block device /dev/md0 ) like this :
What was the exact device layout? Physical storage then MD RAID then
LUKS then some file system, or physical storage then LUKS then MD RAID
then some file system, or some other arrangement?
What was the exact command used to "add a disk"?
--
Michael Kjörling • https://michael.kjorling.se • michael@kjorling.se
“People who think they know everything really annoy
those of us who know we don’t.” (Bjarne Stroustrup)
^ permalink raw reply [flat|nested] 12+ messages in thread* Re: [dm-crypt] yet another header reconstruction question
2016-02-16 11:32 Florian Dotzer
2016-02-16 12:01 ` Michael Kjörling
@ 2016-02-16 15:01 ` Arno Wagner
2016-02-16 19:41 ` Sven Eschenberg
1 sibling, 1 reply; 12+ messages in thread
From: Arno Wagner @ 2016-02-16 15:01 UTC (permalink / raw)
To: dm-crypt
On Tue, Feb 16, 2016 at 12:32:06 CET, Florian Dotzer wrote:
> sent again as text. sorry for HTML input. hopefully it is more readable now .
fine now.
> Dear Readers of the List .
>
> I had a encrypted RAID 5 on my QNAP Device in /dev/md0.
>
> It worked without any problems for about 6 years .
> But space went low and desaster began.
> After adding a disk , mdadm had overwritten the
> header (block device /dev/md0 ) like this :
>
> 6d 64 61 64 6d 3a 20 61 64 64 65 64 20 2f 64 65 mdadm: added /de
> 76 2f 73 64 63 33 0a 00 00 00 00 00 00 00 00 00 v/sdc3..........
> 00 00 00 00 00 00 00 00 63 62 63 2d 70 6c 61 69 ........cbc-plai
> 6e 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 n...............
> 00 00 00 00 00 00 00 00 73 68 61 31 00 00 00 00 ........sha1....
> 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
> 00 00 00 00 00 00 00 00 00 00 08 08 00 00 00 20 ...............
> bc 31 80 6d da a4 f0 5c ed 9f 24 96 fc 1b 72 6a
What did you do?
Did you pipe the output from mdadm into /dev/md0?
If so, there might be a chance to recover this.
> According to the documentation on-disk-format ,
> magic (LUKS 0xba 0xbe ) , version and cipher name
> seem to be overwritten.
>
> I'd like to know the possible versions ( 00 01 ? ) and cipher names
> (aes ?) in order to be able to reconstruct the header (fingers crossed )
First, make that header backup now, if you have not already.
The data that is missing depends on the QNAP device.
Defaults can be changed on compile. Easiest option is
likely to make a new LUKS container on it and try what
is in there. You should be able to use the loop-device
procedure from FAQ Item 2.6 from the commandline for
that. If those values do not work, next option is to
have the QNAP create a LUKS container on a new disk
and see what it does.
Regards,
Arno
--
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
If it's in the news, don't worry about it. The very definition of
"news" is "something that hardly ever happens." -- Bruce Schneier
^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: [dm-crypt] yet another header reconstruction question
2016-02-16 15:01 ` Arno Wagner
@ 2016-02-16 19:41 ` Sven Eschenberg
0 siblings, 0 replies; 12+ messages in thread
From: Sven Eschenberg @ 2016-02-16 19:41 UTC (permalink / raw)
To: dm-crypt
Am 16.02.2016 um 16:01 schrieb Arno Wagner:
> On Tue, Feb 16, 2016 at 12:32:06 CET, Florian Dotzer wrote:
>> sent again as text. sorry for HTML input. hopefully it is more readable now .
>
> fine now.
>
>> Dear Readers of the List .
>>
>> I had a encrypted RAID 5 on my QNAP Device in /dev/md0.
>>
>> It worked without any problems for about 6 years .
>> But space went low and desaster began.
>> After adding a disk , mdadm had overwritten the
>> header (block device /dev/md0 ) like this :
>>
>> 6d 64 61 64 6d 3a 20 61 64 64 65 64 20 2f 64 65 mdadm: added /de
>> 76 2f 73 64 63 33 0a 00 00 00 00 00 00 00 00 00 v/sdc3..........
>> 00 00 00 00 00 00 00 00 63 62 63 2d 70 6c 61 69 ........cbc-plai
>> 6e 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 n...............
>> 00 00 00 00 00 00 00 00 73 68 61 31 00 00 00 00 ........sha1....
>> 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
>> 00 00 00 00 00 00 00 00 00 00 08 08 00 00 00 20 ...............
>> bc 31 80 6d da a4 f0 5c ed 9f 24 96 fc 1b 72 6a
>
> What did you do?
> Did you pipe the output from mdadm into /dev/md0?
> If so, there might be a chance to recover this.
Looks alot like he did (if he did it himself manually). If so, maybe he
can also provide the actual command from the shell history? It could
help analyzing what happened.
btw: I agree, if just the short output of mdadm was written to the disk
chances are quite good for recovery.
>
>> According to the documentation on-disk-format ,
>> magic (LUKS 0xba 0xbe ) , version and cipher name
>> seem to be overwritten.
>>
>> I'd like to know the possible versions ( 00 01 ? ) and cipher names
>> (aes ?) in order to be able to reconstruct the header (fingers crossed )
>
> First, make that header backup now, if you have not already.
>
> The data that is missing depends on the QNAP device.
> Defaults can be changed on compile. Easiest option is
> likely to make a new LUKS container on it and try what
> is in there. You should be able to use the loop-device
> procedure from FAQ Item 2.6 from the commandline for
> that. If those values do not work, next option is to
> have the QNAP create a LUKS container on a new disk
> and see what it does.
>
> Regards,
> Arno
>
Regards
-Sven
^ permalink raw reply [flat|nested] 12+ messages in thread
* [dm-crypt] Yet another header reconstruction question
@ 2016-02-15 16:07 Florian Dotzer
2016-02-15 17:04 ` Arno Wagner
0 siblings, 1 reply; 12+ messages in thread
From: Florian Dotzer @ 2016-02-15 16:07 UTC (permalink / raw)
To: dm-crypt
[-- Attachment #1: Type: text/html, Size: 2748 bytes --]
^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: [dm-crypt] Yet another header reconstruction question
2016-02-15 16:07 [dm-crypt] Yet " Florian Dotzer
@ 2016-02-15 17:04 ` Arno Wagner
0 siblings, 0 replies; 12+ messages in thread
From: Arno Wagner @ 2016-02-15 17:04 UTC (permalink / raw)
To: dm-crypt
Please re-send as non-HTML. Thanks.
Arno
On Mon, Feb 15, 2016 at 17:07:35 CET, Florian Dotzer wrote:
> <html><head></head><body><div style="font-family: Verdana;font-size: 12.0px;"><div>Dear Readers of the List .</div>
>
> <div> </div>
>
> <div>I had a encrypted RAID 5on my QNAP Device in /dev/md0.</div>
>
> <div> </div>
>
> <div>It worked without any problems for about 6 years . But space went low and desaster began.</div>
>
> <div>After adding a disk , mdadm had overwritten the header (block device /dev/md0 ) like this :</div>
>
> <div> </div>
>
> <div><span style="font-family: courier new , courier , monospace;">6d 64 61 64 6d 3a 20 61 64 64 65 64 20 2f 64 65 mdadm: added /de</span></div>
>
> <div><span style="font-family: courier new , courier , monospace;">76 2f 73 64 63 33 0a 00 00 00 00 00 00 00 00 00 v/sdc3.......... </span></div>
>
> <div><span style="font-family: courier new , courier , monospace;">00 00 00 00 00 00 00 00 <strong>63 62 63 2d 70 6c 61 69</strong> ........cbc-plai </span></div>
>
> <div><span style="font-family: courier new , courier , monospace;"><strong>6e </strong>00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 n............... </span></div>
>
> <div><span style="font-family: courier new , courier , monospace;">00 00 00 00 00 00 00 00 <strong>73 68 61 31</strong> 00 00 00 00 ........sha1.... </span></div>
>
> <div><span style="font-family: courier new , courier , monospace;">00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ </span></div>
>
> <div><span style="font-family: courier new , courier , monospace;">00 00 00 00 00 00 00 00 00 00 <strong>08 08</strong> 00 00 00 <strong>20</strong> ............... </span></div>
>
> <div><span style="font-family: courier new , courier , monospace;">bc 31 80 6d da a4 f0 5c ed 9f 24 96 fc 1b 72 6a </span></div>
>
> <div> </div>
>
> <div>According to the documentation on-disk-format ,</div>
>
> <div>magic (LUKS 0xba 0x be ) , version and cipher name seem to be overwritten.</div>
>
> <div> </div>
>
> <div>I'd like to know the possible versions ( 00 01 ? ) and cipher names </div>
>
> <div>(aes ?) in order to be able to reconstruct the header (fingers crossed )</div>
>
> <div> </div>
>
> <div>user support from vendor QNAP tried an hour claiming 'fs super block could not be found'</div>
>
> <div>and finally redirected me to 'commercial $$$upport' . </div>
>
> <div> </div>
>
> <div>QNAP advertised my Box with 'Disks can be AES-encrypted with 256 bit " so</div>
>
> <div>I suspect its something related with aes .</div>
>
> <div> </div>
>
> <div>(And no , I had no header backup, Ahhh !)</div>
>
> <div> </div>
>
> <div>Any helpful reply is welcome . And yes , I will make backups in the future . ;-))</div>
>
> <div> </div>
>
> <div>Greetings , Florian</div></div></body></html>
> _______________________________________________
> 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
If it's in the news, don't worry about it. The very definition of
"news" is "something that hardly ever happens." -- Bruce Schneier
^ permalink raw reply [flat|nested] 12+ messages in thread
end of thread, other threads:[~2016-02-24 16:24 UTC | newest]
Thread overview: 12+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
[not found] <mailman.1.1455706801.5962.dm-crypt@saout.de>
2016-02-18 8:51 ` [dm-crypt] yet another header reconstruction question Florian Dotzer
2016-02-18 9:34 ` Michael Kjörling
2016-02-18 10:26 ` Sven Eschenberg
2016-02-18 12:53 ` Robert Nichols
[not found] <mailman.1.1455879602.30698.dm-crypt@saout.de>
2016-02-24 8:43 ` Florian Dotzer
2016-02-24 16:24 ` Arno Wagner
2016-02-16 11:32 Florian Dotzer
2016-02-16 12:01 ` Michael Kjörling
2016-02-16 15:01 ` Arno Wagner
2016-02-16 19:41 ` Sven Eschenberg
-- strict thread matches above, loose matches on Subject: below --
2016-02-15 16:07 [dm-crypt] Yet " Florian Dotzer
2016-02-15 17:04 ` 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.