
Writing userspace USB drivers for abandoned devices - signa11
https://blog.benjojo.co.uk/post/userspace-usb-drivers
======
jason0597
It's things like these that sometimes make me think of all those businesses
that rely on some ancient Windows XP machine because it's the only thing that
supports the proprietary drivers for the engineering machine they bought
nearly 2 decades ago for hundreds of thousands of pounds. If instead the
drivers were open source (and the relevant controller software for that
machine), they could more easily move over to a more recent operating system
that doesn't run the risk of being infected with some virus (think Wannacry)

I imagine also how more difficult it would be for someone to reverse engineer
the drivers for something a lot more complex than a VGA-to-webcam box.

~~~
ChuckNorris89
Well yes, open source firmware and drivers would be cool but for most
companies that's part of their proprietary IP and they think that making it
open would make their product easier to copy/exploit by competitors. Since it
cost them lots of time and money to develop there's no way your gonna convince
management to just make it open unless you're some stinking rich FAANG Co. and
those HW product sales are not your main source of income.

Just look how locked down Broadcom documentation and even datasheets are.
Everything is under NDA.

HW business make money by selling more HW so making you buy their latest
product just for the latest updates even though the 10 year old one still does
the job is a viable business model for them.

Source: I worked in the hw industry and it's how they think.

~~~
baroffoos
AMD is a company that has largely gone from proprietary to open source and
without looking at their financials I think it seems to have been going really
well for them. AMD GPUs just work out of the box on linux without having to
install anything so I and almost every linux gamer buys an AMD card now even
if it isn't the best performance per $

~~~
kbenson
Didn't that strategy start before ATI was bought by AMD? How much of that
strategy is just following through on what they were doing at ATI before and
how much is it is in line with what AMD does in general?

~~~
baroffoos
When I was buying gpus around 2013 there was only a proprietary AMD driver on
linux.

~~~
wtallis
I'm really curious how you came to believe that, given that AMD started
supporting the development of open source GPU drivers in 2007 by collaborating
with Novell/SuSE and releasing low-level documentation. By 2013 the open-
source AMD GPU drivers were far better than any reverse-engineered NVidia
driver has ever been, and only two years later AMD started the process of
deprecating part of their proprietary AMD driver in favor of a hybrid approach
(proprietary userspace module, open-source kernel driver).

~~~
baroffoos
I just looked in to this and it looks like what I am thinking of is the AMDGPU
driver which wikipedia says released in 2015. I'm not sure what the driver you
are talking about is or what the difference between the AMDGPU driver and
yours is. I just remember in 2013 people saying nvidia was best for linux use
and then with the AMDGPU driver people saying AMD now is.

~~~
pmjordan
The AMDGPU driver was the first one where the "main" consumer driver was the
FOSS one. Prior to this, "fglrx" was for many years the fully-featured,
proprietary driver, intended for both professional purposes where certified
OpenGL drivers are needed, and for consumers. The "radeon" open source drivers
tended to lag behind in both hardware support, features, and performance.
Initially, they were largely a community effort, but then AMD started
publishing some GPU documentation, and then also put more of its own resources
into developing the FOSS driver.

The UX of the "fglrx" drivers tended to be pretty awful, all told; typically
worse than nvidia's proprietary drivers, so they were wildly unpopular among
users. The performance gap eventually started closing, to the extent that some
games/apps would be faster on the "radeon" drivers, and some on "fglrx".

Eventually, AMD switched to the AMDGPU model, where the kernel driver is
always FOSS (and part of the upstream kernel), and there is the FOSS userland
driver as part of Mesa for consumers, and a proprietary certified OpenGL
driver for workstation users.

(I believe Valve also had a hand in this somewhere along the way - they were
interested in shipping Steam Machines/SteamOS and understandably were keen on
having a stable and fast graphics stack and so contributed to Mesa.)

~~~
baroffoos
Thanks for the info

>The UX of the "fglrx" drivers tended to be pretty awful, all told; typically
worse than nvidia's proprietary drivers, so they were wildly unpopular among
users.

This is my memory of the time. Both options being undesirable and proprietary
but nvidia's at least working better.

------
djsumdog
I would have given up long before the point this person got to. This is pretty
damn amazing, and could gain a little bit of life from these old, closed,
binary blob, everything in software devices. Tons of kudos for doing this.

