Distribute additional files along with driver files through Windows Update channel

Hi guys, my project involves update firmware for a device and the firmware data was stored in a binary file. I would like to know if there is any method to distribute the firmware file along with driver files through Windows Update? I’ve tried adding it when creating HLK package but when I download the signed package the firmware binary file was removed. For now I am using an installation package to distribute both driver and firmware binary files but it would be best if the whole package could be distributed through Microsoft Windows Update.
Thanks!

Is the firmware file referenced in the INF in a copy directive ? Pnp and WU and HLK don’t really care or know what files are in the driver package. If the INF says to copy the file somewhere it is a part of the package and all referenced files should be signed as a part of package submission.

1 Like

Thank you Sir! Let me add the Copy section into the INF, do some experiment and report back to you then.

Something that you may also consider is to embed the firmware into your driver itself … that has several advantages:

  • You’re going to be pushing the firmware through the driver anyway, so now you don’t need to handle reading from ??? and those edge cases (remember, code not written is code without bugs)
  • It avoids the problems when there’s a problem with the firmware, such as it’s missing or an older copy or an unknown version copied over it … you have total control over what gets written and what is not. This is especially important for a malware “downrev” attack, where an attacker takes a copy of your firmware with a known exploit and replaces your later version with the downrev version. For medical devices this is actually a requirement to get certification from the FDA
  • You can have a “last known good” or “recovery” firmware image ready if things don’t go right that you can recover from. When updating firmware you always want to have a “last known good” or a “recovery” image you can upload (ideally that’s on the hardware and being handled there, but …)
  • It makes it hard(er) for people to reverse engineer the firmware, both for IP protection and for malware actors
  • You can have a “ladder” approach to firmware, where a generic firmware is first loaded that can interrogate what’s attached downstream of the hardware and then load the specific firmware needed

I do a lot of work with the Cypress line of chipsets, which has a very handy firmware upload/ renumeration feature. Firmware images (and there are upwards of 20 in some drivers) are loaded based on the chip VID/PID and the results of the interrogation firmware. When a new firmware image is ready to be released invariably there is some new feature exposed, or some new bug found [sigh] or MS has released a new version of the WDK the driver needs to be compiled with [really heavy sigh!] and I’m needing a new driver anyway

Once you get to be needing to support a few variants of hardware with several years of model changes and have a deck of 20+ firmware images, embedding the images in the driver starts to make a lot of sense …

@craig_howard … so… what’s your favorite way to DO this (that is, embed the firmware in the driver image)? I’ve done this sort of thing in user-mode apps, where you put a driver (for example) as a binary resource that you then extract and install at run-time. But I’ve never considered doing this for a driver image.

Aside from creating a big H file with hex values in it… how do you like to do this?

Thanks for sharing,

Peter

Exactly that … there’s a binary to header utility I use [this is an example of one https://github.com/AntumDeluge/bin2header] that as a prebuild stage I use to encode the binary into a header file which is then included in the driver body

For the Cypress chips it simply parses through the header “blob” pushing the hex record contents to the chip … for chips that want binary data it’s a simple conversion from the text header “blob” to raw binary

For the more secure applications, such as medical devices or logging fobs or where there’s a concern that someone with a hex editor will do some digging around there is an AES256 encryption stage in the binary to header utility prior to conversion, which means that encrypted binary is in the header file and which is decrypted by the boot firmware using a key provided by the driver using a PBKDF2 exchange of a known seed value and iteration count …

So, the build process is …

  • Build the firmware, get the .hex images
  • Encode the .hex into .h using the utility, optionally encrypting it with AES256 using a key specific to that firmware image
  • Build the driver, including the .h files and have those .h portions statically linked as “blobs”

In use simply connect to the device (USB vendor commands, PCI BAR registers, etc.) and either push directly the “blob” per the device requirements or if it’s encrypted query the device for a “magic register” on the device which contains the PBKDF2 seed value, and another “magic register” for the PBKDF2 iteration count, apply that to the stored PBKDF2 hash of the AES decryption key and then push the resultant key to the device and again start pushing the “blob”

One nice thing about this approach (and assuming the device can handle this, like the Cypress renumeration) is that you can first load an interrogation firmware to determine downstream devices, then the “working” firmware … you don’t need one massive firmware image for all possible permutations. Another nice thing is that you can load up a debugging firmware capable of enabling whatever you need in the field (blinky lights, board header, etc.) without exposing that debugging interface until it’s needed. That really simplifies in the field debugging …

  • The device has a problem and the firmware goes into safe mode
  • The driver will detect that, push the debugging firmware and trigger a device diagnostic scan as well as trigger the “blinky light” thing
  • The driver collects the results of the scan and pushes that to the EventLog or similar, sometimes it will push that to a text message or email (gotta love Kernel Winsock!)
  • The driver loads up a firmware that will keep the device quiesced but still able respond to usermode programs (so you don’t have usermode apps crashing every time they try to use the device)

Get the email, send out a tech or whatever … done and done!

1 Like

Followup: Recently I came across a new (to me) USB specification called “DFU” (Device Firmware Update), some good info of which can be found here [http://dfu-util.sourceforge.net/] … this appears to be a standardization of the Cypress Renumeration technology of the Anchor (then FX2 and FX3) chips, and essentially allows a compliant composite USB device with the appropriate firmware support to push at runtime firmware updates … essentially what I was describing earlier, but all standardized up :slight_smile:

There are several vendors which support this DFU endpoint technology at this writing (STM and Cypress) as well as it being supported in the WinUSB class driver, the lib-usb interface library and an open source dfu-util utility; using a combination of all of these I was able to successfully update an STM32 discovery POC from both a custom UMDF driver as well as an entirely usermode console to lib-usb to WinUSB to the STM32 firmware (using WCID descriptors to handle the Device Interface GUID without needing a UMDF driver or even a WinUSB .inf file for the POC hardware)

… new stuff every day … :slight_smile: