VeraCrypt / Forums / Technical Topics: Veracrypt SUDDENLY password wrong! UEFI PBA

dsfe - 2017-05-02

Hi,
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! :(

Last edit: dsfe 2017-05-02

If you would like to refer to this comment somewhere else in this project, copy and paste the following link:

dsfe - 2017-05-02

After further investigation I am quite sure GPT paritition table got damaged somehow: When I pulled a whole disk backup (sector for sector) I cant see the 16MB Microsoft reserved paritition, which I can see in Gparted on the system itself. Any chance to rescue it?

If you would like to refer to this comment somewhere else in this project, copy and paste the following link:

Alex - 2017-05-02

keys places:
1. 62 sector of OS drive
2. copy of keys: rescue disk, file svk_bak

Use 1.20b2p2 from https://sourceforge.net/projects/dc5/files/beta/
1.19 contains problem with rescue

If you would like to refer to this comment somewhere else in this project, copy and paste the following link:

dsfe - 2017-05-02

Ok, it is not GPT partition table, a scan with gdisk in Ubuntu showed no error, checksums are correct and GPT with protective MBR in place. So only the Veracrypt Volume header can be damaged - where is the backup for the full disk encryption volume header stored when it is UEFI? (as far as I know not in the paritition itself)

If you would like to refer to this comment somewhere else in this project, copy and paste the following link:

dsfe - 2017-05-02

Thanks for the answer: I already used 1.20b2p2 rescue disk files - sadly didn't help

If you would like to refer to this comment somewhere else in this project, copy and paste the following link:

dsfe - 2017-05-02

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?

Last edit: dsfe 2017-05-02

If you would like to refer to this comment somewhere else in this project, copy and paste the following link:

Alex - 2017-05-02

You can copy svk_bak to 62 sector of OS drive (not partition) via rescue disk or other tools like "dd"
Then it should be possible to mount the disk with mount->mount options->system volume check box

PIM default is 0. (means HMAC iterations = 15000 + 485*1000 )

Also you can verify header(svk_bak) via DcsFV (slow mode)

If you would like to refer to this comment somewhere else in this project, copy and paste the following link:

dsfe - 2017-05-02

Thanks, I would like to verify header first with DcsFV What do I have to fill in to <Path></Path>? Default value does not seem to work

If you would like to refer to this comment somewhere else in this project, copy and paste the following link:

dsfe - 2017-05-02

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?

If you would like to refer to this comment somewhere else in this project, copy and paste the following link:

dsfe - 2017-05-02

Btw. I am using the latest beta Version 1.20Beta2 of VC.

If you would like to refer to this comment somewhere else in this project, copy and paste the following link:

dsfe - 2017-05-02

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?

Last edit: dsfe 2017-05-02

If you would like to refer to this comment somewhere else in this project, copy and paste the following link:

Alex - 2017-05-03

DcsFV:
Path should point to svh_bak (password at the moment of creation! )

Fill correct login parameters in DcsFV config. (password, PIM, hash, boot, tcmode) DcsFV will print info with encryption details. You can experiment with header with parameters you know exactly.

Mount as external:
To mount the drive it is necessary to select: Select partition->Mount->Mount options->Mount partitions using system encryption
But at first verify svk_bak to be sure of pwd, PIM.

If you would like to refer to this comment somewhere else in this project, copy and paste the following link:

dsfe - 2017-05-03

Hi, thanks for the answer. I meant the following section of the DcsFV.cfg file:

<Medias>
<Media>
<Path>\.\PhysicalDrive0</Path>
Which input should I use for Path variable? Default one doesnt work for me.

Default value leads me to error message: "\.\PhysicalDrive0 can not open"

And is this part of the config file section:

<Logins>
<Login>
(...)
<Pim>0</Pim>

<Hash>SHA-512</Hash>

<Boot>1</Hash>
correct? shouldnt it be <Boot>1</Boot>?

I tried mounting the system drive as external drive several times, and I uses the mount options ("Mount->Mount options->Mount partitions using system encryption") as you stated before, but no luck... :( I'cant explain it, normally it should work since I verified the key in sector 62 is the same as in svh_bak-file :/ I really have no clue what else it could be.

I'm currently trying to reproduce the initial encryption on a VM (same Windows 10 Version, same VC Version 1.19 etc.) with the same password an settings. I still suspect there went something wrong with PIM default value in Veracrypt 1.19...

If you would like to refer to this comment somewhere else in this project, copy and paste the following link:

Alex - 2017-05-03

Use path to file
e.g.
<Path>c:\svk_bak</Path>

Try several logins with diffrent PIM.
Boot 1 is correct.

If you would like to refer to this comment somewhere else in this project, copy and paste the following link:

dsfe - 2017-05-03

Ok thanks, I'll try it - the rest of the standard settings are ok, right?
Do I really need to test 10000 blocks since its only a 512byte file?

Last edit: dsfe 2017-05-03

If you would like to refer to this comment somewhere else in this project, copy and paste the following link:

dsfe - 2017-05-03

Ok, I answered it myself. Block 0 is sufficient as it seems. I really dont know why but it seems my PIM is wrong. I test more combinations.

If you would like to refer to this comment somewhere else in this project, copy and paste the following link:

dsfe - 2017-05-03

What about special characters, can this program handle them? (the passwords consists of special characters)

If you would like to refer to this comment somewhere else in this project, copy and paste the following link:

dsfe - 2017-05-03

Ok answered myself, my special characters are no problem for the program. I continue testing...

If you would like to refer to this comment somewhere else in this project, copy and paste the following link:

dsfe - 2017-05-03

Btw. to note for others: PIM 485 equals PIM 0 or not set for UEFI PBA devices.

If you would like to refer to this comment somewhere else in this project, copy and paste the following link:

cpe - 2017-05-06

deleted

Last edit: cpe 2017-05-06

If you would like to refer to this comment somewhere else in this project, copy and paste the following link:

dsfe - 2017-05-06

I reproduced this initial issue somehow on a Windows 10 VM. How excatly I can't say. I think it has something to do with recent Windows 10 updates ... I try to investigate it.

If you would like to refer to this comment somewhere else in this project, copy and paste the following link:

dsfe - 2017-05-06

Ok, has nothing to do with Windows updates as it seems. I am trying again ...

If you would like to refer to this comment somewhere else in this project, copy and paste the following link:

dsfe - 2017-06-05

Just an update: I gave up on recoverying for now - I simply dont have time for it. I had a backup which sadly wasnt that up to date but I needed to start over. Thanks for the help, maybe I try to investigate more when I have the time. Just for info: I gave up FDE on this particular system as I am afraid this might happen again. On the other system I'll stick with goold old MBR FDE since it was stable for years and NEVER had any problem with it.

If you would like to refer to this comment somewhere else in this project, copy and paste the following link:

dsfe - 2017-06-11

Thanks for all the help: I finally recovered my data. Strangely the password was wrong, but I am 100% sure that the password I entered was 100% correct, but now it seems that it was a shorter version of it somehow. I can't explain it to myself, but I am glad I 100% recovered my files now. I learned my lesson and subscribed to an online backup service for my most important data.

If you would like to refer to this comment somewhere else in this project, copy and paste the following link:

Andreas Boehlk - 2017-06-12

I hope that You have a possibility to backup the encrypted data, otherwise I do not see a reason for using Veracrypt. For pure access control a BIOS/HDD-password would be sufficient.
Regards
Andreas
P.S. In case of encrypted backup I am interested in the method.

If you would like to refer to this comment somewhere else in this project, copy and paste the following link:

Veracrypt SUDDENLY password wrong! UEFI PBA

Open source disk encryption with strong security for the Paranoid

Forums

Help

Veracrypt SUDDENLY password wrong! UEFI PBA document.SUBSCRIPTION_OPTIONS = { "thing": "topic", "subscribed": false, "url": "subscribe", "icon": { "css": "fa fa-envelope-o" } };

Veracrypt SUDDENLY password wrong! UEFI PBA