• August 22, 2019 2.9.8

  Device driver for all The Imaging Source USB cameras except the 33U, 37U, 38U and AFU auto focus series.
  Version 2.9.8	Released August 22, 2019	Type ZIP	Filesize 3MB
  Requirements Intel Core i3 or similar, 2 GB RAM USB 3.0 controller Graphics card with 24 or 32 bit Windows 7 (32 & 64 bit), Windows 8 (32 & 64 bit), Windows 10 (32 & 64 bit) DirectX 9.0c or higher
  Changelog Added several internal interfaces for particular sensors (J003).

• January 25, 2019 2.9.6

  Device driver for all The Imaging Source USB cameras except the 33U, 37U, 38U and AFU auto focus series.
  Version 2.9.6	Released January 25, 2019	Type ZIP	Filesize 3MB
  Requirements Intel Core i3 or similar, 2 GB RAM USB 3.0 controller Graphics card with 24 or 32 bit Windows 7 (32 & 64 bit), Windows 8 (32 & 64 bit), Windows 10 (32 & 64 bit) DirectX 9.0c or higher
  Changelog Added missing Tonemapping Auto property.

• May 4, 2018 2.9.5

  Device driver for all The Imaging Source USB cameras except the 33U, 37U, 38U and AFU auto focus series.
  Version 2.9.5	Released May 4, 2018	Type ZIP	Filesize 3MB
  Requirements Intel Core i3 or similar, 2 GB RAM USB 3.0 controller Graphics card with 24 or 32 bit Windows 7 (32 & 64 bit), Windows 8 (32 & 64 bit), Windows 10 (32 & 64 bit) DirectX 9.0c or higher
  Changelog Enabled tonemapping for 8bit video formats, e.g. Y800, RGB24 and RGB32.

• November 21, 2017 2.9.4

  Device driver for all The Imaging Source USB cameras except the 33U, 37U, 38U and AFU auto focus series.
  Version 2.9.4	Released November 21, 2017	Type ZIP	Filesize 3.2MB
  Requirements Intel Core i3 or similar, 2 GB RAM USB 3.0 or USB 2.0 controller (depends upon camera model) Graphics card with 24 or 32 bit Windows XP, Windows Vista, Windows 7 (32 & 64 bit), Windows 8 (32 & 64 bit), Windows 10 (32 & 64 bit) DirectX 9.0c or higher
  Changelog Repaired not working J003 mono sensor pattern fix on particular video formats. This driver version is the last that works in Windows XP.

• January 9, 2017 2.9.3

  Device driver for all The Imaging Source USB cameras except the 33U, 37U, 38U and AFU auto focus series.
  Version 2.9.3	Released January 9, 2017	Type ZIP	Filesize 3.2MB
  Requirements Intel Core i3 or similar, 2 GB RAM USB 3.0 or USB 2.0 controller (depends upon camera model) Graphics card with 24 or 32 bit Windows XP, Windows Vista, Windows 7 (32 & 64 bit), Windows 8 (32 & 64 bit), Windows 10 (32 & 64 bit) DirectX 9.0c or higher
  Changelog Added a pattern fix for J003 mono sensors.

• January 9, 2017 2.9.1

  Device driver for all The Imaging Source USB cameras except the 33U, 37U, 38U and AFU auto focus series.
  Version 2.9.1	Released January 9, 2017	Type ZIP	Filesize 3.2MB
  Requirements Intel Core i3 or similar, 2 GB RAM USB 3.0 or USB 2.0 controller (depends upon camera model) Graphics card with 24 or 32 bit Windows XP, Windows Vista, Windows 7 (32 & 64 bit), Windows 8 (32 & 64 bit), Windows 10 (32 & 64 bit) DirectX 9.0c or higher
  Changelog Fixed the driver signature Code 52 error on new Windows 10 v1607 systems.

