LinuxQuestions.org

LinuxQuestions.org (/questions/)
-   Linux - Security (https://www.linuxquestions.org/questions/linux-security-4/)
-   -   Encrypted Disk (https://www.linuxquestions.org/questions/linux-security-4/encrypted-disk-4175736796/)

Jackson111 05-07-2024 04:07 PM

Encrypted Disk
 
Hello,

I have a Linux desktop, with an added encrypted backup disk. There was no OS installed there whatsoever, just ext2, and the files on top of it. I was unmounting it after use.

Yesterday, I found out the disk was nowhere to be seen in the Nautilus. I checked via lsblk, and it was in the /sdb. Upon closer inspection, i found out that there was nothing to mount, as there was no file system there any more, and all the space was considered UNALLOCATED!

Basically, the disk was wiped clean somehow. The subsequent test concluded that disk was otherwise OK.

What could have happened? I don't consider myself so clumsy to wipe it out just like that without noticing.

Is there a possibility that the Windows partition on the same Desktop could have done it? I couldn't prevent it from updating recently. Strangely, on the disk that got wiped there was also a 16 MB Windows partition.

As I don't have much experience with encrypted disks, some input would be appreciated!

syg00 05-07-2024 10:40 PM

The encryption is not the problem here. Post this output (using [code] tags)
Code:

sudo parted /dev/sdb "print free"
If it was simply the partition table being erased, testdisk will likely be the best way to recover your partition.

Jackson111 05-07-2024 11:02 PM

Quote:

Originally Posted by syg00 (Post 6500411)
The encryption is not the problem here. Post this output (using [code] tags)
Code:

sudo parted /dev/sdb "print free"
If it was simply the partition table being erased, testdisk will likely be the best way to recover your partition.

sudo parted /dev/sdb "print free"
Model: ATA ST4000DM004-2CV1 (scsi)
Disk /dev/sdb: 4001GB
Sector size (logical/physical): 512B/4096B
Partition Table: gpt
Disk Flags:

Number Start End Size File system Name Flags
1 17.4kB 16.8MB 16.8MB Microsoft reserved partition msftres
16.8MB 4001GB 4001GB Free Space

syg00 05-07-2024 11:24 PM

Code:

sudo parted /dev/sdb "print free"
Model: ATA ST4000DM004-2CV1 (scsi)
Disk /dev/sdb: 4001GB
Sector size (logical/physical): 512B/4096B
Partition Table: gpt
Disk Flags:

Number  Start  End    Size    File system  Name                          Flags
 1      17.4kB  16.8MB  16.8MB              Microsoft reserved partition  msftres
        16.8MB  4001GB  4001GB  Free Space

Code tags make it much more readable.
The reserved partition shouldn't have been formatted with a filesystem, so you might be in luck - what does this show ?.
Code:

lsblk -f

Jackson111 05-07-2024 11:45 PM

It just shows that there is sdb1 on sdb

Zero other info (like filesystem etc)

lvm_ 05-08-2024 01:21 AM

What's you primary concern - recover the data or find out what has happened? If the former, use testdisk. The are other ways, but this one is probably the safest. But if the latter, can't help you especially if windows is involved.

pan64 05-08-2024 02:08 AM

if you are lucky only the gpt/mbr was overwritten and probably you can restore it. Otherwise windows do not make things like this "just for fun". Did you boot windows at all?
In linux the name of the disk sometimes changes, it can be /dev/sdb, /dev/sda or probably something else.

syg00 05-08-2024 04:26 AM

What now worries me is that lsblk should be aware of LUKS, even on a truncated partition like the current /dev/sdb1. If the magic bytes are missing, then the header might have been trashed. Without a (separate) backup of the header the data would be lost in that case.

If the encryption was something other than LUKS, I've no experience.

Jackson111 05-08-2024 11:37 AM

Thanks everybody for the great input!

I would like to gain understanding in what had happened, but also to recover the data.

It IS concerning that the LUKS encrypted partition got wiped out. I will try the Testdisk to see if something can be done, but I just wonder what may have happened. The encrypted disks are not erasable just like that.

Admittedly, I don't have too much experience with LUKS. The partition has been created over a year ago, and I actually may have initially formatted disk as FAT. Can that play a role?

rknichols 05-08-2024 05:21 PM

Quote:

Originally Posted by Jackson111 (Post 6500534)
The encrypted disks are not erasable just like that.

Actually, they are. If you overwrite any part of the master key salt or the material in the keyslot, the data is unrecoverable unless you saved a backup of the LUKS header.
Quote:

The partition has been created over a year ago, and I actually may have initially formatted disk as FAT. Can that play a role?
Does "initially" mean before or after you set up the LUKS encryption? If before, then it would not be relevant.

About your only chance now is if testdisk can identify a LUKS header**, perhaps somewhere other than the current start of partition 1. If so, note that testdisk has no way to determine the size of the LUKS partition, as there is nothing in the LUKS header to indicate that, and testdisk will assume a size just large enough to hold the LUKS header. You should create a new partition at the determined starting point and of maximum possible size.

**You can also use a hex editor to search the disk for a sector beginning with the ASCII characters "LUKS" followed by the hex bytes "BA" and "BE" (total of 6 bytes). Doing that will avoid testdisk's assumptions about the reasonable starting locations for a partition.

Jackson111 05-08-2024 05:50 PM

Although I know how to create an encrypted partition from the Terminal, I did it from the GUI, just for the sakes of having the mainstream settings, which would play well with removing the disk and opening elsewhere. As I said, I am not very experienced in that field.

I will have time to run all the great suggestions in peace over weekend, and I hope that I get to recover the data. It is not critical, as nothing will get lost forever, but I'd have to go through a variety of backups and restore some stuff manually. What I might lose forever though would be some GoPro metadata, that apparently gets lost when saving in their cloud (as many users say).

One last thing that bothers me is this:

Microsoft reserved partition msftres

Created by the Nautilus, or some violent overwriting via the Windows update on other partition? I wonder, as I haven't seen it before.

Thanks again everybody!

syg00 05-08-2024 08:22 PM

No, that would be Microsoft in action, I meant to mention that earlier. Never seen it clobber an already existing disk without asking tho'.

syg00 05-09-2024 12:54 AM

I wonder if they zeroed it out .... ugh. Try this; if it returns a single line of zeroes, I'm afraid your data is probably lost.
Code:

sudo dd if=/dev/sdb1 count=2 | hexdump

Jackson111 05-09-2024 03:26 PM

Quote:

Originally Posted by syg00 (Post 6500637)
I wonder if they zeroed it out .... ugh. Try this; if it returns a single line of zeroes, I'm afraid your data is probably lost.
Code:

sudo dd if=/dev/sdb1 count=2 | hexdump


IT DIDN'T!

Thx!!!!!!

Jackson111 05-10-2024 03:27 PM

TestDisk 7.1, Data Recovery Utility, July 2019
Christophe GRENIER <grenier@cgsecurity.org>
https://www.cgsecurity.org

Disk /dev/sdb - 4000 GB / 3726 GiB - CHS 486401 255 63
Partition Start End Size in sectors
>P Linux filesys. data 1046287267 1053821026 7533760 [^K~M27n1ҥ %~JMM-7D]



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,
Enter: to continue
cramfs, 3857 MB / 3678 MiB


Any suggestions while I am going through the manual?


All times are GMT -5. The time now is 11:13 AM.