Fwd: Recover LUKS partition from deleted partition table

[Kyle Bond <ultimatedevr@xxxxxxxxx>]

Just posting this so if anyone has the same issue as me, they'll be able to find this solution.

--Kyle Bond

---------- Forwarded message ----------
From: Arno Wagner <arno@xxxxxxxxxxx>
Date: Fri, Oct 2, 2009 at 11:20 PM
Subject: Re: Recover LUKS partition from deleted partition table
To: Kyle Bond <ultimatedevr@xxxxxxxxx>


Hi Kyle,

On Fri, Oct 02, 2009 at 11:09:51PM -0400, Kyle Bond wrote:
> Thanks for commenting the hexdump in such detail; made things a lot easier
> for me to understand.

Glad to be able to help. Of course if this would go up to
multiple hours I would need to find my consulting hat
and charge you ;-)

> I had a feeling my data was gone with the wind...at
> least I have a backup of most of the stuff that was on there.

Very good.

> Now the real
> question is how did that data get there? It looks to me like gparted
> overwrote the key with......"stuff" (looks like a logfile or something to
> me).

Would be my guess also.

> Thanks again for all the help! Now I'm off to utilize my backups...

You are welcome.

Arno

> --Kyle Bond
>
> On Fri, Oct 2, 2009 at 8:35 PM, Arno Wagner <arno@xxxxxxxxxxx> wrote:
>
> > Hi Kyle,
> >
> > that does not look good. I found the following block at an offset of
> > 64kB, right in the middle of keyslot 1:
> >
> >
> > 00010000  30 30 30 30 30 30 30 00  6d 73 64 6f 73 00 4c 55  |
> > 0000000.msdos.LU|
> > 00010010  4b 53 ba be 00 65 78 74  65 6e 64 65 64 00 62 74  |KS...
> > extended.bt|
> > 00010020  72 66 73 00 65 78 74 34  64 65 76 00 6c 69 6e 75
> >  |rfs.ext4dev.linu|
> > 00010030  78 2d 73 77 61 70 00 6c  69 6e 75 78 2d 73 77 61
> >  |x-swap.linux-swa|
> > 00010040  70 28 76 31 29 00 6c 69  6e 75 78 2d 73 77 61 70
> >  |p(v1).linux-swap|
> > 00010050  28 6e 65 77 29 00 6c 69  6e 75 78 2d 73 77 61 70
> >  |(new).linux-swap|
> > 00010060  28 76 30 29 00 6c 69 6e  75 78 2d 73 77 61 70 28
> >  |(v0).linux-swap(|
> > 00010070  6f 6c 64 29 00 66 61 74  31 36 00 66 61 74 33 32
> >  |old).fat16.fat32|
> > 00010080  00 68 66 73 00 68 66 73  2b 00 75 66 73 00 52 65
> >  |.hfs.hfs+.ufs.Re|
> > 00010090  49 73 45 72 34 00 4c 41  42 45 4c 4f 4e 45 00 4c
> >  |IsEr4.LABELONE.L|
> > 000100a0  56 4d 32 00 5f 42 48 52  66 53 5f 4d 00 42 54 52
> >  |VM2._BHRfS_M.BTR|
> > 000100b0  46 53 20 69 73 20 6e 6f  74 20 79 65 74 20 73 75  |FS is not yet
> > su|
> > 000100c0  70 70 6f 72 74 65 64 2e  00 0a 2d 00 54 68 65 20
> >  |pported...-.The |
> > 000100d0  66 69 6c 65 20 73 79 73  74 65 6d 20 69 73 20 64  |file system is
> > d|
> > 000100e0  61 6d 61 67 65 64 00 75  64 65 76 73 65 74 74 6c
> >  |amaged.udevsettl|
> > 000100f0  65 00 75 64 65 76 73 65  74 74 6c 65 20 2d 2d 74  |e.udevsettle
> > --t|
> > 00010100  69 6d 65 6f 75 74 3d 00  75 64 65 76 61 64 6d 20
> >  |imeout=.udevadm |
> > 00010110  73 65 74 74 6c 65 20 2d  2d 74 69 6d 65 6f 75 74  |settle
> > --timeout|
> > 00010120  3d 00 75 73 69 6e 67 20  6c 69 62 70 61 72 74 65  |=.using
> > libparte|
> > 00010130  64 00 73 68 72 69 6e 6b  20 66 69 6c 65 20 73 79  |d.shrink file
> > sy|
> > 00010140  73 74 65 6d 00 67 72 6f  77 20 66 69 6c 65 20 73  |stem.grow file
> > s|
> > 00010150  79 73 74 65 6d 00 72 65  73 69 7a 65 20 66 69 6c  |ystem.resize
> > fil|
> > 00010160  65 20 73 79 73 74 65 6d  00 64 65 6c 65 74 65 20  |e
> > system.delete |
> > 00010170  70 61 72 74 69 74 69 6f  6e 00 73 74 61 74 76 66
> >  |partition.statvf|
> > 00010180  73 20 28 00 29 3a 20 00  55 6e 61 62 6c 65 20 74  |s (.): .Unable
> > t|
> > 00010190  6f 20 66 69 6e 64 20 6d  6f 75 6e 74 20 70 6f 69  |o find mount
> > poi|
> > 000101a0  6e 74 00 25 31 20 6f 66  20 25 32 20 72 65 61 64  |nt.%1 of %2
> > read|
> > 000101b0  20 28 25 33 20 72 65 6d  61 69 6e 69 6e 67 29 00  | (%3
> > remaining).|
> > 000101c0  25 31 20 6f 66 20 25 32  20 72 65 61 64 00 25 31  |%1 of %2
> > read.%1|
> > 000101d0  20 6f 66 20 25 32 20 63  6f 70 69 65 64 00 5e 28  | of %2
> > copied.^(|
> > 000101e0  2f 5b 5e 20 5d 2b 29 00  3d 3d 3d 3d 3d 3d 3d 3d  |/[^
> > ]+).========|
> > 000101f0  3d 3d 3d 3d 3d 3d 3d 3d  3d 3d 3d 3d 3d 3d 00 6c
> >  |==============.l|
> >
> >
> > The commented hexdumop of your header is attached. It looks like
> > something wrote the 512 bytes above to the partition at offset
> > 0x10000 and thereby destroyed the keyslot contents.
> >
> > Arno
> >
> >
> >
> >
> >
> > On Fri, Oct 02, 2009 at 02:51:12PM -0400, Kyle Bond wrote:
> > > Thanks for clearing that up; I thought simply a hashed copy of the key
> > was
> > > stored in the keyslot and the key itself wasn't stored on the drive.
> > >
> > > I do believe my key was overwritten as the other LUKS drives that I have
> > and
> > > the test luks-formatted loop files I created all have zeros from 0x250 to
> > > 0x1000, but the drive I'm having problems with has data in this region.
> > I've
> > > attached the first 200kB of the LUKS partition so you can take a look at
> > it
> > > and see what's wrong.
> > >
> > > Thanks again for helping!
> > >
> > > --Kyle Bond
> > >
> > > On Fri, Oct 2, 2009 at 9:54 AM, Arno Wagner <arno@xxxxxxxxxxx> wrote:
> > >
> > > > On Fri, Oct 02, 2009 at 12:08:53AM -0400, Kyle Bond wrote:
> > > > > Thank you for the information; very interesting stuff.
> > > > >
> > > > > I found that my keyslot0 was from 0xd0 - 0xff (this is according to
> > pg. 6
> > > > of
> > > > > the pdf you linked me to);
> > > >
> > > > Ah, that is the keyslot, not the key istelf. The key is about 128kB in
> > > > size.
> > > >
> > > > > when I compared it to another LUKS disk of mine
> > > > > the LUKS headers and the keyslots all looked very similar (didn't see
> > > > 0x55
> > > > > 0xAA, or any other partition/disk/sector information other than the
> > UUID
> > > > in
> > > > > the header), so my guess is if the keyslot/header did get overwritten
> > it
> > > > > must've been where the salt & iterations were in the keyslot, or
> > possibly
> > > > > the MK digests in the LUKS header (or something equally undetectable
> > and
> > > > > unrecoverable).
> > > > >
> > > > > Any tips on where to go from here?
> > > >
> > > > Look at the key. Start and end is in the keyslot and
> > > > was 0x1000 - 0x20400 in my test-LUKS partition (incidentially
> > > > just a 10MB file of zeros mounted via loop device).
> > > >
> > > > If you have trouble, feel free to mail me the first 200kB or so
> > > > of your LUKS partition.
> > > >
> > > > Arno
> > > >
> > > >
> > > >
> > > >
> > > > > --Kyle Bond
> > > > >
> > > > >
> > > > > On Thu, Oct 1, 2009 at 2:52 PM, Arno Wagner <arno@xxxxxxxxxxx>
> > wrote:
> > > > >
> > > > > > On Thu, Oct 01, 2009 at 11:58:58AM -0400, Kyle Bond wrote:
> > > > > > > I haven't written anything to the 40GB; there were other logic
> > > > paritions
> > > > > > > within the extended partition, and I have repartitioned the this
> > > > general
> > > > > > > area of the disk several times to get them to show up again. What
> > is
> > > > this
> > > > > > > descriptor you are referring to? I was under the impression that
> > all
> > > > > > > partition-related information goes into the partition table at
> > the
> > > > > > beginning
> > > > > > > of the disk?
> > > > > >
> > > > > > Unfortunately no. The way this is organized is that there
> > > > > > are 4 parition slots in a partition table sector. The 4
> > > > > > primary partitions go into the secotr ath the beginning.
> > > > > > However if you have an extended partition it works like this
> > > > > > (details may be wrong, but this is the princuiple):
> > > > > >
> > > > > >  1. The slot at the beginning points to the extended partition
> > > > > >     sector, which is placed at the beginning of the extended
> > > > > >     partition.
> > > > > >  2. The extended partition sector has the description onf the
> > > > > >     extended partition in its slot 0 and a pointer to the
> > > > > >     partition sector of the first logical partition
> > > > > >     in slot 1. Slots 2/3 are unused.
> > > > > >  3. A partition sector of a logical partition rersides at
> > > > > >     the beginning of that logical partition, has the description
> > > > > >     of that logical partition in slot 0 and a pointer to the next
> > > > > >     logical partition in slot 1. Slopts 2/3 are unused.
> > > > > >  4. Repeat 3. for each logical partition. In the last one
> > > > > >     Slot 1 is unused (zero)
> > > > > >
> > > > > > So then that one-cylinder partition as created, It is possible that
> > > > > > a new partition sector was put right behind its end to keep the
> > chain
> > > > > > of partition sectors intact.
> > > > > >
> > > > > > > Also, would I be able to recognize (via hexdump of the LUKS
> > header)
> > > > if a
> > > > > > > keyslot got overwritten?
> > > > > >
> > > > > > Not the header, the kleyslot. And yes, you should be able to
> > recognize
> > > > > > it as it has structured data.
> > > > > >
> > > > > > The LUKS on disk format is documented here:
> > > > > >
> > > > > >
> > > > > >
> > > >
> > http://cryptsetup.googlecode.com/svn-history/r42/wiki/LUKS-standard/on-disk-format.pdf
> > > > > >
> > > > > > The concrete parameters seem to deviate a bit, for example I found
> > > > > > 3850 anti-forensic stripes instead of 4000 as giben in section 5.
> > > > > >
> > > > > > With a short test (cryptsetup 1.0.7) I found that the first keyslot
> > > > resides
> > > > > > at 0x1000 - 0x20400 from the partition start (128'000 bytes long)
> > It
> > > > seems
> > > > > > the next keyslot is from 0x21000 - 0x40400 and that there is 1536
> > bytes
> > > > (3
> > > > > > sectors) of padding between keyslots that may contain zeros of the
> > > > original
> > > > > > disk content. So if you find somethign structured in the space
> > > > > > 0x1000-0x20400 from partition start, you have a broken keyslot.
> > > > > >
> > > > > > The structure of a partition sector is described here:
> > > > > >
> > > > > >  http://en.wikipedia.org/wiki/Master_boot_record
> > > > > >
> > > > > > The chaining is described here, hiwever I found it by analysing
> > > > > > on-disk srtucture on my own. This chaining seems not to be widely
> > > > > > known.:
> > > > > >
> > > > > >  http://www.boot-us.com/gloss02.htm
> > > > > >
> > > > > > Especially the 0x55 0xAA signature at the end of a partition sector
> > > > > > is very distinct, but the other data may be too. The 446 boot code
> > > > > > bytes are typically zero except in the MBR (the first partition
> > > > > > sector) AFAIK.
> > > > > >
> > > > > > Good luck. Maybe it is just a minor problem. If there really is
> > > > > > a partition sector in your keyslot, there is no chance of
> > recovering
> > > > > > that keyslot.
> > > > > >
> > > > > > Arno
> > > > > >
> > > > > > > --Kyle
> > > > > > >
> > > > > > > On Thu, Oct 1, 2009 at 7:51 AM, Arno Wagner <arno@xxxxxxxxxxx>
> > > > wrote:
> > > > > > >
> > > > > > > > Have you written anything to the 40GB? The LUKS header
> > > > > > > > is small, but the keyslots are a few MB in size each.
> > > > > > > > If there is a partition after sda5, its descriptor may
> > > > > > > > have been put in the middle of your keyslot, effectively
> > > > > > > > destroying it.
> > > > > > > >
> > > > > > > > Arno
> > > > > > > >
> > > > > > > >
> > > > > > > > On Wed, Sep 30, 2009 at 10:08:23PM -0400, Kyle Bond wrote:
> > > > > > > > > Whilst repartitioning my drive trying to move & enlarge my
> > LUKS
> > > > > > > > partition, I
> > > > > > > > > fubar'd the partition table and tried to recreate it from
> > scratch
> > > > > > using
> > > > > > > > > testdisk. However, testdisk hasn't been able to properly
> > discover
> > > > the
> > > > > > > > > partition; it found the LUKS header and created a logical
> > > > partition 1
> > > > > > > > > cylinder in size; I can do a luksDump from it, and I can see
> > > > crypt
> > > > > > > > settings,
> > > > > > > > > key slots etc., however the partition's too small to be able
> > to
> > > > > > access
> > > > > > > > any
> > > > > > > > > data. So I  enlarged the discovered logical partition
> > starting at
> > > > the
> > > > > > > > LUKS
> > > > > > > > > header (found using hexdump -C /dev/sda|grep "4c 55 4b 53 ba
> > be")
> > > > and
> > > > > > > > > extending it back to its original 40GB, however when I try to
> > > > enter
> > > > > > the
> > > > > > > > > password for it cryptsetup won't accept it (I am doing
> > cryptsetup
> > > > > > > > luksOpen
> > > > > > > > > /dev/sda5 root). Help?
> > > > > > > > >
> > > > > > > > > --Kyle
> > > > > > > >
> > > > > > > > > _______________________________________________
> > > > > > > > > dm-crypt mailing list
> > > > > > > > > dm-crypt@xxxxxxxx
> > > > > > > > > http://www.saout.de/mailman/listinfo/dm-crypt
> > > > > > > >
> > > > > > > >
> > > > > > > > --
> > > > > > > > Arno Wagner, Dr. sc. techn., Dipl. Inform., CISSP -- Email:
> > > > > > > > arno@xxxxxxxxxxx
> > > > > > > > GnuPG:  ID: 1E25338F  FP: 0C30 5782 9D93 F785 E79C  0296 797F
> > 6B50
> > > > 1E25
> > > > > > > > 338F
> > > > > > > > ----
> > > > > > > > Cuddly UI's are the manifestation of wishful thinking. -- Dylan
> > > > Evans
> > > > > > > >
> > > > > > > > If it's in the news, don't worry about it.  The very definition
> > of
> > > > > > > > "news" is "something that hardly ever happens." -- Bruce
> > Schneier
> > > > > > > >
> > > > > >
> > > > > > --
> > > > > > Arno Wagner, Dr. sc. techn., Dipl. Inform., CISSP -- Email:
> > > > > > arno@xxxxxxxxxxx
> > > > > > GnuPG:  ID: 1E25338F  FP: 0C30 5782 9D93 F785 E79C  0296 797F 6B50
> > 1E25
> > > > > > 338F
> > > > > > ----
> > > > > > Cuddly UI's are the manifestation of wishful thinking. -- Dylan
> > Evans
> > > > > >
> > > > > > If it's in the news, don't worry about it.  The very definition of
> > > > > > "news" is "something that hardly ever happens." -- Bruce Schneier
> > > > > >
> > > >
> > > > --
> > > > Arno Wagner, Dr. sc. techn., Dipl. Inform., CISSP -- Email:
> > > > arno@xxxxxxxxxxx
> > > > GnuPG:  ID: 1E25338F  FP: 0C30 5782 9D93 F785 E79C  0296 797F 6B50 1E25
> > > > 338F
> > > > ----
> > > > Cuddly UI's are the manifestation of wishful thinking. -- Dylan Evans
> > > >
> > > > If it's in the news, don't worry about it.  The very definition of
> > > > "news" is "something that hardly ever happens." -- Bruce Schneier
> > > >
> >
> >
> >
> > --
> > Arno Wagner, Dr. sc. techn., Dipl. Inform., CISSP -- Email:
> > arno@xxxxxxxxxxx
> > GnuPG:  ID: 1E25338F  FP: 0C30 5782 9D93 F785 E79C  0296 797F 6B50 1E25
> > 338F
> > ----
> > Cuddly UI's are the manifestation of wishful thinking. -- Dylan Evans
> >
> > If it's in the news, don't worry about it.  The very definition of
> > "news" is "something that hardly ever happens." -- Bruce Schneier
> >

--

Arno Wagner, Dr. sc. techn., Dipl. Inform., CISSP -- Email: arno@xxxxxxxxxxx
GnuPG:  ID: 1E25338F  FP: 0C30 5782 9D93 F785 E79C  0296 797F 6B50 1E25 338F
----
Cuddly UI's are the manifestation of wishful thinking. -- Dylan Evans

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@xxxxxxxx
http://www.saout.de/mailman/listinfo/dm-crypt