On a side note, I wish there was a more standard way to deal with Linux kernel
modules. The ABI incompatibility leaves a ton of dead old hardware out there
for non-maintained kernels. In an ideal world without tons of binary blobs and
.o files out there; this wouldn't matter. You could recompile everything for
the latest version.

You might have to fill in some missing symbols or swap out deprecated
functions, but it'd be considerably easier than this. That was the ideal
behind open source; that we could always be able to figure out how our stuff
works, and it seems like today we only have open source middle ware, and so
much close source stuff build on top of open source stuff.

------
xg15
Hang on, did he just buy essentially a freely reprogrammable FPGA with built-
in RAM, A/D converter and USB support - for $20? Seems to me, you could do a
lot more with those devices, now that the wire protocol is known.

(Edit) It doesn't appear that he decoded the bitstream format though, so some
more work would be needed before you could use it as a general-purpose FPGA.

~~~
jack12
Yeah, a 16K Spartan 6, 64MBytes of DDR3 RAM, and an FX2LP USB High-Speed
controller is a pretty terrific repurposed FPGA dev board in the vein of the
chubby75 or panologic, even if the high-speed ADC turns out to have too many
limitations / too weird signal conditioning (i.e. is too VGA-focused) to be
very useful (but VGA probably at least means a pair of I2C pins is exposed on
the DSUB-15, right?). Considering the FX2LP is already wired up to load the
bitstream to the FPGA, and expects to on every power-up, that's a huge bonus
for a dev board. Even if the binary blob of FX2LP firmware provided in the
manufacturer's drivers does checksums, signature checks, etc. to make changing
the bitstream data difficult, it would be pretty simple to write a new
firmware to allow uploading of any custom bitstream (see: fx2lib), since it's
such a well-known and widely-hacked chip -- maybe you can even manage to trick
Xilin's ISE into believing it's a real Xilinx "USB Platform Cable" (FPGA JTAG
programmer) since at least some of them use an FX2 for their USB interface.
With a generic bitstream uploader utility for the FX2 you wouldn't even need
to deal with any hardware modifications or even need to buy and connect a JTAG
programmer if you were just starting out. And with everything being uploaded
on every reset of the devboard, you don't have to worry about bricking
anything either, since you just power-cycle the devboard to bring the
programmer AND FPGA back to their default waiting-for-firmware/"rescue" mode.

But while the article says he got a lot of them (at least 3 from the photo)
for $25 total, it looks like they're more typically ~$50+S/H each on ebay,
which is less exciting.

The same company seems to have moved on to 'av.io'-branded USB3 devices now,
which from a quick glance/binwalk of the downloadable firmware package
(inspired by this article) appears to have FX3 USB Super-Speed controllers,
and Spartan FPGAs. But it's designed to store the FX3 firmware and FPGA
bitstream on the device itself (to allow it to boot up as a UVC webcam with no
drivers required on the host, like this article was hoping would be the case
for the older device), so it would require a bit more reverse engineering to
figure out how to kick the FX3 into firmware update mode to replace the FX3
firmware with a custom bitstream uploader. But it's a ton more expensive, and
who knows what generation and size of FPGA or how much and what sort of memory
it would have.

~~~
wott
> Yeah, a 16K Spartan 6, 64MBytes of DDR3 RAM, and an FX2LP USB High-Speed
> controller

The last one alone, CY7C68013(A) has always been an expensive chip (like $10 a
piece if you just want a few).

What is funny is that I wasn't aware it existed in QFP-56 package, it is not
supposed to exist :-)

~~~
andrewcchen
It's in a QFN not QFP package

~~~
ip26
QFNoWay

Worst package I've had the pleasure of hand mounting.

~~~
namibj
It's quite nice though when you consider it's really small without requiring
difficult BGA mounting (QFN reflow is about as hard as QFP reflow).

It also provides superior electrical properties like low-inductance.

~~~
xg15
More IC manufacturers with hobbyist buyers should adopt "QFN - At Least It's
Not BGA" as a slogan.

------
phendrenad2
Reminds me of this: [https://www.theinquirer.net/inquirer/news/1047633/one-
writes...](https://www.theinquirer.net/inquirer/news/1047633/one-writes-linux-
drivers-235-usb-webcams) ("One man writes Linux drivers for 235 USB webcams")

~~~
ChuckNorris89
Wow, cool thanks for sharing. Very interesting read.

