I recieved two emails in response to my last post, both from people owning slightly obscure hardware wondering how they might be able to reverse engineer it and possibly get Linux driver production underway.
The first step is to spy on the device during normal usage. In the case of the Alauda, this means monitoring all USB port traffic while using the device under Windows using the vendor-supplied driver.
Fortunately this is relatively easy to do with USB, you can use software such as USBSnoop on windows which will log all the traffic to a file. Other hardware is not so easy, sometimes you have to resort to expensive “middle-man” hardware devices which monitor and record the traffic for you.
After logging a few sessions, you then have the daunting task of analysing the logs. They are cryptic and hard to understand at first. Here is a small part of a USBSnoop log right after plugging in the MAUSB-10:
[93 ms] >>> URB 6 going down >>>
-- URB_FUNCTION_VENDOR_DEVICE:
TransferFlags = 00000001 (USBD_TRANSFER_DIRECTION_IN, ~USBD_SHORT_TRANSFER_OK)
TransferBufferLength = 00000002
TransferBuffer = f6a77d3c
TransferBufferMDL = 00000000
UrbLink = 00000000
RequestTypeReservedBits = 00000000
Request = 00000008
Value = 00000000
Index = 00000001
IRQL=2
[94 ms] < << URB 6 coming back <<<
-- URB_FUNCTION_CONTROL_TRANSFER:
PipeHandle = 81b72c20
TransferFlags = 0000000b (USBD_TRANSFER_DIRECTION_IN, USBD_SHORT_TRANSFER_OK)
TransferBufferLength = 00000002
TransferBuffer = f6a77d3c
TransferBufferMDL = 81c029e0
00000000: 80 01
UrbLink = 00000000
SetupPacket =
00000000: c0 08 00 00 01 00 02 00
This starts to make more sense after reading the USB specs – the host computer is sending a command to the device and gets 2 bytes of data back (0x80 0x01) in return. I think that this particular command is querying the device status, and 80 01 means not ready yet. After 10 or so of these commands have been sent, the final one returns a new value of “0x14 0x01”, and after that, all kinds of crazy stuff starts happening, so 14 01 somehow indicates that the device is ready for action.
Once you have an idea about which command does what, and how to interpret the responses, you can then start writing code to mimick what the windows driver does. I’ve archived a good HOWTO (slightly out of date) which provides an introduction to this: Reverse engineering Windows USB device drivers for the purpose of creating compatible device drivers for Linux.
Obviously the process will be different for non-USB devices, but I hope this shows that while it’s an interesting experience, reverse engineering is pretty damn hard, especially you have so little to go on. It’s much easier if you can get a copy of the manufacturers technical documents, which is sometimes possible.
