Windows 10 Boot loader broke my Linux LUKS disk

Question

I have 3 disks:

1. Main OS (CentOS)
2. HDD encrypted with LUKS for data (Hardware RAID10, LSI Logical Volume)
3. Windows 10 (Recently installed for testing)

My problem is when I installed Windows 10, it broke my LUKS disk by creating a boot loader on it... Now I can't decrypt my disk and I really need my data.

Can I revert the process with Gparted or other tool ? I hope my data is not destroyed by that boot loader...

I really need help please !

EDIT 1 Added some information

fdisk -l

Disk /dev/sda: 12000.0 GB, 11999999164416 bytes, 23437498368 sectors
Units = sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 4096 bytes
I/O size (minimum/optimal): 4096 bytes / 4096 bytes
Disk label type: dos
Disk identifier: 0x385dcf68

   Device Boot      Start         End      Blocks   Id  System
/dev/sda1   *        2048     1026047      512000    7  HPFS/NTFS/exFAT

After the answer of Xen2050 here is my result:

LANG=C grep -obUaP "\x4C\x55\x4B\x53\xBA\xBE" /dev/sda

164822601573:LUKS��

Then hope is returned!

I dd my header with block size of 1 bytes with that

dd if=/dev/sda of=luks_header bs=1 skip=164822601573 count=2097152

Now I have my luks header, I can confirm it start with LUKS with vi

LUKSº¾^@squashfs^@sqsh^@hsqs^@lvm2pv^@LVM2 001^@btrfs^@

Now the next step is to rewrite my luks header...

EDIT 2 Added developement

From this unix.stackexchange: https://unix.stackexchange.com/questions/177831/recovering-a-luks-partition

I found the start if my header

hexdump -s 164822601573 -C /dev/sda | grep LUKS
2660314f65  4c 55 4b 53 ba be 00 73  71 75 61 73 68 66 73 00 |LUKS...squashfs.|

Set up loop devices

losetup -o 0x2660314f65 -r -f /dev/sda
losetup -a
cryptsetup luksOpen /dev/loop0 luksrecover

But I have this message error message:

Unsupported LUKS version 115.

I think my header is corrupted... Here is the beginning of mine:

|LUKS...squashfs.|
|sqsh.hsqs.lvm2pv|
|.LVM2 001.btrfs.|
|_BHRfS_M.f2fs.. |
|...<device.</dev|
|ice>.PRI.TIME.DE|
|VNO.%s-XXXXXX.w.|
| PRI="%d".>%s</d|
|evice>.. %s="%s"|
|.%s.old.1.42.9.2|
|8-Dec-2013......|
|................|
*
|...............d|
|.... n;.0.&.A.v.|
|QkkXa.M<q.P ...D|
|.........a...d..|
|...x............|
|.............T..|
|..........@.....|
|.i@<device DEVNO|
|="0x%04lx" TIME=|
|"%ld"...........|

And here is a functional header

|LUKS....aes.....|
|................|
|........xts-plai|
|n64.............|
|........sha1....|
|................|
|............... |
|2x.l...r0....8|.|
|...'..[!D..J..tp|
|....?J...~.x"s.=|
|.?.....]981be66e|
|-a0b0-4daa-8a2c-|
|5a6e5d8ed3ae....|
|..q....ZG..}#..,|
|...w..!|..3..>.?|
|.;.&...-........|
|................|
|................|

Answer 1

Really, a backup of the LUKS header is what you need. But, maybe it's possible that it actually wasn't overwritten and only the disk partition table was messed up and you can't find the start of the LUKS device.

The LUKS header actually begins with the characters LUKS then two non-ascii characters 0xba and 0xbe, so you could search your entire disk looking for that string. All in hex, it's

4C 55 4B 53 BA BE

Have a Program Search

PhotoRec should be able to find LUKS headers/files and it's in the Debian & Ubuntu sources, and available for Windows too, tell it to search your entire drive.

Or try TestDisk too (from the same author), it can try searching for lost partitions & may find the LUKS one.

---

Search "yourself"

Or, you could search the entire drive kind of "yourself" byte-by-byte, with your favourite hex editor (Bless is nice) or with grep on linux (found from this other Q):

LANG=C grep -obUaP "\x4C\x55\x4B\x53\xBA\xBE" /dev/your-hard-drive-device

Without the initial LANG=C setting it wasn't working for me, my usual "language" is apparently UTF-8, and those options are the short form of --only-matching --byte-offset --binary --text --perl-regexp see man grep or info grep)

It should output the byte where the LUKS header starts, if it finds one. You could then use dd to copy the LUKS container somewhere safe, or use that info to create a partition that starts at the right spot, though making a backup copy first would be safest, you don't want to overwrite the header by mistake.

• For example:

  $ LANG=C grep -obUaP "\x4C\x55\x4B\x53\xBA\xBE" file
  5242880:LUKS��
  

  Here, it's 5,242,880 bytes into the file (in linux everything's a file, the whole hard drive too, for example /dev/sdb).

Now's a good time to make a header backup, they're 1M or 2M long, so copy the next 2M with dd.

dd requires a little math to figure out a good block size (-bs), it tends to read extremely slow with a low block size, the default 512 bytes is probably too slow for more than a few megabytes on a hard drive, 1M (1048576 bytes,dd` knows M, G, K, etc) should be ok.

• In the above example, it happens to be exactly 5M from the start (5242880 / 1048576 = 5) so this command would copy from 5M to the end of the file/device, writing to the file outfile (in the current directory):

  dd if=file of=outfile bs=1M skip=5
  

For a header-only backup, you could use count=N to stop copying after N blocks, just figure out how many blocks of your selected bs= are in 2 megabytes, above it would be just 2. See dd's help for info.