USB Reverse Engineering: A Universal Guide

20 Comments

Every hacker knows what it is to venture down a rabbit hole. Whether it lasts an afternoon, a month, or decades, finding a new niche topic and exploring where it leads is a familiar experience for Hackaday readers.

[Glenn ‘devalias’ Grant] is a self-proclaimed regular rabbit hole diver and is conscious that, between forays into specific topics, short-term knowledge and state of mind can be lost. This time, whilst exploring reverse engineering USB devices, [Glenn] captured the best resources, information and tools – for his future self as well as others.

His guide is impressively comprehensive, and covers all the necessary areas in hardware and software. After formally defining a USB system, [Glenn] refers us to [LinuxVoice], for a nifty tutorial on writing a linux USB driver for an RC car, in Python. Moving on to hardware, a number of open-source and commercial options are discussed, including GoodFET, FaceDancer, and Daisho – an FPGA based monitoring tool for analysing USB 3.0, HDMI and Gigabit Ethernet. If you only need to sniff low speed USB, here’s a beautifully small packet snooper from last year’s Hackaday prize.

This is a guide which is well-informed, clearly structured, and includes TL;DR sections in the perfect places. It gives due credit to LibUSB and PyUSB, and even includes resources for USB over IP.

If you’re worried about USB hacks like BadUSB, perhaps you should checkout GoodUSB – a hardware firewall for USB devices.

Header image: Ed g2s (CC-SA 3.0).

 

20 thoughts on “USB Reverse Engineering: A Universal Guide”

  3. Thanks for article, will be looking into more detail this w/end, tah

    Provokes me to review state of the art if one wished to bit bang a
    processor just to add comparatively low speed USB and of course
    after the CPU/system selected primarily for other functions which
    are not time dependent.

    Eg A product designed for simple logging has a few spare pins
    and code space and under appropriate circumstances could a bit-
    banged USB mode be implemented such as to offer low data volume,
    status and reports no more than say 100Kbytes each hour or so.

    I’ve read a low speed compatibility mode in the standard is around
    as little as 150K bytes/sec as part of the spec compliance,
    if that were true then a portable device with developed software
    should be recognisable by any compliant host. Which raises
    a question as to how low speed compliant USB can actually go ?

    There is some discussion of this here
    https://www.avrfreaks.net/forum/bit-banging-usb
    and thus curious if observers of this thread have personal experience,
    such as when they also personally have reverse engineered USB for
    whatever reasons or the enthusiast imagines cramming as much as
    possible into the lowest end CPU to achieve some minimal USB functionality ?

    Cheers

    Report comment
    Reply

  4. what I would like to know is who’s the genius behind USB 3.0 ? They made it so that you can plug it in either way, yet for the PC side its still the same. They should have made the change on both ends. DUGH….

    Report comment
    Reply

    1. Eh?

      USB-C plugs are reversible, USB 3.0 is available in a variety of connectors. Your PC may have either the old style USB-A(?) socket, or the new reversible USB-C socket, or both.

      Report comment
      Reply

    2. I believe it’s perfectly valid to use USB-C at both ends of the connection. Not only reversible, but the entire cable can be turned. It will be cool if laptops start including multiple USB-C ports commonly.

      Report comment
      Reply

  6. I’ve been wondering. Imagine you have two USB devices, one connecting to the other directly, through USB. Is there a device that can act as a MitM proxy between those devices, so that one can modify (or at least see) the data being sent from one device to the other on the fly?

    Report comment
    Reply

    1. Ah good question.
      From my earliest recollection when USB first came out there was an
      option for device manufacturers to offer a start peer to peer mode
      option if the device type could accommodate it – sort of like rs-232
      terminal to terminal.

      ie Say both devices programmed to allow peer to peer hostless
      comms for what ever function or subests etc such as terminal to
      terminal etc or Eg data logger (DL) to terminal or DL to DL
      as backup, extract, compare, report exceptions etc

      Then device 1 powers up, sends an id string but goes nowhere then waits.
      Device 2 then powers up whilst connected to device 1 sending its id
      string recognised by device 1 – they then handshake and all good.
      IIRC the id string had a flag to indicate if it could accept peer to peer
      and the nature of its function or another string on an ack type h/shake etc

      We did this all the time with multiple daisy chain rs-232, etc 485 & current loop

      In other words an intermediate device only needed if either of the connected
      devices not suitably programmed or variations to that effect with the intermediate
      Device doing something re protocols, buffering etc. Only minor issue
      re power up timing, delay, reconnect etc usually only 500mS max or so…

      I think this might now be in the USB spec for peer to peer, worth a look and
      I think the detail also comes up in the usbview utility either .com or .exe

      Cheers :-)

      Report comment
      Reply

      1. when USB first came out you couldnt just connect two Hosts to each other. USB OTG lets you switch between host/device modes, but that came out with USB 2.0.
        There were special USB link cables for connecting PCs directly, but they acted as USB device from both ends, and required additional driver/software.

        Report comment
        Reply

  8. Easiest way to reverse Windows drivers for Linux is to have a Linux box and on top of that a VirtualBox. Use the USB device inside of the VirutalBox with windows and use usbmon to monitor all the Packages. Normaly all devices confirm to the USB standard so that you only must care about the package Level and not the levels below. usbmon has a binary interface with it you can dump the packages. After dumping you can write a basic driver to replay the dump. And as soon as the USB device responds you can start to reverse the protocol.

    Report comment
    Reply

Leave a Reply

Please be kind and respectful to help make the comments section excellent. (Comment Policy)

This site uses Akismet to reduce spam. Learn how your comment data is processed.