Recovering Veracrypt Volume After Mistakenly Creating Partition Table
Open source disk encryption with strong security for the Paranoid
Brought to you by:
idrassi
Menu
▾
▴
Hello,
While trying to format a USB drive, I mistakingly used GParted and created a new msdos partition table on a mounted SSD with a VeraCrypt volume.
After noticing I selected the wrong drive, the volume remained mounted and I could back up a couple of files, so I thougth the data was safe so I umounted the volume and tried to mount it again but I haven't been able to mount it since.
I figure the files are still there because I did not formatted any partition whatsoever but I'm having issues with mounting the volume.
While troubleshooting, the first thing I did was to dd the whole drive so I have that as a backup.
I've explored Discord and Reddit and have tried restoring the volume header from the embedded backup, but it failed with the error:
"Operation failed due to one or more of the following: - Incorrect password. - Incorrect Volume PIM number. - Incorrect PRF (hash). - Not a valid volume."
Suggestions were given to reset the partition structure to its original state, but I can't recall how it was, the drive contents were always displayed as Unallocated entirely ever since I created the VeraCrypt's volume in that particular SSD.
So, if anyone out there has dealt with a similar mess or knows a thing or two about VeraCrypt or partition recovery, I'd really appreciate your two cents. Any insights, suggestions, or advice would be like a ray of hope in this dark tunnel of data despair.
Can you mount the volume using the embedded backup header instead of trying to restore the header?
How would I do that? Thanks for the reply.
On the screen where you enter the password, click the Mount Options button and enable the "Use backup header embedded in volume if available" option.
Ah ok, then yes, I had tried doing that already.
Just tried again and got the same error message:
Operation failed due to one or more of the following:
Any other ideas?
It boggles my mind how I was able to recover some files after the partition table was created, even if GParted prompts that all the data in the disk is going to be erased, so that leads me to believe the files haven't been overwritten.
Maybe creating a MBR or GPT partition table instead of msdos would work?
What was the original layout of the accidentially formatted device? Did you use full disk encryption or encrypted partitions?
Full disk encryption.
Has there only been created a partition table on the device or also a formatted partition?
I got the brand new SSD, placed it on my hub and encrypted it using VeraCrypt, the drive always appeared as "Unallocated" space on its entirety.
https://i.ibb.co/sKpCRb6/image.png
I did some testing and found the following:
After creating a VC volume, using an entire block device, and creating a msdos partition table with GParted afterwards, GParted changed the first ~2 MiB and last ~1.5 MiB of the device, resulting in both the main VC volume header and backup header at the end of the volume being overwritten.
So, it seems that the only way to make the volume accessible again is, to restore a previously created backup of the header.
Since the filesystem inside the volume is likely to be damaged by partition table creation, too, further steps would then become necessary.
Greets.
Thank you, unfortunately I do not have a header backup.
When you say: further steps would then become necessary
Do you have an idea on what I should try?
The fact that gives me hope is that I could backup some files after creating the partition table and before unmounting the volume, so I believe the filesystem is intact somehow.
According to what you reported, it seems that both main and backup header were overwritten. Therefore, the only way to make the volume mountable again, restoring a previously created header backup is mandatory.
I assume that it's impossible to mount the volume again without mentioned backup. The reason for being able to access files after creating the partition table would be that the volume was still mounted. The volume header is only needed for mounting the volume. It's also likely that the filesystem was already damaged, but the damage remained unnoticed, since the filesystem inside the volume was already mounted, too. The moment you unmounted the volume, you missed the chance to backup undamaged data from the volume.
In case, you would be able to mount the volume again, the filesystem inside would have to be repaired, to mount it. That's what I was implying back there.
Sorry for the bad news :-(
Greets
Last edit: RealTehreal 2024-03-17
Just for the sake of completion: I reproduced the behavior: I created a new partition table on a block device while its VeraCrypt volume was mounted. I was able to copy all data without data loss. At least in Linux it is common for the kernel to prevent overwriting currently used files / data. Therefore it was damaged after dismounting the volume. I was unable to mount it again afterwards, since both headers were overwritten.
Greets
Damn! So sad to hear that.
Anyways, thank you for your in-depth response.