How to properly set up VeraCrypt to be able to boot encrypted OS installed on raw partition?
Thanks to Alex/kavsrf (dcs.sourceforge.io) I'm able to have hidden OS however EFI boot from within VM doesn't seem to be happy and doesn't prompt for password.
Guess is that it is one of security elements checking system ID of the system which differs between physical system and VM system hence not launching password prompt.
Not sure if it shouldn't be more under DCS project, but since it is VeraCrypt, thought will seek for advise here first.
The setup is as following based on EFI:
1. encrypted OS (w10 64bit)
2. hidden encrypted OS (DCS based) (w10 64bit).
3. encrypted Linux (Luks).
Hard drive is NVE.
All works fine when I boot into any of above systems directly.
The problem is visible when trying to launch VeraCrypt/DCS from within other system being it any of windows 10 or Linux using VmWare or VirtualBox.
I've tried also with latest VmWare Workstation Pro 14, as it support NVE drives and detected drive properly as NVE and exposed it accordingly to guest system.
I'm not using external USB with keys, dedicated partition on HDD is used for that and exposed to VM in same order as physical one.
Many thanks for help.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I use the same configuration. To start Linux in vm from Windows I use VirtuaBox. There is problem to start it automatic. By default EFI shell is executed and I run DcsBoot from the EFI shell.
Note: my disk configuration - SSD + HDD. ESP is on HDD. Linux is on HDD. Windows system is on SSD.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
What didn't work for me was to run Windows (VeraCrypt/DCS) encrypted
from within Linux and this is the difficulty.
What worked without any problem was to run Linux within Windows
(VeraCrypt/DCS).
The problem is itself with VeraCrypt/DCS boot as it then doesn't even
ask for password. My take is that it is due to some checks if running on
the same system.
This in itself raises another problem - if hardware fails, let's say
anything but HDD, moving HDD wouldn't work easily even to same hardware
as these checks would fail in the same way?
Thanks,
Dawid
On 2017-10-30 4:41, Alex wrote:
Hello,
I use the same configuration. To start Linux in vm from Windows I use
VirtuaBox. There is problem to start it automatic. By default EFI
shell is executed and I run DcsBoot from the EFI shell.
Note: my disk configuration - SSD + HDD. ESP is on HDD. Linux is on
HDD. Windows system is on SSD.
yes. "dcscfg -srm" creates platform dependent mark (SMBIOS structures based) To solve the problem you can create two diffrent volumes with diffrent mark or update the mark before boot.
one more: mark is in 61 sector.
Last edit: Alex 2017-10-31
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Alex, thanks for help again.
Are there any chances that multple marks could be embedded in i.e. USB key/separate partition?
If I'd go in direction to create second mark. How should the process look like?
Currently I have mark of physical HW.
How to create mark for VM HW? Should I boot to DSC shell (prior system boots and then modify the mark?)
I prefer to ask before try, as don't want to screw up my system.
Thanks,
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
VM HW mark is possible to create from EFI shell booted in the VM.
Mark can be on disk (sector 61) or on any partition on the usb drive.(any block device)
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I've managed to go past password check, by renaming platform info and
the other small file.
Unfortunately I couldn't run DcsCfg.dcs -srm. Somehow VmWare EFI shell
didn't recognize executable file and complained. I've tried running
through Shell provided under one of the posts/guide related to DCS with
same result. Hence moved ahead and removed files which allowed me to get
to password prompt.
Once password was accepted, question about which Hash to use was
presented. Selected "TEST ALL" and result was that "Authorizing...
Successs.." Followed by Start ... and digits.
The only problem is that system doesn't do anything afterwards. Not sure
what is the problem. Is it searching next EFI boot option or something else?
vmware.log shows:
2017-11-25T22:00:09.186+01:00| vcpu-0| I125: Guest: About to do EFI boot: VeraCrypt
2017-11-25T22:00:44.553+01:00| vcpu-0| I125: NVME-VMM: Controller level reset via CC.EN bit transition on nvme0
2017-11-25T22:00:44.553+01:00| vcpu-0| I125: NVME-CORE: Doing a partial reset of controller regs and queues.
2017-11-25T22:00:44.556+01:00| vcpu-0| I125: NVME-VMM: Controller level reset via CC.EN bit transition on nvme0
2017-11-25T22:00:44.556+01:00| vcpu-0| I125: NVME-CORE: Doing a partial reset of controller regs and queues.
2017-11-25T22:00:44.558+01:00| vcpu-0| I125: NVME-VMM: Controller level reset via CC.EN bit transition on nvme0
2017-11-25T22:00:44.558+01:00| vcpu-0| I125: NVME-CORE: Doing a partial reset of controller regs and queues.
2017-11-25T22:00:44.561+01:00| vcpu-0| I125: NVME-VMM: Controller level reset via CC.EN bit transition on nvme0
2017-11-25T22:00:44.561+01:00| vcpu-0| I125: NVME-CORE: Doing a partial reset of controller regs and queues.
2017-11-25T22:00:44.563+01:00| vcpu-0| I125: NVME-VMM: Controller level reset via CC.EN bit transition on nvme0
2017-11-25T22:00:44.563+01:00| vcpu-0| I125: NVME-CORE: Doing a partial reset of controller regs and queues.
2017-11-25T22:00:44.566+01:00| vcpu-0| I125: NVME-VMM: Controller level reset via CC.EN bit transition on nvme0
2017-11-25T22:00:44.566+01:00| vcpu-0| I125: NVME-CORE: Doing a partial reset of controller regs and queues.
2017-11-25T22:00:44.568+01:00| vcpu-0| I125: NVME-VMM: Controller level reset via CC.EN bit transition on nvme0
2017-11-25T22:00:44.568+01:00| vcpu-0| I125: NVME-CORE: Doing a partial reset of controller regs and queues.
2017-11-25T22:00:44.571+01:00| vcpu-0| I125: NVME-VMM: Controller level reset via CC.EN bit transition on nvme0
2017-11-25T22:00:44.571+01:00| vcpu-0| I125: NVME-CORE: Doing a partial reset of controller regs and queues.
2017-11-25T22:00:44.574+01:00| vcpu-0| I125: NVME-VMM: Controller level reset via CC.EN bit transition on nvme0
2017-11-25T22:00:44.574+01:00| vcpu-0| I125: NVME-CORE: Doing a partial reset of controller regs and queues.
2017-11-25T22:00:44.577+01:00| vcpu-0| I125: NVME-VMM: Controller level reset via CC.EN bit transition on nvme0
2017-11-25T22:00:44.577+01:00| vcpu-0| I125: NVME-CORE: Doing a partial reset of controller regs and queues.
2017-11-25T22:00:44.580+01:00| vcpu-0| I125: NVME-VMM: Controller level reset via CC.EN bit transition on nvme0
2017-11-25T22:00:44.580+01:00| vcpu-0| I125: NVME-CORE: Doing a partial reset of controller regs and queues.
2017-11-25T22:00:46.841+01:00| vcpu-0| I125: Tools: Tools heartbeat timeout.
2017-11-25T22:00:46.841+01:00| vcpu-0| I125: Tools: Running status rpc handler: 1 => 0.
2017-11-25T22:00:46.841+01:00| vcpu-0| I125: Tools: Changing running status: 1 => 0.
Thanks,
On 11/07/2017 04:40 PM, Alex wrote:
VM HW mark is possible to create from EFI shell booted in the VM.
Mark can be on disk (sector 61) or on any partition on the usb
drive.(any block device)
Forgot to say big thanks for all your help! It worked like magic!
I can now boot encrypted raw partition from VM.
The only other open question is if it is possible to somehow trick
system to load password without prompt, i.e. as a key from somewhere?
(only in case of boot from VM). I didn't find solution to that but to
get VM booted at all, I have EFI partition loaded from file available at
hypervisor level pretending to be partition on the raw disk.
It looks like that:
real HW:
EFI partition.
OS 1 decoy
OS 2 hidden
Other OS (encrypted too)
etc.
when booting from hypervisor (as VM):
EFI partition -> loaded image from file system (in fact it is
encrypted FS on partition 4 under Other OS).
OS 1 decoy
OS 2 hidden - inaccessible for VM, but visible
Other OS (encrypted too) - inaccessible for VM, but visible.
Hope that makes sense and helps others.
Thanks again for help.
On 11/27/17 8:19 AM, Alex wrote:
Hello Bugsy,
by default after authorization success DcsBoot starts
EFI\Microsoft\Boot\bootmgfw.efi. It can be modified via DcsProp or via
USB authorization media.
e.g. to check state you can try to execute EFI shell after
authorization success
<!-- AutoLogin 0/1 Posibility to avoid password prompt AutoPassword is password by default Use it with PlatformLocked or TPMLocked enabled to lock password to the computer. --><configkey="AutoLogin">0</config><configkey="AutoPassword"></config>
Hi Guys,
How to properly set up VeraCrypt to be able to boot encrypted OS installed on raw partition?
Thanks to Alex/kavsrf (dcs.sourceforge.io) I'm able to have hidden OS however EFI boot from within VM doesn't seem to be happy and doesn't prompt for password.
Guess is that it is one of security elements checking system ID of the system which differs between physical system and VM system hence not launching password prompt.
Not sure if it shouldn't be more under DCS project, but since it is VeraCrypt, thought will seek for advise here first.
The setup is as following based on EFI:
1. encrypted OS (w10 64bit)
2. hidden encrypted OS (DCS based) (w10 64bit).
3. encrypted Linux (Luks).
Hard drive is NVE.
All works fine when I boot into any of above systems directly.
The problem is visible when trying to launch VeraCrypt/DCS from within other system being it any of windows 10 or Linux using VmWare or VirtualBox.
I've tried also with latest VmWare Workstation Pro 14, as it support NVE drives and detected drive properly as NVE and exposed it accordingly to guest system.
I'm not using external USB with keys, dedicated partition on HDD is used for that and exposed to VM in same order as physical one.
Many thanks for help.
Hello,
I use the same configuration. To start Linux in vm from Windows I use VirtuaBox. There is problem to start it automatic. By default EFI shell is executed and I run DcsBoot from the EFI shell.
Note: my disk configuration - SSD + HDD. ESP is on HDD. Linux is on HDD. Windows system is on SSD.
Hi Alex,
Thanks for swift answer.
What didn't work for me was to run Windows (VeraCrypt/DCS) encrypted
from within Linux and this is the difficulty.
What worked without any problem was to run Linux within Windows
(VeraCrypt/DCS).
The problem is itself with VeraCrypt/DCS boot as it then doesn't even
ask for password. My take is that it is due to some checks if running on
the same system.
This in itself raises another problem - if hardware fails, let's say
anything but HDD, moving HDD wouldn't work easily even to same hardware
as these checks would fail in the same way?
Thanks,
Dawid
On 2017-10-30 4:41, Alex wrote:
yes. "dcscfg -srm" creates platform dependent mark (SMBIOS structures based) To solve the problem you can create two diffrent volumes with diffrent mark or update the mark before boot.
one more: mark is in 61 sector.
Last edit: Alex 2017-10-31
Alex, thanks for help again.
Are there any chances that multple marks could be embedded in i.e. USB key/separate partition?
If I'd go in direction to create second mark. How should the process look like?
Currently I have mark of physical HW.
How to create mark for VM HW? Should I boot to DSC shell (prior system boots and then modify the mark?)
I prefer to ask before try, as don't want to screw up my system.
Thanks,
VM HW mark is possible to create from EFI shell booted in the VM.
Mark can be on disk (sector 61) or on any partition on the usb drive.(any block device)
Hi Alex,
Thanks again for your help.
I've managed to go past password check, by renaming platform info and
the other small file.
Unfortunately I couldn't run DcsCfg.dcs -srm. Somehow VmWare EFI shell
didn't recognize executable file and complained. I've tried running
through Shell provided under one of the posts/guide related to DCS with
same result. Hence moved ahead and removed files which allowed me to get
to password prompt.
Once password was accepted, question about which Hash to use was
presented. Selected "TEST ALL" and result was that "Authorizing...
Successs.." Followed by Start ... and digits.
The only problem is that system doesn't do anything afterwards. Not sure
what is the problem. Is it searching next EFI boot option or something else?
vmware.log shows:
2017-11-25T22:00:09.186+01:00| vcpu-0| I125: Guest: About to do EFI boot: VeraCrypt
2017-11-25T22:00:44.553+01:00| vcpu-0| I125: NVME-VMM: Controller level reset via CC.EN bit transition on nvme0
2017-11-25T22:00:44.553+01:00| vcpu-0| I125: NVME-CORE: Doing a partial reset of controller regs and queues.
2017-11-25T22:00:44.556+01:00| vcpu-0| I125: NVME-VMM: Controller level reset via CC.EN bit transition on nvme0
2017-11-25T22:00:44.556+01:00| vcpu-0| I125: NVME-CORE: Doing a partial reset of controller regs and queues.
2017-11-25T22:00:44.558+01:00| vcpu-0| I125: NVME-VMM: Controller level reset via CC.EN bit transition on nvme0
2017-11-25T22:00:44.558+01:00| vcpu-0| I125: NVME-CORE: Doing a partial reset of controller regs and queues.
2017-11-25T22:00:44.561+01:00| vcpu-0| I125: NVME-VMM: Controller level reset via CC.EN bit transition on nvme0
2017-11-25T22:00:44.561+01:00| vcpu-0| I125: NVME-CORE: Doing a partial reset of controller regs and queues.
2017-11-25T22:00:44.563+01:00| vcpu-0| I125: NVME-VMM: Controller level reset via CC.EN bit transition on nvme0
2017-11-25T22:00:44.563+01:00| vcpu-0| I125: NVME-CORE: Doing a partial reset of controller regs and queues.
2017-11-25T22:00:44.566+01:00| vcpu-0| I125: NVME-VMM: Controller level reset via CC.EN bit transition on nvme0
2017-11-25T22:00:44.566+01:00| vcpu-0| I125: NVME-CORE: Doing a partial reset of controller regs and queues.
2017-11-25T22:00:44.568+01:00| vcpu-0| I125: NVME-VMM: Controller level reset via CC.EN bit transition on nvme0
2017-11-25T22:00:44.568+01:00| vcpu-0| I125: NVME-CORE: Doing a partial reset of controller regs and queues.
2017-11-25T22:00:44.571+01:00| vcpu-0| I125: NVME-VMM: Controller level reset via CC.EN bit transition on nvme0
2017-11-25T22:00:44.571+01:00| vcpu-0| I125: NVME-CORE: Doing a partial reset of controller regs and queues.
2017-11-25T22:00:44.574+01:00| vcpu-0| I125: NVME-VMM: Controller level reset via CC.EN bit transition on nvme0
2017-11-25T22:00:44.574+01:00| vcpu-0| I125: NVME-CORE: Doing a partial reset of controller regs and queues.
2017-11-25T22:00:44.577+01:00| vcpu-0| I125: NVME-VMM: Controller level reset via CC.EN bit transition on nvme0
2017-11-25T22:00:44.577+01:00| vcpu-0| I125: NVME-CORE: Doing a partial reset of controller regs and queues.
2017-11-25T22:00:44.580+01:00| vcpu-0| I125: NVME-VMM: Controller level reset via CC.EN bit transition on nvme0
2017-11-25T22:00:44.580+01:00| vcpu-0| I125: NVME-CORE: Doing a partial reset of controller regs and queues.
2017-11-25T22:00:46.841+01:00| vcpu-0| I125: Tools: Tools heartbeat timeout.
2017-11-25T22:00:46.841+01:00| vcpu-0| I125: Tools: Running status rpc handler: 1 => 0.
2017-11-25T22:00:46.841+01:00| vcpu-0| I125: Tools: Changing running status: 1 => 0.
Thanks,
On 11/07/2017 04:40 PM, Alex wrote:
Last edit: Bugsy 2017-11-25
Hello Bugsy,
by default after authorization success DcsBoot starts EFI\Microsoft\Boot\bootmgfw.efi. It can be modified via DcsProp or via USB authorization media.
e.g. to check state you can try to execute EFI shell after authorization success
Hi Alex,
Forgot to say big thanks for all your help! It worked like magic!
I can now boot encrypted raw partition from VM.
The only other open question is if it is possible to somehow trick
system to load password without prompt, i.e. as a key from somewhere?
(only in case of boot from VM). I didn't find solution to that but to
get VM booted at all, I have EFI partition loaded from file available at
hypervisor level pretending to be partition on the raw disk.
It looks like that:
real HW:
EFI partition.
OS 1 decoy
OS 2 hidden
Other OS (encrypted too)
etc.
when booting from hypervisor (as VM):
EFI partition -> loaded image from file system (in fact it is
encrypted FS on partition 4 under Other OS).
OS 1 decoy
OS 2 hidden - inaccessible for VM, but visible
Other OS (encrypted too) - inaccessible for VM, but visible.
Hope that makes sense and helps others.
Thanks again for help.
On 11/27/17 8:19 AM, Alex wrote:
Probably this can help.
see DcsProp.example
https://sourceforge.net/projects/dc5/files/beta/