[dm-crypt] Restored luks2 header to wrong drive!

[dm-crypt] Restored luks2 header to wrong drive!

[Default User]

[-- Attachment #1: Type: text/plain, Size: 2911 bytes --]

Hi.

I am sure you have heard this before.

I have a computer running Debian unstable, Cinnamon desktop environment.  I
have a testing usb thumb drive, labeled USBSDOO3,  which I formatted ext4,
and encrypted with luks1, using the Gnome "disks" utility program.

I then installed cryptsetup and used its "convert" option to change
USBSD003 from luks1 to luks2.

Then I used the cryptsetup header backup function to backup the luks2
header to my internal ssd drive. All good so far.

Then, as a test, I tried to restore the luks2 header to USBSD003.

Well, I made a HUGE mistake!
USBSD003 was plugged in as device /dev/sdc1.

But . . .
I entered the command:

Sudo cryptsetup luksHeaderRestore /dev/sdb1
--header-backup-file \
LUKS_header_backups/USBSD003_luks_header_backup_2020-05-04.

Unfortunately, at /dev/sdb1 was a 1Tb usb external hard drive, one
partition only, formatted ext4, UNENCRYPTED, labeled USBHD005. So I endeded
up restoring the header to the hard drive, instead of to the thumb drive!

Disaster!
The hard drive (was) about 78% full of real, important data, much of which
was not backed up elsewhere.

Immediately realizing what I had done, I used the Gnome "Disks" utility to
unmount, "lock" and power off both USBSD003 and USBHD005. And then rebooted.

Now when I plug in USBHD005, the "Disks" program asks for the luks2
passphrase, which I type in correctly. It replies "Unable to mount 1.0 TB
Encrypted".

The "Disks" graphical window, under "Volumes", shows 2 horizontal bars. The
one on top says "Partition 1", and an unlocked lock icon.

The one below says "1.0 TB Unknown".

Lower down, the window says:
Size:  1.0 TB (1,000,200,994,816 bytes).
Device:  /dev/mapper/luks-dda13787-d4ab-40f2-8cb9-6edbad-868747.
Contents:  Unknown.

In a terminal, with luks2 "unlocked", if I enter:
sudo cryptsetup status /
dev/mapper/luks-dda13787-d4ab-40f2-8cb9-6edbad-868747
It replies:

/dev/mapper/luks-dda13787-d4ab-40f2-8cb9-6edbad-868747 is active.
type:       LUKS2
cipher:    aes-xts-plain64
keysize:  256 bits
key location:  keyring
device:   /dev/sb1
sector size:  512
offset:   4096 sectors
size:      1953517568
mode:   read/write

When luks2 is "locked", the terminal says:
/dev/mapper/luks-dda13787-d4ab-40f2-8cb9-6edbad-868747 is inactive.
And says the same thing when USBHD005 is "powered off" by the "Disks"
program.

Neither the the terminal "mount" command, nor the Nautilus or Nemo file
managers, show any indication of USBHD005 OR /dev/sdb(1).

Running:
lsblk -o name,label,size,retype,model
shows:

sdb
sdb1
luks-dda13787-d4ab-40f2-8cb9-6edbad-868747
931.5G

I did try to "image" USBHD005 on a brand new 1Tb external sub drive, but
the image ran out of space just before finishing.  Apparently I need a 2Tb
drive to image a 1Tb drive.

I also read the LUKS faq, but I must confess that much of it was "over my
head".

So . . .
Is there a way I can recover my data from USBHD005?

[-- Attachment #2: Type: text/html, Size: 6005 bytes --]

Re: [dm-crypt] Restored luks2 header to wrong drive!

[Michael Kjörling]

On 4 May 2020 23:07 -0400, from hunguponcontent@gmail.com (Default User):
> Immediately realizing what I had done, I used the Gnome "Disks" utility to
> unmount, "lock" and power off both USBSD003 and USBHD005. And then rebooted.

Sorry, but that -- especially the reboot -- was a mistake. Had you not
done that, it's possible that file system metadata would still have
been in RAM, and could perhaps have been at least partially recovered
that way. Once you rebooted, that door was closed.


> Is there a way I can recover my data from USBHD005?

First off, _forget about LUKS_ being involved here. What has really
happened is that you've overwritten the first few and the last few
megabytes of the partition. A partition which was previously formatted
as unencrypted ext4fs. (It would have been a very different matter if
it had been LUKS encrypted, in which case the answer unfortunately
almost certainly would have been that absent a header backup, your
data is irrecoverable. But that's not the situation you're in.) So
don't focus on _what_ you've overwritten that portion of the partition
with; look at ext4fs filesystem metadata overwrite recovery techniques
instead. (Which is off topic on this list.)

As long as you don't write _anything_ further to that drive, you have
a decent chance of getting most of your data back. Since the drive
itself still appears to be fully functional, even professional data
recovery services shouldn't be prohibitively expensive for the
purpose, were you to choose to go that route.

If you're serious about attempting data recovery, you really should
get yourself into a position where you can image the entire partition,
so that you can work on the image and let the current drive sit
_physically unplugged_ for the duration. A 2TB external USB HDD can
probably be had for $100-$150 or the local equivalent in, at least
most parts of, the Western world. And look at it this way: once you're
done, having that drive will allow you to have a second copy of this
highly important data.

-- 
Michael Kjörling • https://michael.kjorling.se • michael@kjorling.se
 “Remember when, on the Internet, nobody cared that you were a dog?”

Re: [dm-crypt] Restored luks2 header to wrong drive!

[Default User]

[-- Attachment #1: Type: text/plain, Size: 486 bytes --]

Well, thank you for your reply Michael.

Now I guess there is nothing left to do but grieve.

It is too late for me, but maybe someday, computer backups and encryption
will be "less art and more science".

Just a note: maybe LUKS could someday add a feature that would check before
restoring a luks2 header, and alert the user that they are trying to
restore to a different disk than the header was backed up from, or to a
disk that does not appear to contain LUKS encrypted data.

: (

[-- Attachment #2: Type: text/html, Size: 868 bytes --]

Re: [dm-crypt] Restored luks2 header to wrong drive!

[Robert Nichols]

On 5/5/20 8:39 AM, Default User wrote:
> 
> 
> Well, thank you for your reply Michael.
> 
> Now I guess there is nothing left to do but grieve.

testdisk is quite good at recovering partitioning and partially overwritten
filesystems. You can find testdisk at https://www.cgsecurity.org/wiki/TestDisk

Many recovery packages include testdisk. My own favorite is SystemRescueCd,
available from http://www.system-rescue-cd.org/

-- 
Bob Nichols     "NOSPAM" is really part of my email address.
                 Do NOT delete it.

Re: [dm-crypt] Restored luks2 header to wrong drive!

[Milan Broz]

On 05/05/2020 15:39, Default User wrote:
> 
> Just a note: maybe LUKS could someday add a feature that would check
> before restoring a luks2 header, and alert the user that they are
> trying to restore to a different disk than the header was backed up
> from, or to a disk that does not appear to contain LUKS encrypted
> data.

A generic warning is there:

# cryptsetup luksHeaderRestore /dev/sdb --header-backup-file /luks-bck.img

WARNING!
========
Device /dev/sdb does not contain LUKS2 header. Replacing header can destroy data on that device.

...

Just is should say what filesystem is there (we do this check on luksFormat already):
through libblkid:

# cryptsetup luksFormat /dev/sdb
WARNING: Device /dev/sdb already contains a 'ext4' superblock signature.
...

so it is really just trivial fix.

Milan

Re: [dm-crypt] Restored luks2 header to wrong drive!

[Carlos E. R.]

[-- Attachment #1.1: Type: text/plain, Size: 1789 bytes --]

On 05/05/2020 15.39, Default User wrote:
> 
> 
> Well, thank you for your reply Michael.
> 
> Now I guess there is nothing left to do but grieve.
> 
> It is too late for me, but maybe someday, computer backups and 
> encryption will be "less art and more science".

Data recovery software can at least recover most of your files. Just ask on another mail list or forum.

Ideas from my notes:  

PartedMagic CD.

PhotoRec


PhotoRec        camera cards.
                        http://www.cgsecurity.org/wiki/PhotoRec
f3              http://oss.digirati.com.br/f3/          recupera/analiza llaveros.

foremost        http://foremost.sourceforge.net/
                http://en.wikipedia.org/wiki/Foremost_(software)
                Foremost is a forensic data recovery program for Linux used to recover files using their headers, footers, and data structures through
                a process known as file carving.[3] Although written for law enforcement use, it is freely available and can be used as a general data recovery tool.[2]

        ext4magic       (from greg) - There is also some commercial software, apparently.

                http://www.pdatungsteno.com/2006/05/26/recuperar-datos-de-tarjetas-de-memoria-cds-o-discos-duros-tras-un-desastre/
                http://www.dzoom.org.es/noticia-1780.html
                http://www.freedownloadmanager.org/es/downloads/recuperación_de_tarjeta_flash_gratis/
                http://www.ondata.es/recuperar/dispositivos-fotograficos.htm

                Restorer Ultimate.      <http://www.restorer-ultimate.com/>  payware, good (windows).



If you have questions about that, feel free to ask me offlist.


-- 
Cheers / Saludos,

		Carlos E. R.
		(from 15.1 x86_64 at Telcontar)


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 261 bytes --]

Re: [dm-crypt] Restored luks2 header to wrong drive!

[Arno Wagner]

Not so fast!

ext2/3/4 does several superblock backups over the whole drive and
the directories are also distributed (but not replicated). 
As the LUKS2 header is not that large, most data and structure 
should be recoverable.

First step: Make a sector-image of the drive. Only work on the copy.
Second step: Find out how to recover an ext4 with overwritten start.
     -> This is not the right mailing-list for that question.  
        But there should be fairly generic instruction out there.
        Maybe there is an ext2/3/4 FAQ or recovery HOWTO?   

Regards,
Arno

On Tue, May 05, 2020 at 15:39:07 CEST, Default User wrote:
>    Well, thank you for your reply Michael.
>    Now I guess there is nothing left to do but grieve.
>    It is too late for me, but maybe someday, computer backups and
>    encryption will be "less art and more science".
>    Just a note: maybe LUKS could someday add a feature that would check
>    before restoring a luks2 header, and alert the user that they are
>    trying to restore to a different disk than the header was backed up
>    from, or to a disk that does not appear to contain LUKS encrypted
>    data.
>    : (

> _______________________________________________
> dm-crypt mailing list
> dm-crypt@saout.de
> https://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

Re: [dm-crypt] Restored luks2 header to wrong drive!

[Chris Murphy]

On Mon, May 4, 2020 at 9:10 PM Default User <hunguponcontent@gmail.com> wrote:
>
> Hi.
>
> I am sure you have heard this before.
>
> I have a computer running Debian unstable, Cinnamon desktop environment.  I have a testing usb thumb drive, labeled USBSDOO3,  which I formatted ext4, and encrypted with luks1, using the Gnome "disks" utility program.
>
> I then installed cryptsetup and used its "convert" option to change USBSD003 from luks1 to luks2.
>
> Then I used the cryptsetup header backup function to backup the luks2 header to my internal ssd drive. All good so far.
>
> Then, as a test, I tried to restore the luks2 header to USBSD003.
>
> Well, I made a HUGE mistake!
> USBSD003 was plugged in as device /dev/sdc1.
>
> But . . .
> I entered the command:
>
> Sudo cryptsetup luksHeaderRestore /dev/sdb1
> --header-backup-file \
> LUKS_header_backups/USBSD003_luks_header_backup_2020-05-04.
>
> Unfortunately, at /dev/sdb1 was a 1Tb usb external hard drive, one partition only, formatted ext4, UNENCRYPTED, labeled USBHD005. So I endeded up restoring the header to the hard drive, instead of to the thumb drive!

So the first step is, don't panic. And don't try to fix it. The more
writes you make without a plan, the greater the chance of permanent
data loss.

If you can, make a block copy of the drive so you can safely test
repairs. All repair attempts come with risk of making the problem
worse. If you can't make a copy of the drive, at least check this out:
https://raid.wiki.kernel.org/index.php/Recovering_a_failed_software_RAID#Making_the_harddisks_read-only_using_an_overlay_file

And it could even be useful if you do make a block copy, because then
you can iterate repair attempts before committing.

You might have to estimate what the offset was, if this drive was
partitioned, and whether the mistaken luks header restore stomped on
just the partition map. New partition tools create the first partition
at LBA 2048 (1MiB offset). If it's GPT, the backup may still be intact
and restorable. And speaking of old tools, grab a recent Live image of
Fedora or Arch, when you get down to recovery you want the latest
tools.

Anyway, since it's ext4, I'd search the ext4 list archives for prior
advice. And then once you have an initial strategy you can post it and
ask for a sanity check. Google finds a lot of ancient advice. It might
be valid.

-- 
Chris Murphy

Re: [dm-crypt] Restored luks2 header to wrong drive!

[Default User]

[-- Attachment #1: Type: text/plain, Size: 306 bytes --]

Hi to all.

Thank you for the encouragement.

Before doing anything else, I need to get at least a 2Tb drive.  (A spare
1Tb drive ran out of room, and would not hold both the image file and the
dd_rescue log file.)

Then I can use dd_rescue to image the "damaged" drive. And then work from
the image file.

[-- Attachment #2: Type: text/html, Size: 558 bytes --]