Windows: improve mounted volume storage identity

[0x1337F00D]

Summary

This improves the Windows storage identity reported by mounted VeraCrypt volumes without introducing a new driver ABI or registry option.

It fixes two separate contract problems:

1. STORAGE_DEVICE_DESCRIPTOR.DeviceType was populated with FILE_DEVICE_DISK (0x07). In a storage device descriptor this field uses SCSI peripheral device types, where 0x07 means optical memory. Mounted volumes now report DIRECT_ACCESS_DEVICE (0x00).
2. Device-hosted volumes retained VeraCrypt's synthetic 1 MiB partition view even when the driver had a real lower disk and partition. The driver now captures a complete backing identity and reports a coherent view of the encrypted volume's data area.

No debug fields, performance counters, direct-I/O changes, DCS changes, or new registry gates are included.

Raw-volume identity

For a normal volume mounted from a raw partition or whole disk, the driver records the complete lower-stack STORAGE_DEVICE_NUMBER tuple and the host partition starting offset.

When the identity is complete and representable, responses are derived from:

start  = host partition start + encrypted volume data-area offset
length = mounted volume data length
end    = start + length

The same values are then used for:

• IOCTL_STORAGE_GET_DEVICE_NUMBER
• IOCTL_VOLUME_GET_VOLUME_DISK_EXTENTS
• IOCTL_DISK_GET_PARTITION_INFO[_EX]
• IOCTL_DISK_GET_DRIVE_LAYOUT[_EX]
• disk geometry and media responses
• IOCTL_STORAGE_READ_CAPACITY

This preserves valid whole-disk PartitionNumber == 0 values and avoids mixing fields from unrelated lower-stack queries.

The existing opt-in controls remain authoritative:

• TC_DRIVER_CONFIG_ENABLE_EXTENDED_IOCTL gates the extended storage IOCTLs.
• VC_DRIVER_CONFIG_ALLOW_WINDOWS_DEFRAG gates volume disk extents.

Fail-closed cases

Physical identity is not published when the backing tuple is incomplete, arithmetic or host bounds fail, sector alignment is invalid, or the result cannot be represented by the MBR-compatible view currently returned by this driver.

The physical view is also excluded for:

• file-hosted containers
• hidden volumes
• hidden-volume protection
• partitions in an inactive system-encryption scope

File containers therefore receive the corrected direct-access device type but keep the existing synthetic partition geometry. They intentionally do not receive an invented physical disk number or extent: no matching PhysicalDriveN/PnP disk exists for such a number.

Validation

Development and runtime validation were performed only on Windows 11 ARM64 in a Parallels VM with a locally test-signed driver.

The final one-commit tree built successfully as an ARM64 Release driver:

• commit: 33c7eb2dbc68e851ef3a9c5ab8901b5cef2a5a5c
• veracrypt.sys SHA-256: 8FD4B559E884E3E9D3E6873161BD48083012363BB673F0693D81364FEA62C4E1

Runtime validation combined this commit with the ARM64 system-encryption branch and verified the installed driver hash before loading it as a demand-start test driver.

File-container checks:

• STORAGE_DEVICE_DESCRIPTOR.DeviceType = 0
• BusType = BusTypeVirtual
• synthetic partition/layout/capacity remained coherent
• device number and physical extents remained unsupported by design
• chkdsk completed without errors

Raw VHD-backed partition checks:

• backing identity: Disk 1, Partition 1
• reported data extent: start 196608, length 262144
• partition info and drive layout reported the same start and length
• reported capacity ended at 458752
• STORAGE_DEVICE_DESCRIPTOR.DeviceType = 0
• three mount/dismount cycles completed
• chkdsk completed without errors

No VM snapshot was created. Testsigning, the test service, driver file, and VHD were removed afterward, and Secure Boot was restored.

Scope boundary

This is an IOCTL compatibility change, not a new Windows PnP storage architecture. It does not create a disk PDO or partition PDO for \Device\VeraCryptVolumeX.

Consequently, consumers that query the mounted handle directly can correlate a raw VeraCrypt volume with its real backing disk and extent, but the modern Storage module (Get-Volume / Get-Partition) still does not enumerate the decrypted view as a separate PnP disk or partition. Solving that requires a real storage-stack participant and should be reviewed independently.

x64 Windows, bare-metal hardware, Windows Backup and Restore, and third-party imaging products have not yet been tested.

Related background: #1664, #1036.