3

Basically when I download a zip archive, typically in chrome, but this happens in Mozilla as well, the files in the archive are encrypted (EFS) when I unzip them. Not password protected or anything related to the zip functionality but actually encrypted using Windows EFS.

I cannot for the life of me figure out what is causing this.

Screenshot: enter image description here

However, if I back out to see the root folder, the base directory is not encrypted:

enter image description here

Just to be certain, the zip download is also not encrypted. Have double checked in the properties as well.

enter image description here

I use EFS in a few folders on this computer, but this happens no matter what folder I put the archive into. I can keep it in downloads, move it to my documents, desktop etc., and when I unzip it using the Windows built in application, the folders and files in the archive are always encrypted.

I've searched all over and cannot even find another example of this or what I need to look for to figure out why Windows is doing this when I unzip an archive.

To summarize:

Windows 7_64

Downloaded ZIP archive

Unzip using Windows 7 built in extraction application

Subfolders and files but not the root folder are always encrypted using my EFS credentials.

Windows is always kept up to date. Have always run Eset smart security on this computer. EFS is used in several folders on this computer, but never ones like desktop or downloads or my documents. Any suggestions or direction on this would be greatly appreciated.

Screenshots of the properties of these folders. This is for an archive that is kept in downloads.

Downloads folder properties:

enter image description here enter image description here

Archive properties (unblocking doesn't change anything):

enter image description here enter image description here

Properties after unzipped:

enter image description here enter image description here

Properties of encrypted files:

enter image description here enter image description here

7
  • Provide a screenshot of the Properties of the source folder, that you placed into an .ZIP archive, its not unrealistic that a program like WinZip archive the contents with the exact properties the files and folder has. "hen I unzip it using the Windows built in application, the folders and files in the archive are always encrypted." - This is to be expected if your extracting the folders to one of those encrypted locations, or perhaps your entire profile is using EFS, submit more information. – Ramhound Nov 9 '16 at 21:29
  • Updating, the base folders are not encrypted, but posting the screenshots from them. – Jestep Nov 15 '16 at 15:23
  • I posted the comment before adding the screenshots, let me know if there are other properties you need to see. – Jestep Nov 15 '16 at 15:32
  • Based on the information, the .zip file itself is not encrypted, but the contents that are being extracted are encrypted. This either means when the zip file was created the contents were encrypted, if thats the case, unecrypt them and create a new archive. Have you simply unchecked, encrypt contents to secure data, that will decrypt the contents. My suggestion would be to use something other then the built-in functionality to extract the contents of the archive. – Ramhound Nov 15 '16 at 15:40
  • 1
    I'll start digging there. This specific computer is not currently on a domain, it may have been in the past, but I will see if I can find anything in the local policy that might affect this. – Jestep Nov 15 '16 at 16:47
0

tldr: Windows bug presumably fixed in Windows 8

We ran into this problem when trying to copy some old data from one Windows file server to a NetApp NAS. We kept running into a problem where ROBOCOPY would fail to copy files:

2020/05/23 19:49:43 ERROR 6000 (0x00001770) Accessing Destination Directory l:\Somepath\folder\__MACOSX\
The specified file could not be encrypted.

As with your experience, it turned out that the files had been encrypted. Looking at the file properties showed that the users themselves had encrypted the files. When we interviewed the users, they claimed that they did not do this on purpose and didn't remember performing the steps (I showed them) to perform the encryption.

After some research, I found a link to an old Microsoft blog post, which has since been removed. Here is a link to the article on the Internet Archive and the text below.

https://web.archive.org/web/20131110020048/http://blogs.msdn.com/b/asklar/archive/2012/05/03/why-do-zip-files-from-mac-os-show-up-as-green-encrypted.aspx

Why do .zip files from Mac OS show up as green/encrypted?

It’s kind of funny really. The ZIP specification mandates that a program/OS creating a zip archive include a tag informing about itself to the program trying to decompress the archive. This information is called “version made by”, and looks like this:

      0 - MS-DOS and OS/2 (FAT / VFAT / FAT32 file systems)
      1 - Amiga                     2 - OpenVMS
      3 - UNIX                      4 - VM/CMS
      5 - Atari ST                  6 - OS/2 H.P.F.S.
      7 - Macintosh                 8 - Z-System
      9 - CP/M                     10 - Windows NTFS
     11 - MVS (OS/390 - Z/OS)      12 - VSE
     13 - Acorn Risc               14 - VFAT
     15 - alternate MVS            16 - BeOS
     17 - Tandem                   18 - OS/400
     19 - OS/X (Darwin)            20 thru 255 - unused

Now, interestingly, it seems that Mac OS is tagging the zip archives it creates with the value 3 (UNIX). Ok, so far no problem, I guess.

The problem happens when Windows gets confused about how to interpret file/folder attributes. In FAT/NTFS, these values are stored according to this definition of File Attribute Constants. You’ll see that FILE_ATTRIBUTE_ENCRYPTED has a value of 0x4000.

The interesting part is how Mac OS is storing its file attributes in the zip archive. Mac OS, being a UNIX based OS, uses the UNIX file/folder attributes system (and permissions, but that’s a topic for another time…).. Well, it just so happens that in POSIX, the flag to describe a directory/folder (S_IFDIR) coincidentally also has the value 0x4000. So it turns out the zip decompression code wasn’t aware that there might be other operating systems out there that might create zip archives…

Bonus question: can you change this behavior. Answer: No; but you can clear the encryption flag from the extracted files/folders easily.

Related to this problem, when the EFS Service on the Windows File Server performed the encryption, a local user profile was created for the user that copied the file. This had also been a mystery (since users don't have access to log into the File Server or otherwise run programs).

At the bottom of the post in the comments, the post's author mentions that the bug was fixed in Windows 8. I tried to reproduce the problem on Windows 10 and could not.

Unfortunately in each of our cases, the users computers had been rebuilt and they no longer had access to the certificates used to encrypt the files. We've since added an EFS recovery key account to prevent this from happening again, but since everyone is on Windows 10 it shouldn't happen anyway.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.