This post contains instructions on how to get a submission CAB file for kernel-mode device drivers for Windows 10 ready for the Windows Hardware Developers Center Dashboard portal. To increase the security of the Windows platform, since version 1607, having a kernel-mode driver signed by the portal is required. I would recommend following the links under each step to go to the authoritative source and gain a clear picture about how your needs fit into the process. Previously installed device drivers that have not been signed by the portal and were installed on Windows 10 won’t be rejected by the OS if an upgrade to version 1607 occurred after their installation.

Driver Signing changes in Windows 10
Driver Signing changes in Windows 10, version 1607

NOTE: I should say early on that you’ll need an Extended Validation Code Signing Certificate for your company if you don’t already have one. The Microsoft’s Hardware Dev Center help docs contain the requirement details for the certificate.

The following link is a must-read on the proper submission format for the portal. Much of the information there could not be found elsewhere in the same digested format.

Q&A with project director of the MHDCDp

It’s also a good idea to see where we’re headed. Read through the following Driver Signing page on Microsoft’s Hardware Dev Center to see what our end goal is. That is one of the more important links because it shows the submission format that’s necessary for the portal.

At this stage of the driver release process, you should already have your built driver and INF file and have already verified that it’s not going to destroy someone’s system. While the WHDCD portal will run extensive tests against your driver to check if it’s running exploits against known vulnerabilities, during this process you will be signing attestation agreements in which you “attest” to the veracity of the drivers you’re submitting. Consult the details of those agreements to see what you’re responsible for.

The process can be painstaking. There are many details specific to your use case that will make finding a guide to fit your exact needs unlikely. However, included in this post are the links to much of the documentation that one can dig through for help.

Expect your first submission to the portal to be rejected!

Terms and Definitions

  • CAB – Cabinet files, an archive file for Windows that supports lossless file compression and signing (formerly known as Diamond files)
  • INF – a setup configuration file, used with Windows Installer and with installing device drivers
  • CAT – a catalog file, used as a signature for a set of files, has cryptographic hashes/thumbprints
  • DDF – Diamond Directive File, the build configuration file for makecab
  • HSM – Hardware Security Module, typically a USB device that contains the EV code signing certificate as an encrypted token containing the private key
  • EV Code Signing Certificate – An Extended Validation code signing certificate, these require an additional vetting process around the request for the cert. The signature from an EV cert won’t expire when the certificate expires. Typically sent on an HSM. They are recognized by Microsoft SmartScreen. This kind of cert is required for submission to the MHDCDp.
  • HLK – The Windows Hardware Lab Kit, used to test hardware for Windows 10 (contains chkinf, which we’ll use later)

Process Overview

When you have your driver built into a SYS file and your INF file written, we’re going to verify the INF file with chkinf and generate a CAT file using inf2cat that contains cryptographic hashes for each of the driver files in the capsule. We’ll sign the driver with signtool before we package it up into a CAB file, and we’ll create a DDF cabinet-creation directive file to specify how the cabinet should be composed. Finally, we’ll use makecab to create the CAB file and sign the CAB. At this point the driver submission will be ready for the Windows HDCD portal.

Steps

Step 1 – Gaining the Certificate
I’ll assume that you’ve got your kernel-mode drivers built and that you’re ready to begin making a submission. You’ll need to discover which type of certificate, standard or EV, you need. However, the EV cert is good for all situations that require a code signing cert for the MHDCDp. To get the latest info on selecting the proper cert by your submission type, check out Microsoft’s Hardware Dev Center Get a code signing certificate article.

Step 2 – Installing the Certificate
Install the EV Code Signing Certificate to your local store. EV code signing certs are often shipped certified mail on a Hardware Security Module. You’ll need this and the private key. Install the cert using the methods outlined from your certificate provider.

Step 3 – Sign your drivers
You can sign the drivers through Visual Studio:

Signing a Driver for Public Release

Or you can just use signtool in an admin command-prompt:

You’ll need to use the Common Name of your certificate. To get this:
1. Open certmgr.msc (Windows Key + R, certmgr.msc,)
2. Find the install location of your cert. It’s more than likely that the certificate installs to the Certificates – Current User > Personal > Certificates store.
3. Right-click the cert name and go to the Details tab.
4. Select from the drop-down list
5. Select the Subject field.
6. Look in the Value box. The Common Name of your certificate starts with ”CN = “.

signtool documentation


Location of the Common Name for the certificate

Step 4 – Install Windows Hardware Lab Kit
Install the Windows HLK (at least version 10)
Download the Windows Hardware Lab Kit

Step 5 – Check the INF for errors
In C:\Program Files (x86)\Windows Kits\10\Tools\x86\ChkInf\ run the chkinf.bat against the INF file. This runs Perl scripts that check the syntax of your INF files before you make a submission to WHQL. You’ll want to run this to save yourself from having your submission rejected for mistakes. After running chkinf an ‘\htm’ folder will be created that contains a summary file of the set of files checked and a detailed summary HTM file per INF file checked. The detailed summary file contains errors by line, warnings, and an annotated version of the INF file that was checked with the errors and warnings inline. The composition of an INF file is beyond the scope of this post, but if you’re troubleshooting chkinf error messages, here’s a link to the documentation.

