How to create a signed Windows 8 driver for USB Ir Toy

As part of a home automation project I’ve been testing different infrared receivers/transmitters. One inexpensive USB-based transceiver is the Usb Infrared Toy (v2): http://dangerousprototypes.com/docs/USB_Infrared_Toy

This uses the Microchip PIC 18F2550 microcontroller which acts as a virtual USB serial port. The problem is that the included driver isn’t signed so it can’t be used in Windows 8.x. Various people have suggested to disable signature checking in Windows, but that’s both risky and complicated. I wanted to go the proper route instead, which is to sign the driver with a certificate. A real certificate is about $180/year (code signing certificate) and I didn’t wan to pay that, so the alternative is to use a self-created certificate and ask Windows to trust that (which is a normal Windows process, doesn’t require a diagnostic boot, etc). I wanted to document the steps so it can be reproduced as well for other drivers.

Get the driver inf-file in order

First step was to clone the repository so I can commit my changes. The creators of Usb Ir Toy are currently using code.google and have all their projects in one repository. Since code.google is going away and to make it easier to work on this project I copied out the Usb Ir Toy folder and put it up on github instead, here: https://github.com/HakanL/UsbIrToy. The next task was to update the inf-file so it would be compatible with Windows 8.x and go through the signature check (using inf2cat). I took the latest Microchip example driver inf file (http://www.microchip.com/pagehandler/en-us/devtools/mla/home.html) and just copied the relevant settings over. Note that for devices like these (that emulate a serial port) the “driver package” doesn’t actually include the driver, it just consists of an inf-file that describes the device and then it references the built-in usbser driver that’s included with Windows. But you still have to sign the inf-file so Windows can trust it. Here’s the updated inf-file: https://github.com/HakanL/UsbIrToy/blob/master/inf-driver/mchpcdc.inf. And to generate the cat-file from the inf file I used the command tool inf2cat from the Windows Device Driver kit (https://msdn.microsoft.com/en-us/windows/hardware/gg454513#drivers) using the instructions from here https://msdn.microsoft.com/en-us/library/windows/hardware/ff547089(v=vs.85).aspx to come up with this command line:

Inf2Cat.exe /driver:. /os:6_3_X86,6_3_X64,Server6_3_X64,8_X64,8_X86,Server8_X64,Server2008R2_X64,7_X64,7_X86,Server2008_X64,Server2008_X86,Vista_X64,Vista_X86,Server2003_X64,Server2003_X86,XP_X64,XP_X86,2000

Note that the /driver parameter is pointing to the directory where the inf file is, not the file itself. I used . since I was already in that folder. This command runs some signability tests and then outputs the cat-file. From there you need to sign that file before it’s ready to used as a device driver.

Hacking the Harmony RF Remote

Why

For my home automation system I’ve been looking for a sleek universal remote. Some of the requirements are:

• RF (my A/V cabinet is in the garage)
• Great ergonomics
• Inexpensive (<$100)
• Not too many buttons
• Use regular batteries so I don’t have to put it back in a charging station after use
• High WAF (Wife Approval Factor)
• Ability to integrate it to my DIY home automation system

I finally found it, the Logitech Harmony which is part of their Ultimate package ($130+), but you can buy it as an add-on for $30 (http://www.amazon.com/Logitech-Harmony-Companion-Ultimate-915-000245/dp/B00LTKGFDQ). After some research I figured out that it’s using the popular NRF24LE1 chip (NRF24L01+ radio plus a 8051 MCU). That is totally hackable!

My ultimate goal is to attach a cheap NRF24L01+ chip (http://www.amazon.com/nRF24L01-Wireless-Transceiver-Arduino-Compatible/dp/B00E594ZX0) to my home automation system (based on Raspberry Pi) and use this remote to control my A/V equipment.

I figured there are two phases to this goal, phase one is to determine the RF protocol and ids used to send packets between remote and hub. Phase two would be to understand the packet protocol and see if there are any software-based frequency hopping, encryption, etc.