Re: Veracrypt Windows 10 Portable
Lillia Iniguez
VeraCrypt is a software that creates an encrypted container that will contain the data you will put in it. If you install VeraCrypt on your Windows Server and create an encrypted container on your fileserver, your users will need to have VeraCrypt installed on their Client computers to be able to open the containers.
I am looking to find a way to encrypt files and folders on my windows 2016 server. I need to find a solution which will allow me to assign users to access keys. Would you say EFS is the best way of doing this?
So my desktop PC has two SSDs in it. One is my main Linux drive that only has two partitions, /boot and /, which is just a simple full disk dm-crypt LUKS encryption setup, using systemd-boot. The other drive is a Windows 10 installation also fully encrypted with VeraCrypt.
My esp is mounted at /boot. So naturally I put shellx64.efi in /boot/EFI and that's why Win10.conf says /EFI/shellx64.efi. However after configuring all this, when I select Windows 10 on the systemd-boot screen, nothing happens, there is only a single non-blinking cursor top left of the screen and it is stuck there.
What am I missing? I know if both operating systems were on the same drive everything would be much easier as I could just point to the EFI that is on the same drive, but they're not so how do I make this work?
Anyone able to help with this? I was using linux-hardened when I initially posted this, but have moved to the regular linux kernel for other reasons. I thought it might also fix this problem so I came back to trying it again, but no luck. Same problem, single non-blinking cursor at the top left of the screen and it is stuck there when I select Windows 10 entry. I also placed shellx64.efi in /boot instead of /boot/EFI/ and edited Win10.conf accordingly, same problem.
So after removing the -nointerrupt -noconsolein -noconsoleout options I can boot into the shell, but nothing happens, it doesn't execute windows.nsh. I have to manually type windows.nsh and press enter. Once I do, I'm prompted for the VeraCrypt password and PIM, but this happens inside the shell, not like the regular VeraCrypt boot which is a fullscreen different looking boot screen. When I enter the password and PIM inside the shell, it says success but nothing happens. It is stuck there, doesn't boot into Windows.
So after removing the -nointerrupt -noconsolein -noconsoleout options I can boot into the shell, but nothing happens, it doesn't execute windows.nsh. I have to manually type windows.nsh and press enter.
Once I do, I'm prompted for the VeraCrypt password and PIM, but this happens inside the shell, not like the regular VeraCrypt boot which is a fullscreen different looking boot screen. When I enter the password and PIM inside the shell, it says success but nothing happens. It is stuck there, doesn't boot into Windows.
O.K. - one last test: When you boot into the UEFI shell as above don't start windows.nsh. Issue the command "map" and look for the correct file system (FS[0-9]:) of your EFI partition. In most cases this should be "FS0:". Issue those commands:
I did that, it was FS3 for me. Same result, asks for the VeraCrypt password and PIM inside the shell, and once I enter both it says success but nothing happens. Doesn't switch to Windows, it is stuck there.
What I would like is for systemd-boot to instantly show me the fullscreen VeraCrypt password and PIM prompt (the same one I get when I select VeraCrypt bootloader from the BIOS) when I select the Windows 10 entry in systemd-boot. But this just doesn't happen.
As I am neither a developer nor a specialist on EFI executables I can only guess what's the problem here: The VeraCrypt EFI executable (DcsBoot.efi) can not be called from the EFI shell and must be called by the EFI Boot Manager inside the BIOS to provide the functionality that you require.
In that case maybe create a working uefi boot entry for windows/veracrypt and boot through the boot menu provided by your uefi implementation.
If that works you can try to add a menu item to systemd-boot that sets the BootNext UEFI variable to that entry (if the shell has soemthing like that, maybe you can find some efi program you can compile?) and then perform a warm reboot (reset -w)
nvme0n1p1, p2 and p3 were default partitions created by Windows. (I installed Windows first, then installed Arch). I installed Arch in a way, that my /boot is on a separate partition, NOT on the existing EFI partition created by Windows.. So have that in mind, beacuse I think more people install their /boot partition to existing one created by Microsoft.
(make sure to create myMountPoint directory earlier).
Inside that mounted partition was single "EFI" directory, and inside that "EFI" directory there were 3 directories: "Boot", "Microsoft" and "VeraCrypt".
And then copy all of the contents of the mounted "EFI" directory to (in my case) /boot/EFI.
And that's actually all. I DID NOT HAVE TO create any entries in /boot/loader/entries, because somehow they were picked up by the systemd-boot. One problem with my solution is, I copied all contents of "EFI" partition, and I'm sure there is only certain files needed to be copied, because if all of them will get copied like I showed, in the systemd-boot menu, many entries will show up, and in my case all point to the same Windows with working VeraCrypt.
So to improve that solution, you need to find what minimal files needs to be copied, not to have such bloated boot menu.
But for me it works, it's better than entering the UEFI/BIOS menu to boot to Windows, and I'm lazy, so I left it as it is xD.
I have Windows 10 computer with full disk encryption with VeraCrypt (standard settings- AES and SHA-256). Can I now install Ubuntu on this hard drive (preferably with full disk encryption too) without messing up the VeraCrypt bootloader?
n.b.Files on an unencrypted Windows, (Win 7, have not tried Win10), are accessible for anyone using an Ubuntu Install disk, booting to 'try' the Ubuntu system, and then mounting the NTFS partition. All files (unencrypted by third-party encryption software) including Administrator files are accessible, copyable onto USB media, and deletable without a trace that Windows has been accessed.
I would not attempt it. Too often we see requests for help because an "along-side another OS" installation failed and the tools we have to resolve can only deal with unencrypted disks... Please correct me if I'm wrong...
I am unsure if decrypting the whole disk, install Ubuntu and encrypt again is an option in VeraCrypt? I had a brief look at their website but did not find anything helpfull.
My advise: either install Ubuntu as a VM in Windows 10 using VMWare or VirtualBox or install Ubuntu on a separate bootable disk.
On UEFI boot systems, this article claims one can do it by first installing the dual boot, encrypting windows system partition, reversing boot loader order from: VeraCrypt> Grub (which gets skipped after whole diskencryption) to: Grub>VeraCrypt. To reverse the order of the bootloaders apparently one could use EasyUefi, and this link lists more ways to reverse the order.
OK. So I used VeraCrypt to encrypt the system partition and now Windows boots its automated repair only. After the repair in what I think is Windows Recovery Environment I can choose to boot off USB and THERE I can choose to boot the VeraCrypt loader.
I used BOOTICE (latest version) to modify the UEFI boot entries to boot the VeraCrypt loader in the first place by choosing "Active", "Boot this entry next time" and by placing VeraCrypt in the first position on the list using the "Up" button. When I restart the PC, UEFI boots the VeraCrypt Loader as it should but when I switch off the PC and on again, UEFI boots to the Windows Boot Manager which loads the Windows Automated Repair again.This description is probably somewhat inaccurate because I don't exactly know how UEFI booting works [recommend me a good read ;)]. Obviously in my UEFI (in BIOS) I can't find the VeraCrypt boot option, there's only the Windows Boot Manager and EFI shell to choose from. How do I insert the VeraCrypt loader there? I have secure boot disabled.
I also tried to use Windows BCDEdit cmdlet but it is a no go (it does not see the VeraCrypt loader). Neither is Visual BCD Editor. My system is MSI H81-P33 & i5-4690K with the latest BIOS. Only BOOTICE somehow works.
OK, I came up with a solution and it works even after I switch off the computer. In BOOTICE I modified the Windows Boot Manager to load "\EFI\VERACRYPT\DCSBOOT.EFI" (the VeraCrypt loader) instead of the original Windows loader (\EFI\MICROSOFT\BOOT\BOOTMGFW.EFI) and saved it. I only modified "Media file:" text field in BOOTICE. When I reopened BOOTICE to see if the change sticked I noticed that there are now 2 separate Windows Boot Manager entries: the original (which I presume Windows automatically recreated after I changed it) and the one I changed with the VeraCrypt loader path.
My UEFI (BIOS) now sees 2 separate Windows Boot Manager entries (which are named the same, no need to change that I guess). I hope it doesn't compromise my security and Windows performance in any way. And I hope any future Windows Updates won't mess with my solution.
Note, as future Win10 update can bypass the patch, including major security patches that alter the firmware, there is no guarantee the machine will always work, such as with the way Truecrypt works with Win7. While you can recover and roll back to the last good OS, it can take much time. Bitlocker works without issue or in Win10 Home, use Veracrypt in file container mode which is reliable and transportable.
d3342ee215