• January 15, 2016 2.8.9

  Device driver for all The Imaging Source USB cameras except the 33U, 37U, 38U and AFU auto focus series.
  Version 2.8.9	Released January 15, 2016	Type ZIP	Filesize 2.3MB
  Requirements Intel Core i3 or similar, 2 GB RAM USB 3.0 or USB 2.0 controller (depends upon camera model) Graphics card with 24 or 32 bit Windows XP, Windows Vista, Windows 7 (32 & 64 bit), Windows 8 (32 & 64 bit), Windows 10 (32 & 64 bit) DirectX 9.0c or higher
  Changelog Changed certificates so that the driver can also be installed in Vista.

• November 9, 2015 2.8.7

  Device driver for all The Imaging Source USB cameras except the 33U, 37U, 38U and AFU auto focus series.
  Version 2.8.7	Released November 9, 2015	Type ZIP	Filesize 2.3MB
  Requirements Intel Core i3 or similar, 2 GB RAM USB 3.0 or USB 2.0 controller (depends upon camera model) Graphics card with 24 or 32 bit Windows XP, Windows Vista, Windows 7 (32 & 64 bit), Windows 8 (32 & 64 bit), Windows 10 (32 & 64 bit) DirectX 9.0c or higher
  Changelog Fixed an error which can appear when using sharpness on older CPUs.

• October 20, 2015 2.8.5

  Device driver for all The Imaging Source USB cameras except the 33U, 37U, 38U and AFU auto focus series.
  Version 2.8.5	Released October 20, 2015	Type ZIP	Filesize 2.3MB
  Requirements Intel Core i3 or similar, 2 GB RAM USB 3.0 or USB 2.0 controller (depends upon camera model) Graphics card with 24 or 32 bit Windows XP, Windows Vista, Windows 7 (32 & 64 bit), Windows 8 (32 & 64 bit), Windows 10 (32 & 64 bit) DirectX 9.0c or higher
  Changelog Fixed a bug which can appear on LivePause call.

• July 15, 2015 2.8.0

  Device driver for all The Imaging Source USB cameras except the 33U, 37U, 38U and AFU auto focus series.
  Version 2.8.0	Released July 15, 2015	Type ZIP	Filesize 2.4MB
  Requirements Intel Core i3 or similar, 2 GB RAM USB 3.0 or USB 2.0 controller (depends upon camera model) Graphics card with 24 or 32 bit Windows XP, Windows Vista, Windows 7 (32 & 64 bit), Windows 8 (32 & 64 bit), Windows 10 (32 & 64 bit) DirectX 9.0c or higher
  Changelog Support of DFK ECU010-L34 with serial number property. Added tone mapping.

• February 17, 2015 2.7.33

  Device driver for all The Imaging Source USB cameras except the 33U, 37U, 38U and AFU auto focus series.
  Version 2.7.33	Released February 17, 2015	Type ZIP	Filesize 2.4MB
  Requirements Intel Core i3 or similar, 2 GB RAM USB 3.0 or USB 2.0 controller (depends upon camera model) Graphics card with 24 or 32 bit Windows XP, Windows Vista, Windows 7 (32 & 64 bit), Windows 8 (32 & 64 bit), Windows 10 (32 & 64 bit) DirectX 9.0c or higher
  Changelog The Auto Focus Onepush Running flag now resets correctly after the auto focus has finished.

• February 5, 2015 2.7.32

  Device driver for all The Imaging Source USB cameras except the 33U, 37U, 38U and AFU auto focus series.
  Version 2.7.32	Released February 5, 2015	Type ZIP	Filesize 2.4MB
  Requirements Intel Core i3 or similar, 2 GB RAM USB 3.0 or USB 2.0 controller (depends upon camera model) Graphics card with 24 or 32 bit Windows XP, Windows Vista, Windows 7 (32 & 64 bit), Windows 8 (32 & 64 bit), Windows 10 (32 & 64 bit) DirectX 9.0c or higher
  Changelog Video format MJPG (2592x1944) of DFK AFU050-L34 camera can now be used.

