1

I have a 2 TB Western Digital MyBook I encrypted with LUKS over a year ago. A few months ago, I decided to be reckless and accidentally formatted the disk in Windows when trying to create a boot-able USB disk with different software. The drive was totally reformatted. But then, I put a GPT partition header (GUID partition table) on it with no data.

I use Linux Mint 22.1 as my default OS.

Long story short - the drive and partition are gone with a new GPT partition installed. This means the 'disks' app still shows the drive as /dev/sdc (which it is) but that it is "Unallocated Space".

To say that the data on this drive is important is an understatement.

I’ve looked through the following articles to try and address this issue, but to no avail:

When performing hexdump -C /dev/sdc | grep LUKS, for over an hour, I see the following:

4774f600 eb 02 92 95 54 d3 f2 e3 ca d1 4c 55 4b 53 e0 16 |....T.....LUKS..| 98ea5380 d7 01 bf 4c 55 4b 53 8c f2 24 43 72 9f 4a 63 94 |...LUKS..$Cr.Jc.| c7b54730 7c f3 4c 4c 55 4b 53 71 4c 47 40 69 96 53 57 12 ||[email protected].| 2963da820 04 75 9e 51 4c 55 4b 53 fe 1c 76 f6 30 ad c5 c1 |.u.QLUKS..v.0...| 495e522c0 aa e1 e4 ac 21 6c 29 4c 55 4b 53 b0 e9 98 63 b5 |....!l)LUKS...c.| 508fbcd90 ec 2e 2b 4e 59 1f 4c 55 4b 53 b7 27 18 1b 60 62 |..+NY.LUKS.'..`b| 59dde6680 d2 4c 55 4b 53 57 5f d3 f8 40 ce 4f d6 3e b0 83 |[email protected].>..| 7d4a7f640 70 9d 24 a6 05 d5 bd 4c 55 4b 53 67 c6 74 56 62 |p.$....LUKSg.tVb| 7f38a7520 ee 9d e8 1e 13 19 b2 28 55 e9 d8 4c 55 4b 53 1b |.......(U..LUKS.| 81bac7400 fc 10 90 53 a2 9e 78 d9 37 8c db b4 4c 55 4b 53 |...S..x.7...LUKS| 8ff10e9f0 4c 55 4b 53 9d a5 a7 67 a6 3d 5a e4 62 8b 20 39 |LUKS...g.=Z.b. 9| a51b31010 f0 4c 55 4b 53 d9 d7 e7 df 6e 03 53 9c 54 8a ef |.LUKS....n.S.T..| ca9ecb700 1e 53 df f2 4c 55 4b 53 b7 bf 24 86 89 00 49 06 |.S..LUKS..$...I.| ceb247eb0 47 4c 55 4b 53 c6 1c 95 d8 41 86 19 d0 e9 74 c9 |GLUKS....A....t.| e6521bb10 45 ff ec cd 68 a5 58 bf b1 4c 55 4b 53 5b 14 51 |E...h.X..LUKS[.Q| ead66c2e0 d0 6b 8d a0 c3 cf 4c 55 4b 53 1b 14 86 01 a2 c2 |.k....LUKS......|

I created an image of the disk (image.dd).

When following frostschutz' procedure for "cryptsetup repair, Part Two — Full Header Recovery"

(Overwritten LUKS with a partition table)

Step 1: Result of metadata recovery: stdbuf -oL strings -n 64 -t d image.dd | grep '"keyslots":'

20480 {"keyslots":{"0":{"type":"luks2","key_size":64,"af":{"type":"luks1","stripes":4000,"hash":"sha256"},"area":{"type":"raw","offset":"32768","size":"258048","encryption":"aes-xts-plain64","key_size":64},"kdf":{"type":"argon2id","time":12,"memory":1048576,"cpus":4,"salt":"5JN08SD5Z1cryqRFiQvn+JensssvRMuayF2jHXKjGDY="}}},"tokens":{},"segments":{"0":{"type":"crypt","offset":"16777216","size":"dynamic","iv_tweak":"0","encryption":"aes-xts-plain64","sector_size":512}},"digests":{"0":{"type":"pbkdf2","keyslots":["0"],"segments":["0"],"hash":"sha256","iterations":313944,"salt":"cHPpJJpF2ivqLjkyTTJmKmqVcVSaRqN0L0V+yx0La+E=","digest":"COHktekQxX/2Jfq4ro8hqDweVOmom5bGAPa23nzkEV0="}},"config":{"json_size":"12288","keyslots_size":"16744448"}}

Valid JSON string found at offset 20480....

After following the entire procedure to its end (working on the image.dd) it keeps saying "Device luks.recovery is not a valid LUKS device."

