From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from sb38.braegelmann.net (sb38.braegelmann.net [78.46.45.242]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.server123.net (Postfix) with ESMTPS for ; Sat, 2 Jul 2016 12:42:39 +0200 (CEST) From: =?UTF-8?Q?Bernd_Br=c3=a4gelmann?= References: <655760b1-5f92-e6f5-50c1-d46edef89cd9@braegelmann.net> <20160702102000.GA22828@tansi.org> <20160702102517.GA23072@tansi.org> Message-ID: <57779A93.20805@braegelmann.net> Date: Sat, 2 Jul 2016 12:42:27 +0200 MIME-Version: 1.0 In-Reply-To: <20160702102517.GA23072@tansi.org> Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit Subject: Re: [dm-crypt] Incidentaly partitioned LUKS device - header lost? List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: dm-crypt@saout.de 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 : >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@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 >> _______________________________________________ >> 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 >_______________________________________________ >dm-crypt mailing list >dm-crypt@saout.de >http://www.saout.de/mailman/listinfo/dm-crypt