#94 Windows EFS broken on non-system VeraCrypt volumes

[Natanji]

The problem was reported in this thread here:
https://sourceforge.net/p/veracrypt/discussion/technical/thread/e4a3053c/?limit=25

To reiterate some of the information: EFS encrypted files cannot be read, moved or copied when on a VeraCrypt volume that is not the system volume. These options give the error "invalid MS-DOS function". Only some systems seem affected, but on affected systems this is 100% reproducible.

I experienced this problem after doing the anniversary update for Windows 10 a few days ago, and upgrading VeraCrypt to 1.17 from 1.15 so perhaps the error is somewhere in between those versions. I did some researching into this problem...

1. The event log shows nothing. Zero. Nada.

2. It happens on all volumes, including VeraCrypt File Containers - but NOT on the System volume encrypted using VeraCrypt. Also not partitions not mounted by VeraCrypt (like unencrypted partitions).

3. The files can be renamed and deleted, but not moved or copied. This will show the error "invalid MS-DOS function" in explorer and "invalid function" when used in an elevated cmd.exe using copy/xcopy. Maybe because these actions make Windows try to read the actual contents of the data, whereas for renaming and deleting that doesn't matter?

4. Trying to decrypt affected fails results in an error in changing attributes, ERROR_WAIT_1

5. It happens to both old and newly encrypted files. So if I encrypt a file right now on any VeraCrypt mounted volume aside from the encrypted System volume, it will be affected. Of course it also doesn't happen to new files on partitions not mounted by VeraCrypt (like unencrypted partitions).

6. Copying a file from a non-affected volume to an affected volume results in a file with the same name to be created, having the EFS encryption attribute, but being empty (0 bytes) even when the original file was huge. The "invalid MS-DOS function" error appears, too.

7. Choosing read-only or removable media (or both) doesn't change anything, the problem still happens.

8. It only affects one of my machines (Desktop), not the other (Laptop). My Laptop doesn't use VeraCrypt system encryption though, so perhaps this is somehow related? Both did the anniversary upgrade and the update from VeraCrypt 1.15 to 1.17 recently.

9. This is on my Desktop, no kind of Apple hardware connected to it. So it's an unrelated problem to Apple. "Enable extended disk control codes support" doesn't affect the issue positively or negatively, either - is it generally a good idea to turn this on, or leave it off?

10. Decrypting the whole volume in-place results in the files being normally accessible.

This is a really annoying VeraCrypt bug and I hope you can do something to fix it for the next release. I'll be available if you need any more concrete help, and I can test out potential fixes.

[kpaseetpin]

I guess i have to beat the devs over the head with steps to reproduce.

Steps to reproduce

1. Create a test file

   • Create a file called HelloWorld.txt on an NTFS formatted volume
   • Open the file in Notepad, and enter the contents "Hello, world!"
   • Save the file, and close notepad

2. Encrypt the file using NTFS encryption

   • Right click the file HelloWorld.txt in Windows Explorer, and select Properties
   • On the General tab, click the Advanced button
   • Check the Encrypt contents to secure data checkbox
   • Click OK to close and Advanced attributes dialog box
   • Click OK to close the HelloWorld.txt Properties dialog box

3. Copy the NTFS EFS encrypted file to a Veracrypt mounted partition

   • Right click the file HelloWorld.txt in Windows Explorer, and select Copy
   • In Windows Explorer, navigate to a mounted, NTFS formatted, Veracrypt volume
   • Right-click in the Windows Explorer file list, and select Paste
   • Notice the error Invalid MS-DOS function

To eliminate any blame of Explorer, i created a sample program that simply does:

CopyFile("c:\temp\HelloWorld.txt", "f:\HelloWorld.txt", false);

The function fails, and GetLastError returns ERROR_INVALID_FUNCTION (1): "Incorrect function"

Using Process Monitor reveals a call to DeviceIOControl with the IOCTL IOCTL_MOUNTDEV_QUERY_DEVICE_NAME. The function call fails with Invalid Parameter.

From MSDN:

Support for this IOCTL by the mount manager clients is mandatory. Upon receiving this IOCTL a client driver must provide the (nonpersistent) device (or target) name for the volume. The mount manager uses the device name returned by the client as the target of a symbolic link. An example of a device name would be "\Device\HarddiskVolume1".

(Emphasis mine)

You can see the stack trace chain leading up to the DeviceIOControl:

Module	Function
KERNELBASE.dll	DeviceIOControl
KERNELBASE.dll	GetVolumeNameForRoot
KERNELBASE.dll	GetVolumePathNameInternalW
KERNELBASE.dll	GetVolumePathNameW
feclient.dll	EfspGetFullName
feclient.dll	CEfsClientBase::LocateAndConnectToService
feclient.dll	CEfsClientBase::EfsFileKeyInfoClient
feclient.dll	EfsClientGetKeyInfo
feclient.dll	EfsClientGetEncryptedFileVersion
KERNELBASE.dll	Tbsi_Physical_Presence_Command
KERNELBASE.dll	BasepCopyFileW
KERNELBASE.dll	CopyFileExW
KERNELBASE.dll	CopyFileW
TestVeraCryptBug.exe	TestVeraCryptBug.exe + 0x4e224

Now that i've done the hard work, can you please respond correctly to the IOCTL_MOUNTDEV_QUERY_DEVICE_NAME i/o control code when asked for it?

(GitHub issue can be found here)