• January 14, 2015 2.7.31

  Device driver for all The Imaging Source USB cameras except the 33U, 37U, 38U and AFU auto focus series.
  Version 2.7.31	Released January 14, 2015	Type ZIP	Filesize 2.3MB
  Requirements Intel Core i3 or similar, 2 GB RAM USB 3.0 or USB 2.0 controller (depends upon camera model) Graphics card with 24 or 32 bit Windows XP, Windows Vista, Windows 7 (32 & 64 bit), Windows 8 (32 & 64 bit), Windows 10 (32 & 64 bit) DirectX 9.0c or higher
  Changelog Support for IMX236 based cameras. Support for RGB64 color formats. Several performance improvements.

• June 6, 2014 2.7.9.1152

  Device driver for all The Imaging Source USB cameras except the 33U, 37U, 38U and AFU auto focus series.
  Version 2.7.9.1152	Released June 6, 2014	Type ZIP	Filesize 2.1MB
  Requirements Intel Core i3 or similar, 2 GB RAM USB 3.0 or USB 2.0 controller (depends upon camera model) Graphics card with 24 or 32 bit Windows XP, Windows Vista, Windows 7 (32 & 64 bit), Windows 8 (32 & 64 bit), Windows 10 (32 & 64 bit) DirectX 9.0c or higher
  Changelog Added new properties: Brightness, sharpness, de-noise, saturation, hue and contrast. Added new property: Highlight reduction. Added new property: White balance temperature controls. Pixelfix for Y16 cameras now works as expected. VideoControl_ExternalTrigger (DirectShow property) can now be set as expected.

• January 1, 2014 2.6.5.1014

  Device driver for all The Imaging Source USB cameras except the 33U, 37U, 38U and AFU auto focus series.
  Version 2.6.5.1014	Released January 1, 2014	Type ZIP	Filesize 1.9MB
  Requirements Intel Pentium IV or similar, 2 GB RAM USB 3.0 or USB 2.0 controller (depends upon camera model) Graphics card with 24 or 32 bit Windows XP, Windows Vista, Windows 7 (32 & 64 bit), Windows 8 (32 & 64 bit) DirectX 9.0c or higher
  Changelog Fixed missing auto-gain for DFK AFU130. Fixed focus when start value is out of auto_focus_range. Fixed problem with AUTOFOCUS_ROI_RIGHT: minimum possibly wrong. Fixed auto focus ROI not working for 21*UC cameras. Fixed crash on load/connect with certain cameras 22/72xUC. Fixed previous exposure settings not being loaded on reconnect. Complete reworking of internal property system. Fixed Windows XP driver load crash. Fixed drop counter to be accessible from DirectShow. Fixed Windows 8 problem with certain video formats needing converters with standard DirectShow filters (e.g. Y800, capturing to an Y800 avi file was not possible). Fixed a problem with Windows 8 usbxhci driver not allowing transfers larger then 4 MB.

• February 26, 2013 2.4.14.851

  Device driver for all The Imaging Source USB cameras except the 33U, 37U, 38U and AFU auto focus series.
  Version 2.4.14.851	Released February 26, 2013	Type ZIP	Filesize 1.9MB
  Requirements Intel Pentium IV or similar, 2 GB RAM USB 3.0 or USB 2.0 controller (depends upon camera model) Graphics card with 24 or 32 bit Windows XP, Windows Vista, Windows 7 (32 & 64 bit), Windows 8 (32 & 64 bit) DirectX 9.0c or higher
  Changelog WHQL certification.

Update the device driver from the Device Manager and check. To update the device driver follow these steps. A) Press Windows and R keys together, Enter devmgmt.msc and press enter.‌ b) If you are prompted for an administrator password or confirmation, type the password or provide confirmation. This article explains the creation process of a Linux kernel device driver for an undocumented USB device. After having reverse-engineered the USB communication protocol, I present the architecture of the USB device driver. In addition to the kernel driver I introduce a simple user-space tool that can be used to control the device.

This article explains the creation process of a Linux kernel device driver foran undocumented USB device. After having reverse-engineered the USBcommunication protocol, I present the architecture of the USB device driver. Inaddition to the kernel driver I introduce a simple user-space tool that can beused to control the device. Although I have to delve into the specifics of aparticular device, the process can be applied to other USB devices as well.

