EFI hidden OS on 1.26: DcsCfg.dcs -rnd 2 -oshideprep succeeds through main header update but never creates gpt_enc / hidden GPT files

[dewittghy5656h]

Hello,

I am reporting what looks like an incomplete or broken EFI hidden OS flow on VeraCrypt 1.26 / DCS.

I am using the manual EFI/GPT hidden OS method. H_OS system encryption completed successfully, but DcsCfg.dcs -rnd 2 -oshideprep never reached the GPT filename stage and created no GPT files (gpt_enc, gpt_hos, gpt_hidden, gpt_hid).

I stopped before doing any more writes because I do not want to damage the disk further if this is a bug/regression or if I missed a required step.

Environment
VeraCrypt: 1.26
Architecture: x86-64
Windows: Windows 11 Home x64
Boot mode: UEFI/GPT
Secure Boot: temporarily disabled only to boot a custom UEFI shell USB
Internal disk: Kingston NVMe
BitLocker / Device Encryption: fully disabled and all internal volumes fully decrypted before VeraCrypt system encryption
Disk layout

Internal NVMe partitions:

original protected ESP, 100 MB
MSR, 128 MB
old visible Windows, 240 GB
OUTER_A, 131 GB
H_ESP, 260 MB EFI
H_OS, 390 GB
OUTER_B, 148 GB
Recovery, 800 MB
Recovery/OEM, 19 GB

H_OS is installed on partition 6, using partition 5 as EFI.

What succeeded before -oshideprep
H_OS install succeeded
H_OS booted
VeraCrypt system partition encryption on H_OS succeeded
VeraCrypt pretest succeeded
DcsBoot boot entry worked
Full Rescuezilla snapshot was taken after H_OS encryption and before -oshideprep
UEFI shell

The normal VC rescue menu did not provide an EFI shell, so I created a separate FAT32 UEFI shell USB and copied the whole \EFI\VeraCrypt\ folder onto it.

In shell:

DcsCfg.dcs -dl d

showed:

disk 0 = USB
disk 2 = internal NVMe
-oshideprep behavior

Running plain:

DcsCfg.dcs -oshideprep

failed with:

No randoms

Running:

DcsCfg.dcs -rnd 2 -oshideprep

got past that failure.

I then chose:

Disk = 2
Start outer = 4
End outer = 7

Observed prompts/answers:

Sectors [781025280, 781557759], Wipe data?
answered y
this matches partition 5 (H_ESP)
Sectors [1911521280, 1913159679], Wipe data?
answered n
this matches partition 8 (800 MB Recovery), not an outer partition
Init outer headers?
answered y
Selected:
AES
XTS
SHA-512
Entered first outer password
Save outer? -> y
Entered second outer password
Save outer? -> y
Update main encryption header? -> y
entered the real H_OS password
received Success

After that, output was:

Success

Start 400157573120 length 419430400000
VolumeSize 419430400000
HiddenVolumeSize 0
flags 0x1
Encrypted already

Then it returned to shell prompt.

Expected but missing

I expected the next stage to ask for GPT filenames, e.g.:

encrypted GPT filename (gpt_enc)
hidden GPT filename (gpt_hos, gpt_hidden, or similar)

But I never saw any such prompts.

Also, no GPT files were created anywhere I could find:

not on USB root
not in \EFI\VeraCrypt
not on any mapped fsX: filesystem

I checked for:

gpt_enc
gpt_hos
gpt_hidden
gpt_hid

All absent.

Trying read-only checks such as:

dcscfg.dcs -pf gpt_enc -pl
dcscfg.dcs -pf gpt_hos -pl
dcscfg.dcs -pf gpt_hidden -pl
dcscfg.dcs -pf gpt_hid -pl

returns:

load: not found

Current partition check

After the above, running:

dcscfg.dcs -ds 2 -pl

still shows the ordinary partition layout, not an obvious hidden/merged GPT state.

Questions:

On VC 1.26, after successful -rnd 2 -oshideprep, should GPT filename prompts always appear?

Is HiddenVolumeSize 0 expected here?

Could answering n to the wipe prompt for the 800 MB Recovery partition prevent GPT file generation?

Does the recovery partition layout interfere with EFI hidden OS on current DCS?

Does argument order matter?

DcsCfg.dcs -rnd 2 -oshideprep
versus
DcsCfg.dcs -oshideprep -rnd 2

Are there any additional flags/steps on current 1.26 that are not reflected in older docs/forum posts?

Is rerunning -oshideprep appropriate here, or is restore from the pre--oshideprep disk image the only safe recovery?

Any clarification on the expected successful post--oshideprep behavior for 1.26 would be very helpful.

Thanks a lot!

[idrassi]

@dewittghy5656h
Thanks for the detailed report. From the output, -oshideprep didn't actually complete the GPT generation stage.

The important lines are:

    Start 400157573120 length 419430400000
    ...
    Encrypted already

This means the system encryption header already has a non-zero encrypted area length. In this state, DCS aborts before asking for the gpt_enc / gpt_hidden filenames. The Success line before it only means that the header password was accepted: it doesn't mean that the main header update completed.

The manual EFI hidden OS flow requires running -oshideprep before the H_OS in-place encryption has been performed, while the system header still has EncryptedAreaLength = 0. In your case H_OS had already been fully encrypted, so the current behavior is expected from the implementation.

There is also a second problem: DCS partition indexes are zero-based. Based on the layout you posted, Start outer = 4 selected H_ESP and End outer = 7 selected the 800 MB Recovery partition. The intended outer partitions were likely OUTER_A and OUTER_B, which would be different indexes, probably 3 and 6 if the printed order matches your list.
This explains why the first wipe prompt matched H_ESP and the second matched Recovery.

Answering n to the second wipe prompt isn't what prevented GPT file creation. The later abort was caused by the non-zero EncryptedAreaLength. However, the current DCS code unfortunately doesn't stop the whole operation when a wipe is declined, so subsequent outer header writes may still have used the selected Recovery partition as the end partition. HiddenVolumeSize 0 in this output is just the value read from the existing H_OS system header. Argument order between -rnd 2 and -oshideprep shouldn't matter.

Please don't rerun -oshideprep on the current disk state. Since H_ESP was wiped and outer headers may have been written using the Recovery partition as the end partition, the safest recovery is to restore your snapshot from before -oshideprep. To retry the hidden OS flow, you need to go back to a state before H_OS encryption starts, verify the zero-based GPT indexes with DcsCfg.dcs -ds <disk> -pl and only then run -oshideprep with the correct outer start/end indexes.

I will also improve DCS here: the tool should detect the already-encrypted header before doing destructive writes, abort if a wipe is declined and make the zero-based partition index requirement clearer.

[idrassi]

The proposed improvement to DCS has been implemented: veracrypt/VeraCrypt-DCS@4be7235