This project has moved. For the latest updates, please go here.

Veracrypt SUDDENLY password wrong! UEFI PBA

Topics: Technical Issues, Users Discussion
May 2 at 8:19 AM
Edited May 2 at 8:34 AM
I have no clue what could have happened, here is the situation:

HP Laptop, FDE in January 2017 with Veracrypt 1.19, UEFI + GPT
The FDE worked flawlessly until yesterday. The day before yesterday the Laptop was normally shutdown, nothing special happened. Nothing was changed, no keyboard layout etc. Now suddenly Veracrypt Bootloader says the standard error #3 (Authorization failed, wrong password, PIM or Hash)

What I have:
-Password and PIM which are 100% correct
-Veracrypt Rescue USB Disk

I can't image what could have happened. What I tried so far:
-Restore bootloader with Veracrypt Rescue USB Disk -> no luck
-Mount Veracrypt system partition with Ubuntu + Veracrypt 1.19 on the same machine -> no luck, same error as stated above (Authorization failed, wrong password, PIM or Hash); I tried with and without special PBE mount settings -> no luck, keyboard layout is set 100% correct, password 100% correct!
-Mount Veracrypt system partition on another Windows 10 -> no luck, same error as stated above (Authorization failed, wrong password, PIM or Hash), keyboard layout is set 100% correct, password 100% correct!

This all tells me, that maybe the GPT partition table got corrputed somehow, or maybe the volume header.

But I can still see the 4 partitions on the system drive.

Where is the backup the volume header of a UEFI/FDE GPT paritition placed?

Any clue?
Help would be much appreciated! :(
May 2 at 9:33 AM
keys places:
  1. 62 sector of OS drive
  2. copy of keys: rescue disk, file svk_bak
Use 1.20b2p2 from
1.19 contains problem with rescue
May 2 at 2:36 PM
Thanks, how can I use backup Volume Key Header on another device?
May 2 at 5:41 PM
Edited May 2 at 5:42 PM
Update: it seems the rescue USB disk can't find the encrypted paritition. The decryption process fails with "not found".

Something other weird happened: was there a change or maybe a bug in standard PIM with Veracrypt 1.19? I can observe the following:

earlier, before I updated the EFI files in EFI partitition and with the old rescue disk, and all the time while the system worked properly, I had default PIM, and the unlocking process took about 4 seconds. Now when I choose standard PIM and try to unlock with rescue disk it takes about 15-20 seconds. How can this be? Was Veracrypt 1.19 standard PIM not 98 as it should be with FDE?
May 2 at 8:16 PM
Ok, I think, I might should go search the volume with your tool (DcsFV)? What do I have to fill in to <Path></Path>?
May 2 at 8:51 PM
Ok, update: I read sector 62 of the OS drive with dd in Ubuntu (dd bs=512 if=/dev/sda of=/sectortest.img skip=62 count=1) and compared the hash of the output to the hash of the svh_bak-file. They are identical! So the correct headerfile is in place, but why can't I mount the partition in Windows on another device then?
May 2 at 9:11 PM
Edited May 2 at 9:12 PM
Ok summing up:

-GPT paritition table seems ok - /gdisk reported that ("Found valid GPT with protective MBR; using GPT.")
-Partition Header seems to be ok in sector 62 of the OS drive (hash sum of the sector matches the hash sum of the backup svh_bak-File)

Does the OS partition itself contain any header/etc that may be corrupt?

So what else could make a problem mounting the drive?

At creation of the veracrypt partition I used the default PIM value. So maybe it is a PIM confusion? I'll try it with explicit zero value, maybe this helps. The strange thing, I already stated is, that default PIM (no input value, just ENTER in Bootloader) took only 4 seconds, now after using rescue USB disk checking the passwords takes with no input value to PIM field (just ENTER) about 12 seconds. How can this be?
May 4 at 4:48 AM
Regarding the computation time:

Did you use the default KDF?
When you have 12 seconds, do you use the bootloader or do you tray to mount on a different system
May 6 at 9:51 PM
Thanks for the answer. I have no idea where the 12 seconds came from. I did this always in bootloader. On different system there was no change in speed. I used default KDF.

I think I can reproduce the initial issue now, but need more testing.