How to confirm if this is the case? Can you please provide some commands what to run, what to check? Maybe something similar to DcsFV?
I don't believe that this is the case, but if there is any other block caught by password checking routine, it has to be possible to verify which one. How the block 61 of partition or anything is being picked? It has to fulfill specific pattern or something?
Since it is brand new system I can wipe out all sector 61 besides the partitions which are required.
Is it 61 starting with count from 0 or 1? I'd use Linux dd to zero it.
I can also try to revert step, but would need to get some guidance what needs to be done with commands.
In the worst case I can restore original partition layout, try to boot it (not sure if it will work), try to decrypt or if worse goes to worst, re-install H_OS and basically start process from scratch.
Please advise.
Last edit: Bugsy 2017-08-04
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I've just confirmed with
dd if=/dev/<root_device> bs=512 count=1 skip=62|hexdump
that it is the same content as svh_bak of the H_OS.
I've also confirmed that:
partition 1 (first) has weird content in sectors 60,61,62 with numbers 24xx where xx increases by one and it goes through 25xx and 26xx, where it should be NTFS recovery partition.
partition 2 - EFI has these sectors empty.
partition 3 - reserved, 60 is empty, 61 has something at offset 0x00 literraly for elements occupied, 62 has something completely random. I'm unsure what should be content of this partition normally as it is default Micrososft reserved between ESP/EFI and data partition
partition 4 is the Decoy_OS already.
My line of thought is that whilst I don't really know the logic of DcsBoot, hence it is difficult to troubleshoot and take any further steps.
@Alex, you've describes something already, but I can't still make a link of when password is taken, how it evaluates it, where it seeks, does it start through all block devices one by one and checks (what does it check?). If I could repeat this steps or at least zero out errors it would bring me one step closer to solution I guess.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I've went ahead and cleaned up p6 with zeros.
Created partition on USB drive and followed exactly same steps as earlier for partition p6, meaning
–srw 3 –ds 2 -rnd 2 # this time ds 2 is second partition on USB drive.
Q: is -srw required at all? It just wipes, how about if I ignore security, could I go directly on clean partition with SRM?
–srm 3 –ds 2
-pf gpt_hos –aa -pe # only password for H_OS was accepted, others didn't work. gpt_hos is plain copy of gpt_enc from earlier steps
-pf gpt_hos –sra 0 –ds 2
reboot, et voilla... I can access hidden OS now.
Next step is to get access to Decoy_OS.
What do I need to do?
Last edit: Bugsy 2017-08-04
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Further test:
1. Restored OS Header keys using Decoy_OS recovery EFI boot. Didn't help at all to boot Decoy_OS with or without USB key allowing me to boot H_OS (I'll call is USB_HOS from now).
same steps as above for successfull creation of USB_HOS just ds = 8 empty partition.
Nothing else has been changed and I can't get it working unless would plug in earlier prepared USB key.
So, something is wrong here. Maybe DscProp settings?
It is currently:
<config key="SecRegionSearch">1</config>
<config key="DcsBootForce">0</config>
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Further tests to find out what works, what doesn't. All modifications to DcsProp done on first (decoy_OS) EFI/EPS partition (p2 in my case).
For below H_OS I could boot only with USB_HOS in the slot at EFI boot time.
Question: is it important that partition on HDD with keys (the one like on USB) is after encrypted Decoy_OS and H_OS? This is the only thing I can think of as source of the issue/bug.
Prepared partition on USB and on HDD in the very same way, but could boot only with USB in.
Further tests after adding key_os as recommended above:
GPT removed and encrypted with Decoy_OS pass (OS key header from Decoy_OS already restored, not sure if it played a role at all, but guess so).
Deco_OS & H_OS boot but USB required for both OSes
<configkey="SecRegionSearch">1</config><configkey="DcsBootForce">0</config>
Deco_OS & H_OS boot but USB required for both OSes
<configkey="SecRegionSearch">1</config><configkey="DcsBootForce">1</config>
Decoy_OS (with or without USB)
<configkey="SecRegionSearch">0</config><configkey="DcsBootForce">1</config>
nothing DcsBoot doesn't ask for pass (with or without USB)
<configkey="SecRegionSearch">0</config><configkey="DcsBootForce">0</config>
So in summary, managed to boot both Decoy_OS and H_OS but it required USB even if have partition created in the right way.
Thoughts on why it required USB?
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I've went ahead and moved partitions (resized recovery), created there one for vaul and repeating same steps now have vault on HDD allowing me to boot.
Verdict: there is a bug (or "feature = works as designed" but I'd call it limitation) that vault has to be enumerated before real HDD where encrypted partition is. At least this is what my tests show.
Hopefully all my writing will help someone in the future - as I have it working now. Probably a bit better understanding of what is what.
I'd also like to offer my contribution to Alex to create improved version of documentation for humans like me, explaining all concepts, what is for what and how to use it as it should help to popularize solution. It was very diffiult to get this working for me.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
For USB scenario good choice:
<config key="SecRegionSearch">1</config>
<config key="DcsBootForce">1</config>
If USB connected => vault from USB is used => password of HOS is entered => HOS booted
If USB not connected => default header is used(DcsBootForce=1) => password of Decoy OS is entered => Decoy OS booted
Your scenario (USB is connected always(partition)) => partition vault contains headers for HOS and Decoy OS. Password from Decoy OS => boot Decoy. Password HOS => Boot HOS.
Your vault size for 3 headers. "-srw" is important step to hide number of OSs installed. (random data inside random data...)
Thank you for proposal of documentation. It can help many people to use these features.
note about "-srm". It is mark. It is based on serial number of BIOS. So move HDD to other computer => mark will not be detected. If the mark is on USB, serial number of the USB is used also => simple copy of USB device does not create USB vault.
There is possibility to "lock password to platform". It mixes password and serial of BIOS and serial of USB. So authorization is possible only on this computer(the same BIOS serial) and with this USB (the same USB serial). => Something - "what I have"
Probably I'll add "-srl" option to list all available vaults. It looks like it is necessary.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Alex, thank you very much for support. It has been a tough ride for me as I did run into the mentioned bug (vault partition after data partitions) and was pulling out hairs.
One question, since my scenario sometimes require to boot H_OS from within VM (i.e. hypervisor run on Decoy_OS, or anything else), what should be fulfilled to get that running?
I suppose it has somethin gto do with: here is possibility to "lock password to platform".
I've assigned all required raw partitions but DcsBoot.efi does not even rompt for password. It is the very same N_ESP (ESP/EFI for Decoy_OS).
PlatformInfo does contain details of physical system which are certainly different when running from within VM.
One of options is to map this single partition to a clone as file on Decoy_OS which would then contain appropriate PlatformInfo.
Running DcsBoot.efi with wrong PlatformInfo returns no output, but running wihtout this file raises: PlatformInfo create Unsupported
Same is when running DcsInfo.dcs. What's wrong?
Given this, do I have to also have a copy of vault partition and have keys within it regenerated from within VM? This complicated the whole picture a bit.
Not sure what and how it should work hence asking instead of spending another night to try to get that running.
btw. on TrueCrypt there was no such validation and my scenario worked very well. Just issue with Windows Activation which was completely outside of TrueCrypt.
Last edit: Bugsy 2017-08-05
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I managed to execute D_OS from H_OS via VirtualBox. The reason - to keep the D_OS visited. if you want to execute H_OS from Linux - it can be but I did not try this.
You can remove PlatformInfo generation: Remove DcsInfo.dcs.
PlatformInfo is help file to simplify configuration(picture password) and support.
There is plan to add Bluetooth authorization (vault or just mark on Bluetooth device) but I do not have notebook with Bluetooth and I do not know model. (I know UEFI 2.5 spec contains Bluetooth and AMI adds Bluetooth) If someone have PlatformInfo with Bluetooth protocols it can help to choose next development computer for me.
About the bug: I cannot reproduce it. Need scenario.
Password is requested if mark for the computer is OK (BIOS serial the same) Execution from VM - BIOS different => mark is not detected
Last edit: Alex 2017-08-06
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Should I remove only PlatformInfo?
This I tried but running DcsInfo.dcs gave me error afterwards as reported: PlatformInfo create Unsupported
If I remove DcsInfo.dcs I'm not sure how to recreate PlatformInfo. Which command is used then to recreate it?
The scenario is as following:
D_OS & H_OS prepared as per above, directly on physical system.
on D_OC installed VmWare Workstation (in my case but it should not differ with VmWare Player but it might differ with VirtualBox.
Next step is to try to boot (as EFI system) this installation.
Creation VmWare I've selected Windows 10 64bit as this is what I'm on.
There might be difference between VmWare and VirtualBox in a way these to generate UUID (VirtualBox System-uuid or something like this and VmWare name bios.uuid).
I'm pretty sure platform ID is source of the problem.
I'll PM you with details of my system.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I'd also like to offer my contribution to Alex to create improved version of documentation for humans like me, explaining all concepts, what is for what and how to use it as it should help to popularize solution. It was very diffiult to get this working for me.
Hey, Bugsy. Have you ever gotten to writing (at least a skeleton for) a more human readable/understandable documentation for the process of creating a nos+hos+linux system with gpt/uefi? I've been re-reading the orig. doc and a thread or two that exists on the subject for some time now and still don't understand even how to begin. Oh, and happy NY!
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Unfortunately I did not finish writing documentation. Apologies for delayed answer as notification got into spam folder.
Having said that I've seen here on the forum recently some guides on how to do that. Not sure if these are of any help.
Regards,
Bugsy
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Also can I have more than 1 USB Keys for the same HOS? Of course the worry is if I lost the usb key I'll never be able to log-in to the HOS again, and I suppose that also will prevent decrypting the HOS as well as last resort? So the idea is to have a backup usb key or a few keys. I guess the procedure is the same, prepare the new usb with say first M unallocated and follow step 6 to wipe, mark and apply, please confirm and thanks Alex.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Just a bit of academic argument, isn't the presence of usb keys expose the fact that there is a hidden operating system? I mean if an adversary found out that there are the gpt_enc and gpt_hid files on a usb or find out that in one or more usb drives the primary partition started at an offset and there is a crc at sector 61? My suggestion is when you improve your dcscfg program, it may help to wipe sector 61 as well so that the crc is not obvious.
I suppose that's the argument to put a key for the NOS on the usb itself so that it can boot normally with the usb in and those gpt files should be in a hidden container instead. (until you are doing a backup of the HOS)
-srm - is to set mark
-srw - is to clean vault space
one more - probably you've added mark(-srm) to other disk and the disk can be detected as vault => wrong password.
so the order of srw and then srm is the right one.
Thanks! How can I verify this?
By "this" I meant to verify if there is any other disk which would be denying password?
mark can be in 61 sector of any block device(disk or partition) it looks like random string.
How to confirm if this is the case? Can you please provide some commands what to run, what to check? Maybe something similar to DcsFV?
I don't believe that this is the case, but if there is any other block caught by password checking routine, it has to be possible to verify which one. How the block 61 of partition or anything is being picked? It has to fulfill specific pattern or something?
Since it is brand new system I can wipe out all sector 61 besides the partitions which are required.
Is it 61 starting with count from 0 or 1? I'd use Linux dd to zero it.
I can also try to revert step, but would need to get some guidance what needs to be done with commands.
In the worst case I can restore original partition layout, try to boot it (not sure if it will work), try to decrypt or if worse goes to worst, re-install H_OS and basically start process from scratch.
Please advise.
Last edit: Bugsy 2017-08-04
I've just confirmed with
dd if=/dev/<root_device> bs=512 count=1 skip=62|hexdump
that it is the same content as svh_bak of the H_OS.
I've also confirmed that:
partition 1 (first) has weird content in sectors 60,61,62 with numbers 24xx where xx increases by one and it goes through 25xx and 26xx, where it should be NTFS recovery partition.
partition 2 - EFI has these sectors empty.
partition 3 - reserved, 60 is empty, 61 has something at offset 0x00 literraly for elements occupied, 62 has something completely random. I'm unsure what should be content of this partition normally as it is default Micrososft reserved between ESP/EFI and data partition
partition 4 is the Decoy_OS already.
My line of thought is that whilst I don't really know the logic of DcsBoot, hence it is difficult to troubleshoot and take any further steps.
@Alex, you've describes something already, but I can't still make a link of when password is taken, how it evaluates it, where it seeks, does it start through all block devices one by one and checks (what does it check?). If I could repeat this steps or at least zero out errors it would bring me one step closer to solution I guess.
Small progress.
I've went ahead and cleaned up p6 with zeros.
Created partition on USB drive and followed exactly same steps as earlier for partition p6, meaning
–srw 3 –ds 2 -rnd 2 # this time ds 2 is second partition on USB drive.
Q: is -srw required at all? It just wipes, how about if I ignore security, could I go directly on clean partition with SRM?
–srm 3 –ds 2
-pf gpt_hos –aa -pe # only password for H_OS was accepted, others didn't work. gpt_hos is plain copy of gpt_enc from earlier steps
-pf gpt_hos –sra 0 –ds 2
reboot, et voilla... I can access hidden OS now.
Next step is to get access to Decoy_OS.
What do I need to do?
Last edit: Bugsy 2017-08-04
Further test:
1. Restored OS Header keys using Decoy_OS recovery EFI boot. Didn't help at all to boot Decoy_OS with or without USB key allowing me to boot H_OS (I'll call is USB_HOS from now).
Nothing else has been changed and I can't get it working unless would plug in earlier prepared USB key.
So, something is wrong here. Maybe DscProp settings?
It is currently:
<config key="SecRegionSearch">1</config>
<config key="DcsBootForce">0</config>
Further tests to find out what works, what doesn't. All modifications to DcsProp done on first (decoy_OS) EFI/EPS partition (p2 in my case).
For below H_OS I could boot only with USB_HOS in the slot at EFI boot time.
H_OS boot
<config key="SecRegionSearch">1</config>
<config key="DcsBootForce">0</config>
H_OS boot
<config key="SecRegionSearch">1</config>
<config key="DcsBootForce">1</config>
Decoy_OS (with or without USB)
<config key="SecRegionSearch">0</config>
<config key="DcsBootForce">1</config>
nothing DcsBoot doesn't ask for pass (with or without USB)
<config key="SecRegionSearch">0</config>
<config key="DcsBootForce">0</config>
Last edit: Bugsy 2017-08-04
Question: is it important that partition on HDD with keys (the one like on USB) is after encrypted Decoy_OS and H_OS? This is the only thing I can think of as source of the issue/bug.
Prepared partition on USB and on HDD in the very same way, but could boot only with USB in.
Further tests after adding key_os as recommended above:
GPT removed and encrypted with Decoy_OS pass (OS key header from Decoy_OS already restored, not sure if it played a role at all, but guess so).
So in summary, managed to boot both Decoy_OS and H_OS but it required USB even if have partition created in the right way.
Thoughts on why it required USB?
I've went ahead and moved partitions (resized recovery), created there one for vaul and repeating same steps now have vault on HDD allowing me to boot.
Verdict: there is a bug (or "feature = works as designed" but I'd call it limitation) that vault has to be enumerated before real HDD where encrypted partition is. At least this is what my tests show.
Hopefully all my writing will help someone in the future - as I have it working now. Probably a bit better understanding of what is what.
I'd also like to offer my contribution to Alex to create improved version of documentation for humans like me, explaining all concepts, what is for what and how to use it as it should help to popularize solution. It was very diffiult to get this working for me.
Good results.
For USB scenario good choice:
<config key="SecRegionSearch">1</config>
<config key="DcsBootForce">1</config>
If USB connected => vault from USB is used => password of HOS is entered => HOS booted
If USB not connected => default header is used(DcsBootForce=1) => password of Decoy OS is entered => Decoy OS booted
Your scenario (USB is connected always(partition)) => partition vault contains headers for HOS and Decoy OS. Password from Decoy OS => boot Decoy. Password HOS => Boot HOS.
Your vault size for 3 headers. "-srw" is important step to hide number of OSs installed. (random data inside random data...)
Thank you for proposal of documentation. It can help many people to use these features.
note about "-srm". It is mark. It is based on serial number of BIOS. So move HDD to other computer => mark will not be detected. If the mark is on USB, serial number of the USB is used also => simple copy of USB device does not create USB vault.
There is possibility to "lock password to platform". It mixes password and serial of BIOS and serial of USB. So authorization is possible only on this computer(the same BIOS serial) and with this USB (the same USB serial). => Something - "what I have"
Probably I'll add "-srl" option to list all available vaults. It looks like it is necessary.
Alex, thank you very much for support. It has been a tough ride for me as I did run into the mentioned bug (vault partition after data partitions) and was pulling out hairs.
One question, since my scenario sometimes require to boot H_OS from within VM (i.e. hypervisor run on Decoy_OS, or anything else), what should be fulfilled to get that running?
I suppose it has somethin gto do with:
here is possibility to "lock password to platform".
I've assigned all required raw partitions but DcsBoot.efi does not even rompt for password. It is the very same N_ESP (ESP/EFI for Decoy_OS).
PlatformInfo does contain details of physical system which are certainly different when running from within VM.
One of options is to map this single partition to a clone as file on Decoy_OS which would then contain appropriate PlatformInfo.
Running DcsBoot.efi with wrong PlatformInfo returns no output, but running wihtout this file raises:
PlatformInfo create Unsupported
Same is when running DcsInfo.dcs. What's wrong?
Given this, do I have to also have a copy of vault partition and have keys within it regenerated from within VM? This complicated the whole picture a bit.
Not sure what and how it should work hence asking instead of spending another night to try to get that running.
btw. on TrueCrypt there was no such validation and my scenario worked very well. Just issue with Windows Activation which was completely outside of TrueCrypt.
Last edit: Bugsy 2017-08-05
I managed to execute D_OS from H_OS via VirtualBox. The reason - to keep the D_OS visited. if you want to execute H_OS from Linux - it can be but I did not try this.
You can remove PlatformInfo generation: Remove DcsInfo.dcs.
PlatformInfo is help file to simplify configuration(picture password) and support.
There is plan to add Bluetooth authorization (vault or just mark on Bluetooth device) but I do not have notebook with Bluetooth and I do not know model. (I know UEFI 2.5 spec contains Bluetooth and AMI adds Bluetooth) If someone have PlatformInfo with Bluetooth protocols it can help to choose next development computer for me.
About the bug: I cannot reproduce it. Need scenario.
Password is requested if mark for the computer is OK (BIOS serial the same) Execution from VM - BIOS different => mark is not detected
Last edit: Alex 2017-08-06
Thanks Alex.
Should I remove only PlatformInfo?
This I tried but running DcsInfo.dcs gave me error afterwards as reported:
PlatformInfo create Unsupported
If I remove DcsInfo.dcs I'm not sure how to recreate PlatformInfo. Which command is used then to recreate it?
The scenario is as following:
D_OS & H_OS prepared as per above, directly on physical system.
on D_OC installed VmWare Workstation (in my case but it should not differ with VmWare Player but it might differ with VirtualBox.
Next step is to try to boot (as EFI system) this installation.
Creation VmWare I've selected Windows 10 64bit as this is what I'm on.
There might be difference between VmWare and VirtualBox in a way these to generate UUID (VirtualBox System-uuid or something like this and VmWare name bios.uuid).
I'm pretty sure platform ID is source of the problem.
I'll PM you with details of my system.
Hey, Bugsy. Have you ever gotten to writing (at least a skeleton for) a more human readable/understandable documentation for the process of creating a nos+hos+linux system with gpt/uefi? I've been re-reading the orig. doc and a thread or two that exists on the subject for some time now and still don't understand even how to begin. Oh, and happy NY!
Hi Tulip,
Unfortunately I did not finish writing documentation. Apologies for delayed answer as notification got into spam folder.
Having said that I've seen here on the forum recently some guides on how to do that. Not sure if these are of any help.
Regards,
Bugsy
Alex do you know of any backup program that will support decrypting the hidden OS to be backuped? I.e. not backing up the whole partition as RAW tks.
I use dism to create full image. Steps:
1. Apply gpt_enc
2. Boot WinPE
3. Mount OS via WinPE + VeraCrypt.
4. dism to capture image.
5. restore gpt_hid
Might be this is not the best choice but it works.
Also can I have more than 1 USB Keys for the same HOS? Of course the worry is if I lost the usb key I'll never be able to log-in to the HOS again, and I suppose that also will prevent decrypting the HOS as well as last resort? So the idea is to have a backup usb key or a few keys. I guess the procedure is the same, prepare the new usb with say first M unallocated and follow step 6 to wipe, mark and apply, please confirm and thanks Alex.
yes. just repeat procedure (-srw, -srm, -sra)
Great ;-)
I can confirm it works, as this is what I've done working on my partition setup :) Kept the USB on the side.
Hi Alex,
Just a bit of academic argument, isn't the presence of usb keys expose the fact that there is a hidden operating system? I mean if an adversary found out that there are the gpt_enc and gpt_hid files on a usb or find out that in one or more usb drives the primary partition started at an offset and there is a crc at sector 61? My suggestion is when you improve your dcscfg program, it may help to wipe sector 61 as well so that the crc is not obvious.
I suppose that's the argument to put a key for the NOS on the usb itself so that it can boot normally with the usb in and those gpt files should be in a hidden container instead. (until you are doing a backup of the HOS)
Last edit: Fan_of_Snowden 2017-08-08
Fact of USB with keys is not a problem(there is another similar fact - data encrypted)
There are N slots for OSs. It can be the only Decoy OS or several hidden OS on the USB with headers.
It is impossible to detect real headers. (rnd inside rnd)
gpt_hid, gpt_enc are secret recovery files! USB with keys do not have to contain these files!
gpt_hid is copied to 61+d*256 sector and encrypted.