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 that the hardware is the same, regardless of region, and the firmware just implements a dark pattern to limit functionality (perhaps to avoid additional FCC certifications, support incidents, etc.).
Anyway, I've spent a few nights extracting the firmware from other regions, found a great presentation where the company details the hardware and platform, and discovered that the audio capabilities of the hardware for the prosumer device approach that of the professional device (higher sampling frequencies and resolution during recording).
My hope was to be able to flash the device with a modified file system that enabled the features, but ran into the firmware appearing to be encrypted, but potentially decrypted on the host before being pushed to the device. I've been decompiling the drivers to see if I could dump keys or the decrypted payloads, but also thought about sniffing the USB I/O and dumping that way. It looks like this is a nice intro to help me on my way.
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 reach a larger total customer pool than by only offering the more expensive variant.
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?
Absolutely; and pleasing an audience of one (me) isn't a great business move. Thanks for your exceptional effort.
> I like to document the path I took
I think people learn more from this kind of inductive approach.
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.
Sometimes, but I often find them to be pretty good, and if I look at third party sources first, I usually wish I'd come to the spec much sooner in the process; the actual spec tends to make most third party sources redundant or plainly erroneous.
But of course, not all specs are equal; some are unreadable or poor introductions.
unfortunately, it seems that the pre-req article is down, so here's the cached copy: http://webcache.googleusercontent.com/search?q=cache:https:/...
To elaborate on this section:
http://devalias.net/devalias/2018/05/13/usb-reverse-engineer...
- There are two versions of the USB/IP drivers. The initial version has a bug where disconnection of a device causes a blue screen. This version is signed by ReactOS, and so you can install this version's drivers without needing to jump through any hoops under Windows. Then there's a patched version that does not cause the bluescreen. Great! Except that this version is not signed by ReactOS. Okay, maybe we can get ReactOS to sign it -- nope, they discontinued their driver signing program because of new regulations by Microsoft put in place within the last year (https://www.reactos.org/wiki/Driver_Signing). You can also no longer install unsigned drivers on Windows 10 by putting your machine into test mode. This capability was silently removed by Microsoft within the last year. You can still put your device into test mode, but the driver signing checker will still block installation. This is a damn shame because USB/IP is a great project, and it even has a signed driver but the patched version of the driver is not signed. This is infinitely frustrating.
- Microsoft used to have this perfect thing called UDE (https://docs.microsoft.com/en-us/windows-hardware/drivers/us...). They removed it last year.
- Kernel mode drivers for Windows now have to go through this signing process (https://docs.microsoft.com/en-us/windows-hardware/drivers/in...) as of last year. As mentioned before, this is why ReactOS discontinued their driver signing program as it's too difficult to meet these new requirements.
I have read every forum post, stack overflow post, Windows technical docs, everything I could possibly find for a way to do stable, pure software emulation of USB devices on Windows. They all evaporated within the last year or two. So frustrating as I really really want to build out something but there's simply no way to do it.
At this point I have resorted to attempting to hook every Windows system call related to USB device initialization and spoofing them but have been met with no success thus far.
I should note that the reason I want to do this in software is because I want to distribute the end result to a relatively large amount of potential users as GPL'd software. For this reason hardware emulation or patching / downgrading Windows isn't an option sadly.
Does anyone know of something I missed?
I have before me two tablets. Both running W10 home, both using the same Intel Atom internals. But apparently one is running a the 32-bit version and the other the 64-bit version.
And lo and behold, the 32-bit version has a problem with the latest sd reader driver that MS pushes, so that it fails to see the inserted card. But the very same card, and the very same driver version, and the very same windows updates, works just fine with 64-bit.
At this point in time i wonder if i should either go back to nature or switch every PC-like product in this house to a BSD, because F Apple for their silo, F MS for their back and forth Q&A, and F the Linux "community" with their constant music chair-ing.
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 a long time ago. When the signing check fails it fails with a very distinctive error code/message, so I searched for that in all system files and went "down the rabbit hole" of patching out a few checks. I don't remember the details but there was less than a dozen bytes that needed to be changed. Previous cracking experience certainly helps. ;-)
Would running a VM on top of windows and passing the device through to that be an option given your use-case? Could then run *nix or similar in there, and avoid the windows driver hell.
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.
