4

I have a drive with 2 partitions

  • 1st is plain ext4
  • 2nd is encrypted LUKS.

The partition table has been overwritten. I've found the beginning of the second partition, which I need to recover, thusly:

# hexdump -s 400000m -C /dev/sdc | grep LUKS
61d3dec850 79 c8 81 6d e5 4c 55 4b 53 40 49 aa 29 df de d7 |y..m.LUKS@I.)...|

Also:

# losetup -o 0x61d3dec850 -r -f /dev/sdc
# losetup -a
/dev/loop0: [0005]:477209 (/dev/sdc), offset 420166420560

So far, this problem pops up:

# cryptsetup luksOpen /dev/loop0 luksrecover
Device /dev/loop0 is not a valid LUKS device.

Is it wrong offset? Should I seek for the magic number 0xEF53 identifying ext4 as adviced here ?

It's a 1TB drive so please, I need an advice that does not force a scan of the entire drive all over again (e.g. testdisk which seems have no option to start at a specified offset to save time on scanning).

P.S. This question seems to be closely related but does not match.

Improve this question
5
  • Just a idea from binary logic: did you may have missed the offset by one bit?
    – Fabian N.
    Commented Jan 6, 2015 at 21:57
  • How would that happen? I suspect it's more likely a false positive on LUKS finding as already has been suggested here serverfault.com/questions/656752/luks-partition-recovery#656768 . I recall experimenting with cryptsetup on this drive prior to the final implementation and it could be remnants of that. I'll keep seeking for more LUKS hits.
    – hexedone
    Commented Jan 7, 2015 at 1:57
  • I wish happy hunting (But thanks for the remainder to backup the header data / partition table)
    – Fabian N.
    Commented Jan 7, 2015 at 2:08
  • Indeed, indeed. I have the LUKS headers saved , but not the partition table. Lesson learned.
    – hexedone
    Commented Jan 7, 2015 at 2:16
  • If you have a backup of the header (a real backup, which is usually >1MB in size, not just a luksDump), recovery is possible. Same if you actually find the real header intact. What you showed is not a LUKS header.
    – frostschutz
    Commented Jan 7, 2015 at 3:29

1 Answer 1

Reset to default
3 
dd if=/dev/mapper/storage2-crypto bs=16 count=1 2>/dev/null | 
  od -t c -t x1
0000000   L   U   K   S 272 276  \0 001   a   e   s  \0  \0  \0  \0  \0
         4c  55  4b  53  ba  be  00  01  61  65  73  00  00  00  00  00

That's what it looks like on my system. See https://gitlab.com/cryptsetup/cryptsetup/wikis/LUKS-standard/on-disk-format.pdf (page 6)

The first six bytes must be the same, most probably the first eight and probably the first 16+. You have found a string with LUKS but obviously the wrong one as LUKS@I is not the magic bytes.

Look for the right data; that should give you the correct position.

Improve this answer

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .