Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

USB Reverse Engineering: Down the Rabbit Hole

devalias.net

Post reply on HN
Print view View original

31–40 of 48 posts

Re: USB Reverse Engineering: Down the Rabbit Hole

#31

Post by lesbaker »

duxup wrote: post #28
jonhohle wrote: post #2

What a weekend find! This is a nice piece in a puzzle I'm trying to solve related to a consumer audio device with upgradeable firmware. The platform of the device is used for both a prosumer audio device, a professional device, as well as other consumer devices. On top of that, the prosumer device appears to have different functionality enabled based on the part of the world you buy the device, but my hypothesis is t…

Reminds me of some popular headphones (I forget the name) that had two models. One was the standard model and one was the pro model. Someone went to repair their headphones and found that the only difference between the two models was some extra foam that was installed to distort the sound bit in the standard model... I wish I could remember who that was.

It was Sennheiser headphones: https://news.ycombinator.com/item?id=2214158

Re: USB Reverse Engineering: Down the Rabbit Hole

#33

Post by red75prime »

gmueckl wrote: post #27
red75prime wrote: post #23

Earlier quoted context omitted.

Putting "#ifdef PROSUMER" or something to this effect into the source code shouldn't be too costly. Disabling existing functionality is easy and it feels like cheating even if it's called "market segmentation".

This is what developers like us tend to think. But consider this: the development cost of the sodtware does not change much in order to create feature reduced versions of most products. But if you are in a small market where the volume of expected sales for the full version of the product can barely lead to proftability, creating a cheaper version for a higher volume market is a sound business strategy. This would no…

I'm not saying that it is not a viable strategy. But it needs to be taken into account that tech-savvy users will not see it as a fair play, and probably will not think twice before making the most of a cheaper version.

Re: USB Reverse Engineering: Down the Rabbit Hole

#34

Post by _xzxj »

ncmncm wrote: post #32

I see so much custom hardware. Can somebody tell me why running the drivers of interest in a virtualbox/qemu image, and logging interaction on the host OS, doesn't do a better job than custom hardware?

I'm not sure why this person listed so much hardware, I've done some USB protocol reversing using a TotalPhase Beagle 480. I think I probably could have done something in software, but the nice thing is the TotalPhase software is a lot like Wireshark -- which I was already familiar with. I wasn't totally familiar with hacking around USB so it made learning how USB worked much easier instead of me just pulling data off the wire and trying to start from scratch.

Re: USB Reverse Engineering: Down the Rabbit Hole

#35

Post by rvense »

ncmncm wrote: post #32

I see so much custom hardware. Can somebody tell me why running the drivers of interest in a virtualbox/qemu image, and logging interaction on the host OS, doesn't do a better job than custom hardware?

Is that possible? I thought vbox et al enabled USB communication by allowing the guest OS drivers to hit the hardware directly.

Re: USB Reverse Engineering: Down the Rabbit Hole

#36

Post by ZirconiumX »

corndoge wrote: post #18
fragmede wrote: post #12

Earlier quoted context omitted.

It's hard to know, as you don't mention what physical USB device you're trying to circumvent, but virtualization has come a long way, especially if you take advantage of PCI pass-through. One approach, then, is to run Linux as the host OS, fake the USB device on Linux (hell, the Linux kernel has USB/IP support), and pass that into a virtualized Windows instance, which will just see a regular USB device.

This is an option I hadn't thought of, but the typical end user won't want to do this or know how as it's a gaming peripheral. I can't be more specific as there are some legal barriers I'm sorting out right now.

Myself and a friend needed to do something somewhat similar to get an emulation/mocking framework[1] for Corsair Utility Engine. Our hack was to run the Windows driver in a VM, run the framework in Linux, then pass through the virtual USB device to Windows.

[1]: https://github.com/ckb-next/fakeyboard

Re: USB Reverse Engineering: Down the Rabbit Hole

#37

Post by dekhn »

teraflop wrote: post #24
digi_owl wrote: post #8

Earlier quoted context omitted.

Sounds like a real classic market segmentation tactic. I recall reading about a oscilloscope or something that had two models, one monochrome and slightly worse performance, one color and slightly better better. Turns out that if you flashed the firmware of the latter onto the former, the performance improved to match the latter's. Basic thing is that by doing this, the marketing people has calculated that they may r…

You might be thinking of the Rigol DS1054Z digital oscilloscope. It's pretty popular with hobbyists because it's an inexpensive entry-level scope that can easily be "unlocked" to act like a much more expensive model, including better-than-advertised bandwidth.

and a full protocol decoder! For $350!

Re: USB Reverse Engineering: Down the Rabbit Hole

#38

Post by fragmede »

corndoge wrote: post #18
fragmede wrote: post #12

Earlier quoted context omitted.

It's hard to know, as you don't mention what physical USB device you're trying to circumvent, but virtualization has come a long way, especially if you take advantage of PCI pass-through. One approach, then, is to run Linux as the host OS, fake the USB device on Linux (hell, the Linux kernel has USB/IP support), and pass that into a virtualized Windows instance, which will just see a regular USB device.

This is an option I hadn't thought of, but the typical end user won't want to do this or know how as it's a gaming peripheral. I can't be more specific as there are some legal barriers I'm sorting out right now.

If it's an input device for Windows games, without revealing the device, why does it have to go through the USB stack? Basically all games on Windows use DirectX, specifically its DirectInput libraries. (It's been a while, so they've probably been renamed, but the point remains that USB isn't necessary for all input devices, though it is up the application as to what it'll take.) Many emulators are more flexible; might take a look there, and if not, there's also Bluetooth - do the fakery in hardware.

Re: USB Reverse Engineering: Down the Rabbit Hole

#39

Post by posterboy »

teraflop wrote: post #24
digi_owl wrote: post #8

Earlier quoted context omitted.

Sounds like a real classic market segmentation tactic. I recall reading about a oscilloscope or something that had two models, one monochrome and slightly worse performance, one color and slightly better better. Turns out that if you flashed the firmware of the latter onto the former, the performance improved to match the latter's. Basic thing is that by doing this, the marketing people has calculated that they may r…

You might be thinking of the Rigol DS1054Z digital oscilloscope. It's pretty popular with hobbyists because it's an inexpensive entry-level scope that can easily be "unlocked" to act like a much more expensive model, including better-than-advertised bandwidth.

I heard the difference might be because testing determines lesser quality builds which then are limited in software to meet the respective specs within a broad error margin. The unlocked ones might work and display but you loose all guarantees on precision. This process is called binning, and is done with many electronic parts, most famously cpus that are binned according to energy efficiency, clock frequency, or cache size.

Of course that doesn't excempt them from attempting price differentiation, e.g. under the veil of this process.

Re: USB Reverse Engineering: Down the Rabbit Hole

#40

Post by jack12 »

_xzxj wrote: post #34
ncmncm wrote: post #32

I see so much custom hardware. Can somebody tell me why running the drivers of interest in a virtualbox/qemu image, and logging interaction on the host OS, doesn't do a better job than custom hardware?

I'm not sure why this person listed so much hardware, I've done some USB protocol reversing using a TotalPhase Beagle 480. I think I probably could have done something in software, but the nice thing is the TotalPhase software is a lot like Wireshark -- which I was already familiar with. I wasn't totally familiar with hacking around USB so it made learning how USB worked much easier instead of me just pulling data of…

With the software-only approach (e.g. usbmon), the interface is even more like Wireshark :) https://wiki.wireshark.org/CaptureSetup/USB
Post reply on HN