UnZixWin - Rationale and history

After encountering my first ZIX archive, and googling on the extension, I located the site where the WinZix program I apparently needed was to be downloaded from. But once I read the EULA, I became suspicious. The liberties they wanted to take with my computer seemed to go way beyond what is acceptable for AdWare (which the creators freely admit to it being).

So, I did more research, and encountered a lot of red flags about this particular software. Damage reports and virus reports were plentiful in conjunction with WinZix, so I decided not to install it. Instead, I used a hex editor and poked around inside.

Being familiar with the makeup of many file formats (AVI, JPEG and a long list of others), I realized that what I was after was to be found inside, apparently not even compressed at all. More poking revealed that there was metainformation (a manifest, in my terminology) at the end describing what the contents were. After a bit of offset maths, I was able to decipher the entire structure of the archive.

Furious with this blatant attempt to fool me and hijack my computer, I wrote a corresponding article describing and debunking the format, including instructions on how to approach the dissection of the archive and extraction of the contents. But in order to put my money where my mouth was, I decided to write an app that did what I described. The result, née UnZix, was completed in a weekend. That's the beauty of Visual Basic. And the main logic was actually only a few hours' work; the rest was UI building, icon design and documentation.

I then discovered that another programmer, Jim Dunn, had written a command-line utility in PowerBasic, also called UnZix, and he had beaten me to the punch in getting the thing online.

Since not everybody is comfortable with command-line utilities, and since I had put in all that work, I decided to publish my own proggie as well, only I had to rename it (and edit the icons). The first release, 0.0.5, was submitted to TPB and TorrentBox. I lowballed the version number, because it never had undergone widespread beta testing.

Thanks to feedback from users, I was able to lay my hands on more problematic ZIX archives, so that I could handle folder hierachies and multiple files. Also, some stupid bugs were weeded out. Also, the first version choked on huge (>2GB) files, which prompted a substantial rewrite of the file handling logic. Versions 0.0.6 and 0.0.7 were the result of those updates.

In my article on the ZIX format, I made a few predictions about its future. I predicted that they would alter the format radically once it had been widely debunked, that it would aquire the compression (which they lied about offering), that they would ditch the revealing metainformation, and that whatever compression they used would not be original or innovative, but cribbed from someone smarter than they. I went so far as to say that they would probably change everything but the header.

Man, I should get myself a turban, a crystal ball and a 1-800 phone number! Those predictions proved spookily accurate. Starting approximately in June of this year, Zix archives appeared in the wild which confirmed almost all my predicitions. The scam artists responsible for WinZix had apparently caught on to us catching on to them. In fact, they even altered the header.

Exacerbating the problem with this new format was that these ZIX archives also contained junk data. The files inside consisted of high-entropy random garbage data, most likely produced with a utility called Dummy. This data was impossible to distinguish from an encrypted and/or compressed datastream, and so there was no way of knowing whether the data was valid, and no way of disseminating whether or not encryption and compression was used, and by what algorithms. How do you tell random crap produced intentionally from random crap produced by your own decryption efforts? You don't.

My only recourse was to release an interim version, 0.0.8, which anticipated the new format and simply put up a "sorry, can't do it" message, instead of an inaccurate "this ain't no zix!" mesage.

But then, in August, the case was broken wide open again. Someone snooped around inside WinZix with a hex editor, and discovered copyright claims from Jean-Loup Gailly and Mark Adler, authors of ZLIB. So now we knew what compression was used. And it wasn't new, or original, or superior to RAR or ZIP. It was ZLIB, and while it's certainly great, it's no invention on the part of the WinZix scammers. Another of my predictions had proven true.

Shortly thereafter, some tentative autopsy reports of the new format began to appear. Someone even produced a crude C command-line proggie which could extract the fírst file inside an archive. Based on guesswork, it worked somewhat quirkily if at all. It had no provisions for extracting multiple files, or even finding out whether they were present. And some of the guesswork I found to be erroneous. However, it confirmed one of my suspicions: the content wasn't encrypted post-compression (since the ZLIB routines could chew the data). And while the files it extracted proved to be junk, there was a good chance that the content was junk to begin with; the bastards who spread ZIX archives are fond of doing that.

What I needed now was a ZIX archive with a valid file inside, so that I could rule out the presence of any encryption. What I also needed was an archive with multiple files inside, so that I could determine the organization of any directory structure.

And, in September of 2007, I hit paydirt. Thanks to alert users who pointed me to a certain archive, the final pieces of the puzzle came together. This file contained a file I had encountered before, plus more, as well as what laughingly passed for a directory structure. I was able to identify some of the unknown numbers as MD5 checksums, and after some sleuthing and experimentation, the whole format was cracked. Read the specs here if you're curious.

Since the initial release, the app has grown in size and complexity, to the point where providing the source code almost serves no purpose. It now uses HTML bindings in some features, employs an external ZLIB library dll, and has taken on features for decoding more than just ZIX archives. The source code is still available to all and sundry, but I fear that it is more than a little complex. Given time and energy, I will try to document the source code somewhat more thoroughly.

During 2008, and half of 2009, I received very few emails and queries about Zix files and UnZixWin, leading me to surmize that the spreading of ZIX files had stopped. That meant my utility was becoming obsolete, which is sort of a good thing. To my surprise, in July of 2009 I received some email with requests for bugfixes and improvements. It seems that ZIX files are still in the wild.

Consequently, I did a substantial rewrite, sprucing the utility up with a new user interface, added multiple-file support, and fixed some stupid bugs which didn't occur to anyone except a couple of recent users. Version 0.1.0 is still a beta version, but it looks a lot better than before.

It is important to declare that UnZixWin really is a product of many minds. I would not have managed to get it this far without the aid and support of many other people, who were kind enough to provide example ZIX archives, bug reports, encouragement, and invaluable bits of information obtained from all over the web. The success of UnZixWin is thus due to you.

Thanks, guys!