Unable to access decrypted UEFI OS (1.19-BETA2)
Open source disk encryption with strong security for the Paranoid
Brought to you by:
idrassi
Menu
▾
▴
Hey,
So basically, Windows update broke something with my Windows installation and in order to fix this I'd have to decrypt my OS because I wasn't able to access it (automatic repair loop). I know that 1.19 has the glitch in rescue disk that does not restore first 50MB, but there is no other way to even 'upgrade' your rescue disk without access to Windows installation. So after I decrypted the volume, it still shows up as RAW and I am unable to do anything with it. Tried running TestDisk 7.0, but it doesn't find the partition. I am currently on Ubuntu installation from USB and that's my only way to communicate, I'd appreciate fast help.
It is possible to use the Rescue Disk files from 1.20-BETA and keep only the files "EFI/VeraCrypt/svh_bak" and "EFI/Boot/original_bootx64.vc_backup". Users could have provided you with the file before decrypting but it is too late now.
As you know, the 1.19 bug doesn't correcly decrypt the first 50 MB and that's why the partition will not be visible by any tool since all filesystem information are present in these 50 MB.
As I wrote in a previous post, such situation requires the development of a dedicated tool to fix the first 50 MB...I didn't work on it yet. I will see if I can write a quick-n-dirty implementation that can help...I will update you in few hours.
Hey,
Thank you very much for your fast reply. I'm looking really forward to your update :)
I have an implementation but I need more tests (very important) and it's sleep time!
I will spend time on it tomorrow and I will keep you informed.
No problem, have a good night, mate :) Thank you for helping me out with this issue.
Hi,
I finally managed to have an implementation can can recover data after 1.19 faulty OS decryption. I tested it and it is working fine: just extract the content of the zip file whose link is below over your existing Rescue Disk, boot over the modified Rescue Disk and then choose Decrypt OS. After typing the passwiord and PIM, it will automatically detect the issue and propose to fix it. Once fixed, just reboot, type your password and windows will start!
Let me know if you have any problems.
Thanks a lot! The tool did indeed decrypt the first 50MB making the volume detectable again as NTFS, but I think something went wrong earlier (before I used your tool), I think all my data that was earlier decrypted has been totally corrupted during the initial decrypt, as I am unable to access files on the drive, chkdsk refuses to work, TestDisk reports "Can't open filesystem. Filesystem seems damaged" (but it detects it now, unlike before) and PhotoRec didn't recovery ANY files from the disc.
This is very strange. I'm not aware of any bug in 1.19 that would cause complete corruption of all data, especially that the first 50 MB has been recovered correctly.
Did you do decryption in one take? Was there any intruption and did you perform any action in between like restoring volume header?
Maybe the cause of this is the same as why Windows was refusing to start before decryption.
For now I have no idea what happened in your case and I don't see how this could be cause by the Rescue Disk alone...
64-bit patch did not work for me.
I originally attempted OS decryption using the rescue disk that I had generated in the 1.19 client. Decryption completed successfully, but the computer continued to boot-loop into Windows Automatic Repair. I patch the rescue disk using the 64-bit patch in your post and reattempted decryption. Again it completed successfully, but the Windows Automatic Repair bootloop continues whereby it attempts to auto repair the system, but is unable to do so. Using command line for further troubleshooting shows the following:
ckdsk /f c:
- The type of the file system is NTFS. Unable to determine volume version and state. CHKDSK aborted. Failed to transfer logged messages to the event log with status 50.
c:
- The disk structure is corrupted and unreadable.
I also attempted a separate windows installation on another disk. I installed veracrypt and mounted the partition. Neither the Check Filesystem or Repair Filesystem options work. The following error message occurs in command:
- The Type of the file system is RAW. CHKDSK is not available for RAW drives.
Attempting to Permanently Decrypt the drive also yields errors:
Operation failed due to one or more of the following:
- Incorrect password
- Incorect Volume PIM number
- Incorrect PRF (hash)
- Not a valid volume
- Source: MountVolume:7763
The password and PIM are the same used during all processes associated with accessing the volume and they are correct, so that's not the issue here.
What's the next step?
When trying to write to the RescueDisk it says it needs to be erased. So I extracted the ISO from the CD to the hard drive.
I then opened the ISO in burning software and added the EFI folder to the disk's root folder and burned the ISO and extra files all in one sitting. The CD boots but it says the disk is already decrypted (not offering to repair anything). Do I need to open up the 1.19 ISO file, and replace it with some the new files offered for download and burn it again?
hello did you get solution to the unreadeble disk problem
What happens when the decryption process is restarted? Is it the first 50MB at the beginning of the drive, or the first 50MB from where the decryption started?
Why was it all so easy with TrueCrypt but is it so hard with VeraCrypt? Maybe the TC developers saw this coming, Hardware and software developments that together make independent encryption well nigh impossible.
Hi,
I think I am having a similar issue. I had partly encrypted my system drive on windows with 1.19 Stable to about 15%, and then I decided I wanted different settings, so I stopped encryption and rebooted, but then I had a boot problem. I am not worried about gettingi the drive booted now, but I would like my system drive decrypted. I used the rescue disk for 1.20BETA2 and selected decrypt , and it started at about 84% and finished. However, now when I look at the drive in gparted, it is showing as unknown/raw space instead of NTFS.
Should I try using the rescue disk files above? How can I tell if my first 50meg are not correct?
I have run into this before where decrypting from the system disk said it was decrypting and didn't, so when it was interrupted and restarted elsewhere I ended up with a drive that was half decrypted, half not. I wish I had written down the exact byte where the first decryption was interrupted, since I had a devil of a time (hours with a sector editor) figuring out where the exact dividing line was.
I suspect you may have run into the same issue as well.
I just tried to look up my post from when this happened. It was back in 2015, and other posts of mine from there are still here but that thread is gone. I made some noise then about a bug in the rescue disk decryption, but it was dismissed at the time. I hope it is looked into again, because I still firmly believe there are still bugs (and not just the one in 1.19) in the rescue disk decyption, especially when partially encrypted/decrypted volumes are involved.
First of all, first thing to do right now is make a sector level image of that drive as it currently exists. This is important, it will let you try things without worrying that any one attempt will make things worse.
When you decrypted the volume, was it fully decrypted and the header removed? Do you still have a VeraCrypt rescue disk with the header from that volume? If you can get the VeraCrypt header back on the volume, you can play around with the setting in the header that tells it where the dividing line between encrypted/unencrypted data is and we can see if you have a case of a partially encrypted drive.
But, before you do anything else, make that image.
Mounir, I'm not new to computers, but I have been finding it difficult to follow your instructions. Would it be workable to build an option into a Veracrypt installer to repair a 1.19 installation? I think unless someone has a CD-RW or DVD-RW, then they could just create the 1.19 rescue disk, then write that folder above onto that same CD or DVD, then do that? I know I've tried to work with the iso image that 1.19 creates and then write the folder into there, but I'm not sure which software to use. If there was an executable tool that would be able to work with one's 1.19 rescue disk iso, and add the repair folder to that, I think that might be a little more helpful, unless someone wants to give me precise step by step instructions on how to create that modified 1.19 rescue disk.
Is this the same system you are already able to boot into Windows by pressing the ESC key from the thread below?
https://sourceforge.net/p/veracrypt/discussion/general/thread/9d37a018
If yes, just select the option to restore the original Windows OS bootloader from the 1.19 Rescue Disk to stop being prompted to enter the VeraCrypt password/PIM at bootup.
Oh, my system is running, already used the rescue disk to recreate the OS bootloader, but I was just saying that trying to add a folder to an iso image and then burn that, not sure what software I'd have to use but I didn't even know if I was doing it right or if it would work. I tried to make something like that and use Rufus to burn it to a USB stick, but it didn't come up with a Veracrypt prompt, which I suppose my rescue disk should have, if plainly just burned to a CD-RW or DVD-RW.
I tried this patch as well, it initially didnt want to unencrypt the drive again, but I rebooted and retried and it ran, looked like it had more blocks as well to process than before.
It completed but I had the same issue where it appears that it is corrupt and unreadable. I left the unit last night running a chkdsk /f /r and it seemed that it was removing every file as an orphan.
I'm hoping to go look at it this morning and that allowing it to do its thing will result ina good disk again, but from reading others accounts, I'm not as hopeful. Luckily I prepped my client's expectations that the data may not be recoverable in the first place.
Not going to spin my wheels on this much longer, will end up reformatting and loading data from Carbonite, and then use latest version to re-encrypt it and create a new rescue flash drive.