Usb on Colin O'Flynn

USB Triggering & Hacking

Mon, 02 Sep 2019 01:50:39 +0000

This blog post covers several topics that I should have made independent posts about… but anyway. Here we are. It’s September and I should have done this months ago.

Trezor / USB Hacking Updates (Black Hat + WOOT)

I had an earlier blog post with details of the Trezor attack. It turns out this is more generic type of attack than I realized, so I extended this work into a WOOT paper as well. Quickly I thought I should update on that…

ESC SV 2015 - USSSSSB: Talking USB From Python

Tue, 09 Jun 2015 01:51:57 +0000

At ESC 2015 SV I gave a talk on using USB From Python, see the talk description here. This blog post is serving as a placeholder to allow me to update links to software used during the live demo.

For SuperCon 2015, there is a Project Page with these details too. You can also ask questions on the project page.

Download Slides

There is two versions of the slides. Use the SuperCon slides, but I left a copy of the ESC ones here in case you wanted the original for some reason.

USB Inrush Testing

Mon, 02 Mar 2015 23:51:31 +0000

The USB spec has limits on the ‘inrush current’, which is designed to prevent you from having 2000uF of capacitance that must be suddenly charged when your board is plugged into the USB port. The limit works out to around 10uF of capacitance . Your board might have much much more - so you’ll have to switch portions of your board on later with FETs as a soft-start. For the ChipWhisperer-Lite, I naturally switch the FPGA + analog circuitry as to meet the 2.5 mA suspend current. Thus I only have to ensure the 3.3V supply for the SAM3U2C meets the inrush limits, which is a fairly easy task. This blog post describes how I did this testing. The official USB Test Specs for inrush current testing describe the use of the Tektronix TCP202 which is $2000, and I don’t think I’d use again a lot. Thus I’m describing my cheaper/easier method. First, I used a differential probe (part of the ChipWhisperer project, so you can see schematics) to measure the current across a 0.22 ohm shunt resistor. The value was selected as I happened to have one around… you might want a smaller value (0.1 ohm say) even, as the voltage drop across this will reduce the voltage to your device. The differential probe has enough gain to give your scope a fairly clean signal. This shows my test board, where the differential probe is plugged into a simple 2-pin header: From the bottom, you can see where I cut the USB shield to bring the +5V line through the shunt: To calibrate the shunt + gain from the diff-probe, I just used some test loads, where I measure the current flowing through them with a DMM. You can then figure out the equation for converting the scope measurement to a current in amps. Finally, we plug in our actual board. Here I’ve plugged in the ChipWhisperer-Lite prototype. The following figure shows the measurement after I’ve used a math channel in PicoScope to convert the voltage to a current measurement, and I’ve annotated where some of these spikes come from: Saving the data, we can run through the USB Electrical Analysis Tool 2.0 to get a test result. The USB-IF tool assumes your scope saves the files with time in seconds and current in amps. The PicoScope .csv files have time in miliseconds, so you need to import the file into Excel, divide the column by 1000, and save the file again. Finally you should get something like this: Note the inrush charge is > 50mC, but there is an automatic waiver for anything < 150 mC. While the system would be OK due to the waiver, I would prefer to avoid exceeding the 50 mC limit. In this case there’s an easy solution - I can delay the USB enumeration slightly from processor power-on, which limits the inrush to only the charging of the capacitors (which is done by ~15mS). This results in about 47 mC. This means I’ve got about 100 mC of headroom before I exceed the official limits! This extra headroom is needed in case of differences due to my use of the shunt for example. In addition, I should be adjusting the soft-start FET gate resistor to reduce the size of that huge soft-start spike. Ideally the capacitor charging shouldn’t draw more than the 500mA I claim when I enumerate, so that’s a little out of spec as-is! If I don’t want to change hardware I could consider using PWM on the FET gate even…

Making a USB-HID Keyboard Encoder Board for PicoScope

Sun, 05 Jan 2014 01:46:00 +0000

Ever wanted to control something from a knobby-looking USB peripheral? In this example I wanted to control the PicoScope software from a bunch of encoders mounted on a USB peripheral:

