[dm-crypt] Incidentaly partitioned LUKS device - header lost?

Bernd Brägelmann bernd at braegelmann.net
Sat Jul 2 12:42:27 CEST 2016


Hi Arno,

thanks for answering. I created the partition table within /dev/md2 and
the raid is still working.

My current last hope is that the salt might be in a redundant part of
the raid array. Currently I grep the single devices for the LUKS-header
file like this:

grep -a -b -P --only-matching 'LUKS\xba\xbe' /dev/sdc
grep -a -b -P --only-matching 'LUKS\xba\xbe' /dev/sdb
grep -a -b -P --only-matching 'LUKS\xba\xbe' /dev/sdd

Could that be successful?

However here is also my mdadm --detail:

/dev/md2:
        Version : 1.2
  Creation Time : Thu Jan  3 21:43:32 2013
     Raid Level : raid5
     Array Size : 3906763776 (3725.78 GiB 4000.53 GB)
  Used Dev Size : 1953381888 (1862.89 GiB 2000.26 GB)
   Raid Devices : 3
  Total Devices : 3
    Persistence : Superblock is persistent

    Update Time : Fri Jul  1 13:02:14 2016
          State : clean
 Active Devices : 3
Working Devices : 3
 Failed Devices : 0
  Spare Devices : 0

         Layout : left-symmetric
     Chunk Size : 512K

           Name : braegel1:2  (local to host braegel1)
           UUID : 54ee60b5:45837e78:661fa3ed:3eacb88f
         Events : 44120

    Number   Major   Minor   RaidDevice State
       0       8       17        0      active sync   /dev/sdb1
       1       8       33        1      active sync   /dev/sdc1
       3       8       49        2      active sync   /dev/sdd1

Regards,

Bernd


Am 2. Juli 2016 12:25:17 MESZ, schrieb Arno Wagner <arno at wagner.name>:
>Ah, sorry, I am confused. The first question is whether
>you killed the RAID as well or whether you created the
>msdos partition table within /dev/md2. In the latter
>case we do not need the RAID info.
>
>Regards,
>Arno
>
>On Sat, Jul 02, 2016 at 12:20:00 CEST, Arno Wagner wrote:
>> Hi Bernd,
>> 
>> data-recovery for this is typically relatively easy or completely
>> impossible. To determine which it is, we need to find out what 
>> happened exactly. The only really irreplaceable values in the header
>> are the salts (see FAQ Item 6.12). These are not secret, but 
>> each is 256 bits of crypto-grade randomness and they cannot
>> be reconstructed or guessed.
>> 
>> The first question is what was overwritten by that partition 
>> sector. Traditionally, Linux software RAID has the RAID superblock
>> at the end, but unfortunately some people "improved" this, so
>> it can now be at the end, at the start and at 4kB from the start.
>> 
>> This is relevant becauese it influences the data offset, i.e.
>> the place where the LUKS header is put.
>> 
>> Hence we need the output of
>> 
>>   mdadm --detail /dev/md2
>> 
>> whichs dumps the RAID metadata.
>> 
>> Regards,
>> Arno
>> 
>> 
>> On Sat, Jul 02, 2016 at 08:33:09 CEST, Bernd Brägelmann wrote:
>> > Hi there,
>> > 
>> > i think i destroyed my luks data.
>> > 
>> > I accidentally created a msdos partition table on the luks device.
>I
>> > think the device was not partitioned. The device is a raid5 mdadm
>at
>> > /dev/md2.
>> > 
>> > Now i cannot luksOpen the device anymore.
>> > 
>> > I already try to hexdump|grep for the LUKS header but until now i
>> > haven't found it. In the Luks-FAQ 6.1 the problem is described as a
>> > common user error and it is very common that the partitioning has
>> > destroyed the LUKS header.
>> > 
>> > My question is: Is my data destroyed beyond recovery? It would
>really
>> > help me to cope with this. Is it possible to "manually" fix a
>partially
>> > destroyed LUKS header? Are there other ways to recover the data? I
>would
>> > gladly pay for a recovery solution.
>> > 
>> > Regards,
>> > 
>> > Bernd
>> > 
>> > -- 
>> > Bernd Brägelmann  -  FA für Radiologie
>> > Robert-Koch-Straße 42     28277 Bremen
>> > www.berndbraegelmann.de +4915141457796
>> > _______________________________________________
>> > dm-crypt mailing list
>> > dm-crypt at saout.de
>> > http://www.saout.de/mailman/listinfo/dm-crypt
>> 
>> -- 
>> Arno Wagner,     Dr. sc. techn., Dipl. Inform.,    Email:
>arno at 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
>> _______________________________________________
>> dm-crypt mailing list
>> dm-crypt at saout.de
>> http://www.saout.de/mailman/listinfo/dm-crypt
>
>-- 
>Arno Wagner,     Dr. sc. techn., Dipl. Inform.,    Email:
>arno at 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
>_______________________________________________
>dm-crypt mailing list
>dm-crypt at saout.de
>http://www.saout.de/mailman/listinfo/dm-crypt


More information about the dm-crypt mailing list