MSI-based WMFHotfix Installer

Packaged by Evan Anderson and Jeff Sacksteder of Wellbury LLC

20060103, 11:57AM EST - It's been a long night, but we've gotten an MSI-based version of Ilfak Guilfanov's WMF hotfix up and running.
20060104, 10:52AM EST - SANS copy of the patch isn't avalable for some reason, so we put a copy up here.
20060104, 11:50PM EST - Added pre-build binaries for MSI custom action. Some commentary about the Accent Consulting patch.


THIS MSI PERFORMS THE SAME PRE-INSTALL TESTS AS ILFAK'S INSTALLER AND DOES NOT "DAMAGE" THE REGISTRY UPON REMOVAL!

Full source code to my MSI is provided below. SANS has received this source for review, and has reverse-engineered my MSI to assure that it only does what we say it does.

Instructions are below for a reasonably technically inclined person to be able to rebuild the MSI from my sources. If you trust me, download and use my binary MSI.


DOWNLOADS

Internet Storm Center's official posting of the binary MSI

Coralized Copy of Wellbury's Mirror of the Patch -- PLEASE USE THIS ONE IF POSSIBLE!

Wellbury's Mirror of the Patch

md5sum for MSI: 0dd56dac6b932ee7abf2d65ec34c5bec

Source Code, Binaries, WiX Source, Folder Structure

md5sum for source: df8d6e0e57417abb68d26880244e8192


Accent Consulting's Patch and this Patch - Differences and Similarities

Accent Consulting's patch and my patch are very similar. I wrote my MSI after seeing problems with the "first generation" MSI's. I got a copy of the InnoSetup definition file from Ilfak and based my work on that. Details of the "registry damage" that Accent refers to are as follows:

The first MSI patches that some people made just blindly wrote to the "AppInit_DLLs" of the "REG_SZ value in "HKLM\Software\Microsoft\Windows NT\CurrentVersion\Windows" key, ignoring what might already be there. When they uninstalled, they just cleared that key. I believe this is the "damage" that Accent Consulting is referring to. Additionally, the first-generation MSI's did not do exactly the same things that Ilfak's InnoSetup installer did, insofar as actually querying the hotfix DLL to be sure that the fix really works on a given machine. The first-generation MSI's that people created really shouldn't be used for these reasons.

Both Accent and I implemented "Custom Actions" in our MSI's to append to the "AppInit_DLLs" value instead of just overwriting it, and to correctly preserve anything else that was in that value on uninstall. It's not clear to me if Accent's MSI calls the "get_wmffix_code" function in Ilfak's patch like mine does, since Accent isn't distributing the source code for the EXE's that their "Custom Actions" use. My MSI calls Ilfak's patch during installation, and if the patch says "incompatible", my MSI fails, thus letting you know that you're not protected.

On the surface, they seem to be comparable. I don't know if Accent's MSI causes the installation to fail when a machine is "incompatible" with Ilfak's fix, but mine does. I've tested the REGTEST.EXE and REGROLLBACK.EXE custom action files from Accent's MSI, and they appear to work as I described above with respect to preserving the contents of "AppInit_DLLs". I was also pleased to see that REGTEST.EXE correctly handles an absent "AppInit_DLLs" value. I didn't try it with a non-REG_SZ value, but that's probably not a big deal. (ACS-01-SRV01, eh? *smile*)

I'm a little biased toward recommending my patch because, obviously, I wrote it, but also because the full source code to both my "Custom Actions" and the actual build of the MSI (with the WiX toolkit) are available. My site has instructions to completely rebuild my MSI in a "clean room" environment so that you can be sure that you've got a good binary. If you build in exactly the same environment that I did, you'll get an MSI with the same md5sum and everything.


To Build the MSI

Ilfak changed the function patched_gdi32 between versions 13 and 14 of his hotfix, and that tripped us up a little bit. We also had a less than fun time dealing with the Windows Installer. To do this patch right, the MSI needs to emulate exactly the functionality of Ilfak's InnoSetup-based routine. This means modifying the registry value for AppInit_DLLs, not just overwriting it. This also means calling Ilfak's get_wmffix_code() function and failing the installation if the underlying patch says that it's not going to work. The MSI that we've built utilizes two (2) "Custom Actions" to perform the necessary installation and uninstallation tasks.

Hopefully this saves you hours of unpaid overtime, and lets you sleep better at night. Big thanks to Ilfak for writing the patch. He did all the real work, we just made an MSI.