Quit wasting time debugging USB: Using TotalPhase Triggers

Mon, 29 Apr 2013 01:52:00 +0000

This blog post might seem commercial… but I have no connection to TotalPhase. I’ve used their Beagle 480 USB analyser for some time, and before that have used a variety of other solutions (mostly SW-based), so have some idea what other options are out there. It’s worth noting that they seem to give free updates forever. When I first used the Beagle 480 it could dissect mass storage & HID I think. Since then they’ve added almost every class possible… hell you can even do stuff like sniff a USB-Ethernet device, and pass the frames to Wireshark for IP-layer decoding. Total Phase has added tons of features in the last 4-5 years I’ve used this device, and they’ve all been freely available and usable with my device. So why do I think other debuggers are a waste of time? Simply: the ability to trigger in/out of the device. Check out this video for more: I also wrote about some of this in an article in Circuit Cellar, see The CC Webstore if you want to check that out, but the part I talk about debugging with the 480 is only a few paragraphs. Basically you can do stuff like the following:

Split Ground Plane: Example of failing high-speed signals

Sat, 06 Apr 2013 01:16:00 +0000

I’ve got a SASEBO-W board, which has a FPGA & a FT2232H for high-speed USB comms. I was seeing errors on the high-speed USB device, and couldn’t figure out why:

Power Split

The SASEBO-W is a multi-purpose board including a Xilinx LX150 Spartan 6 FPGA and a FTDI FT2232H USB interface. One use of the board is for measuring the power consumption of the FPGA and using that power consumption to perform power analysis attacks. I believe for this reason the ground planes are split, to facilitate making those measurements. This split plane is joined through a common-mode choke. To use the high-speed USB interface it requires passing signals across a split in the plane – something very undesirable. The following figure shows what the ground currents for these signals would be. The signals are running on a 60 MHz clock if using the fastest available FT2232H mode. A measurement of the potential difference between the two planes (done at CN3) shows the following figure. This is due to the 60 MHz clock being driven from the FT2232H to the FPGA, there was no data being transferred in this image. Note that the FPGA I/O interface is 2.5V, meaning that signals being sent from the FPGA to the FT2232H will already have a reduced amplitude compared to the 3.3V I/O voltage. There should be enough headroom in practice such this interface works OK, and the FPGA has 3.3V tolerant I/Os. The following figure shows a data bus line measured at the FT2232H in blue, the horizontal markers are set at 2.0V and 0.8V respectively, which are the limits for logic High/Low at the FT2232H. Note that due to this ground noise the signal is degraded to the point of crossing this threshold! If we mount a jumper on CN3 this shorts the two ground planes together. This isn’t an ideal low-impedance path, but it will make an improvement. In the above figure the yellow line is with this jumper mounted. The following figure shows the voltage difference between the two planes with such a jumper mounted. Compare to the earlier figure where the peak-to-peak voltage was almost 500mV! Monitoring both the ground difference and bus lines show when the line switch there is still some extra noise contributed – the green line below (NB: note scale differs from above figure) shows a still fair amount of bounce during the transition, but in practice the USB communication seems reliable between the FT2232H and the FPGA. So, that’s why you cannot cross high-speed traces across split planes!

Making AT90USBKEY Run on 5V (Easy Way)

Sat, 20 Aug 2011 14:01:00 +0000

I needed to use my AT90USBKEY at higher than 3.3V for ADC input purposes. It’s not documented in the manual, but the schematic shows they anticipated this. You can easily convert the AT90USBKEY to run on 5V with a few changes. The changes needed are:

Remove resistor R20 (0-ohm resistor)
Remove resistor R16 (0-ohm resistor)
Place a 0-ohm resistor on pads at R21 (move R16 or R20)

That’s it! The DataFLASH chip’s VCC needs to be in the 2.5-3.6V range, but with those changes it is still powered by the 3.3V regulator. Thus you don’t need to remove the DataFLASH chips. The DataFLASH devices have 5V tolerant I/O, so even though your MCU is running at 5V, it won’t fry the DataFLASH. Note the logic high levels of the DataFLASH may not be sufficient to actually work with the MCU, since it’s logic high will only be using 3.3V logic.