The Case of the Zip File That Wouldn’t Open
Posted by William Diaz on December 8, 2010
While trying to extract the SysInternal PSTools.zip, I was running into the following error: “The Compressed (zipped) Folder is invalid or corrupted.”
WinZip also failed to open the file with “Cannot open file: it does not appear to be a valid archive.”
To verify the issue was not isolated to the file itself, I downloaded again and was still unable to extract. Further, I tested the same file on a couple of my co-workers workstations and they, too, could not open. Finally, I turned to a test system, similar to mine but oddly enough it opened. So what was different with the test system? I was logged on as the local computer admin. And what was different about the local admin account vs my domain account? Logging on locally to the workstation obviously does not run group policy for the domain.
To find out what was different between the two downloads, I decided to run a trace on the PsTools.zip while downloading it using Process Monitor. I applied a filter to look for PsTools.zip in the path of any operation and started the download. There were only a handful of operations on both the test system logged in as local admin and the one logged on with a domain account. In fact, they were both identical, with the same number of operations and matching file activity. I decided to focus on only write operations and this is when I saw the problem.

You can see that the file is written in 65KB chunks until the end of the file write is reached, which is 45,073 bytes. 1,638,400 + 45,073 = 1,683,473 bytes. I checked the file properties of a working PsTools.zip:

Here is the trace from the domain account that downloaded but could not open PsTools.zip:

You can see only 32,768 bytes are written in the last chunk. 1,638,400 + 32,768 = 1,671,168 bytes, which is the size of the zip file downloaded via any domain account:

The last chunk of data missing, thus the compressed file would not open.
Since we know that the problem is a result of data being omitted (perhaps stripped) from the zip file, we can then narrow down the mechanism—probably a network component. As I mentioned before, local accounts do not inherit group policy, which includes the ISA proxy that our domain accounts are pointed to in Internet Explorer. Local accounts need to be manually configured in IE and pointed to an ISA. In most cases, we just point them to our most liberal proxy, a non-production proxy as opposed to xxx-proxy.domain.com that the domain accounts use.
Upon escalating, it was determined that our cloud-based web security and filtering (a recent move), was at fault. Actually, fault is not entirely accurate. The vendor explained that this was by design as PsTools.zip contains multiple binaries (exe files) that can be interpreted to contain code that is malicious. As traffic passes through their “towers” it is scanned for viruses and “if the amount of data is small then we will block this outright, but at a certain threshold we will allow a download to occur while we scan it. If we find the download to contain malicious code then we corrupt the download so the file is useless and no danger to your machine or environment.” In other words, the missing 12kb was part of “corrupting” the download. To work around this, an exception was created for the SysInternals site. Alternatively, switching to a proxy that bypasses the web security & filtering service would have also sufficed.
The Woes of Cloud Web Security « Windows Explored said
[…] The Case Of The Corrupt Download & The Case of the Zip File That Wouldn’t Open […]
nascent said
Amazing. I too was experiencing this at work. Disabled my proxy and re-downloaded the file. It worked with no issues.
I’d tried multiple downloads all resulting in the same issue prior.