Introduction

Recently, I found a fancy device while searching eBay: the DreamCheeky USBmissile launcher. The manufacturer neitherprovides a Linux driver nor publishes the USB protocol specification. Only abinary Windows driver is available, turning the missile launcher into complete“black-box” for Linux users. What a challenge! Let’s get the damn gadgetworking under Linux.

To facilitate USB programming, the USB interface is accessible from user-spacewith libusb, a programming API concealinglow-level kernel interaction. The proper way to write a device driver for themissile launcher would hence be to leverage this API and ignore any kernelspecifics. Nevertheless, I wanted to get involved with kernel programming anddecided thus to write a kernel module despite the increased complexity andhigher effort.

The remainder of this article is structured as follows. After pointing to somerelated work, I give a quick USB overview. Thereafter, I present thereverse-engineering process to gather the unknown USB commands steering themissile launcher. To come up with a full-featured kernel device driver, Idescribe the kernel module architecture which incorporates the derived controlcommands. Finally, I demonstrate a simple tool in user-space that makes use ofthe driver.

Related Work

Apparently I have not been the only one who played with this gadget. However,none of the existing approaches I have encountered pursue the creation of aLinux device driver for the kernel. The LauncherLibrary provides a user-spacelibrary based on libusb. AHmissile is aGTK+ control tool; a ncurses application isavailable, too.Apple users get happy with the USB missile launcherNZ project. Moreover, the python implementationpymissile supports a missilelauncher of a different manufacturer. The author combined the missilelauncher with a webcam in order to to create an automated sentry guard reactingon motion. I will return to these funky ideas later.

USB Primer

The universal serial bus (USB) connects a host computer with numerousperipheral devices. It was designed to unify a wide range of slow and old buses(parallel, serial, and keyboard connections) into a single bus type. It istopologically not constructed as a bus, but rather as a tree of severalpoint-to-point links. The USB host controller periodically polls each device ifit has data to send. With this design, no device can send before it has not beenasked to do so, resulting in a plug-and-play-friendly architecture.

Linux supports two main types of drivers: host and device drivers. Let’s ignorethe host component and have a deeper look at the USB device. As shown on theright side, a USB device consists of one or more configurationswhich in turn have one ore more interfaces. These interfaces contain zero ormore endpoints which make up the basic form of USB communication. An endpointis always uni-directional, either from the host to the device (OUT endpoint)or from the device to the host (IN endpoint). There are four types ofendpoints and each transmits data in a different way:

• Control
• Interrupt
• Bulk
• Isochronous

Alpha Project Usb Devices Drivers

Control endpoints are generally used to control the USB deviceasynchronously, i.e. sending commands to it or retrieving status informationabout it. Every device possesses a control “endpoint 0” which is used by the USBcore to initialize the device. Interrupt endpoints occur periodicallyand transfer small fixed-size data portions every time when the USB host asksthe device. They are commonly used by mice and keyboards as primary transportmethod. As bulk and isochronous endpoints are not relevant forour missile launcher, I skip their discussion. An excellent introduction from aprogramming perspective gives the Linux DeviceDrivers book. Below issome output from lsusb -v providing detailed information about the missilelauncher.

The output is structured and indented like a typical USB device. First, vendorand product ID uniquely identify this USB gadget. These IDs are used by the USBcore to decide which driver to give a device to. Moreover, hotplug scripts candecide which driver to load when a particular device is plugged in. Next, wecan read off the maximum power usage (100 mA) in the configuration section. Thesubordinate interface contains apparently one interrupt IN endpoint (besidesthe control endpoint 0) that can be accessed at address 0x81. Because it isan IN endpoint, it returns status information from the device. To handle theincoming data we first need to understand the missile launcher controlprotocol.

Reverse-Engineering the USB Protocol

