I’ve spent the last few days updating FdInstall, which is used to install/uninstall/upgrade fdrawcmd.sys. It needed a few improvements for Vista support, which gave the perfect excuse for a complete revamp.
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:
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.
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.
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.
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 Windows/System32/Drivers, 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 Windows/System32/Drivers, 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.