Timeline for Overwritten LUKS with a partition table
Current License: CC BY-SA 4.0
19 events
| when toggle format | what | by | license | comment | |
|---|---|---|---|---|---|
| S May 4, 2023 at 9:19 | history | bounty ended | Chris Davies | ||
| S May 4, 2023 at 9:19 | history | notice removed | Chris Davies | ||
| S May 1, 2023 at 15:31 | history | bounty started | Chris Davies | ||
| S May 1, 2023 at 15:31 | history | notice added | Chris Davies | Reward existing answer | |
| Apr 4, 2023 at 1:11 | vote | accept | sataoverflow | ||
| Apr 4, 2023 at 0:09 | answer | added | frostschutz | timeline score: 19 | |
| Mar 31, 2023 at 1:06 | comment | added | sataoverflow | Let us continue this discussion in chat. | |
| Mar 31, 2023 at 0:10 | comment | added | sataoverflow | I guess I'm confused then, I think I understand what I'm seeing is the half intact second header. Then what does the key portion look like? | |
| Mar 31, 2023 at 0:09 | history | edited | sataoverflow | CC BY-SA 4.0 | deleted 955 characters in body |
| Mar 30, 2023 at 22:33 | comment | added | frostschutz | Slight confusion here. The JSON you posted above should be the backup header. The key material on the other hand exists only once. Can't say more since I don't know what your header looks like. You need either primary or backup header to be intact. And then you also need intact key material (there is no backup of that). | |
| Mar 30, 2023 at 22:11 | history | edited | sataoverflow | CC BY-SA 4.0 | Closure |
| Mar 30, 2023 at 21:36 | comment | added | sataoverflow | @frostschutz The post you linked was a great explainer, but it seems in my data is lost. The primary luks slot is mockingly overwritten with Invalid partition table 5 times, and the backup header is simply zero'd over with no trace to be found in my hex editor. I appreciate the help, better to find find out in less than 24 hours than to waste 2 weeks. A hard lesson for me to update my backups more often than once a year. Ill update my post for future onlookers accordingly. Thanks again for the help. | |
| Mar 30, 2023 at 20:33 | comment | added | frostschutz | then try and see if the repair method I linked works for you | |
| Mar 30, 2023 at 20:31 | history | edited | sataoverflow | CC BY-SA 4.0 | Luks Dump without greps shows some intact luks JSON |
| Mar 30, 2023 at 20:22 | comment | added | sataoverflow | @frostschutz It was treated as a single device, I'm not sure which of the two it was, but you gave me the perfect command to run, because it gave me some hope. I can see an entire block of luks JSON! Im not sure if its fully intact, it looks like just before the block it might have gotten overwritten, How do I tell if its fully intact? It starts with this 00005000 7b 22 6b 65 79 73 6c 6f 74 73 22 3a 7b 22 30 22 |{"keyslots":{"0"| | |
| Mar 30, 2023 at 10:57 | comment | added | frostschutz | Was the drive partitioned before? If not then the LUKS header would simply sit at offset 0 (and die as soon as anything creates a partition table) and you could check hexdump -C in full (no grep). If it was partitioned, was it a single partition? That would usually be offset 1 MiB these days. Scanning the entire drive for the offset is only useful if you had multiple partitions and LUKS was only one of them at an unknown offset. You can also use strings -t d -n 4 /dev/disk | less and see if any LUKS related strings pop up (aes-xts etc.) for LUKS 2 this would show JSON metadata strings | |
| Mar 30, 2023 at 10:47 | comment | added | frostschutz | | grep LUKS does not help for overwritten headers. This might be your only chance: cryptsetup repair (only for LUKS 2) but you have to know the correct offset and find one of LUKS JSON metadata strings first. Damaged key material cannot be recovered. Unfortunately in a lot of these cases even a slightly damaged LUKS header simply means "game over". | |
| S Mar 30, 2023 at 3:50 | review | First questions | |||
| Mar 30, 2023 at 13:54 | |||||
| S Mar 30, 2023 at 3:50 | history | asked | sataoverflow | CC BY-SA 4.0 |