Is this pointless? If I can see LUKS keyslots, the offsets, etc, then am I just doing this wrong?

Thanks!

Improve this question
6
  • 1
    If it was LUKS 2 and the linked guide (part two in particular) does not help then it's probably gone, sorry. The string LUKS is only 4 bytes, so it's not at all uncommon to encounter it in random data. Read a few gigabytes of /dev/urandom and you'll probably find it there too. E.g. pv < /dev/urandom | grep -m 1 LUKS. Also LUKS only appears at the very start of the header so it's the first thing that gets wiped. The guide uses a more specific search string for this reason… Commented Apr 12 at 19:57
  • 1
    I assume you have not made a backup of the LUKS header. That's why I use the same header on different drives in different computers. You never know... But what exactly does "the drive and partition are gone" mean? Did you format the partition which had the LUKS header or did you format the whole drive, overwriting the partition table? Commented Apr 12 at 20:15
  • To be frank, its late in Europe right now so I need to do some more work tomorrow (Sunday). I have not tried the entire part 2 process identified above yet. Commented Apr 12 at 20:55
  • Also for the person who asked "What does the drive and partition are gone mean?" I am trying to explain that the 'disks' app still shows the drive as /dev/sdb (which it is) but that it is "Unallocated Space". Commented Apr 12 at 20:57
  • I think the valid json part must start at 0x0200 and not at 20480 which is 0x5000. run: dd if=image.dd bs=512 skip=0 count=1 2>/dev/null | hexdump -C | grep LUKS and you're looking for something like: 00000000 4c 55 4b 53 00 02 ... => "LUKS\x00\x02". If you don't find it at offset 0, then scan the image.dd file for it with something like grep -aboa 'LUKS' image.dd. If you confirm that LUKS start at 20480, you can try to open from that offset with sudo cryptsetup luksOpen --type luks2 --offset 40 image.dd luks_img Commented Jul 11 at 8:04

1 Answer 1

Reset to default
0

What I would do in your case is to make an image of the disk with testdisk and after to work on a copy of the image to try to undelete LUKS partition

testdisk programm and its documentation can be found here: https://www.cgsecurity.org/wiki/TestDisk

  • make an image of the drive with testdisk
  • copy this disk image (make a backup)
  • re-open the copy of the disk image with testdisk and select the drive and try to undelete partition

To make a disk image with testdisk you can use:

testdisk /log /debug /dev/sdb

and follow the menu to create a disk image.

To try to undelete partition, first analyse the disk image with testdisk and follow the detailed process on the wiki : https://www.cgsecurity.org/testdisk_doc/partition_recovery.html

As you told that recovering data is not an option, if your recover the partition but if it's damaged you can use testdisk to try to undelete files from the partition (see detailed guide: https://www.cgsecurity.org/testdisk_doc/undelete.html).

If later you need a more fine recovery tool (a file level recovery tool) you can try to use photorec from the same author (also very well documented, follow the process here: https://www.cgsecurity.org/testdisk_doc/photorec.html)

I would also recommend to never work directly on the physical disk you're trying to recover. The idea is to always make a disk image (block device copy), to copy it to a safe place as a backup and to work on a second copy of the image

NB: testdisk is referenced here for Linux Mint: https://community.linuxmint.com/software/view/testdisk

testdisk program (included photorec) seems to be available under Linux Mint directly through apt, try:

sudo apt update sudo apt install testdisk
Improve this answer
5
  • Thank you all for the help so far. Now that I am back from a trip, I have time to focus on this recovery effort. I did create the image file on a separate drive and made a backup. Following the link on recovery shortly. Will post what I find out. Commented Apr 19 at 6:19
  • Ok, on Easter Sunday morning I ran 'sudo testdisk image.dd'. After doing a quick and then deep search for a partition on the image, it found nothing. Commented Apr 20 at 7:19
  • When I run "sudo testdisk image.dd" on the image, and select the first option, "Intel" - Intel/PC partition", then "analyze" testdisk reports: Partition sector doesn't have the endmark 0xAA55. If I try with the option "EFI GPT", and "analyze" it reports that I have a bad GPT partition, invalid signature. Any ideas how to proceed? Commented Jul 6 at 8:14
  • I also don't think I addressed one of the questions from before about formatting the partition. I accidentally formatted the entire drive. Commented Jul 6 at 8:20
  • When the disk was originally configured, did it use gpt or mbr for the partition table? If you reconfigured the disk using gpt when the original was mbr, this might cause problems. And, not to throw salt into the wound, but "important data" should always be backed up. Commented Jul 9 at 19:28

You must log in to answer this question.

Start asking to get answers

Find the answer to your question by asking.

Ask question

Explore related questions

See similar questions with these tags.