Reverse Engineering

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 (0×80 0×01) 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 “0×14 0×01″, 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.

10 Responses to “Reverse Engineering”

  1. skTrdie Says:

    Well basically I don’t know much about the entire reverse engineering stuff, but it is interesting being able to “convert” any kind of hardware to make it Linux compatible. Well right now I own a powerbook with Linux, and my only problem is Airport Extreme. I think on the PPC part they are working on converting something, I found this: http://linux-bcom4301.sourceforge.net/go/progress but it seems very complicated… maybe you have something to say about this, because Airport Extreme has been a huge problem for PPC users like me, and this problem has been going on for too much time.

  2. dsd Says:

    It looks like they have a much harder task at hand.

    Where I can use usbsnoop to figure out what the windows driver is doing on my USB bus, it looks like they do not have any suitable tools like this, so they have to reverse engineer it a different way – by disassembling the windows driver code, and then reassembling it in the form of a Linux driver. This is much more long winded and there are legal issues regarding disassembly, hence they must work in two seperated groups.

    Judging by the content on their site, it looks like they are making good progress on the documentation though.

  3. Max Lapshin Says:

    Hi. I’ve found Your blog via google. I’m interested in reverse engineering of one software: Pentax Remote Assistant.
    This software is written for Windows and it can communicate via USB cable with digital photo camera.
    Pentax doesn’t have such a software for Linux (but there is one for MacOSX).
    How do You think: will it be easy to make such a thing?

  4. dsd Says:

    Depends what the software does, and how much support linux provides already.

    If using that software is the only way to get images off the camera, then you’ll need to write a new driver (you’ll probably want to write one for gphoto2 rather than for the kernel).

  5. Nathan Fearnley Says:

    I have a usb joystick and a usb gamepad from a company that went out of business a while ago (InterAct Accessories). They’re nice devices, it’s just that there are no drivers for Windows XP. Basic 4 Axis, several button HID interface works, but the force feedback isn’t supported without the custom drivers. How would I go about writing a driver for Windows XP if I already have a driver for 98/ME/2000?

  6. Anonymous Says:

    >I have a usb joystick and a usb gamepad from a company that went out of business a while ago (InterAct Accessories). >They’re nice devices, it’s just that there are no drivers for Windows XP. Basic 4 Axis, several button HID interface works, >but the force feedback isn’t supported without the custom drivers. How would I go about writing a driver for Windows XP >if I already have a driver for 98/ME/2000?
    if you do mabe you could inform the react OS team about that(so mabe they could add it to their OS)

  7. Bryan Says:

    I’m presently interested in reverse engineering the windows driver for the X-ROM GBA linker and cartridge. There is a beta linux driver, but it is distributed as a binary and the source is unavailable. Further, development of this driver for linux has stopped, and it fails to work under 2.6.16+ kernels.

    I saw your tips on USB Snoop and the reverse engineering HOWTO. Are there any other tips you can give?

  8. jessy_mark Says:

    I have reversed a driver thru windows using usbsnoop, then converting thru usbsnooplibusb.pl , after it is compiled, the drivers just flashes the light of scanner, i need to know how do i use this binary as a driver to interface the scanner.

    please help me, i am new to linux drivers!

  9. vigilancer Says:

    Do you know any tool for miniPCI/PCI traffic analyze?
    Need one for reverse wireless card driver.

  10. Jithin Says:

    Hey I have found the whole idea interesting.Do u think it will be possible to reverse a USB controller like a joystick and deduce the keystrokes each time a key is pressed.?

Leave a Reply

You must be logged in to post a comment.