The first step involves reverse-engineering (or “snooping”) the USBcommunication protocol spoken by the binary Windows driver. One approach wouldbe to consign the device in a VMware and capture the exchanged data on the hostsystem. But since several tools to analyze USB traffic already exist, the easiersolution is to rely on one of those. The most popular free application appearsto be SnoopyPro. Surprisingly I donot have Windows box at hand, so I had to install the binary driver togetherwith SnoopyPro in a VMware.

In order to capture all relevant USB data and intercept all device controlcommands, the missile launcher has to perform every possible action while beingmonitored: moving the two axes alone and together, shooting, and moving to thelimiting axes boundaries (which will trigger a notification that the axescannot be moved further in one direction). While analyzing the SnoopyProdump, one can easily discover the control commands sentto the missile launcher. As an example, the Figure below shows an 8 bytetransfer buffer. When moving the missile launcher to the right, the bufferholds 0x00000008. Moving the launcher up changes the buffer contents to0x00000001. It is apparently very easy to deduce the control bytes used tocontrol the missile launcher. Unless a “stop” command (0x00000000) is sent tothe device, it keeps the state of the last command. This means if the “down”command is issued, the device continues to turn until it receives a newcommand. If it is not possible to move further, the motor keeps up running andthe gears crack with a unbearable painful sound. Upon closer examination, theinterrupt IN endpoint buffer varies depending on the current device position.Whensoever an axis reaches its boundary (and creates the maddening sound), thedevice detects it and changes the interrupt buffer contents accordingly. Thismeans of notification can be leveraged by the kernel developer to implement aboundary checking mechanism sending a stop command as soon as the missilelauncher runs against a wall.

Here is an excerpt of the driver source showing the complete list of controlcommands that can be sent to the device.

The following bytes appear in the buffer of the interrupt IN endpoint (shown ascomment) and indicate that a boundary has been reached.

With all required control information in place, let’s now adopt the programmer’sperspective and delve into the land of kernel programming.

The Device Driver

Open Usb Device

Writing code for the kernel is an art by itself and I will only touch the tip ofthe iceberg. To get a deeper understanding I recommend the books Linux DeviceDrivers and Understanding the LinuxKernel.

As for many other disciplines the separation of mechanism and policy is afundamental paradigm a programmer should follow. The mechanism provides thecapabilities whereas the policy expresses rules how to use those capabilities.Different environments generally access the hardware in different ways. It ishence imperative to write policy-neutral code: a driver should make thehardware available without imposing constraints.

A nice feature of Linux is the ability to dynamically link object code to therunning kernel. That piece of object code is called a kernel module.Linux distinguishes between three basic device types that a module canimplement:

• Character devices
• Block devices
• Network interfaces

A Character (char) device transfers a stream of bytes from and to theuser process. The module therefore implements system calls such asopen, close, read, write and ioctl.A char device looks like a file, except that file is “seekable” and most devicesoperate sequentially. Examples for char devices are the text console(/dev/console) and serial ports (/dev/ttyS0). Most simplehardware devices are driven by char drivers. Discussing block devicesand network interfaces goes beyond the scope of this article, pleaserefer to the specified literature for details.

Besides this classification, other orthogonal ways exist. As an example, USBdevices are implemented as USB modules but can show up as char devices (likeour missile launcher), block devices (USB sticks, say), or network interfaces(a USB Ethernet interface). Let us now look at the rough structure of a USBkernel module and then turn to particularities of the missile launcher.

Apart from some global variables, helper functions, and interrupt handlers,this is already the entire kernel module! But let’s start off step by step. TheUSB driver is represented by a struct usb_driver containing some functioncallbacks and variables identifying the USB driver. When the module is loadedvia the insmod program, the __init usb_ml_init(void) function is executedwhich registers the driver with the USB subsystem. When the module is unloaded,__exit usb_ml_exit(void) is called which deregisters the driver from the USBsubsystem. The __init and __exit tokens indicate that these functions areonly called at initialization and exit time. Having loaded the module, theprobe and disconnect function callbacks are set up. In the probe functioncallback, which is called when the device is being plugged in, the driverinitializes any local data structures used to manage the USB device. Forexample, it allocates memory for the struct usb_ml which contains run-timestatus information about the connected device. Here is an excerpt from thebeginning of the function:

