Windows System Software -- Consulting, Training, Development -- Unique Expertise, Guaranteed Results

Home NTDEV

More Info on Driver Writing and Debugging


The free OSR Learning Library has more than 50 articles on a wide variety of topics about writing and debugging device drivers and Minifilters. From introductory level to advanced. All the articles have been recently reviewed and updated, and are written using the clear and definitive style you've come to expect from OSR over the years.


Check out The OSR Learning Library at: https://www.osr.com/osr-learning-library/


Before Posting...

Please check out the Community Guidelines in the Announcements and Administration Category.

Distribute additional files along with driver files through Windows Update channel

thdangthdang Member Posts: 2

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!

Comments

  • Doron_HolanDoron_Holan Member - All Emails Posts: 10,613
    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.
    d
  • thdangthdang Member Posts: 2

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

  • craig_howardcraig_howard Member Posts: 126

    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 ...

  • Peter_Viscarola_(OSR)Peter_Viscarola_(OSR) Administrator Posts: 8,568

    @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

    Peter Viscarola
    OSR
    @OSRDrivers

  • craig_howardcraig_howard Member Posts: 126
    edited July 20

    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!

Sign In or Register to comment.

Howdy, Stranger!

It looks like you're new here. If you want to get involved, click one of these buttons!

Upcoming OSR Seminars
OSR has suspended in-person seminars due to the Covid-19 outbreak. But, don't miss your training! Attend via the internet instead!
Developing Minifilters 24 May 2021 Live, Online
Writing WDF Drivers 14 June 2021 Live, Online
Internals & Software Drivers 27 September 2021 Live, Online
Kernel Debugging 15 November 2021 Live, Online