As before, avoiding UPX compression on the module is a magic fix. It’s particularly frustrating because the compression isn’t hiding anything, since the original module can be extracted using freely available code that they’re already using! Why should using a reversible executable packer be an instant black mark? Shouldn’t they be more worried about unknown or non-reversible packers? Grrr.

I’ve updated the driver installer with a UPX-less version. Hopefully the complete removal will mean an end to these virus scanner hassles.

Avira have since confirmed the issue as a false-positive, and will be fixing it in a future virus definition update. Thanks to zogzog for taking the time to report the original problem.

It’s also a stepping stone to possibly releasing the driver as open source in the future, which is something I’ve been asked to consider. Though at least one of the requests was just so the driver could be used by GNU GPL programs, which I didn’t think was a problem anyway. I’m unclear on whether the driver is seen as a library dependency or part of the OS, and whether it’s only a problem if the calling program is useless without the driver.

Another reason for postponing an open source release is the confusion about Vista x64 driver signing. A binary release for would need to be signed, effectively making the digital certificate another project dependency. Nobody would be willing to distribute their own certificate to allow an equivalent binary to be built, which seems to violate the GNU GPL. Or am I missing something?

Googling for other online scanners I came across a handy site to check it more thoroughly. Simply upload your file and have it checked by around 30 commercial scanning engines, with near-live results (if there aren’t too many queued jobs).

I submitted the latest FdInstall.exe, and as expected AntiVir was the only engine to consider it infected, so I fired off an e-mail to report the false-positive. However… eSafe, Fortinet and Panda considered the file to be ‘suspicious’. The Additional Information section at the bottom reported the UPX packer, and that the file had a binary resource.

Just to compare, I submitted the old FdInstall.exe for scanning. No virus detected, but both eSafe and Fortinet still considered it suspicious due to the use of UPX.

I rebuilt FdInstall.exe without compressing the header, and resubmitted it for scanning. Result: completely clean! One of the scanners still reported the presence of UPX and binary resources, but it wasn’t enough to show as suspicious.

It seems that many scanning engines consider compressed executables to be a worry, as though they’re trying to hide something. I’m surprised this is still the case when using well-known packers like UPX, which can be unpacked using freely available programs and code.

I’ve now updated the FdInstall.exe on my site with an uncompressed version. It adds a whopping 11% (11K) to the installer size, but it’s well worth it to avoids further false-positives.

Hats off to Fortinet for their comprehensive response to my query in less than an hour. The file is white-listed in their latest definitions. Avira have also confirmed the file is clean, and plan to fix the issue in a future definition update.

The original installer was designed to have minimal dependencies, be simple to use, and avoid reboots where possible. I went for a single dialog design, with dynamic option choices that depended on whether the driver was already installed, and how the version number compared to that of the active installer.

Here’s what it looked like on first-time installation:

I wanted the new installer to be much more traditional wizard, with an uninstall entry in Add/Remove programs. I had already used NSIS for the SimCoupe installer, so I knew it would do the job without being too bloated.

The new installer also addresses the following areas:

1. Single installer for x86 and x64

   32-bit applications are prevented from writing to the Windowssystem32 directory on 64-bit platforms, which now contains 64-bit system files. Such requests are redirected into WindowsSysWOW64 instead, which is the new location for 32-bit system files. FdInstall’s attempts to write fdrawcmd.sys into Windowssystem32drivers ended up in the wrong place, so a 64-bit installer was created as a work-around.

   Since then I’ve discovered the Wow64DisableWow64FsRedirection API function, which turns off the redirection, allowing 32-bit applications access to the 64-bit directories. The allows a single new 32-bit installer to cover both x86 and x64 platforms.

2. Vista x64 driver signing

   Starting with the 64-bit version of Vista, Microsoft requires kernel-mode drivers to be digitally signed. Unsigned drivers are simply not allowed to load on the system, even if you’re running with Administrator access rights on the current machine!

   Here’s what happens when an unsigned driver is installed:

   

   This insane decision is being pushed as a security measure, despite user-mode applications generally causing most of the problems on Windows machines. In fact, the best known kernel rootkit was a music protection system released by Sony, and driver signing certainly wouldn’t have helped block it! The signing requirement seems more likely to be a DRM measure to protection the digital media path from copying.

   The only free signing work-arounds are to have a debugger attached to the system, or to press F8 during each boot to disable Digital Signature Enforcement. Neither of these are particularly usable for a production driver, even a free one like mine! My only real option was to buy a digital certificate, costing from £140 (GlobalSign) to £275 (Verisign) per year.

3. Known publisher

   When launching downloaded applications from Internet Explorer, or any adminstrative application in Vista, Windows prompts for final confirmation from the user before launching it. The severity of the confirmation prompt depends on whether the application is digitally signed.

   Note the difference between the unsigned and signed applications below:

   

   Fortunately, the certificate needed for Vista x64 driver signing was also suitable for signing other modules, including the new installer.

4. Improved Vista support

   Microsoft recommends that all applications designed to run on Vista include a manifest resource entry describing their privilege requirements. This allows each program to indicate whether they should run with the standard users rights, or whether Windows should boost it to run with Administrative rights (prompting if necessary). FdInstall needs to install a kernel-mode driver, so Admin rights are required.

   It just happens that running the original installer under 32-bit Vista would correctly prompt for these rights, despite the lack of manifest entry. For compatibility reasons, applications with “install” or “setup” sub-strings in their filenames are assumed to be installers and are boosted automatically.

The actual driver installation involves copying the binary to system32drivers, adding a new service, adding the driver as a lower filter for floppy-class devices, then restarting the devices to activate the driver without a reboot. Uninstallation requires most of these steps in reverse, but in a slightly different order!

Most of those aren’t standard NSIS facilities, so I created a small (5K) plug-in DLL to be called from the installer script. Most of the DLL code was the same as the original installer, so it was simply a copy-and-paste exercise. A slight complication was the device restarting, which couldn’t be done from a 32-bit application since it calls 64-bit class installer DLLs (failed with ERROR_IN_WOW64). That required an additional tiny (3K) x64 application to make the calls, using exactly the same code as the 32-bit version.

The install script is relatively simple compared to most other applications. The target directory is fixed at system32drivers, the only installation option is the driver itself, and there is no need to install any icons.

Here are the 3 wizard steps (welcome, license, copy+finish):

The final installer size is 96K, a mere 25K larger than the total for the old installers – not bad considering how much better it looks!

The finished installer is now available from the fdrawcmd.sys page.

1. fdrawcmd.sys is almost unchanged since the 1.0.1.9 release in May, as there’s been nothing much to do. I’ve no outstanding issues to fix, and only a minor enhancement that wasn’t worth a new release.

   I’ve been working on improving the driver installer, which will use the same NSIS setup as SimCoupe instead of my small custom installer. This will give a more traditional install/uninstall process and include both 32-bit and 64-bit drivers in one download. I’ll release a new version once it is complete, even if the embedded drivers don’t get updated from the previous release.

2. SimCoupe is also due a refresh build in the next month, mainly to improve Vista support. I’ve done some minor enhancements and fixes to the main code branch, but only enough to make it version 1.01 rather than 1.1.

   I’ve made a start to bigger changes in a code branch, which largely involves separating the emulation+sound from the UI+video processing. This should hopefully eliminate the occasional sound glitches from moving things over the main window, etc. It should also do more to spread the workload on multi-core CPUs. I also have some fragments of other features, including movie and sound recording.

3. SamDisk has been neglected for a few months, despite having been close to a release for a while! I’m happy with the core functionality, which does an excellent job with copy-protected and custom formatted disks (right to the limit of the PC controller’s ability). I’ve still not decided on the list of disk image formats for the initial version, but it’ll certainly include EDSK, MGT, TRD, D81 and BPB (for normal PC disks).