My audio interface has SSH enabled by default

Or maybe there's two people in the room, each on different channels altogether. In this case the other person is just uncorrelated background noise instead of a persistent echo.

Or, in-context: There's two people in the same room, both talking on the same Discord channel.

Anyway, audio routing is useful. Being able to route audio with two different PCs is a pretty neat feature of the rodecaster.

A lot of consumer electronics need to be FCC compliant, which involves a process of proving that the device doesn't emit too much of the wrong EMI/RFI in the wrong places.

And safety-wise, we use tend to use ETL, UL, and CSA for testing. These are third-party Nationally Recognized Testing Labs, and their own marks are used on devices they approve. But they're only really concerned about the safety of a product. In very broad strokes: If the device is proven to be unlikely-enough to burn a house down or cause electrical shock to humans, then it gets approved.

CE is a whole different thing. No government body in the USA requires or respects a CE mark on consumer goods; that mark doesn't hold any legal weight here.

Whether good or bad, CE is just not how we roll on this side of the pond.

(Of course, none of that means that laws in the EU don't affect product availability and features here. Globalization be that way sometimes.)

But I don't think anyone here would care about that. It's not such an unusual arrangement. I guess it's kind of impressive to use it on my desk at home, but in pro audio world it's actually kind of mundane.

Maybe I'll write about it more after I get the gumption to gain a root shell on it (or brick it, whichever comes first). I think you guys might find that part more interesting. :)

I suppose this could save a bit of time if you don't already have Wireshark installed, with a minor risk of hallucinations.

Other than this, he used Docker for some reason* to edit ~root/.ssh/authorized_keys and /etc/shadow in the firmware tarball, then wrote a quick Python script to send the relevant HID messages and copy the modified tarball to a volume mounted from a USB drive exposed by the device in response to one of the HID messages.

Maybe he used Claude to do some of this other stuff. Who knows? But the only thing in the post or the linked scripts that wasn't immediately obvious to me is why he installed the whois package in his Ubuntu container, but it turns out that, in Debian, the mkpasswd utility is installed by the whois package for historical reasons[1].

So basically, you have to be an insane hacker, or else have a basic working knowledge of Linux system administration (or at least know how to use the man(1) command; then again Google would probably suffice as an alternative) and how to write trivial programs in any language with bindings to a USB HID library.

* Presumably because he was on a Mac and didn't have a Linux box handy to generate the hashed password (which requires using glibc crypt(3) in a way that isn't compatible with macOS libc crypt(3), so nontrivial on a Mac).

Not sure why he needed password authentication in the first place, but, at the author's request, I won't shoot him.

I will, however, point out that, unless the sshd_config file on the device already set PermitRootLogin to something other than the default "prohibit-password", password authentication wouldn't have worked to log in as root, even with PasswordAuthentication set to "yes".

[1] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=116260

Not necessarily malice, more like nobody on the audio side really owns the rootfs.

The big question is whether it's only listening on the USB-side network, or on the actual LAN. First one is annoying. Second one would actually bother me.