chkinf documentation

Step 6 – Create the catalog file
We’ll need to create a catalog file for each driver capsule. The CAT file contains cryptographic hashes for a driver’s INF file for a list of Windows versions that we’ll specify. To create the *.CAT catalog files, run the following command depending upon the target architecture (i.e., X86 or X64). You’ll need to add this to your path or run it directly from that folder.

Inf2cat exists in the C:\Program Files (x86)\Windows Kits\10\bin\x86 folder from the Windows HLK install:

inf2cat documentation

Catalog Files and Digital Signatures

Step 7 – Create the DDF file for the submission CAB
Create a *.DDF file (Diamond Directive File) for makecab using a format similar to the following, (e.g., replace <> tags with your own). The DDF specifies cabinet properties, the name of the cab file, and the capsule details (i.e., capsules are the individual drivers and their associated files). The following example is a good starting place.

How to write a makecab directive file (DDF)

 

Step 8 – Make the submission CAB
Run the makecab command from the directory containing the DDF file
(e.g., from the same directory as the INF, SYS, and CAT files if the directories were written as .\SSDnsInject.inf etc.):

Step 9 – Sign the submission CAB
Run this command in the directory containing the submission *.cab file. You will need the EV code signing certificate Hardware Security Module and the private key (a prompt will appear):

NOTE: /n, The certificate name here must match the Common Name that you see in certmgr.msc (as before) for a certificate installed to the local store.

Step 10 – At the portal
The portal changes often, so the scope of this post won’t extend there.
However, the following should consistently contain the relevant steps for the current form of the portal.

MHDC Dashboard FAQ

Attestation Signing a Kernel Driver for Public Release

Update a code signing certificate

The following legal agreements must be signed in the portal to make submissions by attestation (kernel-mode drivers not involving manufactured hardware):

For attestation submission, the following agreements will need to be signed:

  • Windows Compatibility Program and Driver Quality Attestment Testing Agreement
  • Windows Certification Program Testing Agreement

For submitting for certification, the following agreements will need to be signed:

  • Windows Logo License Agreement For Software
  • Windows Certification Program Testing Agreement

For using the EV Code Signing Certificate with the MHDCD portal:

  • Code Signing Agreement for Extended Validation (EV) Certified Code

Good luck!

I’ve heard that it’s not very often that a software dev team actually delivers a “start-from-scratch” project on time. I mean, let’s face it. There are a lot of moving pieces and if just one gets out of place, the entire project is thrown out of whack. So, how then can a dev team possibly complete something on time? Well, since my dev team just accomplished a huge project and delivered it on time, I think I may have some insight.

It’s all about having team work, being vocal, timing, early demo, realistic planning, work ethic and, of course, respect.

Let me explain.

Team Work

From the mob programming sessions and the group Skype calls, to off-the-cuff team “water cooler meetings”, there was a whole team understanding of what the project was and the plan to complete it. Daily stand-ups kept each member on board with what the other was working on (and in what environment to reduce the likelihood of code being overwritten). Problems were mentioned in stand-up and often led to an after-stand-up Skype call to discuss and address the issue. It really helps when the whole team applies KISS to stand-ups. 😉

Being Vocal

My actual coding skills aren’t the strongest so, when my team included me in the mob programming sessions, I was a little on edge. I mean, what could I possibly help with?! But wow. What an enriching experience for a tester to be in a room and hear the thoughts of these code geniuses and, as a team, contribute to the project as a whole. I cannot begin to tell you how awesome this was. And one of the best things that came out of those mobbing sessions for me was that when I didn’t understand a part of the solution, my team would explain it to me. If I don’t understand something, I’m not afraid to ask for clarification. And that alone enables me to become a better tester. My testing effectiveness is only as good as my understanding of what I’m testing, right? So, speak up and speak up early. This leads me to my next point.

Timing

I feel one of the most important things to do to deliver a project on time is to be early. Ask questions early: after a project is specked out, take a few minutes to read the project plan and jot down any (no question is a stupid question) questions that come to mind. No matter how insignificant you think it may be, ask it! As the project develops and code and testing are done, continue to re-read the project plan and ask more questions. We all know that once you dive into something, certain things start to make sense and more questions arise. Code early. As soon as it was possible, these devs began putting all the background pieces in place that they knew they’d need to get this project off the ground. Test early. Using KANBAN as the method for managing all items assigned to the team has been the “oil that made the engine run smooth”. I cannot speak highly enough about how the Kanban process helped this team work together EARLY and enabled us to deliver the product on time.

Early Demo

Sometimes what looks good on paper, makes a terrible user experience during execution. That’s why it is super important to demo everything as early as possible. On my team, we were all in charge of demoing whatever was available to the PM. I enjoy taking the lead on the task to demo because I get to add my UX advice on what I thought as a user when the steps are completely non user-friendly. When caught early, this can lead to lower dev costs and a better UI experience all together!

Realistic Planning

