Problem with EFS / Win10 / VeraCrypt
Open source disk encryption with strong security for the Paranoid
Brought to you by:
idrassi
Menu
▾
▴
Hello everybody.
I got a problem since I migrated from Win8 to Win10.
I can't decrypt/uncrypt EFS datas on my VeraCrypt volume.
My partition is non system.
I can crypt a file to EFS, but I can't decrypt it.
When I tried, a msgbox appear : "you have to be admin", I click "ok", and then "an error occurded while applying files's attributes ... Uncorrect Function" (sorry, I translated it from french).
Once the file is crypted, I can't even copy it to a non veracrypt harddrive ! a msgbox told me "msdos function error".
I tried to uncrypt the entire volume (meaning remove the veracrypt encryption), I could then decrypt the efs files. Pretty strange...
It seems that once efs crypted, I don't have access to the files. I event tried to turn off windows defender (I don't have 3td part antivirus or antymalware, just basic windows protection)
I tried to decrypt with the explorer context menu, I tryed with the cipher /D command.
About the cipher command, I got in trouble, local group policies was "bad", and after searching on google, I found a trick : delete some keys on regedit, in localmachine / policies / microsoft...
I tried to copy efs files from veracrypt encrypted volume to non veracrypt volume with the explorer, with "dos" command "copy", and "xcopy", but still don't have access to them.
I tried to change the security ntfs attribute, to allow everyone to have all access to the efs files, but no success.
I use the last stable version of veracrypt.
Everything was ok on win8.
I saw that there was a problem with apple hd drivers, I checked it and I don't have such application from apple.
I just upgraded to win10, 2 days ago. No special application.
I read that it's not a fault from veracrypt, but to my harddriver drivers, but how can I check them ?
Thanks in advance, this problem is making me crazy for 2 days right now, and I think I red everything on the web about it.
Last edit: Johnny5 2015-12-22
Hello everybody,
I have exactly the same problem. (Moreover I can decrypt/uncrypt with windows 7 the file encrypted with windows 10 on a VeraCrypt volume, but, as Johnny5, I can't decrypt/uncrypt EFS datas on my VeraCrypt volume).
Johnny5 : Did you succeed to solve the problem ?
No, same problem. And I don't understand why there are so few people who have the problem.
The best and easiest way to solve this problem and many others is no usage of WIN ET.
Regards
Andreas
What is Win Et ?
Do You know ET in Steven Spielberg's film. He shows the same behaviour as Win10, they both want to phone home all the time.
Andreas
For those who have the issue: can you check Windows Event Viewer for entries that are logged at the same time as when the decrypt failure happen? maybe it contains some useful information.
Similar issues were reported and they were linked to faulty drivers like Apple Bootcamp (for those running Windows on a Apple Macbook).
Another option to try is to go to VeraCrypt menu Settings -> performance/driver configuration and then check "Enable extended disk control codes support", reboot and try again.
On my side, I will try to see if I can reproduce the issue.
Additional test to do: can you mount the partition as removable media (using mount options) and see if it solves your issue?
I experienced this problem after doing the anniversary update 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...
The event log shows nothing. Zero. Nada.
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).
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?
Trying to decrypt affected fails results in an error in changing attributes, ERROR_WAIT_1
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).
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.
Choosing read-only or removable media (or both) doesn't change anything, the problem still happens.
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.
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?
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.
Last edit: Natanji 2016-08-07
It looks like VeraCrypt 1.18 beta 12 does not contains the problem. I'm able to encrypt/decrypt/copy file on VeraCrypt encrypted drive.
Probably It can cause by AES encryption. What encryption do you use in VeraCrypt?
I just installed 1.18a and it has not solved the problem.
I was able to reproduce the issue and investigate it more deeply.
It turned out that Windows 10 is sending an unknown and undocumented IOCTL to VeraCrypt driver for the volume where EFS files are to be accessed. Of course, VeraCrypt was returning an error when this unknown IOCTL is received and that was causing Windows to stop the EFS operation.
I have implemented a workaround for this specific IOCTL and my tests show that it is working now as on previous Windows versions.
I wanted to publish a beta version so that you can validate the fix on your side but I'm still waiting for Microsoft for sign VeraCrypt driver (necessary for latest Windows 10 versions)...I hope someone in Microsoft is working during the weekend!
Apart from this matter.
Have you already fixed the security gaps from the latest audit?
I've heard rumous that the gaps are significant. Apparentlx thats whx you need such a long time to solve this issue?
Is that true?
The report will be published very soon (with 1.19 release) and you'll see that gaps are not significant as Alex said. Quarkslab spend a lot of type auditing VeraCrypt at different levels (which is very good) and this counted for most of the time since the audit started in August 16th. We worked closely to exchange information about the finding and develop the fixes for the important points.
The other explanation of the delay is that I wanted version 1.19 to also solve other issues like the EFS one and also another issue related to false-positive Evil-Maid attack detection. It took me time to solves these two issues but I think it was important to fixe them for 1.19.
The blocking problem now is Microsoft: No Windows 10 signature received yet from them! Last time it took few hours but this is not the case this time.
Gaps are not significant but important. Work is in progress.
Finally I received the signed driver for 1.19-BETA3 and I have uploaded the new installer at https://sourceforge.net/projects/veracrypt/files/VeraCrypt%20Nightly%20Builds/
Tomorrow I will submit the driver for the 1.19 release and hopefully I will receive it the same day so I can publish 1.19 tomorrow or after tomorrow.
If anyone can validate that indeed 1.19-BETA3 solves the EFS issue that would be great.
That is awesome! Will this 1.19 beta version also fix the issue with the uefi bootloader for msi, hp and acer devices?
https://sourceforge.net/p/veracrypt/discussion/technical/thread/5b859040/
The issues specific to ACER, HP and others are caused by non standard behavior of their firmware which blocks us from update EFI boot configuration. For now, we don't see any solution since it's coming from the firmware and not use.
@Natanji:
What happens if you try to access the EFS file from a Windows 7 machines? Do you get correct content?
For extra precautions, you have to mount your VeraCrypt volume as Read-Only during your manipulation on Windows 10 and Windows 7 to avoid any unexpected issue.
Sadly I have no Windows 7 machine - nor a Windows 7 license - to test this with. All my computers run Windows 10.
I have since restored many of the files that were corrupted via a backup, but I'm still getting really weird errors where the file contents turn into gibberish again. The weirdest was when I had a folder where one app (VLC) would be able to open the file, but another wouldn't be (the Win 10 Modern-style app "Video & TV"). Then I moved the file to a different drive, removed EFS and re-applied EFS, and on that different drive it was now possible for both apps to read it. Then I moved it back to the original location (encrypted partition), and then BOTH apps failed to read the file/displayed an error (and it seemed to only contain gibberish henceforth).
I have the feeling the bug is that EFS doesn't consistently decrypt the file, but sometimes shows me the encrypted contents instead. Since we don't know what that undocumented IOCTL does, maybe it IS actually important in some cases...? Is there a way to contact Microsoft and just ask them what this IOCTL does?
A wild guess: many of the affected files are in the file system on that same encrypted partition multiple times. Does NTFS have the capability to only save the file once physically, and link it from different positions (and actually discover this)?
Thank you for these details. You hypothesis about EFS decryption inconsistency maybe correct an that's why I asked about Windows 7 tests.
I don't have the information about NTFS duplicated files and how they are handled.
The problem is I was not able to reproduce the issue but maybe I will be able to finally reproduce thanks to the duplicated files information.
As for contacting Microsoft, I can open a ticket on their support team asking for the significance of this IOCTL but by experience I know that it is not always guaranteed to have an answer unless we pay a fee (not cheap) so that a Microsoft engineer looks into it. I will pursue this road only after I have exhausted all leads.
Anyway, I will try to reproduce and I will let you quickly.
It's been close to five months and I have not heard back from you on this, nor seen anything pop up in the change logs. What is the current status?
Perhaps if nothing is changed, you could warn users of using EFS right now, since it could on rare occasions lead to irreversible data loss (I luckily had a backup of the data, otherwise I'd have lsot all my personal photos). Me personally, I have discontinued using EFS since I don't trust its reliability under VeraCrypt right now.
I just experiend this problem also. Win10 (home version so can read but not create EFS files), Vercrypt 1.19, 2TB NTFS non-system HDD ESTAT drive with EFS files on it. The partition was enrypted on the same machine. It lives on a USB3 dock. I can open the non EFS files on it fine, but EFS files cannot be opened due to curruption. I can copy them to other drives etc and they keep the EFS. I also tried mounting the device as read only and removeable, which did not help.
I would most definetaly put a warning in VC to tell people NOT to encrypt.
I fortuantely have a backup, but plan to try the 'derypt' option just to see if the files will be restored on this drive.
I also tried taking the disk to a Win 7 computer (with my EFS cert installed) and it also was not able to open the files...
Just for reference, I was able to permanately decrypt the drive using Veracrypt, and verified all my files, including EFS ones, were intact (using checksum compare),
I then removed all the EFS file enryption using Windows (XP pro), then tried re-encrypting the volume using Veracrypt. However Veracrypt gave an error "Cannot shrink the filesystem". It suggested two things to check: that the drive is not in use (I found zero handles in process explorer); and to check the drive for errors using windows scan tool (that found zero problems). Even after rebooting, the same error occured.
So - has anyone else seen this problem where Veracrypt cannot re-encrypt a partition that it has previously encrypted then decrypted?)