------
codeulike
Proper hacking.

That diagonally skewed image is familiar to me from old game writing days when
sprites were written straight to screen memory - you soon learn that if it
comes out skewed, you've probably got an off-by-one bug on the horizontals.

------
ChuckMcM
FWIW, I haven't done a lot of reverse engineering but I have written code to
drive the USB peripherals for a few microcontrollers in the ST and NXP series
and the techniques discussed in the article are just as applicable when trying
to debug what the heck is going on in your USB code. I always get something
interesting out of them.

------
rburhum
The device itself is not that interesting, but I just love the level of detail
that describes the reverse engineering process. Excellent blog post!

~~~
moftz
It seems like the hardware could be repurposed to be a multichannel DAQ or
even a VHF SDR. It's a neat device considering how cheap it is.

------
tux3
I coincidentally just finished writing some userspace libusb code for the
first time today!

Nothing as impressive or interesting as TFA, just enough to let the thing boot
on Linux to the point where proprietary half-working drivers can take over.
It'd be a stretch to call my epson scanner abandoned hardware, but considering
the quality of official drivers, only a small one.

------
hamburglar
Today I learned that you can use wireshark to analyze USB packets. Neat.
Besides the cool-hack-factor, this kind of article is especially great when it
teaches you something.

------
aportnoy
How does one learn how to write device drivers under Linux?

~~~
jsharf
Google search "lkmpg pdf"

It's part of tldp (also google searchable)

~~~
pjc50
> "lkmpg pdf"

I wonder how someone from the outside is supposed to know that's the magic
string to google.

~~~
blotter_paper
One poorly understood school of google-fu is the art of googling for the words
you want to google for.

The first result for the utterly mundane, plain English "how to program linux
drivers" brings me to this tutorial: [https://www.apriorit.com/dev-
blog/195-simple-driver-for-linu...](https://www.apriorit.com/dev-
blog/195-simple-driver-for-linux-os)

Linked from that tutorial is a hypertext version of the content in that PDF:
[http://tldp.org/LDP/lkmpg/2.6/html/lkmpg.html](http://tldp.org/LDP/lkmpg/2.6/html/lkmpg.html)

~~~
eximius
> One poorly understood school of google-fu is the art of googling for the
> words you want to google for.

That's a beautiful way to put it. You've distilled into one sentence a skill
that I've been asked about many, many times (as the token IT guy).

------
tombert
I know virtually nothing of low-level programming, so bare with me; to a lay
person, can someone explain why drivers are _every_ closed source? Isn't a
driver inherently a loss-leader for some kind of hardware product, and
wouldn't it be better for the manufacturer to have it open-source so that more
people could contribute to it?

I'm not asking this passive-aggressively, if someone knows the answer to this
I'd really like to hear it.

~~~
hatsubai
Sometimes, it just doesn't make sense. For example, I write and maintain the
Linux kernel modules for one of the largest, most popular, and most powerful
land vehicles in the world. It wouldn't make sense for us to release these to
the open source community because it requires specific hardware that we make,
specific FPGA firmware that we interface with, and it will only work with
specific software we make. So there's at least one case where it wouldn't make
sense to release this, and that's not even getting into the security aspect of
things.

------
Touche
This is the kind of article that keeps me coming back to HN.

------
joewee
I have a few devices with no public drivers of any kind. Thinking about how to
develop drivers on Linux, I’m guessing I should lookup into the chipsets used
on the board and see if those companies have drivers I can use as a starting
point?

~~~
nwallin
Does it have Windows drivers? If it does, you can set up a VM, set the device
as passthrough, and sniff the traffic to it. Then it's not really any
different than reverse engineering a network protocol or file format.

What are they, out of curiosity?

------
Nzen
tl;dr Ben Cox bought a vga in => webcam out device that its parent company
hadn't updated the linux drivers in a while. This details his journey of using
tcpdump, et al, to analyze the sent packets. Eventually, he simulates the usb
firmware and fpga download such that he can use the device. A quick, engaging
read that was an appropriate level for this non C programmer.

Looking through his archive, I recognize his bgp battleship post from last
year on HN.

~~~
jsharf
This seems pretty formal/professional for an HN comment. Is there some reason
you're writing summaries of HN posts with this degree of effort?

Also, thanks.

~~~
Nzen
It's one of the contexts in which I'm willing to be the change I want to see.

It's disappointing to click on the comments for a post and no one (especially
the submitter) has told me what I'll learn/experience. And yet, there it was,
four hours old, ten points up and no comments. So I give it a skim and it's
really good. Now I want others to read it. Spending five or so minutes
polishing three sentences is basically free for me and positive sum (unless I
do a bad job).

