| View previous topic :: View next topic |
| Author |
Message |
avdb
n00b
Joined: 16 Aug 2020
Posts: 65
Location: Netherlands
|
 Posted: Fri Aug 28, 2020 2:38 pm Post subject: [SOLVED] My root partition disappeared when using testdisk |
 |
|
This morning I was planning on deleting Windows 10 completely for good so I opened up Gparted, deleted the partition, and called it a day. No, there was something wrong.
I forgot to check if there was anything I saved on Windows that might've been important to me. So I installed the Gparted ISO, rebooted my computer, went looking for my deleted partition but without success. It only found my EFI partition. In the process of doing this it seems like I accidentally wrote the changes to my disk.
My root partition was a LUKS encrypted, with Btrfs as it's filesystem. It contained literally everything important that I had on my computer. Prior to this I already lost all my data on my LVM with LUKS partition because of how difficult it is to make basic changes to Logical Volumes.
I'm pretty sure that there's still a way to get my data back, but I don't have the correct knowledge to do so. Testdisk is only able to find Microsoft Data on my partition which is clearly not what I'm looking for. If you know other tools I can try, or a possible solution, let me know below. Thanks in advance.
Last edited by avdb on Sat Aug 29, 2020 4:52 am; edited 1 time in total |
|
| Back to top |
|
 |
