41–48 of 48 posts
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.
Earlier quoted context omitted.
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
Earlier quoted context omitted.
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; mig…
> I won't get deep on describing all of the facts, since that's what Wikipedia is good at Sigh. So many links, so much reading, and not one to the USB spec (that I found by skimming and searching). It's not just this article, but seemingly every 'deep dive does it'. Why do people read everything on the Internet, no matter the source and quality, but skip (what is usually) the best, most important source?
To be fair, specs and standards generally aren't written as introductions, so they're kind of hard to make sense of when starting from zero. USB, with its infernal descriptors and endpoints, benefits mightily from third-party explanations.
Most of the time when I want to hack on something, a super high level abstraction is more than sufficient for my needs (eg. don't need to understand the inner workings of a CPU if all I need is an API). But then there are those times when the spec, in all it's verbose rawness, is the perfect tool for the job.
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?
The hardware side of things is the area that interests me more though, if you want to get into higher speeds than can be handled in software only, or if you want to start doing weird/interesting things in the 'emulate' side of it (not just capturing (eg. facedancer). Coming from a security perspective, those sorts of tools are invaluable for getting to some of the depths that I may want to reach.
Earlier quoted context omitted.
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 cac…
Not saying this isn't happening, but it seems not to be.
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…
Earlier quoted context omitted.
Then there's a patched version that does not cause the bluescreen. Great! Except that you can no longer install unsigned drivers on Windows 10 by putting your machine into test mode. Patching out the signing check itself may not be too difficult... and if the file the signing check is in is also signed and verified by something else, then patch that ... it's patches all the way down. I remember doing this with Vista…
Yeah but I want to distribute the result to users and patching driver signing checks out of their Windows installs is not an option. You are right though.