It helps to have a team (PM included of course!) full of reasonable people who don’t want to bite off more than they can chew. You definitely need your dev team to be “small bite takers”. When the project plan is delivered to the dev team and they commit to only what they know they can accomplish, timely expectations are met. And having the whole team included in the planning process keeps everyone on the same page and keeps a certain degree of team spirit going where everyone feels they are contributing to the solution. This is another crucial piece to getting software out on time.

Work Ethic

A dev team who wants to deliver on time, will deliver on time. Make sure the drive to accomplish the end goal is there across the team. If even one person is slacking, the whole deliverable date is in question.

Respect

Everyone is creative. And in a team of intelligent minds, the last thing to do is limit creativity. There must be an enormous amount of respect within the team so that the way a solution is written is owned by the person writing the code. And if another team member has a different opinion, everyone should listen and work together on the best solution for the business. Respect one another’s work. Respect one another’s creativity. The open respect everyone had for one another on this team is another major reason why the flow of this project was continual.

So, there you have it. Seven helpful tidbits that I learned through experience about how to deliver software on time. If you use these suggestions and your project doesn’t ship on time, perhaps I forgot to document one. Either way, these suggestions are sure to help the flow of a software project to be smooth, consistent, and constant.

#ARSpotLightSpeakers Michelle Ward – Application Security – AppRiver

Michelle Ward opens our 2017 Spot Light Speakers Series with a conversation about Application Security. Enjoy!

Michelle Ward is the founder of Cyber Safe Workforce LLC, a company that helps workplaces teach employees computer security basics. Before starting her own company, she worked 11 years in the defense space building web applications area as a software engineer. Always part of a small team, Michelle learned to wear many hats: leading projects, interfacing with stakeholders, designing, building, testing, deploying and maintaining her applications in a secure environment.

Michelle received her B.S. in Computer Science from the University of West Florida and is a Certified Information Systems Security Professional (CISSP®), a Certified Secure Software Lifecycle Professional (CSSLP), and has had training from BlackHat and DerbyCon in Web application insecurity and hacking web applications using the Open Web Application Security Project (OWASP) Top Ten. Her former career includes a small stint in penetration testing.

Michelle is a passionate advocate for information security and believes that each person has an important role to play. Her volunteer efforts include Cyberthon and the Armed Forces Communications and Electronics Association (AFCEA) Summer Cyber Camps.

#ARSpotLightSpeakers Greg McMenimen – Teammates and Trust

 

Greg McMenimen continues our Spot Light Speaker Series with a conversation about Teammates and Trust. Enjoy!

Greg is married to his beautiful and loving wife of 19 years. They have one daughter who is committed to playing D1 volleyball at the University of Minnesota and is ranked #1 in the nation this coming year. He grew up in Minnesota playing hockey and even played in college for a short time. He left college and joined the U.S. Coast Guard in 1982, where he served for 20 years. He was a rescue swimmer the first 8 years and then joined the National Strike Force (Atlantic Strike Team).

He retired in 2002 and began his career as a Government software engineer contractor in D.C., but eventually moved to Destin because it was too cold. He started working on Mission Planning software, developing AWEs for various aircraft at Eglin Air Force Base, FL. He moved to Heidelberg, Germany with the U.S. Army European Command, where he worked as a Web Developer for a Geospatial-Intelligence group, painting the picture for down-range Special Operations teams from Joint Special Operations Command (JSOC). Greg moved back to Eglin AFB, where he was offered a position as the Chief of Software Engineering on a new Mission Planning tool and worked to re-engineer a Flight Calculation Engine for aircraft and weapon systems. He was then offered another position back in Stuttgart, Germany working for U.S. European Command, a major intelligence systems command. He provided real-time geospatial intelligence data for the Joint Operations Command that oversaw operations in all of Europe and the Middle East, while providing mentoring to the teams in Agile methodologies.

He eventually moved back to the states and left government contracting to take a position as Development Manager for the mature startup, iSirona. They developed server solutions for medical device connectivity and data collection/reporting on medical device alarm fatigue. He took a position as Director of Software Development at E-lead CRM and began implementing Agile methodologies while also building up a software development group of over 60 developers, automation engineers, and product owners. From there, he left E-lead and started work with Dave Dyell, CEO of Jellyfish Health and former CEO of iSirona.

Greg enjoys hobbies such as mountain biking and running races. He swims laps for workouts and enjoys watching his daughter play indoor and sand volleyball.

AppRiver Ignite Talks March 2017 Sudoku & You

One of the main links between theoretical computer science and discrete mathematics is the topic of Graph Theory. Graph Theory is the science of how things are connected and the combinations of connections when certain conditions are in place. A subset of graph theory is the study of Latin Squares. Latin Squares can be used as a method of procedure when it is desired to control or allow for two sources of variability, while investigating a third. With simple conditions, a Latin square can be viewed as a Sudoku puzzle.

In this talk, we review some basic graph theory concepts to solve a Sudoku puzzle in terms of a mathematical graph. We hope to demonstrate how graph theory can be visualized and applied to puzzles.

 

References

More Information on Latin Squares
Blogs