[Top][All Lists]

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

Re: [Bug-ddrescue] fill-mode vs luks encryption

From: Atom Smasher
Subject: Re: [Bug-ddrescue] fill-mode vs luks encryption
Date: Sat, 7 Jun 2014 10:42:13 +1200 (NZST)

On Fri, 6 Jun 2014, Marian Csontos wrote:

Hi, first, have you checked the LUKS headers were unaffected? (Or you have backups) Otherwise an attempt to rescue the data may be futile.

first error is at 0x4B5293D000, so the header should be fine. i do have a backup header, just in case.

Second, // My terminology may be bit unorthodox...

If you wanted markers in the files you would better run ddrescue on the cleartext mapping instead of encrypted device. (However, that may slow things down, and may be unfeasible for some drives holding on just for short periods of time.)

oh yeah... /dev/mapper/udisks-luks-uuid-xxxxx

i hadn't thought of that... maybe i'll give that a shot...

the downside though, IIUC, is that the luks partition uses 4k sectors... so in theory i could lose up to 8x more data than i have errors, if some sectors of the physical drive don't get recovered sequentially. by running ddrescue on the physical disk, i can recover more (encrypted) data (with multiple runs of ddrescue), because it doesn't matter if the 512B sectors are recovered sequentially or not sequentially. in practice, that probably doesn't matter much.

so i think... doing it the way you suggest would have the advantage of being able to identify bad data with fill-mode... but the disadvantage of not recovering as much data. it's a trade-off.

anyway... it's worth a shot while the drive is on my desk, before i RMA it.

Also similarly to keep data encrypted you should write to cleartext mapping on top of another LUKS-encrypted (loop)device.

most of my external drives are encrypted, anyway, so just writing a "normal" image on one of them would be "safe", as it's on an encrypted drive.

Now, with the encrypted data you have...

I am not sure there is a binary grep tool to find sequences of the marker string in the encrypted device (if not it would not be that difficult to write one) - when identified list of offset and span tuples, you would have to dd over the corresponding parts of your cleartext device.

another part of the problem is that block-ciphers don't necessarily have a 1:1 mapping of bits on the drive to bits in a file. 1 bad bit on the drive could easily result in 64 bits of unrecoverable data.


 762A 3B98 A3C3 96C9 C6B7 582A B88D 52E4 D9F5 7808

        "In every respect, vegans appear to enjoy equal
         or better health in comparison to both vegetarians
         and non-vegetarians."
                -- T. Colin Campbell,
                PhD Professor of Nutrition, Cornell University

reply via email to

[Prev in Thread] Current Thread [Next in Thread]