Reverse engineering USB devices 101: Understand your target

We’ve learned USB basics and now we are ready to open our USB sniffer and dig into that device we want to reverse but trying to understand what we want to reverse before reversing leads to an easier and less painful work. So first we need to ask ourselves.

How does our targeted device work from a high level perspective?
Understanding the higher level functionality of our targeted device is necessary to successfully reverse it and can provide hints about the inner implementation. In this tutorial our target device is the infamous CH340 chipset. A chipset that bridges the gap between USB computer and serial-based hardware.

What’s a serial communication?
Serial communication is rather broad term but in its inner core means that data is sent one bit at a time. There are tons of different protocols like the venerable RS232, the widely used in the automotive industry CAN bus and even military ones like MIL-STD-1553.

Serial vs parallel

CH340 chipset is one of the multiples USB to serial converters made to add compatibility between PC with USB ports and old serial peripherals. It is not based in any particular protocol so it would be possible to implement different serial protocols using it.

What are the common serial features
There are a lot of different signals in serial protocols but for the sake of simplicity this is the core of a serial communication.
– RXD pin where data is received.
– TXD pin where data is sent.
– Flow control pins to control wether our devices are ready or not ready to send and receive information. Typical signals are RTS/CTS and DSR/DTR

How a USB device would emulate a serial port?
Serial communications need two pin for sending and receiving data. That translates well to USB endpoints so we will probably find two USB IN/OUT endpoints. There is more than one way to send data in USB. What would be the best USB transfer protocol to emulate a serial port? if we look back to the previous post we have:

– Control transfers for setting and reading configuration.
– Bulk transfers to perform large data transactions where data integrity must be guaranteed.
– Iso transfers where what matters is delivery rate and latency.
– Int transfers for shorts bursts of data.

We can easily discard both control and int transfers. Both bulk and iso transfers would be ok for implementing a serial port. ISO endpoints would guarantee faster rates at the expenses of no error correction (not implemented by default in a serial communication either). Bulk transfers don’t guarantee as much speed but data integrity is assured. What transfer a manufacturer would select?
Probably bulk transfers. Serial communications are much slower than bulk transfers so the choice is clear and using bulk transfers you gain error correction. The option is clear.

Serial ports must be configured correctly before sending and receiving data. Usual values are:

– Baud rate.
– Parity.
– Data bits.
– Stop bits.
– Flow control on/off

The CH340 chipset must know the configuration to correctly read RXD and TXD pin voltages and send them through the bulk endpoint. We must assume that these values are sent through control transfers.

There are two kinds of flow control:
– Hardware based: Some lines are asserted raising or lowering the voltage. This is commonly known as out-band signaling because the signaling comes from a different channel than the data.
– Software based: Some bytes are send to indicate whether the flow must stop or resume. This is obviously in-band signaling.

Hardware flow control is what can cause us some headaches here. The signaling goes out of the band so, if we want to be close to the emulated system, we would need a new endpoint acting as flow control. Latency could be very important here. So I would choose between int or iso transfers.
But it could be implemented in a different way. Maybe there is a control transfer to ask for the line status, maybe some packets are sent through the bulk endpoints at fixed intervals with data about the flow control level.

We just outlined what we probably will find in the next step:
– (Very probable) Two Bulk endpoints (IN/OUT) for exchanging data.
– (Very probable)A set of control transfers to configure baud rate, parity, data bits, stop bits and flow control modes.
– (Maybe) A INT or ISO endpoint for emulating hardware flow control.
– (Maybe) A control transfer to check flow control signaling. This approach would require polling at fixed rate.
– (Maybe) Packets sent alongside data with information about flow control.

We now have some understanding of our target. It will help us greatly when surfing through multiple USB calls but we will see that in the last post.

Reverse engineering USB devices 101: Introduction

Reverse engineering USB devices 101: USB Basics


2 thoughts on “Reverse engineering USB devices 101: Understand your target

  1. Hello … you did a beautiful job … I but ‘unfortunately are looking for a client program that you can connect remotely to a “virtual serial port” type “serial2net”, or other.
    Where can I get this ???
    I hope to be able to explain,

  2. Hey
    I have been following your library to connect android to arduino using USB. I am facing a null pointer exception error while writing to the Serial port. I hope you can guide me..


Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s