Re: Data recovery

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Hi Arno

Thanks for the help. I'll consider the data lost and move on. 

Incidentally, is there any way to recover deleted files from an encrypted drive. eg, you delete some files (and empty the trash), and then recover them afterwards. I know there are tools available, but I'm not sure i they would work on an encrypted drive (while mounted of course). Will encrypting a drive remove all possibilities of undelete?

On Sat, Oct 8, 2011 at 10:02 PM, Arno Wagner <arno@xxxxxxxxxxx> wrote:
On Sat, Oct 08, 2011 at 07:42:09PM +0200, Nico Gevers wrote:
> Hi Arno
>
> Thanks for your reply. I made a header backup and had a look at the hex
> dump. Its about 1.4M so haven't attached it, but can if its useful. The
> drive was using aes-xts-plain with a 512 bit key. According to the FAQ this
> means that 1st keyslot starts at 0x1000 and runs until 0x3f800. Having had a
> look at the dump, I noticed 0x1000 - 0x13300 was fairly regular, and from
> 0x14000 the dump looked quite random until the end of the keyspace. I guess
> that means I've lost some of the key.

Actually, you lost the full key, due to the anti-forensic properties
of LUKS key storage. Hanginf a few bits anywhere in the keyslot is
enough to make the master-key irrecoverable. This is by design.

No idea what overwrites 0x1000-0x13300, except possibly the
fdisk-run...

> Excuse my ignorance here, but wouldn't it be possible (in my case) to
> reverse engineer the data in the keyslot, since I know the original key as
> well as the iterations and salt value. Could I not regenerate the key hash
> and insert it back into the header. I could even check the correctness of
> the key my matching the last half of the bits to the ones in the existing
> keyslot.

No. The key that was lost is the master key, encrypted with
your passphrase and "streched" to the full keyslot size.
If a reconstruction as you suggest were possible, disabling
old passphrases would be impossible.

> As for how it happened, I wish I knew. All I remember is one morning
> starting my machine up and being surprised that the external drive wouldn't
> accept my password. I do remember getting semaphore errors for the first
> time, and since I'm running ubuntu 11.10 beta, perhaps I did an update that
> might have caused a hassle some where (perhaps a kernel update or an update
> to cryptsetup). I wasn't really paying attention since I didn't anticipate
> anything like this.

Should not cause this. Some versions of Ubuntu have a problem that
they offer to create new LUKS partitions during install in unclear
language, leading people to belive their existing LUKS containers
would be activated, but that is about it AFAIK.

So what you see should not happen. Read errors from the disk
would also show up differently. Has maybe somebody else had
access to that disk?

Since you ran fdisk, it is likely impossible to find out anything from
the change-pattern now.

Arno

> Oh, and here's a dump of the luksDump command. I can attach the header if
> its useful to anyone.
>
> Version:       1
> Cipher name:   aes
> Cipher mode:   xts-plain
> Hash spec:     sha1
> Payload offset: 4040
> MK bits:       512
> MK digest:     1e 01 d1 96 ba 79 cd 9f d1 cd 7f ee 1c e5 e7 51 ed a7 61 06
> MK salt:       60 32 3e 38 42 1f 5c 05 ce 21 d6 27 ad 23 bf 1e
>                 a7 18 13 a7 75 8f 33 f0 f6 f8 25 da 0c e0 af 60
> MK iterations: 9125
> UUID:           5048085d-d798-4b4f-902b-88eb2e71fd88
>
> Key Slot 0: ENABLED
> Iterations:         36805
> Salt:               25 4b 79 50 a4 0b 26 40 85 48 5c d0 28 1b 42 73
>                        7b 59 a7 e6 17 81 94 22 c8 45 de 96 b7 bd 8f f1
> Key material offset: 8
> AF stripes:             4000
>
> <the rest of the keyslots are empty>
>
> thanks again
> Nico
>
> On Sat, Oct 8, 2011 at 6:22 PM, Arno Wagner <arno@xxxxxxxxxxx> wrote:
>
> > On Sat, Oct 08, 2011 at 02:28:28PM +0200, Nico Gevers wrote:
> > > Hi
> > >
> > > I've recently decided to encrypt all my drives using luks, running on
> > ubuntu
> > > 11.10. I encrypted my external drive, and loaded all my backups onto the
> > > drive. One morning, I tried accessing the drive, and it wouldn't accept
> > my
> > > key phrase. I tried a couple of times, even tried some variations, but no
> > > avail. Then I stupidly thought of running fsck on the drive. I fixed a
> > > couple of innodes, but then stopped, realising that I was probably doing
> > > more harm than good.
> > >
> > > When I run luksDump on that drive, I get all the expected information. My
> > > question is: is the header still intact. Is there any chance I can
> > recover
> > > my data, owing to the fact that luksDump displays, what seems to me, a
> > valid
> > > header? (I'm assuming that if luksDump shows the information, the header
> > is
> > > intact).
> >
> > The header itself may be intact. But the problem here is the keyslots.
> > If they are damaged, the only thing that can save your data is a header
> > backup.
> >
> > What I wonder is why fsck was even willing to run. Due to the encryption,
> > it will have seen absolutely nothing that looks like a filesystem.
> > It also is quite possible that it 'fixed' things in the keyslot area.
> >
> > In addition, there is the question for the reason fo the initial
> > fail.
> >
> > So, what you do now is make a header backup (procedure is in the
> > FAQ) und analyse that. First, find out in which keyslot your key
> > is (likely the first), then look at the FAQ section on on-disk
> > format and look at the encrypted keyslot with a hex-dump
> > tool, e.g. hd. If there is anything looking regular in the
> > keyslot area, apply procedure for dealing with permanent data
> > loss, also described in the FAQ.
> >
> > You can of course ask for further advice here, but it is impossible
> > to answer your question without looking at that keyslot data.
> >
> > Arno
> > --
> > 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
> >

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

_______________________________________________
dm-crypt mailing list
dm-crypt@xxxxxxxx
http://www.saout.de/mailman/listinfo/dm-crypt

[Index of Archives]     [Device Mapper Devel]     [Fedora Desktop]     [ATA RAID]     [Fedora Marketing]     [Fedora Packaging]     [Fedora SELinux]     [Yosemite News]     [KDE Users]     [Fedora Tools]     [Fedora Docs]

  Powered by Linux