You might have noted the use of goto statements in this code snippet. Whilegoto statements are generally consideredharmful, kernel programmers, however,employ goto statements to bundle error handling at a central place,eliminating complex, highly-indented logic. The probe function allocates memoryfor the internal device structure, initializes semaphores and spin-locks, andsets up endpoint information. Somewhat later in the function, the device isbeing registered. The device is now ready to be accessed from user space viasystem calls. I will discuss the simple user-space tool accessing the missilelauncher shortly. Yet before that, I present the communication primitives usedto send data to the device.

The Linux USB implementation uses a USB request block (URB) as “datacarrier” to communicate with USB devices. URBs are like data messages that aresent asynchronously from and to endpoints. Remember that the USB standardincludes four types of endpoints. Likewise, four different types of URBs exist,namely control, interrupt, bulk, and isochronous URBs. Once an URB has beenallocated and initialized by the driver, it is be submitted to the USB corewhich forwards it to the device. If the URB was successfully delivered to theUSB core, a completion handler is executed. Then the USB core returnscontrol to the device driver.

As our missile launcher features two endpoints (endpoint 0 and the interruptendpoint), we have to deal with both control and interrupt URBs. Thereverse-engineered commands are basically packed into an control URB and thensent out to the device. Also, we continuously receive status information fromthe periodic interrupt URBs. For example, to send simple data to the missilelauncher, the function usb_control_msg is used:

The command cmd is inserted into the buffer bufcontaining the data to be sent to the device. If the URB completes successfully,the corresponding handler is executed. It performs nothing fancy, except tellingthe driver that we launched a (yet uncorrected) command via the writesyscall:

We do not want the missile launcher hardware to be damaged by neither sendingimproper commands nor sending any commands when it reached an axis boundary.Ideally, whenever an axis boundary is reached (meaning that the missile launchercannot turn further in one direction), the device should stop the movement inthe particular direction. The completion handler of the interrupt URB turns outto be the right place to implement this idea:

The above code is used to set the correction_required variable which triggersa “correction” control URB: this URB contains simply the last command withoutthe harming bit. Remember that the URB callback functions run in interruptcontext and thus should not perform any memory allocations, hold semaphores,or cause anything putting the process to sleep. With this automatic correctionmechanism, the missile launcher is shielded from improper use. Again, it doesnot impose policy constraints, it protects only the device.

User-Space Control

For most folks fun starts in here. One doesn’t kick the bucket whendereferencing NULL-pointers and the good old libc is available, too. Afterhaving loaded the kernel module, the missile launcher is accessible via/dev/ml0. A second missile launcher would show up as /dev/ml1 and so on.Here is a very simple application to control the device:

This tool, let’s name it ml_control, allows the user to send data to thedevice via the write syscall. For example, the device moves three seconds upand left with ./ml_control -ul -t 3000, shoots with ./ml_control -f, orstop with ./ml_control -s. Consider the code as proof of concept, of coursemore sophisticated applications are imaginable.

Just for fun, I mounted an external iSight camera on top of the missilelauncher. Like the author of pymissile suggests, creating anautomated sentry based on motion detection is a funky next step. Whenever amovement in the current view is detected, the missile launcher shouldautomatically align itself and fire a missile. Due to the lack of time, I couldnot pursue this project. Maybe someday, in the unlikely event of getting bored,I will return to this idea. Nevertheless, my friend Thorsten Röder quicklyhacked together a Qt GUI. It somehow resembles an early version of Quake…

Summary

In this article, I frame the creation of a USB device driver for the Linuxkernel. At first I reverse-engineer the unknown USB protocol by interceptingall USB traffic to and from the device with the Windows driver. Having capturedthe complete communication primitives, I explain how to build a USB kerneldriver. Finally, a proof-of-conecpt user-space tool is presented that lays thefoundation stone for further fancy ideas. Future work touches topics likeaugmenting the missile launcher with a video camera or mounting it on arbitrarydevices. The code from this article and a full implementation of the devicedriver is available at my github repository.