Unfortunately, development of UEFI support is still on standby. Definitely some help is needed, either from other developers that have knowldge on it or through external funding to help pay for full time work on this feature.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
EFI is quite simple actually, but the Microsoft bootloader chain complicates it a bit. You basically have two issues:
1) Make the unecrypted block device available to the consuming Applications/Bootloaders and DXEs including BOOTMGFW
2) Transmit the encryption key to the Windows Veracrypt I/O Filter from PreOS. It can be done using a RuntimeDXE using a secure key exchange algorithm which destroys it after the first read attempt or via a SystemTable that you would have to clear manually afterwards, but you have no guarantee that you're the first or the only one reading. This is simple and I would recommend the RuntimeDXE approach as it can enforce giving the decryption key only to the veracrypt driver and not any malware. But we have a problem here as well because we don't have an API for accessing a RuntimeDXE from Windows. From what I've discovered, we have: ExpGetSystemFirmwareTableInformation an undocumented API which we can use to get the reset of the system tables.
You can do it the same way you do it on Windows and basically intercept the I/O at the UEFI level or maybe at the BOOTLIB level but I'm not sure if you can instruct bootmgr.efi to load your PreOS driver via BCD.
You can also install a new driver for a virtual hard-drive and present the decrypted volume as a new block device, but that would complicate the bootloader->kernel root filesystem arguments as the device trees wouldn't match anymore and Windows probably wouldn't be able to find the partition again. It's complicated also because Windows mixes it's native device tree with ARC device trees and "EFI device path".
Let's detail the device tree issue a bit. If you create a virtual block device instead of intercepting the BlockIO, the device path for an NTFS Partition would look like:
PciRoot(0x0)/Pci(0x11,0x0)/Pci(0x4,0x0)/Sata(0x0,0x0,0x0)/HD(1,GPT,123456-1234-1234-1234-12345678,0x28,0x64000)/VenHw(VERAGUID-0123-1234-5678-12345678)
which wouldn't match any recognised BootMGFW path, or:
VenHw(VERAGUID-0123-1234-5678-12345678)/HD(1,GPT,123456-1234-1234-1234-12345678,0x28,0x64000)
Which would work with BootMGFW and Winload, but might fail at the NT Kernel since it doesn't start with the ACPI Root.
If Windows DOES support passing the Filesystem GUID as a rootfs argument to ntoskrnl.exe (like MacOS does) or the Filesystem Label (like Linux does), then it can simply scan all the volumes in the system reported by the loaded drivers and it would work, but I don't think that's the way it works.
You can create a new default bootloader that decrypts the volumes and replaces the block-io protocol of that EFI_Handle and the load bootmgfw.efi. This seems like the ugliest and simplest way. The risk is that BOOTMGFW is not aware that you intercepted the APIs and a Windows version upgrade or SP install might screw your boot configuration. This is what McAffee does.
My favorite aproach is based on ReactOS. Basically they are reimplementing bootmgfw, bootmgr and winload. Since we don't need all that functionality, we could in theory write an NTFS filesystem driver that recognises Veracrypt which shows an imaginary EFI\Boot\boot.efi for that filesystem. That boot.efi would in turn load a compatible BOOTLIB made by ReactOS, which chainloads winload.efi with the correct data structures just like the original bootmgfw.efi would. The advantage of this is that we get our bootloader back.
Windows has an idiotic design in which the UEFI bootloader is ignored and Windows has it's own bootloader. This was acceptable until Windows 8 when they moved-it to post-ntkrnlmp userland. So if you want to boot another OS, you have to fully load the Windows 8 kernel/drivers, it then displays the boot menu in userland and if you select some other boot entry it will reboot the computer to that something else. It's the definition of insanity.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Thank you for sharing this work, it looks amazing!
I was not aware that it advanced so far and so well.
Definitely, I will dedicate all my resources to analyze the code and work towards integrating it in VeraCrypt, with all credits going to the original author of course.
This is a good start for 2016!
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I’ve implemented prototype of UEFI support for Veracrypt + EFI + Windows.
The prototype loads Windows 8.1 in EFI mode from GPT drive. The prototype has been tested on VirtualBox 5.0.14.
Notes: This is prototype only. Veracrypt driver is not modified.
It is not suitable for production because it has limited functionality and it uses the following scenario to boot:
1) Boot from external media;
2) Encrypt system partition via EFI crypt application;
3) Start EFI DXE driver to decrypt Windows system partition on fly;
4) Start windows loader.
If it is interesting it is necessary to discuss user friendly setup and other EFI specific details.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Thank you Alex for sharing your prototype.
It's a very intersting approach since it doesn't require modifying VeraCrypt driver, which is a big plus compared to other solutions.
Indeed, a lot of work is needed to make it easy to install and more user friendly but this is a very encourageing step towards full UEFI support.
Here is a video showing UEFI boot of a Windows 8.1 system encrypted with VeraCrypt using Alex prototype (the warning displayed by VeraCrypt after logon is normal since its unmodified binaries don't find the standard MBR bootloader)
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
One enhancement is this version is the System Encryption settings dialog (menu System -> Settings) which supports basic configuration of EFI bootloader (for now only storing PIM and storing hash). Other configurations will be added in the future.
There is still no rescue disk in this version although an ISO is created that only serves as holder of the backup header.
Important Note: Disabling legacy compatibility mode in BIOS configuration before starting system encryption solves many Pre-Test failures. This option can be called CSM, Compatibility Mode, Legacy Mode or other names depending on the motherboard manufacturer.
Big thanks to Alex for his help and hard work on EFI loader. He is now a member of VeraCrypt dev team in charge of EFI bootloader.
Big thanks also for all those who tested the previous EFI version and reported their results. More tests are needed and your feedback is welcomed.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
There is still no rescue disk in this version although an ISO is created that only serves as holder of the backup header.
I have encrypted system partition on EFI/GPT disk. But another instalation of Windows replace EFI patrition on this encrypted disk. After start VC not ask for password.
I have "rescue" disk, but it's not bootable. How to restore proper EFI?.
Last edit: Camis 2016-07-17
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
A new version (BETA8) of EFI Preview installer has been uploaded.
It brings a fix for a Windows booting issue on some machines. It also introduces a first implementation of some GOST standards (Streebog and GOSTHASH for hashing and GOST89 for encryption).
The new GOST encryption standard Kuznyechik (also known as Grasshopper) and the Japanese Camellia cipher will be included in a next build.
These GOST implementations are not optimized (taken from GostCrypt project) so small PIM values (like 1) are more practical for testing.
As usual, tests and feedback are welcomed.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
EFI loads boot loader from EFI boot partition. So encryption of entire drive is not possible. At least EFI boot partition has to be created and contains loader.
Probably we can create hidden OS feature later.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I tried encrypting my Windows 10 installation with 1.18 beta 8 EFI preview. The bootloader does not run because Windows boots using an EFI system partition that is different from the partition where Windows is installed, so the test fails because I'm never prompted for my password after restarting the computer. And as Camis said above, I can only choose to encrypt the Windows boot partition instead of the entire drive. I'm assuming that would fix this issue.
Also, two issues I noticed with this beta: decrypting drives takes much longer than 1.17 does (1.17 takes about 2-5 seconds per drive, 1.18 beta 8 seems to take about 15 seconds or more), and passwords are not being properly temporarily cached while decrypting favorite volumes even though I have that option checked and both of these favorite volumes use the same password.
Last edit: Robert M 2016-05-27
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
A new version (BETA9) of EFI Preview installer has been uploaded.
Some fixes were implemented to solve Pre-Test failures and boot issues.
Also, GostHash was removed and new optimized implementations for Streebog and Gost89 are now used. These implementations are incompatible with the previous version because the previous ones were taken verbatim from GostCrypt project which contained issues.
An enhanced benchmark dialog is now included which enabled checking the performance of hash algorithms and PRF functions (PIM and pre-boot included).
This build is the first to use Visual C++ 2010 both for the EFI BootLoader and for the Windows binaries. This move was necessary because of SSE assembly bugs in Visual C++ 2008.
Thank you all for the tremendous feedback. The road to production-ready release is still long but things are moving, slowly but surely, in the right direction although.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Unfortunately, the build I uploaded 5 hours ago contained drivers built using VC++ 2008 instead of those built using VC++ 2010 and this makes them not working on 64-bit machines because of the bug in VC++ 2008 I mentionned above.
I have uploaded the correct installer (version 1.18.9.1). Please download/install again.
Sorry for the mistake. I have put safeguards in place to avoid such mistakes in the future.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Hey, I use VC v1.18.9.1 and it's working fine, except for GPT/UEFI booting. The pretest fails, due to "incorrect password". It doesn't matter what hashing or encrypting algorithm I use.
I use Windows 10 x64 bit.
Partitions are: [Recovery], [EFI System], [Boot, Page File, Cash Dump, Primary] - Was a clean Win10 Installation.
Mainboard: Asus Crosshair Formula-Z
Bios: 1901 - 12.24.2013
I testet this version of VC on a VM with Win10. There it has only 2 partitions (VM non-UEFI BIOS) and it works fine.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
This is very strange. Either the password entered at boot is somehow not the same as the one used during Windows encryption wizard or VeraCrypt is reading the header from the wrong partition.
What is your keyboard layout on Windows? To eliminate password hopythesis, can you use the simple password eeee?
As for VM, you can test EFI on it. For VeraCrypt EFI development, VirtualBox with EFI activated is used.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Interesting, now it worked, but only on the second try.
When the computer restarted, first there was this message:
The system found unauthorized changes on the firmware.operatin system of UEFI drivers.
Press N to run the next boot device, or enter directly to BIS Setup if there are other boot devices installed.
...
By pressing N, Windows is booting up and Vera Crypt says pretest failed (obvious).
After changin the BIOS settings under: Boot options -> Secure Boot state -> Key Management -> Clear Secure Boot Keys.
VC Boot was used.
After I entered the password "eeee" and left the PIM untouched (there was a"*" character), it gave me this message:
Decrypt error(3)
After reentering the password AND deleting the * from PIM, I was able to login.
Previously I wanted to use the @ character in my password. I use German layout in Windows, but VC changes it to US one. So tried all combinations in German layout and the English one, the password was everytime incorrect.
I will try again later.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Ok I was able to login with "eeee" but on the second try.
First of all after the reboot, there was this message:
The system found unauthorized changes on the firmware.operating system of UEFI drivers.
Press [N] to run the next boot device, or enter directly to BIOS Setup if there are other boot devices installed.
...
By pressing n I obviously boot the Windows boot. In BIOS I go to boot settings -> secure boot state -> key management -> and clear secure boot keys. Then I am able to boot VC.
After entering the first time with: "eeee", it gave me this output:
Enter Password: *****
PIM (Leave empty for default): *
Autherize...
Decrypt error (3)
There is one * too much in pwd and one in PIM. I assume that VC sometimes add two * for only one character, for better security, but after I reentered the pwd and deleted the * char in PIM, I was able to login.
I will test some other cases, later.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Ok I was able to login with "eeee" but on the second try.
First of all after the reboot, there was this message:
The system found unauthorized changes on the firmware.operating system of UEFI drivers.
Press [N] to run the next boot device, or enter directly to BIOS Setup if there are other boot devices installed.
...
By pressing n I obviously boot the Windows boot. In BIOS I go to boot settings -> secure boot state -> key management -> and clear secure boot keys. Then I am able to boot VC.
After entering the first time with: "eeee", it gave me this output:
Enter Password: *****
PIM (Leave empty for default): *
Autherize...
Decrypt error (3)
There is one * too much in pwd and one in PIM. I assume that VC sometimes add two * for only one character, for better security, but after I reentered the pwd and deleted the * char in PIM, I was able to login.
I will test some other cases, later.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I see that sometimes VC is showing two * when I write only one character. But when I delete one character, it deletes two*. Sometimes when it shows only one * and I press del, it deletes two *. It's quite irritating ^^
Last edit: Fallen 2016-07-03
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
From your description, it seems that there is an issue with your keyboard since VeraCrypt bootloader is receiving extra characters. VeraCrypt never adds characters on its own, even for the PIM field, so definitely extra characters are received from keyboard or motherboard.
What's your keyboard layout? Is your keyboard wireless?
On thing that can be done is to add option to display password/PIM values so you can see the value of extra characters.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
View and moderate all "Technical Topics" comments posted by this user
Mark all as spam, and block user from posting to "Forums"
DriveCrypt Plus Pack can also encrypt GPT disks, but i prefer BestCrypt. It is cheaper and easier to use.
Hi everybody,
are there any news on this topic?
Hi,
Unfortunately, development of UEFI support is still on standby. Definitely some help is needed, either from other developers that have knowldge on it or through external funding to help pay for full time work on this feature.
EFI is quite simple actually, but the Microsoft bootloader chain complicates it a bit. You basically have two issues:
1) Make the unecrypted block device available to the consuming Applications/Bootloaders and DXEs including BOOTMGFW
2) Transmit the encryption key to the Windows Veracrypt I/O Filter from PreOS. It can be done using a RuntimeDXE using a secure key exchange algorithm which destroys it after the first read attempt or via a SystemTable that you would have to clear manually afterwards, but you have no guarantee that you're the first or the only one reading. This is simple and I would recommend the RuntimeDXE approach as it can enforce giving the decryption key only to the veracrypt driver and not any malware. But we have a problem here as well because we don't have an API for accessing a RuntimeDXE from Windows. From what I've discovered, we have: ExpGetSystemFirmwareTableInformation an undocumented API which we can use to get the reset of the system tables.
You can do it the same way you do it on Windows and basically intercept the I/O at the UEFI level or maybe at the BOOTLIB level but I'm not sure if you can instruct bootmgr.efi to load your PreOS driver via BCD.
You can also install a new driver for a virtual hard-drive and present the decrypted volume as a new block device, but that would complicate the bootloader->kernel root filesystem arguments as the device trees wouldn't match anymore and Windows probably wouldn't be able to find the partition again. It's complicated also because Windows mixes it's native device tree with ARC device trees and "EFI device path".
Let's detail the device tree issue a bit. If you create a virtual block device instead of intercepting the BlockIO, the device path for an NTFS Partition would look like:
PciRoot(0x0)/Pci(0x11,0x0)/Pci(0x4,0x0)/Sata(0x0,0x0,0x0)/HD(1,GPT,123456-1234-1234-1234-12345678,0x28,0x64000)/VenHw(VERAGUID-0123-1234-5678-12345678)
which wouldn't match any recognised BootMGFW path, or:
VenHw(VERAGUID-0123-1234-5678-12345678)/HD(1,GPT,123456-1234-1234-1234-12345678,0x28,0x64000)
Which would work with BootMGFW and Winload, but might fail at the NT Kernel since it doesn't start with the ACPI Root.
If Windows DOES support passing the Filesystem GUID as a rootfs argument to ntoskrnl.exe (like MacOS does) or the Filesystem Label (like Linux does), then it can simply scan all the volumes in the system reported by the loaded drivers and it would work, but I don't think that's the way it works.
You can create a new default bootloader that decrypts the volumes and replaces the block-io protocol of that EFI_Handle and the load bootmgfw.efi. This seems like the ugliest and simplest way. The risk is that BOOTMGFW is not aware that you intercepted the APIs and a Windows version upgrade or SP install might screw your boot configuration. This is what McAffee does.
My favorite aproach is based on ReactOS. Basically they are reimplementing bootmgfw, bootmgr and winload. Since we don't need all that functionality, we could in theory write an NTFS filesystem driver that recognises Veracrypt which shows an imaginary EFI\Boot\boot.efi for that filesystem. That boot.efi would in turn load a compatible BOOTLIB made by ReactOS, which chainloads winload.efi with the correct data structures just like the original bootmgfw.efi would. The advantage of this is that we get our bootloader back.
Windows has an idiotic design in which the UEFI bootloader is ignored and Windows has it's own bootloader. This was acceptable until Windows 8 when they moved-it to post-ntkrnlmp userland. So if you want to boot another OS, you have to fully load the Windows 8 kernel/drivers, it then displays the boot menu in userland and if you select some other boot entry it will reboot the computer to that something else. It's the definition of insanity.
Hi,
regarding the UEFI support, now a boot loader exists that seems to work:
https://github.com/f-n/CipherShed/tree/efi/src/Boot/EFI/
The loader requires a patch of the Windows driver. This patch was also successfully tested (at least using Windows 8.1). The technical details are described in this paper:
https://github.com/f-n/CipherShed/blob/efi/src/Boot/EFI/doc/cs_efi_loader.pdf
This paper also contains information about the status of the loader and driver development as well as some hints to setup the test and development environment.
To demonstrate the behaviour of the EFI loader and the Windows driver, two screencasts exist:
https://github.com/f-n/CipherShed/tree/efi/src/Boot/EFI/doc/demo-ciphershed-loader-driver.flv
https://github.com/f-n/CipherShed/tree/efi/src/Boot/EFI/doc/demo-ciphershed-loader.flv
Hi Falk,
Thank you for sharing this work, it looks amazing!
I was not aware that it advanced so far and so well.
Definitely, I will dedicate all my resources to analyze the code and work towards integrating it in VeraCrypt, with all credits going to the original author of course.
This is a good start for 2016!
Hi, can you give an estimation of the time needed to implement this ?
+1
Hello!
I’ve implemented prototype of UEFI support for Veracrypt + EFI + Windows.
The prototype loads Windows 8.1 in EFI mode from GPT drive. The prototype has been tested on VirtualBox 5.0.14.
Notes: This is prototype only. Veracrypt driver is not modified.
It is not suitable for production because it has limited functionality and it uses the following scenario to boot:
1) Boot from external media;
2) Encrypt system partition via EFI crypt application;
3) Start EFI DXE driver to decrypt Windows system partition on fly;
4) Start windows loader.
If it is interesting it is necessary to discuss user friendly setup and other EFI specific details.
Thank you Alex for sharing your prototype.
It's a very intersting approach since it doesn't require modifying VeraCrypt driver, which is a big plus compared to other solutions.
Indeed, a lot of work is needed to make it easy to install and more user friendly but this is a very encourageing step towards full UEFI support.
Here is a video showing UEFI boot of a Windows 8.1 system encrypted with VeraCrypt using Alex prototype (the warning displayed by VeraCrypt after logon is normal since its unmodified binaries don't find the standard MBR bootloader)
I have uploaded a new EFI preview installer for VeraCrypt 1.18-BETA7 which solves many compatibility, usability and stability issues. You can get it from the same URL https://sourceforge.net/projects/veracrypt/files/VeraCrypt%20Nightly%20Builds/VeraCrypt%20Setup%201.18-EFI-PREVIEW-BETA.exe/download
One enhancement is this version is the System Encryption settings dialog (menu System -> Settings) which supports basic configuration of EFI bootloader (for now only storing PIM and storing hash). Other configurations will be added in the future.
There is still no rescue disk in this version although an ISO is created that only serves as holder of the backup header.
Important Note: Disabling legacy compatibility mode in BIOS configuration before starting system encryption solves many Pre-Test failures. This option can be called CSM, Compatibility Mode, Legacy Mode or other names depending on the motherboard manufacturer.
Big thanks to Alex for his help and hard work on EFI loader. He is now a member of VeraCrypt dev team in charge of EFI bootloader.
Big thanks also for all those who tested the previous EFI version and reported their results. More tests are needed and your feedback is welcomed.
I have encrypted system partition on EFI/GPT disk. But another instalation of Windows replace EFI patrition on this encrypted disk. After start VC not ask for password.
I have "rescue" disk, but it's not bootable. How to restore proper EFI?.
Last edit: Camis 2016-07-17
A new version (BETA8) of EFI Preview installer has been uploaded.
It brings a fix for a Windows booting issue on some machines. It also introduces a first implementation of some GOST standards (Streebog and GOSTHASH for hashing and GOST89 for encryption).
The new GOST encryption standard Kuznyechik (also known as Grasshopper) and the Japanese Camellia cipher will be included in a next build.
These GOST implementations are not optimized (taken from GostCrypt project) so small PIM values (like 1) are more practical for testing.
As usual, tests and feedback are welcomed.
Hi
I have 2 partition on SSD system disk GPT, and i need to encrypt whole disk. But i can encrypt only system partition.
Does this feature will be introduced ?. Any est date ?.
regards.
Hi Camis,
EFI loads boot loader from EFI boot partition. So encryption of entire drive is not possible. At least EFI boot partition has to be created and contains loader.
Probably we can create hidden OS feature later.
I tried encrypting my Windows 10 installation with 1.18 beta 8 EFI preview. The bootloader does not run because Windows boots using an EFI system partition that is different from the partition where Windows is installed, so the test fails because I'm never prompted for my password after restarting the computer. And as Camis said above, I can only choose to encrypt the Windows boot partition instead of the entire drive. I'm assuming that would fix this issue.
Here's what my partition setup looks like on this drive.
Also, two issues I noticed with this beta: decrypting drives takes much longer than 1.17 does (1.17 takes about 2-5 seconds per drive, 1.18 beta 8 seems to take about 15 seconds or more), and passwords are not being properly temporarily cached while decrypting favorite volumes even though I have that option checked and both of these favorite volumes use the same password.
Last edit: Robert M 2016-05-27
A new version (BETA9) of EFI Preview installer has been uploaded.
Some fixes were implemented to solve Pre-Test failures and boot issues.
Also, GostHash was removed and new optimized implementations for Streebog and Gost89 are now used. These implementations are incompatible with the previous version because the previous ones were taken verbatim from GostCrypt project which contained issues.
An enhanced benchmark dialog is now included which enabled checking the performance of hash algorithms and PRF functions (PIM and pre-boot included).
This build is the first to use Visual C++ 2010 both for the EFI BootLoader and for the Windows binaries. This move was necessary because of SSE assembly bugs in Visual C++ 2008.
Thank you all for the tremendous feedback. The road to production-ready release is still long but things are moving, slowly but surely, in the right direction although.
Unfortunately, the build I uploaded 5 hours ago contained drivers built using VC++ 2008 instead of those built using VC++ 2010 and this makes them not working on 64-bit machines because of the bug in VC++ 2008 I mentionned above.
I have uploaded the correct installer (version 1.18.9.1). Please download/install again.
Sorry for the mistake. I have put safeguards in place to avoid such mistakes in the future.
Hey, I use VC v1.18.9.1 and it's working fine, except for GPT/UEFI booting. The pretest fails, due to "incorrect password". It doesn't matter what hashing or encrypting algorithm I use.
I use Windows 10 x64 bit.
Partitions are: [Recovery], [EFI System], [Boot, Page File, Cash Dump, Primary] - Was a clean Win10 Installation.
Mainboard: Asus Crosshair Formula-Z
Bios: 1901 - 12.24.2013
I testet this version of VC on a VM with Win10. There it has only 2 partitions (VM non-UEFI BIOS) and it works fine.
This is very strange. Either the password entered at boot is somehow not the same as the one used during Windows encryption wizard or VeraCrypt is reading the header from the wrong partition.
What is your keyboard layout on Windows? To eliminate password hopythesis, can you use the simple password eeee?
As for VM, you can test EFI on it. For VeraCrypt EFI development, VirtualBox with EFI activated is used.
Interesting, now it worked, but only on the second try.
When the computer restarted, first there was this message:
By pressing N, Windows is booting up and Vera Crypt says pretest failed (obvious).
After changin the BIOS settings under: Boot options -> Secure Boot state -> Key Management -> Clear Secure Boot Keys.
VC Boot was used.
After I entered the password "eeee" and left the PIM untouched (there was a
"*"character), it gave me this message:Decrypt error(3)
After reentering the password AND deleting the * from PIM, I was able to login.
Previously I wanted to use the @ character in my password. I use German layout in Windows, but VC changes it to US one. So tried all combinations in German layout and the English one, the password was everytime incorrect.
I will try again later.
Ok I was able to login with "eeee" but on the second try.
First of all after the reboot, there was this message:
By pressing n I obviously boot the Windows boot. In BIOS I go to boot settings -> secure boot state -> key management -> and clear secure boot keys. Then I am able to boot VC.
After entering the first time with: "eeee", it gave me this output:
There is one * too much in pwd and one in PIM. I assume that VC sometimes add two * for only one character, for better security, but after I reentered the pwd and deleted the * char in PIM, I was able to login.
I will test some other cases, later.
(My browser doesn't want to reply to a post.. )
Ok I was able to login with "eeee" but on the second try.
First of all after the reboot, there was this message:
By pressing n I obviously boot the Windows boot. In BIOS I go to boot settings -> secure boot state -> key management -> and clear secure boot keys. Then I am able to boot VC.
After entering the first time with: "eeee", it gave me this output:
There is one * too much in pwd and one in PIM. I assume that VC sometimes add two * for only one character, for better security, but after I reentered the pwd and deleted the * char in PIM, I was able to login.
I will test some other cases, later.
I also can't login with "1234567890".
I see that sometimes VC is showing two * when I write only one character. But when I delete one character, it deletes two
*. Sometimes when it shows only one*and I press del, it deletes two *. It's quite irritating ^^Last edit: Fallen 2016-07-03
From your description, it seems that there is an issue with your keyboard since VeraCrypt bootloader is receiving extra characters. VeraCrypt never adds characters on its own, even for the PIM field, so definitely extra characters are received from keyboard or motherboard.
What's your keyboard layout? Is your keyboard wireless?
On thing that can be done is to add option to display password/PIM values so you can see the value of extra characters.