Join us on Wednesday, February 26 at noon Pacific for the Hacking USB Hack Chat with Kate Temkin!
For all its aggravating idiosyncrasies, the Universal Serial Bus has been a game-changer in peripheral connections for nearly a quarter of a century now. What was once simply a means to connect a mouse and a keyboard to a computer has been extended and enhanced into something so much more than its original designers intended. The flexibility that led to these innovative uses for USB also led to its ubiquity, with some form of the connector sprouting from nearly every imaginable device.
Kate Temkin is well-versed in the intricacies of the Universal Serial Bus. As a software lead for Great Scott Gadgets, Kate has developed software and firmware for GSG’s products, like GreatFET and HackRF. Kate also contributes to and maintains a number of open-source projects, including the FaceDancer project. And when she’s not busy with all of this, she can be found sharing her deep knowledge with USB security training courses, where she shows how USB is vulnerable to attack, and what to do to prevent it.
Join us for the Hacking USB Hack Chat this week, where Kate will discuss anything and everything about USB. Come learn about what the future holds for the USB standard, and what you can do to keep your USB project on track.
Our Hack Chats are live community events in the Hackaday.io Hack Chat group messaging. This week we’ll be sitting down on Wednesday, February 26 at 12:00 PM Pacific time. If time zones have got you down, we have a handy time zone converter.
Click that speech bubble to the right, and you’ll be taken directly to the Hack Chat group on Hackaday.io. You don’t have to wait until Wednesday; join whenever you want and you can see what the community is talking about.
“For all its aggravating idiosyncrasies, the Universal Serial Bus has been a game-changer in peripheral connections for nearly a quarter of a century now. ”
A little more open in it’s early years would have helped.
Heh, info was very sparse at all levels, I imagine most systems integrators has a “WTF is that???” moment when the first 5 pin headers turned up on socket 7 motherboards, and the manuals, might have named it or given the acronym but did not give you a clue what it did. Was probably some months later when the ATX board samples came in when they found out what the socket looked like. Gradually though the rumor mill started that eventually you’d be able to plug some “cool stuff” into it, but meanwhile if you wanted compatibility you made sure you bought a PS/2 mouse or keyboard, a parallel port webcam and a RS232 external modem. Finally, late 90s things started to appear.
It’s “killer app” was probably flash memory drives starting to appear, even at a paltry 16MB or so they were more handy than a stack of floppies. So IMO, it barely clung to life the first 5 years and has only being doing a solid job of work for the last 20.
Judging from their website I’m guessing the answer is, “No”, but does GSG have anything to do with the Great Scott! YT channel?
I was wondering the same thing, but I doubt it. Too bad….
Great Scott Gadgets is Mike Ossmann’s company, that basically brought capable SDR tools to hackers. While I like the GS youtube channel too, GSG is on an entirely different level.
And they both were inspired by Doc Brown’s cliche tagline from Back to the Future, FWIW.
If you can wrap your head around all that descriptor thing and the transactions between device and host, USB is quite awesome. And there are some interesting things hidden in its specification. For example in HID descriptors specification for USB one can find a descriptor for a flying carpet controller. Now all we need is a flying carpet simulator…
youtube, miwH5u4_CiE
Look carefully at the carpet itself, 25 linear actuators on top of a large hexapod. The guys who built it narrowly missed an award from the Visual Effects Society last month
I have always hated USB. It’s a shitty, shitty system for what it is. It’s probably one of the more intense opinions I have when it comes to embedded development.
First, it requires custom device drivers for almost any peripheral. That’s insanely asinine. Why they couldn’t have sensible userspace interfaces with a set of standard communication APIs for different use cases is beyond me. How many OSes and VERSIONS of OSes do you have to support exactly? It’s ridiculous.
Second, they tried to discourage USB-to-serial for a long time to force hardware developers to develop “proper” custom device drivers. They could have solved this by providing a standard serial device interface and API… but no… we had to have multiple competing incompatible third party solutions before a more standard solution finally came around. It uses COM ports and still sucks. “What, what port did my device enumerate as on this PC?” “Is that MY FTDI-based device or someone else’s?”
Third, the chipsets suck. Instead of just pushing the handling of device and interface descriptors and device negotiation into registers and internal state machines… it’s left to the hardware manufacturer to implement a large module of confusing crap just to get their device to enumerate and communicate. Usually, that involves taking some chipset vendor’s REALLY crappy example project and trying to work out how to make it work for your use case. You’re left with a large set of files that serve no purpose but to manage the USB connection. Seriously, how many different barely-functional USB example projects have you had to start with over the years to implement USB in your product? It’s crazy.
Fourth, let’s not forget that the USB association wants money every year for the privilege of receiving a vendor ID from them and being allowed to use their pathetic IP.
USB is shit. Sure, it’s halfway decent for end users if all you want is a HID device or mass storage device of some kind. It has ALWAYS sucked for device manufacturers. ALWAYS.
It could have been only marginally more difficult to work with than UARTs. Instead, it was a huge obstacle to getting your product out there for who knows how many device manufacturers.
Well said. At low-level, it’s a nightmare. And proprietary crap to boot.
If your USB serial port chip has an unique serial# in the descriptor, then windows always assign it the same com port (unless there is a conflict).
There are lots of standard APIs.
Some devices use them.
In the old days, as a Linux user, it was necessary to know which ones were generic, and to buy those ones. So I put the blame on the user if their devices require custom drivers.
If you only buy shit USB devices, then USB will appear to be shit.
When I’m writing my own firmware though, I can just use a standard interface.
The problem of vendor IDs is not that easy to solve, except that you can use an abandoned ID if you don’t care. There is a limited amount of bits for IDs, if there wasn’t a gatekeeper then the field would be a useless form of global memory.
I took one of MicroChip’s courses when they rolled out PICs that could implement USB. It certainly was a lot to take in, but it seemed logical and doable. I liked that there were several standard devices and APIs (eg HID) that would possibly meet the majority of device uses, and MicroChip would even let you use their vendor ID for small run projects using PICs.
As a user… it’s been great! Who could say otherwise? USB anything, plug it into a PC, it works. Or maybe you have to follow instructions and run the CD-ROM first…
So, I’m not completely getting the hate. If a company’s big enough to be doing a custom USB implementation with their own vendor ID, they should be big enough to either have an in-house USB expert, or hire a USB consultant.
USB-CDC class includes standard USB to RS-232 interface descriptor. This means that OS should support it without a need for additional drivers. And there are plenty of standard classes and subclasses to cover a wide variety of devices, that should be naively supported by USB compliant OS. But if you want to use non-standard functions, then you need non-standard driver and API. Often vendors do it to add functions to their devices not covered by standard…
Also there are plenty of hardware USB controllers embedded either in separate chips or in microcontrollers. For example PIC18F45K50, which I use from time to time, has USB hardware. There is no hardware state machine, or it’s very simple and limited to parsing low-level communications because of the number of supported classes in USB specification. There can’t be one state machine to cover them all, so you must implement your own. Sadly, there are not many examples and tutorials on working with USB – one just have to learn it the hard way…
As for VID/PID, you can usually use VID of your chipset vendor if your project is non-commercial. There are also few companies that let you purchase a PID from them and use it with their VID…
That was supposed to be a reply to the comment above…
Interesting, thanks. I’ve lately been bashing my head against “why come I can’t do a simple USB to serial converter?” and getting nowhere.
I have done a few projects sing USB Vendor Commands and Window code from scratch with usblib. They are not that difficult. It takes far more code to make a USB CDC device and turn a perfectly packatized protocol back to a characters based interface only to remake a DIY protocol over it to talk to your device.
I am not surprised at not encouraging USB serial port devices by the powers in charge.
USB at the device side suffers from design by committee as it tries to a whole lot of different things to please a lot of people from different groups. The HID classes is a big mess as sometime you want to be 2 or more devices to fit their API support on he PC.
Ok. I just read the transcript and from it learned of the existence of webusb.
And I must say… WTF?!?!?
Let’s see if I get this right.
The idea is that writing drivers for multiple platforms is burdensome to developers and installing them is difficult or even scary to users. So instead the driver will be replaced with a web page that the user must go to to operate his/her device.
This sounds awful!
First, the obvious security concerns with websites accessing hardware directly.
Then, it doesn’t work offline. While working offline is a decreasingly important issue it still seems like a poor design choice.
Worst of all however is that any device depending on it becomes worthless trash just (to most non-hacker users) just as soon as the company drops support.
Everything becomes landfill. This is exactly the opposite of progress. It is more of what the planet does not need.
Or.. it is just another option. Manufacturers develop a webusb method for accessing their hardware AND traditional drivers. In that case it is an even bigger burden on developers.
But what about consumers? Well.. as vulnerabilities begin to appear and for something like this they surely will there will be more scary warning messages and security limitations applied. Eventually webusb will be at least as difficult and scary as simply inserting the driver disk when the computer asks for it.
Hell, if your typical network security type folks get ahold of this it will end up requiring a college degree just to install (and configure the security permissions) of a simple webcam!