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? 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. Commented Jan 7, 2015 at 1:57
  • I wish happy hunting (But thanks for the remainder to backup the header data / partition table) Commented Jan 7, 2015 at 2:08
  • Indeed, indeed. I have the LUKS headers saved , but not the partition table. Lesson learned. 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. 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.

Start asking to get answers

Find the answer to your question by asking.

Ask question

Explore related questions

See similar questions with these tags.