Trying to create Hidden OS on Win 10 with UEFI/GPT the hidden option is greyed out whilst normal is enabled.
Primary partition size is 117GB the one after is currently 515GB but I've tried with 117GB+5% and going higher.
The outer parition (515GB one) is formated to FAT32.
Announcement back in 2016 made me beliefe that UEFI/GPT is supported now and thought it could be used with Windows 10.
Just as an update, I've fresh w10 installation and simple partitioning (EFI, OS, recovery partition).
Same results.
With the simple partitioning I can pass through and get to test if I'd try to encrypt just single partition.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Many thanks Alex for answer and great document.
I've couple of questions as not everything is super clear for me.
Worth pointing might be that I'm not after plausible deniability but more capability to have two Windows OSes on same disk and encrypted. What I'm often doing and was doing in the past as had MBR based system was to launch hidden OS as VM within the first system. Worked like a charm.
does it require partition H_ESP partition? Why cannot it use normal ESP partition? It doesn't get encrypted (looking at 2.1.2 final disk state picture). Maybe it is just new requirement with EFI, and my knowledge is based on legacy MBR one where TrueCrypt was just looking for next partition after the first one.
could the outer be set similar to how it was done with TrueCrypt automatically that the H_OS is not overwritten? I guess the offsets were modified somehow. Would it be ok to have Outer volume and then just the H_OS?
often, H_OS is based on template of original OS, given that I think about cloning unencrypted system and then laying it down to H_OS partition. I don't see any disadvantages in my case (normal system is fresh installation anyway).
How DcsCfg.dcs catches which partition to use? or it just takes the next after the first currently unencrypted? The 2.1.1 prepare disk state diagram shows that theoretically it is not specifically after the already encrypted partition.
Is it required to use "authorization USB"? In my case due specifics, authorization USB could be lost or broken rendering my system when travelling a brick, hence prefer to use password only authorization.
The previous TrueCrypt behavior of hitting "ESC" instead of typing password and booting system from next unencrypted partition (in my case grub) doesn't work anymore due to specifics of EFI? It is in context of trying to figure out how to add Grub and linux to the whole mix. Linux will be luks based, and only grub unencrypted.
Where to find more details on boot process to better understand how to use it and avoid bothering you guys?
Where is some documentation around what which parameter/command does?
Many thanks in advance.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Simple installation is not done because there are little requests for the feature(but too much work). I can try to explain any step of manual configuration if you are planning to continue.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Alex, many thanks with all info. I'll proceed with steps following your guide and will be back in couple of days probably as can work on it only during evenings.
Thanks again!
btw. Trust is that if the process could be "click-through" then more people would use it. :) Kind of a chicken&egg situation :) But I fully understand your point!
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Modify encryption range to include outer volumes
Boot from rescue USB with EFI shell
Execute
EFI\VeraCrypt\DcsCfg.dcs -oshideprep
It wipes Outer volumes, modifies sectors range to be encrypted, create GPT hidden and GPT
OS.
by point 4. start encryption, it means, configure volume to be encrypted, but for the first reboot, before it even starts and verifies password for the first time, I should boot from USB with EFI shell?
In my case, since I don't want to use USB as authorization tool, it's described below "Technology RUD" in readme.txt of DcsWinCfg I believe.
Question is if I have to select any partition or these steps could be skipped?
Where can I find DCS sources?
Another thought I've had is that it is pretty difficult to come by DCS, it took me a while before I found it. This might be reason why it is not so popular. Potentially some more links to it would be helpful from other sites as it would position it higher in search ranking when someone looks for "Hidden OS, TryeCrypt, VeraCrypt". It is unfortunately all about marketing kind of as web is overloaded with other crap and it is difficult to find such gems like DCS and VeraCrypt instructions for hidden OS.
Thanks again for help.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Start encryption. VeraCrypt creates keys and header for OS. Test phase(you can check boot but do not continue encryption). Boot to EFI shell. DcsCfg modifies H_OS encription header to include H_ESP.
Technology RUD is diffrent way to add two factors authorization(what I know - password, what I have - USB with serial number) but for old style header. In your case you create keys on a separate local partition. RUD is optional.
e.g. dcswincfg gives possibility to create serval hidden volumes. dcsfv is flexible tool to scan for header and decrypt any sectors range.
About DCS - I'm working on it some spare time. Current level is functional enough but it is not a commercial project.(too complex installation for ordinary users)
One more - you can create recovery USB with several tools: VeraCrypt recovery, EFI shell, Windows PE(It is possible to mount VeraCrypt volumes from Windows PE)
Steps:
1. Format USB - FAT
2. Unpack recovery zip
3. Copy EFI shell to EFI\shell\shell.efi
4. Copy WinPE to the USB. Rename EFI\Boot\bootx64.efi => EFI\Boot\Winpe_bootx64.efi (WinPE is part of MS ADK)
Last edit: Alex 2017-07-14
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Going through details, trying to simplify my scenario - is it possible to have same recovery USB for normal encrypted OS and hidden OS? The reasoning is that for simplicyt I want to keep it as simple as it could be. From security standpoint I'm just concerned about normal laptop thief and not really hidden data.
Second question would be if limitations as with TrueCrypt apply, like from Hidden OS, one wouldn't see normal OS, as some trick mapping was done to present it as C and partition mapping was done.
Therefore in fact, the non-hidden system was my main use and if needed I was booting from within VIrtualBox hidden OS. Only when I was battery concerned/travelling I was booting directly hidden OS where all my work stuff was in fact.
One more question re WinPE - back in days of TrueCrypt, I've had to update WinPE image (at that time process was not the easiest one).
With current approach if I understand correctly, it is way easier and down to putting WinPE on the USB with rest of tools? Is my thinking correct?
Could you please also suggest how to create scenario where by supplying password A, I'd boot to first system and by supplying password B, I'd boot to second system (hidden OS)?
Basically what I've had in the past (above scenario) was very convenient and fitting perfectly my requirements.
Thanks.
Last edit: Bugsy 2017-07-18
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
As I'm going through the process couple of questions arised:
1. Point 1. from disk_encryption_v1_2 talks about protecting ESP. Question is how do to it? Changing it's type? To which? Happy to boot gparted from CD/ISO and change it, just not sure to which type.
2. Probably originating from above point, issue is that to boot unencrypted OS on hidden_OS partition, I've had to go to EFI shell and manually load EFI for Windows. This in effect after beginning encryption process (configuring at VeraCrypt level, reboot, pasword verification) launched Windows Recovery process (WinPE?) asking me for keyboard layout, selected default and selected "Continue with WIndows 10 start". It launched Windows properly - correct, unencrypted yet partition.
3. I guess next step is to boot to EFI shell and continue from:
EFI\VeraCrypt\DcsCfg.dcs -oshideprep
btw. trying to create USB during VeraCrypt having one USB simulation as yet another disk under VM fails as VeraCrypt seems to ignore this disk. The same test goes through from normal Rescue Disk creation stage later.
Last edit: Bugsy 2017-07-18
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Trying to pass boot test with VeraCrypt for H_OS, I'm always running into situation that after password authentication, it boots to Windows Recovery and allows me further to boot Windows, but once it reaches VeraCrypt on Windows, message is that testing has failed and asks to retry.
Windows Recovery is launched even if I've went ahead and marked all partitions besides Windows H_OS and EFI as Linux filesystem from cfdisk level.
I'm certainly doing something wrong here, missing some concepts, etc.
I've also spotted that Windows installed to H_OS went ahead and created additional partitions.
In effect before installation I've had:
sda5 - Outer start
sda6 - FAT32 100MB (the one prepared to be EFI/ESP)
sda7 - Data/H_OS C: partition
sda8 - outer end
however ater installation it became
sda5 - Outer start
sda6 - FAT32 100MB (the one prepared to be EFI/ESP) - seems to be used once or twice (as some data is on)
SDA7 - new - 450MB Recovery?
SDA8 - new - 100MB new EFI???
SDA9 - data/H_OS C:partition
sda10 - outer end
My next guess is that problems with passing VeraCrypt boot test originates from this.
But how to fix it? Delete one of EFI ones and recovery one?
So far I did mark them as Linux FS and it did not help, Windows found Recovery boot approach presenting me with option to fix, boot from other device or continue booting. Maybe it in fact booted from H_OS one, but something went wrong?
I'm kind of clueless for the moment.
I can keep trying, but don't have that much time and would prefer to seek for an advise.
I've went ahead with further testing, seems like good direction, tried to boot system with DcsBoot and it went through pre-test, but... it doesn't seem to be the right way, it should be picked up automatically. So what to modify and why it didn't work properly in the first place? Some links/EFI files updates? Should I put DcsBoot as default EFI boot?
It is all due to my missing knowledge on this. Please advise.
Thanks.
Last edit: Bugsy 2017-07-18
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
as to answer partially on question, what did happen is that I've ended up with 3xEFI partition, and for some reason it seems like I've been booting from one other partition than the one created within/for hidden OS.
dd'ing the sda8 to sda2 helped to allow me to boot H_OS without manual intervention. However it also rendered normal encrypted OS to be inaccessible as correct password hasn't been accepted anymore. I'm unsure why. Maybe due to some offsets modified by: DcsCfg.dcs -oshideprep ?
I'm still struggling to understand how to achieve situation where by providing password I'd be selecting one or the other OS (1st or 2nd encrypted).
Alex, would be great if you could advise on steps and if possible at all.
Many thanks.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Partition or USB disk for keys data can contain several headers. See security region switches.
-srm <SRT> - mark disk as security regions container(write CRC of platform to 61 sector);
-srw <SRT> - wipe security regions data with random data (write random data [62, 62 + 256 * SRT]) it has to be free! check first partition start sector!
-sra <SRN> - add <gpt_file_name> to security region <SRN>
<SRT> - number of possible security regions. Any security region is 256 sectors with keys and hidden GPT.
Last edit: Alex 2017-07-18
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I was interested in running a hidden OS for academic purpose and have created the GPT partition structure as suggested. However, I'm new to UEFI and GPT and is stuck at the following screen. I was able to create a USB rescue disk with EFI shell included. At this stage both normal and hidden OS are unencrypted. In your disk_encryption v1.2.pdf you describe modifying sector 62 which is too technical for me. Can you describe a really step by step guide as to how to proceed from here using the numbers as shown on the screen shot? Greatly appreciated. I don't require using a USB key to boot to separate OS or using screen password but just by using a different password will do for me. FYI I'm running Windows 10 64 on an MSI notebook with secure boot off.
It asks
1. disk index (in your case 1)
2. Outer start index (partition before hidden ESP. It is for outer fake data to mount with fake password)
3. Outer end index (partition after HOS. It is for outer fake data to mount with fake hidden password)
4. writes random data to outer partitions
5. modifies header on disk
6. saves new GPT with hidden data.
After the step: create USB to authorize (-srm)
Next: Boot OS and start encryption. Modify DcsProp to load keys from external USB
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Thanks for the advice. During oshideprep, it asked me for 2 passwords, I assume the first one is for the outer volume and the 2nd one for the hidden volume? Then it asked me do I want to update the main header and enter Y, then it asked me for another password and then said decrypt password do not match. Is it because both the decoy OS and hidden OS are not yet encrypted? Should I say no to the update main header question? BTW, is creating a USB for the hidden OS mandatory? Will I need a new USB stick or the rescue disk will do? I'm worry that the creation of the authorization USB for H_OS will destroy the rescue disk? Many thanks.
Last edit: Fan_of_Snowden 2017-07-22
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Authorization USB is separate USB (not rescue). First partition of the USB has to start from 1MB. Headers are saved to [62, 62 + 256*NumsHeaders] sectors. The USB is prepared via "-srm", "-srw" "-sra" commands. It is last step.
Main ideas: two factors authoriuzation, keys have to be separate from data encrypted
Password not match - the password is from procedure of OS encryption started.
Last edit: Alex 2017-07-22
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
So I should have started encrypting the hidden OS b4 running the prep, do I need to finish it first or I can interrupt it after say 10% to fastrack the trial, thanks.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Do not start encryption. Just test password. The test procedure write header to 62 sector. DcsCfg tool reads the header and adjust encryption range to include all partitions between start outer and end outer.
One more - do not reboot if you start encryption of modified range. The procedure has to be finished.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Oops! Too late now, I've basically bricked my PC Fortunately, I was able to recover. Here is what I've done:
1. Since my last msg, I've fully encrypted the hidden OS and was able to boot from it by entering the correct hidden password. Since I have not encrypted the normal OS I can also boot into it when windows asked me which system to boot.
2. BTW, the -pshideprep switch created 2 gpt files by default gpt_hidden and gpt_enc on the root directory of my recovery usb.
3. I've tried to create an authorization USB as in step 6 of your pdf. As expected after it has written to sector 62, the usb became unreadable and reported as unformatted by windows
4. I proceeded to step 8 boot from USB, dcscfg -pf gpt_hidden -pl showed me that the 4 partitions: fake_outer, H_ESP, H_OS, fake_end has now merged into 1 big partition
5. I executed dcscfg -ds 1 -pf gpt_hidden -pa
6. BTW, have also copied dcsboot.efi to efi\microsoft\boot as bootmgfw.efi, rename the original to bootmgfw_ms.efi and edited dcsprop as described elsewhere
7. reboot the system and viola, I'm in an infinite loop of veracrypt asking me password and neither the outer password or the H_OS password works, even asking BIOS to boot to rescue USB didn't work it keeps loading the veracrypt bootloader asking for passwords!
8. I eventually have to boot legacy via a windows DVD, go into command prompt, use diskpart to assign drive b to the ESP, reverse the process as in 6 above and now I'm back to be able to normal boot my PC, phew (wiping sweat off my forehead)
9. windows Disk managment of course reported the merged partition as described in 4 and I can mount it using the outer password as previously created.
10. However, I can't mount the hidden volume using the H_OS password nor protect it when mounting the outer volume. Does it mean by following step 6 creating an authorization USB, that USB has to be inserted every time I need to boot to H_OS? Effectively, the USB is a keyfile?
I guess my question to Alex is where to from here? Is there a next step to follow or I have to start all over again from creating the 4 partitions?
P.S. By experimenting before, I have done dcscfg -ds 1 -pf parts_os -ps so I've a GPT file with the original partition scheme so by executing dcscfg -ds 1 -pf parts_os -pa I was able to restore the "unhidden" 4 partitions after the normal OS. I'll wait for your further advice from here, many thanks.
Last edit: Fan_of_Snowden 2017-07-23
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
One more - the usb with header has to contain first partition with start offset ~1MB. It is possible to initialize the USB via diskpart (commands: clean, create part prim offset..., format. see help.)
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
What should be partition layout if I would like to boot to decoy or hidden OS just based on different password (same idea as it worked with TrueCrypt?)
Could you please suggest steps/parameters, how it should look like?
The way it worked with TrueCrypt was:
variables:
d_OS: decoy OS
h_OS: hidden OS
pass1: password for d_OS
pass2: password for h_OS
Starting TrueCrypt loader asked for password, when provided pass1, it did boot d_OS, with pass2 it would load h_OS and with escape hit it would load next partition (sdX3) with Grub/Linux in that case.
Going quickly through DcsBoot source code I've feeling that the same should work with VeraCrypt too, but somehow with latest status of my system, pass1 does not work to start d_OS and only pass2 for h_OS is accepted. It must be due to some pointers written somewhere.
Since I don't need a real hidden OS, as temporary workaround I'd be also fine with installing rEFInd, but I'm pretty sure all I need should be possible directly with VeraCrypt and DCS too, just I'm missing the little piece about where the keys are stored and if there could be a gap between the d_OS and h_OS.
Alex, could you please describe how above could be achieved?
Other question allowing to better understand situation would be if DcsBoot enumerates all partition testing password or somehow else? Is the partition the only place where anything related to password is stored or elsewhere somethig is stored? In other words could one theoretically have multiple encrypted partitions (not necessary hidden) installed on single HD? From earlier great feedback from you it should be possible, but I'm not clear on "regions" part and modifications. Maybe it is only for hidden OS?
This tells me that the issue with booting h_OS is due to sector 62 being probably overwritten when I've tried to boot and encrypt h_OS, as I did manual boot when trying to encrypt h_OS.
Checking steps I've found probably a typo:
Guide says:
Hi All,
Trying to create Hidden OS on Win 10 with UEFI/GPT the hidden option is greyed out whilst normal is enabled.
Primary partition size is 117GB the one after is currently 515GB but I've tried with 117GB+5% and going higher.
The outer parition (515GB one) is formated to FAT32.
Announcement back in 2016 made me beliefe that UEFI/GPT is supported now and thought it could be used with Windows 10.
Full partition set looks as below:
Partition ### Type Size Offset
Partition 1 System 500 MB 1024 KB
Partition 2 Reserved 128 MB 501 MB
Partition 3 Primary 117 GB 629 MB
Partition 4 Primary 515 GB 117 GB
Partition 5 Recovery 460 MB 942 GB
Partition 6 Recovery 11 GB 942 GB
Any suggestions are more than welcome!
Thanks,
bugggsy
Just as an update, I've fresh w10 installation and simple partitioning (EFI, OS, recovery partition).
Same results.
With the simple partitioning I can pass through and get to test if I'd try to encrypt just single partition.
It is possible but not from GUI. See https://dc5.sourceforge.io/docs/disk_encryption_v1_2.pdf
Many thanks Alex for answer and great document.
I've couple of questions as not everything is super clear for me.
Worth pointing might be that I'm not after plausible deniability but more capability to have two Windows OSes on same disk and encrypted. What I'm often doing and was doing in the past as had MBR based system was to launch hidden OS as VM within the first system. Worked like a charm.
Many thanks in advance.
Simple installation is not done because there are little requests for the feature(but too much work). I can try to explain any step of manual configuration if you are planning to continue.
Alex, many thanks with all info. I'll proceed with steps following your guide and will be back in couple of days probably as can work on it only during evenings.
Thanks again!
btw. Trust is that if the process could be "click-through" then more people would use it. :) Kind of a chicken&egg situation :) But I fully understand your point!
Alex, question re one point, doc says:
Boot from rescue USB with EFI shell
Execute
by point 4. start encryption, it means, configure volume to be encrypted, but for the first reboot, before it even starts and verifies password for the first time, I should boot from USB with EFI shell?
In my case, since I don't want to use USB as authorization tool, it's described below "Technology RUD" in readme.txt of DcsWinCfg I believe.
Question is if I have to select any partition or these steps could be skipped?
Where can I find DCS sources?
Another thought I've had is that it is pretty difficult to come by DCS, it took me a while before I found it. This might be reason why it is not so popular. Potentially some more links to it would be helpful from other sites as it would position it higher in search ranking when someone looks for "Hidden OS, TryeCrypt, VeraCrypt". It is unfortunately all about marketing kind of as web is overloaded with other crap and it is difficult to find such gems like DCS and VeraCrypt instructions for hidden OS.
Thanks again for help.
Start encryption. VeraCrypt creates keys and header for OS. Test phase(you can check boot but do not continue encryption). Boot to EFI shell. DcsCfg modifies H_OS encription header to include H_ESP.
Technology RUD is diffrent way to add two factors authorization(what I know - password, what I have - USB with serial number) but for old style header. In your case you create keys on a separate local partition. RUD is optional.
Mounir published sources as zip. I'll create repo at sf. Need some time. (Several tools - DcsFV, DcsWinCfg, DcsPkg) https://sourceforge.net/projects/veracrypt/files/VeraCrypt%201.21/VeraCrypt-DCS-EFI-LGPL_1.21_Source.zip/download
e.g. dcswincfg gives possibility to create serval hidden volumes. dcsfv is flexible tool to scan for header and decrypt any sectors range.
About DCS - I'm working on it some spare time. Current level is functional enough but it is not a commercial project.(too complex installation for ordinary users)
One more - you can create recovery USB with several tools: VeraCrypt recovery, EFI shell, Windows PE(It is possible to mount VeraCrypt volumes from Windows PE)
Steps:
1. Format USB - FAT
2. Unpack recovery zip
3. Copy EFI shell to EFI\shell\shell.efi
4. Copy WinPE to the USB. Rename EFI\Boot\bootx64.efi => EFI\Boot\Winpe_bootx64.efi (WinPE is part of MS ADK)
Last edit: Alex 2017-07-14
Thanks Alex for all help.
Going through details, trying to simplify my scenario - is it possible to have same recovery USB for normal encrypted OS and hidden OS? The reasoning is that for simplicyt I want to keep it as simple as it could be. From security standpoint I'm just concerned about normal laptop thief and not really hidden data.
Second question would be if limitations as with TrueCrypt apply, like from Hidden OS, one wouldn't see normal OS, as some trick mapping was done to present it as C and partition mapping was done.
Therefore in fact, the non-hidden system was my main use and if needed I was booting from within VIrtualBox hidden OS. Only when I was battery concerned/travelling I was booting directly hidden OS where all my work stuff was in fact.
One more question re WinPE - back in days of TrueCrypt, I've had to update WinPE image (at that time process was not the easiest one).
With current approach if I understand correctly, it is way easier and down to putting WinPE on the USB with rest of tools? Is my thinking correct?
Could you please also suggest how to create scenario where by supplying password A, I'd boot to first system and by supplying password B, I'd boot to second system (hidden OS)?
Basically what I've had in the past (above scenario) was very convenient and fitting perfectly my requirements.
Thanks.
Last edit: Bugsy 2017-07-18
As I'm going through the process couple of questions arised:
1. Point 1. from disk_encryption_v1_2 talks about protecting ESP. Question is how do to it? Changing it's type? To which? Happy to boot gparted from CD/ISO and change it, just not sure to which type.
2. Probably originating from above point, issue is that to boot unencrypted OS on hidden_OS partition, I've had to go to EFI shell and manually load EFI for Windows. This in effect after beginning encryption process (configuring at VeraCrypt level, reboot, pasword verification) launched Windows Recovery process (WinPE?) asking me for keyboard layout, selected default and selected "Continue with WIndows 10 start". It launched Windows properly - correct, unencrypted yet partition.
3. I guess next step is to boot to EFI shell and continue from:
EFI\VeraCrypt\DcsCfg.dcs -oshideprep
btw. trying to create USB during VeraCrypt having one USB simulation as yet another disk under VM fails as VeraCrypt seems to ignore this disk. The same test goes through from normal Rescue Disk creation stage later.
Last edit: Bugsy 2017-07-18
Trying to pass boot test with VeraCrypt for H_OS, I'm always running into situation that after password authentication, it boots to Windows Recovery and allows me further to boot Windows, but once it reaches VeraCrypt on Windows, message is that testing has failed and asks to retry.
Windows Recovery is launched even if I've went ahead and marked all partitions besides Windows H_OS and EFI as Linux filesystem from cfdisk level.
I'm certainly doing something wrong here, missing some concepts, etc.
I've also spotted that Windows installed to H_OS went ahead and created additional partitions.
In effect before installation I've had:
sda5 - Outer start
sda6 - FAT32 100MB (the one prepared to be EFI/ESP)
sda7 - Data/H_OS C: partition
sda8 - outer end
however ater installation it became
sda5 - Outer start
sda6 - FAT32 100MB (the one prepared to be EFI/ESP) - seems to be used once or twice (as some data is on)
SDA7 - new - 450MB Recovery?
SDA8 - new - 100MB new EFI???
SDA9 - data/H_OS C:partition
sda10 - outer end
My next guess is that problems with passing VeraCrypt boot test originates from this.
But how to fix it? Delete one of EFI ones and recovery one?
So far I did mark them as Linux FS and it did not help, Windows found Recovery boot approach presenting me with option to fix, boot from other device or continue booting. Maybe it in fact booted from H_OS one, but something went wrong?
I'm kind of clueless for the moment.
I can keep trying, but don't have that much time and would prefer to seek for an advise.
I've went ahead with further testing, seems like good direction, tried to boot system with DcsBoot and it went through pre-test, but... it doesn't seem to be the right way, it should be picked up automatically. So what to modify and why it didn't work properly in the first place? Some links/EFI files updates? Should I put DcsBoot as default EFI boot?
It is all due to my missing knowledge on this. Please advise.
Thanks.
Last edit: Bugsy 2017-07-18
Alex, hi again,
as to answer partially on question, what did happen is that I've ended up with 3xEFI partition, and for some reason it seems like I've been booting from one other partition than the one created within/for hidden OS.
dd'ing the sda8 to sda2 helped to allow me to boot H_OS without manual intervention. However it also rendered normal encrypted OS to be inaccessible as correct password hasn't been accepted anymore. I'm unsure why. Maybe due to some offsets modified by: DcsCfg.dcs -oshideprep ?
I'm still struggling to understand how to achieve situation where by providing password I'd be selecting one or the other OS (1st or 2nd encrypted).
Alex, would be great if you could advise on steps and if possible at all.
Many thanks.
Yes, it is possible.
Partition or USB disk for keys data can contain several headers. See security region switches.
-srm <SRT> - mark disk as security regions container(write CRC of platform to 61 sector);
-srw <SRT> - wipe security regions data with random data (write random data [62, 62 + 256 * SRT]) it has to be free! check first partition start sector!
-sra <SRN> - add <gpt_file_name> to security region <SRN>
<SRT> - number of possible security regions. Any security region is 256 sectors with keys and hidden GPT.
Last edit: Alex 2017-07-18
See man page of DcsCfg and sources. Concepts I can explain.
Hi Alex,
I was interested in running a hidden OS for academic purpose and have created the GPT partition structure as suggested. However, I'm new to UEFI and GPT and is stuck at the following screen. I was able to create a USB rescue disk with EFI shell included. At this stage both normal and hidden OS are unencrypted. In your disk_encryption v1.2.pdf you describe modifying sector 62 which is too technical for me. Can you describe a really step by step guide as to how to proceed from here using the numbers as shown on the screen shot? Greatly appreciated. I don't require using a USB key to boot to separate OS or using screen password but just by using a different password will do for me. FYI I'm running Windows 10 64 on an MSI notebook with secure boot off.
Last edit: Fan_of_Snowden 2017-07-19
You can start with
DcsCfg -oshideprep -rnd 2
It asks
1. disk index (in your case 1)
2. Outer start index (partition before hidden ESP. It is for outer fake data to mount with fake password)
3. Outer end index (partition after HOS. It is for outer fake data to mount with fake hidden password)
4. writes random data to outer partitions
5. modifies header on disk
6. saves new GPT with hidden data.
After the step: create USB to authorize (-srm)
Next: Boot OS and start encryption. Modify DcsProp to load keys from external USB
Hi Alex,
Thanks for the advice. During oshideprep, it asked me for 2 passwords, I assume the first one is for the outer volume and the 2nd one for the hidden volume? Then it asked me do I want to update the main header and enter Y, then it asked me for another password and then said decrypt password do not match. Is it because both the decoy OS and hidden OS are not yet encrypted? Should I say no to the update main header question? BTW, is creating a USB for the hidden OS mandatory? Will I need a new USB stick or the rescue disk will do? I'm worry that the creation of the authorization USB for H_OS will destroy the rescue disk? Many thanks.
Last edit: Fan_of_Snowden 2017-07-22
Authorization USB is separate USB (not rescue). First partition of the USB has to start from 1MB. Headers are saved to [62, 62 + 256*NumsHeaders] sectors. The USB is prepared via "-srm", "-srw" "-sra" commands. It is last step.
Main ideas: two factors authoriuzation, keys have to be separate from data encrypted
Password not match - the password is from procedure of OS encryption started.
Last edit: Alex 2017-07-22
So I should have started encrypting the hidden OS b4 running the prep, do I need to finish it first or I can interrupt it after say 10% to fastrack the trial, thanks.
Do not start encryption. Just test password. The test procedure write header to 62 sector. DcsCfg tool reads the header and adjust encryption range to include all partitions between start outer and end outer.
One more - do not reboot if you start encryption of modified range. The procedure has to be finished.
Oops! Too late now, I've basically bricked my PC Fortunately, I was able to recover. Here is what I've done:
1. Since my last msg, I've fully encrypted the hidden OS and was able to boot from it by entering the correct hidden password. Since I have not encrypted the normal OS I can also boot into it when windows asked me which system to boot.
2. BTW, the -pshideprep switch created 2 gpt files by default gpt_hidden and gpt_enc on the root directory of my recovery usb.
3. I've tried to create an authorization USB as in step 6 of your pdf. As expected after it has written to sector 62, the usb became unreadable and reported as unformatted by windows
4. I proceeded to step 8 boot from USB, dcscfg -pf gpt_hidden -pl showed me that the 4 partitions: fake_outer, H_ESP, H_OS, fake_end has now merged into 1 big partition
5. I executed dcscfg -ds 1 -pf gpt_hidden -pa
6. BTW, have also copied dcsboot.efi to efi\microsoft\boot as bootmgfw.efi, rename the original to bootmgfw_ms.efi and edited dcsprop as described elsewhere
7. reboot the system and viola, I'm in an infinite loop of veracrypt asking me password and neither the outer password or the H_OS password works, even asking BIOS to boot to rescue USB didn't work it keeps loading the veracrypt bootloader asking for passwords!
8. I eventually have to boot legacy via a windows DVD, go into command prompt, use diskpart to assign drive b to the ESP, reverse the process as in 6 above and now I'm back to be able to normal boot my PC, phew (wiping sweat off my forehead)
9. windows Disk managment of course reported the merged partition as described in 4 and I can mount it using the outer password as previously created.
10. However, I can't mount the hidden volume using the H_OS password nor protect it when mounting the outer volume. Does it mean by following step 6 creating an authorization USB, that USB has to be inserted every time I need to boot to H_OS? Effectively, the USB is a keyfile?
I guess my question to Alex is where to from here? Is there a next step to follow or I have to start all over again from creating the 4 partitions?
P.S. By experimenting before, I have done dcscfg -ds 1 -pf parts_os -ps so I've a GPT file with the original partition scheme so by executing dcscfg -ds 1 -pf parts_os -pa I was able to restore the "unhidden" 4 partitions after the normal OS. I'll wait for your further advice from here, many thanks.
Last edit: Fan_of_Snowden 2017-07-23
DcsProp controls where to locate headers (keys)
It instructs DcsInt to find USB marked via "-srm" and try to load header from it.
Note: There are several useful config keys. See details in DcsProp example. (package from dc5)
Last edit: Alex 2017-07-23
One more - the usb with header has to contain first partition with start offset ~1MB. It is possible to initialize the USB via diskpart (commands: clean, create part prim offset..., format. see help.)
...duplicate... removed.
Last edit: Bugsy 2017-07-23
Hi Alex,
Thanks for all help.
What should be partition layout if I would like to boot to decoy or hidden OS just based on different password (same idea as it worked with TrueCrypt?)
Could you please suggest steps/parameters, how it should look like?
The way it worked with TrueCrypt was:
variables:
d_OS: decoy OS
h_OS: hidden OS
pass1: password for d_OS
pass2: password for h_OS
partitions layout:
sdX1 d_OS
sdX2 h_OS
sdX3 Grub/Linux
Starting TrueCrypt loader asked for password, when provided pass1, it did boot d_OS, with pass2 it would load h_OS and with escape hit it would load next partition (sdX3) with Grub/Linux in that case.
Going quickly through DcsBoot source code I've feeling that the same should work with VeraCrypt too, but somehow with latest status of my system, pass1 does not work to start d_OS and only pass2 for h_OS is accepted. It must be due to some pointers written somewhere.
Since I don't need a real hidden OS, as temporary workaround I'd be also fine with installing rEFInd, but I'm pretty sure all I need should be possible directly with VeraCrypt and DCS too, just I'm missing the little piece about where the keys are stored and if there could be a gap between the d_OS and h_OS.
Alex, could you please describe how above could be achieved?
Other question allowing to better understand situation would be if DcsBoot enumerates all partition testing password or somehow else? Is the partition the only place where anything related to password is stored or elsewhere somethig is stored? In other words could one theoretically have multiple encrypted partitions (not necessary hidden) installed on single HD? From earlier great feedback from you it should be possible, but I'm not clear on "regions" part and modifications. Maybe it is only for hidden OS?
Thanks!
UPDATE: I've found answer on one detail:
https://sourceforge.net/p/veracrypt/discussion/technical/thread/bb573cc6/#acf6/e375/4812
Alex - 2016-12-11
I wrote EFI support for VeraCrypt.
EFI rescue disk is my work also. It checks all disks with password and decrypts the volume with successful authorization
This tells me that the issue with booting h_OS is due to sector 62 being probably overwritten when I've tried to boot and encrypt h_OS, as I did manual boot when trying to encrypt h_OS.
Checking steps I've found probably a typo:
Guide says:
but first step saved it under parts_os and seconds step tries to use part_os (no S).
UPDATE2:
doc shows:
both steps use "-pe" which based on DcsCfg encrypts partition if this is the case, then why would install permit to install on it?
Last edit: Bugsy 2017-07-23