NeddySeagoon
Administrator
Joined: 05 Jul 2003
Posts: 54311
Location: 56N 3W
|
| Posted: Fri Aug 28, 2020 4:59 pm Post subject: |
|
|
avdb,
| Douglas Adams wrote: | | Don't Panic! |
Your partition table is only a set of pointers to your data. Removing or destroying the partition table makes it inconvenient to get at your filesysems.
They are safe and well though, just difficult to access.
Testdisk should find everything and some false positives besides. I think you seed a deep scan.
Do not let testdisk write the partition table. We need to weed out the false positives first.
Copy and paste what it finds, or at least, post it without copy typing.
Once we know where testdisk thinks partitions start, we can convert that to an offset in bytes from the start of the disk and feed it to mount.
Your first partition will start at block 2048. A block is 512bytes,
| Code: | | mount -o offset=1048576,ro /dev/sda /mnt/<someplace> |
Will try to mount the filesystem that starts 1048576 bytes from the start of the drive, read only, at /mnt/<someplace>
No partition table required.
Testdisk will report other starting blocks.
Note that the above does not work for Logical Volumes as the LVM metadata, not a filesystem, is at the start of the partition.
_________________
Regards,
NeddySeagoon
Computer users fall into two groups:-
those that do backups
those that have never had a hard drive fail. |
|
| Back to top |
|
|
avdb
n00b
Joined: 16 Aug 2020
Posts: 65
Location: Netherlands
|
| Posted: Fri Aug 28, 2020 5:19 pm Post subject: |
|
|
| NeddySeagoon wrote: |
Your partition table is only a set of pointers to your data. Removing or destroying the partition table makes it inconvenient to get at your filesysems.
They are safe and well though, just difficult to access.
|
Not just difficult, most likely extremely difficult since I will first need to run "cryptsetup open /dev/sdbX (forgot the partition number)" to open the partition with my encryption password.
This is the output of a deep search with testdisk, it seems to be tottaly confused about what's on my drive because I never created an HFS partition:
| Code: |
TestDisk 7.1, Data Recovery Utility, July 2019
Christophe GRENIER <grenier@cgsecurity.org>
https://www.cgsecurity.org
Disk /dev/sdb - 250 GB / 232 GiB - CHS 30401 255 63
The harddisk (250 GB / 232 GiB) seems too small! (< 2184 GB / 2034 GiB)
Check the harddisk size: HD jumper settings, BIOS detection...
The following partitions can't be recovered:
Partition Start End Size in sectors
> Mac HFS 331467640 4190228089 3858760450
Mac HFS 407921528 4266681977 3858760450
MS Data 487343834 974448052 487104219
MS Data 488394751 489445374 1050624
MS Data 488396799 976553982 488157184
|
I'm having a hard time determining which one was is the correct partition since I can't access a single on of them to list the files and I only have the EFI partition left. I also know that it's 180GB. Unless you're really good at recovering lost data on Linux (which I'm not) I don't see a solution anytime soon.
https://forum.cgsecurity.org/phpBB3/viewtopic.php?t=8399
From what I found on the cgsecurity forum it seems like the sector size on Btrfs filesystems is by default wrong (4096 in my and his case).
I'm 100% sure that my LUKS header is still available on the disk because when I perform a hexdump I can still find it's data:
| Code: | | hexdump -C /dev/sdb | grep LUKS |
Output:
| Code: |
01fc7370 73 20 64 65 6e 69 65 64 00 4c 55 4b 53 ba be 00 |s denied.LUKS...|
0201a370 73 20 64 65 6e 69 65 64 00 4c 55 4b 53 ba be 00 |s denied.LUKS...|
0206d370 73 20 64 65 6e 69 65 64 00 4c 55 4b 53 ba be 00 |s denied.LUKS...|
020c0370 73 20 64 65 6e 69 65 64 00 4c 55 4b 53 ba be 00 |s denied.LUKS...|
0c0711a0 73 74 65 6d 64 2d 62 6f 6f 74 2c 20 4c 55 4b 53 |stemd-boot, LUKS|
0c0715e0 2c 20 4c 55 4b 53 2c 20 61 6e 64 20 62 74 72 66 |, LUKS, and btrf|
0c071700 20 4c 55 4b 53 2c 20 61 6e 64 20 62 74 72 66 73 | LUKS, and btrfs|
1bc35640 2d 63 72 79 70 74 5f 77 69 74 68 5f 4c 55 4b 53 |-crypt_with_LUKS|
1bcb0b60 63 72 79 70 74 5f 77 69 74 68 5f 4c 55 4b 53 48 |crypt_with_LUKSH|
1bcb0c60 74 68 5f 4c 55 4b 53 0d 0a 58 2d 53 61 76 65 3a |th_LUKS..X-Save:|
1bcb0c90 2d 63 72 79 70 74 5f 77 69 74 68 5f 4c 55 4b 53 |-crypt_with_LUKS|
1bcba390 2e 6f 72 67 2f 77 69 6b 69 2f 4c 55 4b 53 22 3e |.org/wiki/LUKS">|
1bcbaa00 32 43 5f 64 65 74 61 63 68 65 64 5f 4c 55 4b 53 |2C_detached_LUKS|
1bcbaa80 20 64 65 74 61 63 68 65 64 20 4c 55 4b 53 20 68 | detached LUKS h|
1bcbaaf0 65 74 61 63 68 65 64 5f 4c 55 4b 53 5f 68 65 61 |etached_LUKS_hea|
1bcbab40 74 61 63 68 65 64 20 4c 55 4b 53 20 68 65 61 64 |tached LUKS head|
1bcbc2e0 70 3e 4c 55 4b 53 20 75 73 65 73 20 3c 61 20 68 |p>LUKS uses <a h|
1bcbc8e0 2c 5f 64 65 74 61 63 68 65 64 5f 4c 55 4b 53 5f |,_detached_LUKS_|
1bcbc950 65 64 5f 4c 55 4b 53 5f 68 65 61 64 65 72 73 2e |ed_LUKS_headers.|
1bcbc990 20 64 65 74 61 63 68 65 64 20 4c 55 4b 53 20 68 | detached LUKS h|
1bcbcb60 4c 55 4b 53 20 68 65 61 64 65 72 20 69 74 73 65 |LUKS header itse|
1bcbcd00 64 3d 22 44 65 74 61 63 68 65 64 5f 4c 55 4b 53 |d="Detached_LUKS|
1bcbcd20 64 20 4c 55 4b 53 20 68 65 61 64 65 72 3c 2f 73 |d LUKS header</s|
1bcbcd70 20 4c 55 4b 53 20 68 65 61 64 65 72 20 28 77 68 | LUKS header (wh|
1bcbcf40 68 65 64 20 4c 55 4b 53 20 68 65 61 64 65 72 20 |hed LUKS header |
1bcbd380 65 74 61 63 68 65 64 20 4c 55 4b 53 20 68 65 61 |etached LUKS hea|
1bcbe4b0 69 6e 67 20 61 20 4c 55 4b 53 20 63 6f 6e 74 61 |ing a LUKS conta|
1bcc02c0 43 72 79 70 74 20 4c 55 4b 53 20 6f 6e 20 74 6f |Crypt LUKS on to|
1bcc0370 72 79 70 74 20 4c 55 4b 53 2c 20 44 4d 2d 43 72 |rypt LUKS, DM-Cr|
1bcc0380 79 70 74 20 4c 55 4b 53 20 6f 6e 20 74 6f 70 20 |ypt LUKS on top |
1bcc04f0 20 4c 56 4d 2f 4c 55 4b 53 20 61 6e 64 20 72 65 | LVM/LUKS and re|
1bd047c0 20 63 6f 6e 74 61 69 6e 65 72 20 28 4c 55 4b 53 | container (LUKS|
1bea8600 69 74 68 5f 4c 55 4b 53 2e 68 74 6d 6c 22 20 63 |ith_LUKS.html" c|
1bea8630 70 74 20 77 69 74 68 20 4c 55 4b 53 22 3e 44 6d |pt with LUKS">Dm|
1bea8640 2d 63 72 79 70 74 20 77 69 74 68 20 4c 55 4b 53 |-crypt with LUKS|
1bef3390 72 20 4c 55 4b 53 20 65 6e 63 72 79 70 74 69 6f |r LUKS encryptio|
1bef35a0 20 4c 55 4b 53 20 64 65 76 69 63 65 2c 20 61 64 | LUKS device, ad|
27600000 4c 55 4b 53 ba be 00 01 73 65 72 70 65 6e 74 00 |LUKS....serpent.|
<Supressed output ...>
|
|
|
| Back to top |
|
|
avdb
n00b
Joined: 16 Aug 2020
Posts: 65
Location: Netherlands
|
| Posted: Fri Aug 28, 2020 5:25 pm Post subject: |
|
|
Seems like I made a mistake. Those are the UNRECOVERABLE partitions. These are the partitions Testdisk finds that ARE recoverable:
| Code: |
TestDisk 7.1, Data Recovery Utility, July 2019
Christophe GRENIER <grenier@cgsecurity.org>
https://www.cgsecurity.org
Disk /dev/sdb - 250 GB / 232 GiB - CHS 30401 255 63
Partition Start End Size in sectors
D MS Data 370208355 370214528 6174
D MS Data 370214528 370220701 6174 [Boot]
D MS Data 370980863 372031486 1050624
D MS Data 405424128 446384120 40959993
D MS Data 405424135 446384127 40959993
D EFI System 409051260 409182331 131072 [EFI System Partition] [ARCHISO_EFI]
D MS Data 410018275 410024448 6174
D MS Data 410024448 410030621 6174 [Boot]
D MS Data 410024467 410030640 6174
D MS Data 410030640 410036813 6174 [Boot]
D MS Data 410030659 410036832 6174
D MS Data 410036832 410043005 6174 [Boot]
D MS Data 410036851 410043024 6174
D MS Data 410043024 410049197 6174 [Boot]
D EFI System 410049368 410052247 2880 [EFI System Partition] [EFISECTOR]
D EFI System 410058784 410061663 2880 [EFI System Partition] [EFISECTOR]
D MS Data 445333505 446384128 1050624
>D MS Data 446384127 487344119 40959993
D MS Data 446384128 447434751 1050624
D MS Data 446662243 446668416 6174
D MS Data 446668416 446674589 6174 [Boot]
D MS Data 447434751 448485374 1050624
D MS Data 486293505 487344128 1050624
D MS Data 487344128 488394751 1050624
D MS Data 487622243 487628416 6174
D MS Data 487628416 487634589 6174 [Boot]
Structure: Ok. Use Up/Down Arrow keys to select partition.
Use Left/Right Arrow keys to CHANGE partition characteristics:
P=Primary D=Deleted
Keys A: add partition, L: load backup, T: change type, P: list files,
Enter: to continue
NTFS, blocksize=4096, 20 GB / 19 GiB
|
|
|
| Back to top |
|
|
NeddySeagoon
Administrator
Joined: 05 Jul 2003
Posts: 54311
Location: 56N 3W
|
| Posted: Fri Aug 28, 2020 5:30 pm Post subject: |
|
|
avdb,
None of those partition are correct.
I guess you had EFI, swap and LUKS for everything else?
If your EFI partition is still there, the next partition will start in the following block. It need not but you have go to to some trouble to leave gaps.
Does the EFI partition mount without errors?
Please post your partition table as it is now.
-- Edit --
Select a partition and try to read the files.
If that works the partition start is a filesystem start.
If it fails, you may be looking at your LUKS start.
Do you remember how many partition there were?
_________________
Regards,
NeddySeagoon
Computer users fall into two groups:-
those that do backups
those that have never had a hard drive fail. |
|
| Back to top |
|
|
avdb
n00b
Joined: 16 Aug 2020
Posts: 65
Location: Netherlands
|
| Posted: Fri Aug 28, 2020 5:38 pm Post subject: |
|
|
| NeddySeagoon wrote: |
Do you remember how many partition there were? |
No ... not really. But I had Windows 10 installed so all I know is that first came the EFI partition with the Microsoft Reserved one, after that the Gentoo partition which was the biggest, and following up was the Windows partition directly aligned against the previous one. I remember leaving a good 40GB of space empty because I'm using an SSD.
I didn't use Swap yet because I was planning on doing it later when I had time to figure out how to implement plain dm-crypt (Swapfile doesn't work on Btrfs). All the mount points including /boot were on the Btrfs filesystem except the EFI partition that I told you a hundred times about. |
|
| Back to top |
|
|
Hu
Administrator
Joined: 06 Mar 2007
Posts: 21715
|
| Posted: Fri Aug 28, 2020 6:25 pm Post subject: |
|
|
| avdb wrote: | | I forgot to check if there was anything I saved on Windows that might've been important to me. So I installed the Gparted ISO, rebooted my computer, went looking for my deleted partition but without success. It only found my EFI partition. In the process of doing this it seems like I accidentally wrote the changes to my disk. |
Is it fair to assume you also did not save any copies of the partition table, and you no longer have any recorded copies of when you wrote the original partition table? No handmade notes planning out what you would put where, etc.? | avdb wrote: | | My root partition was a LUKS encrypted, with Btrfs as it's filesystem. It contained literally everything important that I had on my computer. |
Do you have a backup of the important data? | avdb wrote: | | Prior to this I already lost all my data on my LVM with LUKS partition because of how difficult it is to make basic changes to Logical Volumes. |
Could you expand on this? Logical Volumes are actually easier to manage than regular partitions because you can dynamically resize them, and the extra layer of abstraction minimizes the need to reserve space in specific locations for later use. | avdb wrote: | | Not just difficult, most likely extremely difficult since I will first need to run "cryptsetup open /dev/sdbX (forgot the partition number)" to open the partition with my encryption password. |
The partition number is not important yet. You will need to lay down a new partition table, once we identify where the partition boundaries are. When you do that, you will get a value for X. Remembering the old X would not help you now, because it's just an index into an array you no longer have. | avdb wrote: | | This is the output of a deep search with testdisk, it seems to be tottaly confused about what's on my drive because I never created an HFS partition: |
Testdisk is searching for patterns that may indicate the presence of certain predefined objects (LUKS containers, LVM Physical Volumes, swap, filesystems, etc.). These patterns can occur incidentally, since some of the signatures it seeks are not long enough to be statistically impossible to occur by accident. | avdb wrote: | | I'm having a hard time determining which one was is the correct partition since I can't access a single on of them to list the files |
Whichever one is correct would need to be accessed by opening a LUKS device at that offset, then treating the resulting decryption device as a btrfs filesystem. You can't list the files until you have LUKS open, and you can't open LUKS until you know where it starts. | avdb wrote: | | I also know that it's 180GB. |
That helps. You wrote later that you left 40G unused, so we know the target area must be at least (180G+40G) before the end of the drive. We also know that most tools strongly encourage you to align on certain boundaries. | avdb wrote: | | I'm 100% sure that my LUKS header is still available on the disk because when I perform a hexdump I can still find it's data: |
For me, and I think this would be standard, the LUKS signature starts at the very beginning of the containing partition. You can probably rule out every hit that does not end 00. You may be able to add more 0s to that suggestion, but we would need to know details about your old partition scheme to know how many 0s to add. | avdb wrote: | | Code: | | 27600000 4c 55 4b 53 ba be 00 01 73 65 72 70 65 6e 74 00 |LUKS....serpent.| |
|
I like the look of this one. Could you dump and show 64 bytes starting at that offset? | avdb wrote: | | I didn't use Swap yet because I was planning on doing it later when I had time to figure out how to implement plain dm-crypt (Swapfile doesn't work on Btrfs). |
This is fairly straightforward. LUKS is a nice frontend to dm-crypt, and swap inside a LUKS container works fine. You can have one LUKS container for swap, and a separate one for persistent data. |
|
| Back to top |
|
|
avdb
n00b
Joined: 16 Aug 2020
Posts: 65
Location: Netherlands
|
| Posted: Fri Aug 28, 2020 6:31 pm Post subject: |
|
|
After having to redo the Testdisk scan 4 times because I kept accidentally quitting it and there's no way to export results, it took a while, but here's the result of the partitions that are still possible to list files:
| Code: | EFI System 2048 206847 204800 [EFI System Partition] [EFI]
MS Data 328970240 369930232 40959993
MS Data 333570560 333576733 6174 [Boot]
MS Data 333576752 333582925 6174 [Boot]
MS Data 333582944 333589117 6174 [Boot]
MS Data 333589136 333595309 6174 [Boot]
EFI System 333595480 333598359 2880 [EFI System Partition] [EFISECTOR]
EFI System 333604896 333607775 2880 [EFI System Partition] [EFISECTOR]
MS Data 369930240 370980863 1050624
MS Data 370214528 370220701 6174 [Boot]
MS Data 405424128 446384120 40959993
EFI System 409051260 409182331 131072 [EFI System Partition] [ARCHISO_EFI]
MS Data 410024448 410030621 6174 [Boot]
MS Data 410030640 410036813 6174 [Boot]
MS Data 410036832 410043005 6174 [Boot]
MS Data 410043024 410049197 6174 [Boot]
EFI System 410049368 410052247 2880 [EFI System Partition] [EFISECTOR]
EFI System 410058784 410061663 2880 [EFI System Partition] [EFISECTOR]
MS Data 446384128 447434751 1050624
MS Data 446668416 446674589 6174 [Boot]
MS Data 487344128 488394751 1050624
MS Data 487628416 487634589 6174 [Boot] |
|
|
| Back to top |
|
|
avdb
n00b
Joined: 16 Aug 2020
Posts: 65
Location: Netherlands
|
| Posted: Fri Aug 28, 2020 7:10 pm Post subject: |
|
|
| Quote: | | I like the look of this one. Could you dump and show 64 bytes starting at that offset? |
That didn't go too well because when I started dumping all the hard drive's data in a text file the Live Ubuntu environment crashed. I don;t really get what you meant by the first 64 bytes but here's the output of "sudo hexdump -C /dev/sdb | grep ^276000":
| Code: | 27600000 4c 55 4b 53 ba be 00 01 73 65 72 70 65 6e 74 00 |LUKS....serpent.|
27600010 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................|
27600020 00 00 00 00 00 00 00 00 78 74 73 2d 70 6c 61 69 |........xts-plai|
27600030 6e 36 34 00 00 00 00 00 00 00 00 00 00 00 00 00 |n64.............|
27600040 00 00 00 00 00 00 00 00 73 68 61 35 31 32 00 00 |........sha512..|
27600050 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................|
27600060 00 00 00 00 00 00 00 00 00 00 10 00 00 00 00 40 |...............@|
27600070 af 11 47 83 e5 de 1d cd 60 07 69 f3 74 aa 5d 6e |..G.....`.i.t.]n|
27600080 bf 9c f3 94 2b 38 c5 ed b3 14 8a 4e 02 df 44 b6 |....+8.....N..D.|
27600090 cd 6e 4a 5a 83 d8 29 d6 ef f8 30 4f 07 8e a3 01 |.nJZ..)...0O....|
276000a0 59 69 61 5e 00 02 64 70 31 30 32 34 65 30 63 31 |Yia^..dp1024e0c1|
276000b0 2d 39 66 61 33 2d 34 63 64 38 2d 39 38 38 66 2d |-9fa3-4cd8-988f-|
276000c0 32 36 37 66 36 61 38 32 35 35 34 64 00 00 00 00 |267f6a82554d....|
276000d0 00 ac 71 f3 00 13 7d 08 6b 6d 51 0f 5a 56 b4 28 |..q...}.kmQ.ZV.(|
276000e0 40 2f 00 3f ff 51 6f 49 1d bd 98 be 16 b1 11 60 |@/.?.QoI.......`|
276000f0 2d bf 76 8d 47 9d 74 af 00 00 00 08 00 00 0f a0 |-.v.G.t.........| |
| Quote: | | This is fairly straightforward. LUKS is a nice frontend to dm-crypt, and swap inside a LUKS container works fine. You can have one LUKS container for swap, and a separate one for persistent data. |
Just checked the Arch Wiki and it turns out that what I said only applies to kernel versions older than 5.0.
| Quote: | | Could you expand on this? Logical Volumes are actually easier to manage than regular partitions because you can dynamically resize them, and the extra layer of abstraction minimizes the need to reserve space in specific locations for later use. |
Not everybody is a fan of abstraction. The abstraction made me think I knew what I was doing without reading the manual first and it made it possible to do things that technically shouldn't be when dealing with partitions.
| Quote: | | Do you have a backup of the important data? |
No, because I thought that deleting a partition wouldn't be that hard, well seems like it was because I wasn't paying proper attention to the dangerous tools I was playing with.
| Quote: | | Is it fair to assume you also did not save any copies of the partition table, and you no longer have any recorded copies of when you wrote the original partition table? No handmade notes planning out what you would put where, etc.? |
Very fair. All of these problems arose from the difficulties of trying to manage two totally different operating systems on a single drive while providing encryption to one of them. Now that I got rid of the unnecessary I doubt I will ever be playing around with disk management tools again. |
|
| Back to top |
|
|
NeddySeagoon
Administrator
Joined: 05 Jul 2003
Posts: 54311
Location: 56N 3W
|
| Posted: Fri Aug 28, 2020 8:52 pm Post subject: |
|
|
avdb,
That looks like LUKS version 1 header.
That's what | Code: | | 27600000 4c 55 4b 53 ba be 00 01 |
means.
The 27600000 is the hex offset from the start of the drive. Correctly written 0x27600000, where 0x means hex.
To turn that into 512b sectors, we divide by 0x200. 0x200= 512 in decimal.
That gets us a start address of 0x13B000 which we need in decimal to feed into parted.
In decimal, its 1290240.
1290240 also satisfies the alignment critera, being an integer multiple of 8
1290240 is the starting sector of your LUKS container.
Now the non obvious part. We don't know how big your LUKS partition is. Makeing the partition too small will upset the kernel.
Making it too big is harmless, but we will need to delete it later to poke about for your Windows partition.
So ...
Use parted to make a partition table entry with a start block of 1290240 and covering the rest of the disk.
Your Windows partition is inside it but we can fix that later. The partition table entry you use does not matter.
Check that 1290240.
Now do the LUKS dance on your new partition table entry and your btrfs should be back.
_________________
Regards,
NeddySeagoon
Computer users fall into two groups:-
those that do backups
those that have never had a hard drive fail. |
|
| Back to top |
|
|
avdb
n00b
Joined: 16 Aug 2020
Posts: 65
Location: Netherlands
|
| Posted: Sat Aug 29, 2020 4:52 am Post subject: |
|
|
It ... really worked.
First I ran this command to create a loop device:
| Code: | | losetup --find --show --read-only --offset $((0x27600000)) /dev/sdb |
Then I opened the loop-device with my password and mounted it.
| Code: | | cryptsetup open /dev/loop7 btrfs |
I'm now going to try and figure out how to restore the partition without having to copy everything over and reinstalling again. The fun thing is that when I lost my data previously it was on a different drive which means that I could apply the same trick on it. Thanks.
P.S.: I already managed to copy over some files I still had on Windows with Testdisk yesterday so no need to worry about that. |
|
| Back to top |
|
|
NeddySeagoon
Administrator
Joined: 05 Jul 2003
Posts: 54311
Location: 56N 3W
|
| Posted: Sat Aug 29, 2020 10:10 am Post subject: |
|
|
avdb,
A loop device is tidier but it requires kernel support.
We know the first block is 1290240 but we don't know the last block.
We can work that out (fairly closely) by knowing the size of the of the LUKS volume or failing that, the size of the filesystem that it contains.
We know the size of the LUKS header, we can read the header to determine the start of the payload.
Given the size of the payload (your btrfs filesystem) we can work out about where it ends.
You should regard your LUKS container as compromised as you posted enough of the header to enable a determined adversary to mount an off line attack on the first key slot. At the very least, you need to retire that key. Better to make a whole new LUKS container but you can't do that in place.
It depends on your threat model.
Governments would use the $5 wrench attack on your LUKS.
Individuals finding or stealing your laptop would install Windows 10 and sell it.
_________________
Regards,
NeddySeagoon
Computer users fall into two groups:-
those that do backups
those that have never had a hard drive fail. |
|
| Back to top |
|
|
avdb
n00b
Joined: 16 Aug 2020
Posts: 65
Location: Netherlands
|
| Posted: Sat Aug 29, 2020 11:34 am Post subject: |
|
|
I'm back on Gentoo, no worries.
How would this get me compromised when I only posted details that an attacker can retrieve without the encryption key?
I don't have to worry about governmental attacks yet because I'm still practicing OpSec.
It's not laptop, it's a desktop. With how old and heavy it is I doubt anybody would be willing to take the effort and steal it.If you're wondering why I'm using encryption when I'm sitting next to it pretty much all day, it's paranoia. |
|
| Back to top |
|
|
NeddySeagoon
Administrator
Joined: 05 Jul 2003
Posts: 54311
Location: 56N 3W
|
| Posted: Sat Aug 29, 2020 12:47 pm Post subject: |
|
|
avdb,
There is enough detail in your LUKS header post for an attacker to generate a hash collision off line, for the first key slot.
They don't need your pass phrase. Any other pass phrase that hashes to the same value, using the details in your post will work.
That's for the first key slot only. The hash values for the other key slots are still secret. They are in the next block on the disk.
Before your post, an attacker needed physical possession of your drive to start the process.
How good is your pass phrase?
10 characters can be brute forced in under a week with less than £200 of AWS CPU time.
Yes you need to be targeted for anyone to make use of a forum post.
It comes down to your threat model and who/what you want to protect against.
-- Edit --
Once upon a time, md5 was used for password hashes. Then it became possible to trivially generate hash collisions.
Worse, it is possible to generate hash collisions for any random payload you like, so md5 is no use for veryfing that two files have the same content.
Compare your LUKS header post to the spec I linked to see what you published.
_________________
Regards,
NeddySeagoon
Computer users fall into two groups:-
those that do backups
those that have never had a hard drive fail. |
|
| Back to top |
|
|
Hu
Administrator
Joined: 06 Mar 2007
Posts: 21715
|
| Posted: Sat Aug 29, 2020 4:18 pm Post subject: |
|
|
| avdb wrote: | | Quote: | | I like the look of this one. Could you dump and show 64 bytes starting at that offset? |
That didn't go too well because when I started dumping all the hard drive's data in a text file the Live Ubuntu environment crashed. |
Why were you dumping everything when you only needed 64 bytes? | avdb wrote: | I don;t really get what you meant by the first 64 bytes but here's the output of "sudo hexdump -C /dev/sdb | grep ^276000": | Code: | 27600000 4c 55 4b 53 ba be 00 01 73 65 72 70 65 6e 74 00 |LUKS....serpent.|
27600010 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................|
27600020 00 00 00 00 00 00 00 00 78 74 73 2d 70 6c 61 69 |........xts-plai|
27600030 6e 36 34 00 00 00 00 00 00 00 00 00 00 00 00 00 |n64.............| |
|
The section of your post I quoted contains just the first 64 bytes of the LUKS header (16 bytes per row, 4 rows), which is what I wanted you to show. That would have avoided the issues Neddy is trying to explain, because there's nothing particularly secret in the first 64 bytes. |
|
| Back to top |
|
|
avdb
n00b
Joined: 16 Aug 2020
Posts: 65
Location: Netherlands
|
| Posted: Sat Aug 29, 2020 6:21 pm Post subject: |
|
|
| NeddySeagoon wrote: |
How good is your pass phrase?
10 characters can be brute forced in under a week with less than £200 of AWS CPU time.
Yes you need to be targeted for anyone to make use of a forum post.
It comes down to your threat model and who/what you want to protect against.
|
That won't be easy then as my password is 60 characters long (Oh no! I gave the attacker a hint!) of upper- and lowercase letters, symbols and numbers. I never entered it in a password strength checker (most of them require Javascript anyway) but I'm pretty sure it's going to take about 128^60 guesses before it's cracked. |
|
| Back to top |
|
|
avdb
n00b
Joined: 16 Aug 2020
Posts: 65
Location: Netherlands
|
| Posted: Sat Aug 29, 2020 6:29 pm Post subject: |
|
|
| Hu wrote: | | The section of your post I quoted contains just the first 64 bytes of the LUKS header (16 bytes per row, 4 rows), which is what I wanted you to show. That would have avoided the issues Neddy is trying to explain, because there's nothing particularly secret in the first 64 bytes. |
Hmmm, doesn't matter. Switching my password to a different slot should fix the problem. I'm going to try crypt-analysis on myself soon enough once I have time to get a good book on the subject. |
|
| Back to top |
|
|
NeddySeagoon
Administrator
Joined: 05 Jul 2003
Posts: 54311
Location: 56N 3W
|
| Posted: Sat Aug 29, 2020 7:40 pm Post subject: |
|
|
avdb,
Nobody will guess you password. That does not matter to the attack.
The key space is finite. Yes, its large but still finite.
There are far more pass phrases than there are pass phrase hashes in the key space. That means several pass phrases must hash to the same value.
Attackers will try to find a pass phrase that hashes to the same value as your pass phrase.
_________________
Regards,
NeddySeagoon
Computer users fall into two groups:-
those that do backups
those that have never had a hard drive fail. |
|
| Back to top |
|
|
|
|
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum
|
|
Other Things Gentoo