Cynically, tl;dr submission summaries are how I've chosen to feed the beast
until it grants me downvoting power.

------
jdnenej
The thing I am looking forward to most when I retire is having the time to
fuck around with random projects like this.

------
sulam
BGR instead of RGB seems to be very common in hardware land.

Anyone know why?

~~~
spease
Best answer I found is this:
[https://retrocomputing.stackexchange.com/questions/3023/why-...](https://retrocomputing.stackexchange.com/questions/3023/why-
bgr-color-order)

There was apparently an HN thread as well
[https://news.ycombinator.com/item?id=17808191](https://news.ycombinator.com/item?id=17808191)

------
codedokode
If Linux had stable kernel-to-driver interface, that driver could work today.

~~~
Iolaum
If the driver had been mainlined it would still work today.

[https://www.kernel.org/doc/Documentation/process/stable-
api-...](https://www.kernel.org/doc/Documentation/process/stable-api-
nonsense.rst)

~~~
codedokode
What if the vendor would prefer not to disclose source code? All drivers
cannot be included into the kernel, even if they were, this would be a lot of
code and who is going to maintain it?

This document shows how unfriendly is Linux to third-party code. Either you
contribute into giant monolitic kernel, or your device won't work with next
major kernel release.

> Depending on the version of the C compiler you use, different kernel

> data structures will contain different alignment of structures

That doesn't make sense. How does Microsoft use structures in their API then?

Furthermore, unlike Windows software, you cannot compile Linux kernel with
_any_ compiler except for GCC [1]. It doesn't comply with C standards.

> Depending on what kernel build options you select, a wide range of

> different things can be assumed by the kernel

> \- different structures can contain different fields

That looks like poor design. Why care about non-standard configuration? Let
those who use it solve the problems themselves which would be the true open
source way.

> Linux runs on a wide range of different processor architectures.

> There is no way that binary drivers from one architecture will run

> on another architecture properly.

Supporting i386 is enough. Nobody is going to insert a PCI device into a
smartphone. If there will be new CPU architectures, one can use i386 emulator.

> As a specific examples of this, the in-kernel USB interfaces have

> undergone at least three different reworks over the lifetime of this

> subsystem

They could make 3 versions of API and adapters that would support drivers
written against older versions of API.

I think the real reason is that designing API is hard, and Linux developers
have no interest in this. They care only about server platforms and those
platforms have open-source drivers because they need Linux. Nobody cares that
your USB webcam doesn't work because you don't connect webcam to a server.

I think that Linux could also rely on existing Windows drivers that exist for
almost every device. Linux could provide an environment similar to Windows
kernel, and run those drivers in a sandbox. For many devices, this is the only
sane way to have them working with Linux.

[1] [https://stackoverflow.com/questions/20600497/which-c-
version...](https://stackoverflow.com/questions/20600497/which-c-version-is-
used-in-the-linux-kernel)

------
Yajirobe
How do you learn how to do something like this?

~~~
qiqitori
There are many ways to get somewhere, but here's a general list of things you
have to do:

1) Think for a little bit about what you have got and what you want to do

2) Do research. Has this been done before? Have similar things been done
before? (Usually the answer is yes to either question)

2) Think whether it's theoretically possible to do what you want to do with
the information and parts you have (in this case: there is a working driver
for Linux and Windows, but they're closed-source)

3) Fixing computer things usually involves a lot of debugging (tracing). Will
tracing help us out here? What tracing tools/skills do you have, what tracing
tools/skills would you like to have? Often you'll need to extend the tracing
skills/tools you already have, but normally you don't want to spend too much
time on this. (In this case, we can trace without any specialized equipment --
we just need a virtual machine.)

4) Once you have the appropriate traces, take a good look at them (you'll
probably want some scripting abilities here) and see if you notice any
patterns (e.g. "lots of data after this", "just a little data after this",
"this bit of data is always the same", etc.)

5) If you don't know what to do at this point, maybe go back to the tracing
step

------
droithomme
Fantastic write-up of intense hacker stuff. Thanks, this is good stuff.

