UEFI/GPT manual DCS hidden OS works with auth USB, but can decoy OS be added for classic two-password boot?

[dewittghy5656h]

I posted the detailed setup/question on SourceForge here:
https://sourceforge.net/p/veracrypt/discussion/technical/thread/da38d6d36e/?limit=25#d6bb

Opening this GitHub issue only to ask whether this is a supported/known VeraCrypt-DCS path or a current limitation.

My current setup:

• Windows 11 UEFI/GPT
• Manual DCS hidden OS setup
• Auth USB works and boots H_OS
• Normal/decoy Windows is currently not VeraCrypt system-encrypted
• Goal is classic hidden OS behavior:
  decoy password -> decoy Windows
  hidden password -> H_OS

Is it possible to encrypt the decoy Windows and add it to the same DCS/auth USB flow so the same DCS prompt accepts both passwords?

If yes, what is the correct high-level sequence?

Thank you in advance!

[idrassi]

Thanks for the detailed description.

Short answer: the EFI DCS mechanism can support one password prompt that accepts either the hidden OS password or the decoy OS password, but only if the decoy Windows installation is also encrypted. This is an advanced and manual DCS layout, not a standard supported hidden OS workflow, so its plausible deniability properties depend on the exact disk and authorization USB layout.

What you are seeing now is expected: a plain, unencrypted decoy Windows installation can't be accepted by the DCS password prompt, because there is no VeraCrypt system encryption header/authentication data for DCS to test.

For a manual DCS layout with a separate decoy Windows installation, the high-level sequence is:

1. Make full sector level backups of the internal disk and authorization USB.
2. Boot the decoy Windows installation.
3. Eencrypt the decoy Windows installation.
4. After decoy encryption is completed and the sector-62 system encryption header exists, create a new DCS/GPT package for the decoy.
5. Add the existing hidden encrypted package and the new decoy encrypted package to separate security-region slots.

The important point is that the GPT/DCS package for the decoy must be created after VeraCrypt has written the decoy system encryption volume header in sector 62. Otherwise -pe won't find a valid header to decrypt with the decoy password.

Also note that encrypting the decoy OS changes the boot flow. The previous "no USB -> direct Windows Boot Manager -> decoy Windows" path will no longer work the same way. Normal decoy boot will also go through the VeraCrypt DCS boot path.

There is another EFI caveat: when VeraCrypt encrypts the decoy OS, it copies the stock EFI\VeraCrypt files to the ESP. In a manual DCS setup, this may overwrite customized files such as DcsProp, keyboard/picture tables, custom branding or other DCS configuration. Back up the ESP first and be prepared to redeploy your custom DCS files after the decoy encryption completes.

After encryption of the decoy Windows is completed, create the decoy package from the EFI Shell. Keep -ps and -pe as separate commands:

DcsCfg.dcs -dl d
DcsCfg.dcs -ds <osdisk> -pf gpt_decoy_enc -ps
DcsCfg.dcs -aa -pf gpt_decoy_enc -pe

Replace:

• with the physical internal disk number from DcsCfg.dcs -dl d
• gpt_hidden_enc with your existing encrypted hidden-OS package, i.e. the package currently used successfully from the authorization USB
• gpt_decoy_enc with the new encrypted package for the encrypted decoy OS

For the -aa prompt used with -pe, enter the decoy password/PIM/hash, not the hidden OS ones. If hidden and decoy use different PIM or hash settings, make sure DcsProp is configured to request them or otherwise matches the intended boot configuration. -pe derives the encryption context from the header captured from sector 62 of the decoy encrypted disk.
-rnd isn't needed for this -pe step, even though some old command summaries mention it.

Don't add the package with -sra before -pe, otherwise -sra will reject it with:

GPT has to be encrypted

Important note about GPT hiding: donêt blindly apply -phide to the decoy package. In the standard hidden OS layout produced by -oshideprep, the decoy/outer package is the normal encrypted GPT package, while the hidden package is the modified GPT view that exposes the hidden OS. Applying -phide to the decoy package would be wrong in that standard layout.

If your manual layout is non-standard, for example if the hidden OS is on a separate visible partition rather than inside an outer volume container, then the GPT view for decoy boot must be reviewed carefully so the decoy OS can't mount, scan or write to the hidden OS area. In that case the correct -phide / -pedt handling depends on the exact GPT layout and shouldn't be guessed.

Recommended clean rebuild of the authorization USB with two security region slots:

DcsCfg.dcs -ds <usb> -rnd 2 -srw 2
DcsCfg.dcs -ds <usb> -srm 2
DcsCfg.dcs -ds <usb> -pf gpt_hidden_enc -sra 0
DcsCfg.dcs -ds <usb> -pf gpt_decoy_enc -sra 1

Security region slot numbers are zero-based. The example above keeps your existing hidden OS package in slot 0 and adds the decoy package in slot 1. The reverse order also works as long as both packages are written to separate slots.

If you also store DCS tables in the security region, allocate enough zones for those tables plus both encrypted packages; the two slot example is only for two encrypted auth packages and no extra table zones.

I recommend rebuilding the authorization USB rather than expanding an existing one-slot USB in place. Slot 1 starts at sector 318 and occupies sectors 318...573. Depending on where the first partition starts, that range may overlap the EFI/FAT partition and writing there would corrupt the USB. Only attempt inplace expansion if you have a full sector level image and have verified that those sectors are unused, for example because the first partition starts after sector 573. You can also use DcsCfg.dcs -ds <usb> -srdump <prefix> to make a logical backup of existing security regions, but this doesn't replace a full sector-level backup.

About your gpt_enc / gpt_hid observation: only an encrypted package can be added with -sra. If gpt_hid is your unencrypted hidden GPT view file, then it isn't the file to add directly with -sra: you need to add the corresponding encrypted package instead.

So yes, the DCS mechanism can do this for a separate decoy install/manual DCS case, but only after encrypting the decoy OS, creating the decoy package after the sector-62 header exists and using separate security-region slots for the decoy and hidden authentication data.

Last advice: Don't continue on the live disk or authorization USB without full sector level backups.