Having the firmware image just be a boring old tarball + hash sounds super nice. I wish more devices were this open, and I hope Rode won't see this and decide to lock the firmware upgrades down.
In the off chance anybody from Rode sees this: This makes me want to purchase your gear. Don't change it.
It's funny this comes up now. Tomorrow I'm dragging my Zoom R20 recorder on-site to use as an overly-featured USB audio interface for a single-mic live stream. If I'd know this about Rode a week ago I'd have purchased one of these and could have left my R20 hooked-up in the home studio!
Funny you mention that, because my first thought when reading that he submitted a report to the vendor was that they'd "fix" the problem by requiring firmware uploads to be signed (in which case it's "secure" because only their service techs have access to the private key, IOW, security by sternly worded written policy).
I’m guilty of using my Zoom R16 in a similar fashion; as USB audio interface most of the time for a couple of inputs.
The only thing that is a little sad about it is that for example the faders do nothing when the R16 is in USB audio interface mode.
It does however like to randomly turn on reverb and one other effect after power cycling. Which I sometimes forget and then wonder for half a second why the audio is sounding weird :P So there is some extra functionality that is available even in USB audio interface mode, although in this case not desirable for me to have enabled within it. If I want to add reverb or other effects when using the R16 as USB audio interface, I prefer to do so in the DAW. I would have liked to be able to use the faders though.
I'm running my R20 in USB interface / stereo mix mode and the faders do work. I didn't think about trying to apply any effects. I'll play with that, for fun, but I'd definitely add them in the DAW as well. (I really only use my R20 for multitrack recording and do all my effects in the DAW. I like it, and it can do a ton standalone, but my workflow really just needed a multitrack recorder and I could have probably spent a lot less. It just looked like fun...)
I had to upgrade the firmware in my HP printer a couple years ago.
It’s a printer that I think was released in ~2009 (I am not able to check right now), and in order to upgrade the RAM to 256MB I needed to do a firmware update.
I dreaded this, but then I found out that all you do to update the firmware was FTP a tarball to the printer over the network. I dropped it in with FileZilla, it spent a few minutes whirring, and my firmware was updated.
Then I got mad that firmware updates are ever more complicated than that. Let me FTP or SCP or SFTP a blob there, do a checksum or something for security reasons, and then do nothing else.
My favorite firmware update story is a time when I had to reflash firmware on an old IBM Fibre Channel/SCSI gateway because it had become corrupted and wouldn't boot.
Fortunately the first stage bootloader (which may have been in ROM) was intact, and had debugging commands that allowed reading and writing bytes of memory one at a time, and to jump to a specific memory address.
After using IDA to find the compressed firmware in the update blob and figure out how the update process worked, I was then able to use an expect script to use bootloader commands to slowly poke the firmware and the code that decompressed and copied the updated firmware to flash (extracted from the firmware itself after decompressing it with zlib) into RAM a byte at a time, then to jump to the uploaded code to finish the installation.
Worked like a charm, and enabled me to continue using the device for several years until I no longer had a use for it.
I think my favorite is wifi access points that support tftp to load a firmware image (with some kind of hardware switch to enable this state). These can be made effective unbrickable and it's really nice for experimenting.
I'm not sure if it was what OP meant, but it's arguably a good availability technique (as long as you can generate the checksum, that is). Like, if I want to run custom firmware and flash it, having a checksum which verifies that the firmware isn't corrupted may help prevent bricking.
I think it should be locked down to require some kind of physical button input to enable the commands, putting it in some kind of "DFU" mode. Otherwise anything with USB access could brick your device by flashing a bad firmware.
I agree that it shouldn't have SSH enabled, but I do like that the firmware isn't encrypted or signed, so it's not hard to mod it, at no cost to thr manufacturer
I think "my audio interface is a 64-bit Linux computer" would've sounded far more interesting to me as a title. Perhaps a decade or two ago, the functionality of that device would've likely been implemented on a small 16-bit or 32-bit SoC running an RTOS like VxWorks.
Given how many physical controls it has, turning it into a game console seems like a logical next step.
My audio interface is a Linux computer with FPGAs inside (that actually get field-programmed), with two gigabit Ethernet jacks that each talk to different parts of the machine.
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’m building an audio device. It runs Linux for the control plane (it’s just a CM4 running Yocto, maybe I’ll leave SSH running on production units, maybe not, haven’t decided yet). No audio passes through the CM4, there’s a dedicated FPGA and MCU for that. It’s been a fun project, first time hardware for me, feel free to ask my anything!
This particular box also has RS-232, ssh (with almost zero auth), and telnet as a control plane, by default. Any of that only gets used to tweak/report various things with a rather basic human-readiable protocol. (It has built-in functions to make it more secure; I just don't care on my home LAN, or on my pop-up LANs in the field. A sane person with a professional role would have it locked down and on its own VLAN/VPN, but for me and prototyping: Telnet is actually pretty good.)
I designed none of it. I just bought it, and make good use of it. New, it was a mid-4-digit box; used, they're not so bad. (And I use it every day and like it quite a lot, hence the reluctance to go harder on the potential root shell hack.)
My box, as it sits, just does general-purpose GUI-connected DSP stuff with near-realtime tweaking. I'm in the process of getting it to grok OSC, and thus Reaper or whatever, so it has a better control surface for live work.
It has a USB interface that my Linux box treats as a sound card, which works well. My main reason for wanting to get root is to examine (solve?) its ~5-minute boot times.
5 minutes in a live sound environment is the difference between having a large, active, and involved crowd, and having everyone get bored and find something else to do.
Anyway, the FPGAs here just exist to behave as DSPs and...well, digitally process [audio] signals. It works well; I really just wish it booted faster.
And that may be its downfall. :P
---
But enough about that.
What's your device do? What are your plans and dreams with it? (Do I want one?)
I've built a very small amount of hardware. At least at the level of custom PCBs and some code, it's been richly rewarding even when I screw it up, and it makes me feel like I'm on top of the world when I get it right.
Re: yours, that is a _long_ boot time. Boot time on mine isn't great, but I think I'm just going to have to accept that as an artefact of U-Boot, Linux, and an Ethernet switch chip that takes some time to initialise.
Anyway, re: my widget: it's a personal monitor mixer [1], something one might use in the studio or live, not dissimilar to existing products in the market, except: it supports up to 64 channels of Dante or AVB natively, it has a super nice (HiDPI) UI, and absolutely everything is remote controllable using OCA (AES70) or OSC. I even have a MCP bridge so you can let Claude manage it ;) [2]
The hardware is a custom board that hosts a CM4 SOM (for the control plane and UI), a Brooklyn 3 SOM (Dante), and an XMOS which runs the mixer firmware and AVB stack. There are also some nice AKM DACs, and a Marvell Ethernet switch chip that connects the SOMs and XMOS to two external Ethernet ports.
The CM4 runs Yocto which manages the switch in DSA mode (i.e. hardware offloaded bridge), runs the gPTP and SRP stacks for AVB, the OCA daemon, and the UI (which is just a regular OCA client). SSH is presently enabled but there's not a lot to do once you're in there. Working on secure boot at the moment with U-Boot and dm-verity.
Dedicated test gear is different echelon. We've got some crazy-expensive RF test gear where I work that cost us way more than my house. That's an awesome corner of the world, with a combination of robust-but-fickle at every corner.
The sales volume is low, and the development cost is expensive, so the cost to purchase is also expensive. It's an interesting thing to think about, market-wise.
SoundWire. That's an internal[ish], hard-clocked, multipoint, digital audio bus, yeah? I don't know much about it. Looks like it's mostly useful for OE car audio applications?
---
This box I have is just a finished, retail-product, general-purpose pro audio DSP with a good amount of practical analog and digital audio IO. There are many others like it in the marketplace that do very similar things, but this one has a CVE that I want to exploit for my own purposes. :)
---
I really hate being secretive. I strongly prefer to just chat about stuff here, or there, or anywhere.
But even though I'm just some dude in Ohio, my HN comments consistently show up near the top of Google search results when looking at specific topics that I've covered, sometimes just in-passing, so I'm inclined to keep the details to myself for now.
I mean: In the grand scheme of things I haven't even been posting regularly here for very long, but more than once already I've Googled a question and found a link to an answer in my own comment here.
That can be problematic.
This is a great forum for open discussion, and for releasing information, and it is absolutely the wrong forum for secret skunkworks.
If I had a spare box so I could afford to potentially fuck this one up forever, I'd get on with it already. And then, of course, I would publish the results.
I wish I could spill the beans already and maybe get some great help from someone here who does this stuff routinely, but that scares future-me. If the devices can be rooted, then I want them all to be rooted (if useful) -or- better-secured (if not useful).
That sounds fine, except I don't want them to become botnet members, either.
It's a dilemma. There's a lot of this shit out there in the world that doesn't get updated.
Yeah, this is pretty common once a device has any real DSP in it. There's usually some stripped-down Linux on an ARM SoC underneath, and the vendor BSP just happens to ship with sshd on.
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.
Its still crazy to me that everyone has a pocket AI-hacker ready to inspect firmware and modify their devices now. You just put the agent on it and it gives you access in minutes. You would have to be a Hotz tier hacker if you wanted to do anything close to this only last year, or at the very least extremely patient for long hours.
> You would have to be a Hotz tier hacker if you wanted to do anything close to this only last year
This isn't true at all. Yes, LLMs have made it dramatically easier to analyse, debug and circumvent. Both for people who didn't have the skill to do this, and for people who know how to but just cannot be bothered because it's often a grind. This specific device turned out to be barely protected against anything. No encrypted firmware, no signature checking, and built-in SSH access. This would be extremely doable for any medium skilled person without an LLM with good motivation and effort.
You're referring to George Hotz, which is known for releasing the first PS3 hypervisor exploit. The PS3 was / is fully secured against attackers, of which the mere existence of a hypervisor layer is proof of. Producing an exploit required voltage glitching on physical hardware using an FPGA [1]. Perhaps an LLM can assist with mounting such an attack, but as there's no complete feedback loop, it still would require a lot of human effort.
>... but as there's no complete feedback loop, it still would require a lot of human effort.
Not for long. Picture this: a robot receives instructions on what to physically solder in order to complete the desired modification task.
However, before it can send an image back to the vision-aware LLM guiding it, the PCB lights on fire along with the robot because said LLM confidently gave the wrong instructions.
Then, the robotic fire brigade shows up and mostly walks into walls unable to navigate anywhere useful.
The hacking aspect has been hit and miss for me. Just today I was trying to verify a fix for a CVE and even giving the agent the CVE description + details on how to exploit it and the code that fixed it, it couldn't write the exploit code correctly.
Not to say it's not super useful, as we can see in the article
CVEs and all, but I just can't wait for firmwares for cheaper modern cameras from Sony, Nikon and Panasonic getting hacked and modified too add features from more expensive models.
They're all firmware restricted to justify buying more expensive models, in one way or another way.
Minor correction. At 27c3's "Console Hacking 2010" talk. Geohot's Hypervisor work is mentioned at 4:25 or so. Described as "really unreliable" and "eh whatever" due to requiring hardware modification and only granting rudimentary hypervisor access.
These were the same people that then went on to explain how they reverse-engineered the encryption keys of the PS3 to enable "fakesigned" code to be installed
didn't PS3 have a hardcoded nonce for their ECDSA impl that allowed full key recovery? I would agree that I doubt LLMs let people mount side-channel attacks easily on consumer electronics though.
Yes indeed, that chain of exploits was all software and not hardware. Developed after the Hotz exploit and Sony subsequently shuttering OtherOS.
It didn't directly give access to anything however. IIRC they heavily relied on other complex exploits they developed themselves, as well as relying on earlier exploits they could access by rolling back the firmware by indeed abusing the ECDSA implementation. At least, that turned out to be the path of least resistance. Without earlier exploits, there would be less known about the system to work with.
Their presentation [1] [2] is still a very interesting watch.
From the article, it sounds like he used Claude Code as an alternative to Wireshark and Google to decode USB HID traffic and find protocol documentation, respectively.
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".
I used wireshark to capture the traffic, and looked thru the pcap for the area that looked like the updating, and gave the packet numbers and the pcap to claude code to find the details of how it worked instead of scribbling notes for an hour or two i’d guess
I’m very used to doing this stuff manually for various devices and software, but am also interested in tracking llm progress, and it seemed simple enough to get a rundown of what was happening while I did other work.
It was the first time I have messed around with hid devices though, so that was aided by claude
and yeah i’ve been bit by having to google how to get mkpasswd dozens of times over the years and used to have to do a lot of rootfs editing on a mac, so I got used to doing it in a container.
no real reason for wanting pw auth, I ended up turning it off afterwards but it’s been a bit since I wrote this
I used Wireshark to analyze various things (mostly smart home) over the years, but now CC does in minutes what it would take me a few hours before - and provides dedicated, custom made panels for whatever I want.
As an example - debugging KNX magistrale in my home, previously it was either wireshark and a ton of regexes, handwritten scripts (or official software that was terrible), now you just tell CC what you want to extract, and you get beautiful real-time views of the activity.
One thing is previewing the traffic, but then CC can easily fetch docs for any device it finds on the network, if it has an API (official or not), utilize it and do whatever you want.
This 1000% - I’ve used AI to enable SSH in one Phase One digital back I own, and to reverse engineer and patch the firmware on another to make the back think it’s a different back - Credo 50 to IQ250! The internals are literally the Sam.
its really nice to not have to spend hours looking thru packet captures and stuff, i enjoy digging but as i'm getting older I have less time to spend 16 hour days looking at random firmware blobs
Damn, maybe I can throw an agent at trying to unlock IMEI spoofing on my Unifi LTE modem. That one guy on twitter who does all the LTE modem unlocking never replied to my tweet :(
to me this is just normal to do with your devices. I think it’s interesting because it has no fw signing etc and because they left ssh, not because of figuring out how to do the patching.
I really want to know how he solved this problem, which I also face:
>last year i bought a Rodecaster Duo to solve some audio woes to allow myself and my girlfriend to have microphones to our respective computers when gaming together and talking on discord in the same room without any echo
the rodecaster can connect to two computers, and we are both generally in the same discord call. so we have both microphones routed into one input for a computer, and the other person joins with their mic muted and the audio just comes from one client. since the mixing is local there's no echo. email me if you have more questions :)
So both mics will pick up both people (at least somewhat, in the same room) - but because there is no, I assume 20-100ms latency going through the system, to discord, and back - it avoids a slight difference in timing of the two mics picking up the same sound slightly differently. Is that right?
also the audio output of each computer is routed thru the box as well, so i can mix my girlfriend’s computer into her headphones as well as my microphone, so she can hear me with noise canceling headphones, or turn off my microphone if i’m working so she can do stuff without my mic in her ears.
Or if she’s watching a movie or something I can also add her computer audio to my headphones. There’s even a separate audio output for host 1 where you can put ‘chat’ on, like discord on a dedicated interface, so that your application audio is clear and isolated. It’s hella expensive but it really is a great device
It saves on rewiring stuff. Maybe there's only one person talking today. Maybe they're using PC A, or perhaps they're using PC B instead.
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.
Not in the same league or form factor, but I have an old Jabra 65 headset, and the noise canceling is amazing. I can be playing my cello while unmuted on a call, and nobody can hear it.
I know headsets aren't everyone's cup of tea, but a mic close to the source (your mouth) with good noise canceling is a solid solution.
Cyber Resilience Act [1], which is well-intentioned, and doesn't outright forbid user access to firmware, but most vendors will take the easy road and outright block user-modifiable software (if they didn't already), so that their completely closed source, obfuscated and vulnerable version is the only version allowed on their devices.
Well... if you look behind anything that plugs into a wall socket you will see that it has ( among many other things) a CE mark. Even things in the USofA have a CE mark.
If your new product cannot have its CE mark for whatever reason, you will not have the approbations to sell in the USA either.
What the CRA will do, is if you do not have a "CRA" compliant product, you will not have the CE mark. Which means you will not (with very high probability) have the other marks needed to sell outside Europe.
Maybe then you can just sell to your close family members who like you, but good luck if you get caught and it can be proven that your shitty device caused a fire ...
We don't place any value on the CE mark in the States.
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.)
>If your new product cannot have its CE mark for whatever reason, you will not have the approbations to sell in the USA either.
I worked for a US manufacturer that only sold directly in the US, and we never bothered getting CE certification on anything, just FCC. Lots of Europeans imported our products, but we left EU compliance up to them.
The size of the EU market didn't justify the costs of regulatory compliance.
I would like for SSH to be turned off, but I also like that I can just do that myself.
Normally when I look at these devices firmware they’re horrific beasts with insane issues everywhere. This just requires a config change to fix the single thing I don’t like about it. There’s plenty of outrage in the world :)
Having the firmware image just be a boring old tarball + hash sounds super nice. I wish more devices were this open, and I hope Rode won't see this and decide to lock the firmware upgrades down.
In the off chance anybody from Rode sees this: This makes me want to purchase your gear. Don't change it.
It's funny this comes up now. Tomorrow I'm dragging my Zoom R20 recorder on-site to use as an overly-featured USB audio interface for a single-mic live stream. If I'd know this about Rode a week ago I'd have purchased one of these and could have left my R20 hooked-up in the home studio!
Funny you mention that, because my first thought when reading that he submitted a report to the vendor was that they'd "fix" the problem by requiring firmware uploads to be signed (in which case it's "secure" because only their service techs have access to the private key, IOW, security by sternly worded written policy).
I’m guilty of using my Zoom R16 in a similar fashion; as USB audio interface most of the time for a couple of inputs.
The only thing that is a little sad about it is that for example the faders do nothing when the R16 is in USB audio interface mode.
It does however like to randomly turn on reverb and one other effect after power cycling. Which I sometimes forget and then wonder for half a second why the audio is sounding weird :P So there is some extra functionality that is available even in USB audio interface mode, although in this case not desirable for me to have enabled within it. If I want to add reverb or other effects when using the R16 as USB audio interface, I prefer to do so in the DAW. I would have liked to be able to use the faders though.
Interesting.
I'm running my R20 in USB interface / stereo mix mode and the faders do work. I didn't think about trying to apply any effects. I'll play with that, for fun, but I'd definitely add them in the DAW as well. (I really only use my R20 for multitrack recording and do all my effects in the DAW. I like it, and it can do a ton standalone, but my workflow really just needed a multitrack recorder and I could have probably spent a lot less. It just looked like fun...)
I had to upgrade the firmware in my HP printer a couple years ago.
It’s a printer that I think was released in ~2009 (I am not able to check right now), and in order to upgrade the RAM to 256MB I needed to do a firmware update.
I dreaded this, but then I found out that all you do to update the firmware was FTP a tarball to the printer over the network. I dropped it in with FileZilla, it spent a few minutes whirring, and my firmware was updated.
Then I got mad that firmware updates are ever more complicated than that. Let me FTP or SCP or SFTP a blob there, do a checksum or something for security reasons, and then do nothing else.
My favorite firmware update story is a time when I had to reflash firmware on an old IBM Fibre Channel/SCSI gateway because it had become corrupted and wouldn't boot.
Fortunately the first stage bootloader (which may have been in ROM) was intact, and had debugging commands that allowed reading and writing bytes of memory one at a time, and to jump to a specific memory address.
After using IDA to find the compressed firmware in the update blob and figure out how the update process worked, I was then able to use an expect script to use bootloader commands to slowly poke the firmware and the code that decompressed and copied the updated firmware to flash (extracted from the firmware itself after decompressing it with zlib) into RAM a byte at a time, then to jump to the uploaded code to finish the installation.
Worked like a charm, and enabled me to continue using the device for several years until I no longer had a use for it.
I think my favorite is wifi access points that support tftp to load a firmware image (with some kind of hardware switch to enable this state). These can be made effective unbrickable and it's really nice for experimenting.
> Let me FTP or SCP or SFTP a blob there, do a checksum or something for security reasons
Whose security are we talking about here? Mine, or the manufacturer's?
I'm not sure if it was what OP meant, but it's arguably a good availability technique (as long as you can generate the checksum, that is). Like, if I want to run custom firmware and flash it, having a checksum which verifies that the firmware isn't corrupted may help prevent bricking.
Right, I'm not sure either. Hence the question. :)
Checksums are great for helping to validate data integrity. And data integrity can be related to security.
But over the last 25 years or so, I've grown to become pretty averse to phrasing that parse like "for security purposes".
I think it should be locked down to require some kind of physical button input to enable the commands, putting it in some kind of "DFU" mode. Otherwise anything with USB access could brick your device by flashing a bad firmware.
I don't want my audio interface to run SSH (and have some random authorized key added), personally.
I agree that it shouldn't have SSH enabled, but I do like that the firmware isn't encrypted or signed, so it's not hard to mod it, at no cost to thr manufacturer
I think many vendors think security is synonymous with "hard to clone". This us why they require signed images and so on.
I think "my audio interface is a 64-bit Linux computer" would've sounded far more interesting to me as a title. Perhaps a decade or two ago, the functionality of that device would've likely been implemented on a small 16-bit or 32-bit SoC running an RTOS like VxWorks.
Given how many physical controls it has, turning it into a game console seems like a logical next step.
My audio interface is a Linux computer with FPGAs inside (that actually get field-programmed), with two gigabit Ethernet jacks that each talk to different parts of the machine.
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’m building an audio device. It runs Linux for the control plane (it’s just a CM4 running Yocto, maybe I’ll leave SSH running on production units, maybe not, haven’t decided yet). No audio passes through the CM4, there’s a dedicated FPGA and MCU for that. It’s been a fun project, first time hardware for me, feel free to ask my anything!
Nice!
This particular box also has RS-232, ssh (with almost zero auth), and telnet as a control plane, by default. Any of that only gets used to tweak/report various things with a rather basic human-readiable protocol. (It has built-in functions to make it more secure; I just don't care on my home LAN, or on my pop-up LANs in the field. A sane person with a professional role would have it locked down and on its own VLAN/VPN, but for me and prototyping: Telnet is actually pretty good.)
I designed none of it. I just bought it, and make good use of it. New, it was a mid-4-digit box; used, they're not so bad. (And I use it every day and like it quite a lot, hence the reluctance to go harder on the potential root shell hack.)
My box, as it sits, just does general-purpose GUI-connected DSP stuff with near-realtime tweaking. I'm in the process of getting it to grok OSC, and thus Reaper or whatever, so it has a better control surface for live work.
It has a USB interface that my Linux box treats as a sound card, which works well. My main reason for wanting to get root is to examine (solve?) its ~5-minute boot times.
5 minutes in a live sound environment is the difference between having a large, active, and involved crowd, and having everyone get bored and find something else to do.
Anyway, the FPGAs here just exist to behave as DSPs and...well, digitally process [audio] signals. It works well; I really just wish it booted faster.
And that may be its downfall. :P
---
But enough about that.
What's your device do? What are your plans and dreams with it? (Do I want one?)
I've built a very small amount of hardware. At least at the level of custom PCBs and some code, it's been richly rewarding even when I screw it up, and it makes me feel like I'm on top of the world when I get it right.
Can you tell me about your widget?
Re: yours, that is a _long_ boot time. Boot time on mine isn't great, but I think I'm just going to have to accept that as an artefact of U-Boot, Linux, and an Ethernet switch chip that takes some time to initialise.
Anyway, re: my widget: it's a personal monitor mixer [1], something one might use in the studio or live, not dissimilar to existing products in the market, except: it supports up to 64 channels of Dante or AVB natively, it has a super nice (HiDPI) UI, and absolutely everything is remote controllable using OCA (AES70) or OSC. I even have a MCP bridge so you can let Claude manage it ;) [2]
The hardware is a custom board that hosts a CM4 SOM (for the control plane and UI), a Brooklyn 3 SOM (Dante), and an XMOS which runs the mixer firmware and AVB stack. There are also some nice AKM DACs, and a Marvell Ethernet switch chip that connects the SOMs and XMOS to two external Ethernet ports.
The CM4 runs Yocto which manages the switch in DSA mode (i.e. hardware offloaded bridge), runs the gPTP and SRP stacks for AVB, the OCA daemon, and the UI (which is just a regular OCA client). SSH is presently enabled but there's not a lot to do once you're in there. Working on secure boot at the moment with U-Boot and dm-verity.
[1] https://forums.swift.org/t/an-embedded-audio-product-built-w... (note, older prototype)
[2] https://www.linkedin.com/posts/lukehowardmusic_heres-a-long-...
I have some of those at work: they're test platforms for the audio ICs, for things like SoundWire interfaces.
Dedicated test gear is different echelon. We've got some crazy-expensive RF test gear where I work that cost us way more than my house. That's an awesome corner of the world, with a combination of robust-but-fickle at every corner.
The sales volume is low, and the development cost is expensive, so the cost to purchase is also expensive. It's an interesting thing to think about, market-wise.
SoundWire. That's an internal[ish], hard-clocked, multipoint, digital audio bus, yeah? I don't know much about it. Looks like it's mostly useful for OE car audio applications?
---
This box I have is just a finished, retail-product, general-purpose pro audio DSP with a good amount of practical analog and digital audio IO. There are many others like it in the marketplace that do very similar things, but this one has a CVE that I want to exploit for my own purposes. :)
---
I really hate being secretive. I strongly prefer to just chat about stuff here, or there, or anywhere.
But even though I'm just some dude in Ohio, my HN comments consistently show up near the top of Google search results when looking at specific topics that I've covered, sometimes just in-passing, so I'm inclined to keep the details to myself for now.
I mean: In the grand scheme of things I haven't even been posting regularly here for very long, but more than once already I've Googled a question and found a link to an answer in my own comment here.
That can be problematic.
This is a great forum for open discussion, and for releasing information, and it is absolutely the wrong forum for secret skunkworks.
If I had a spare box so I could afford to potentially fuck this one up forever, I'd get on with it already. And then, of course, I would publish the results.
I wish I could spill the beans already and maybe get some great help from someone here who does this stuff routinely, but that scares future-me. If the devices can be rooted, then I want them all to be rooted (if useful) -or- better-secured (if not useful).
That sounds fine, except I don't want them to become botnet members, either.
It's a dilemma. There's a lot of this shit out there in the world that doesn't get updated.
And your video dongle might be a Unix computer: https://www.macrumors.com/2025/02/04/doom-apple-lightning-hd...
Yeah, this is pretty common once a device has any real DSP in it. There's usually some stripped-down Linux on an ARM SoC underneath, and the vendor BSP just happens to ship with sshd on.
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.
It is listening on the LAN. It connects over wifi only when you use certain features, so i didn’t test if that interface is listening as well.
Yeah, LAN is the line for me. USB-side sshd is a weird dev leftover; LAN means it’s now in the home threat model.
Its still crazy to me that everyone has a pocket AI-hacker ready to inspect firmware and modify their devices now. You just put the agent on it and it gives you access in minutes. You would have to be a Hotz tier hacker if you wanted to do anything close to this only last year, or at the very least extremely patient for long hours.
> You would have to be a Hotz tier hacker if you wanted to do anything close to this only last year
This isn't true at all. Yes, LLMs have made it dramatically easier to analyse, debug and circumvent. Both for people who didn't have the skill to do this, and for people who know how to but just cannot be bothered because it's often a grind. This specific device turned out to be barely protected against anything. No encrypted firmware, no signature checking, and built-in SSH access. This would be extremely doable for any medium skilled person without an LLM with good motivation and effort.
You're referring to George Hotz, which is known for releasing the first PS3 hypervisor exploit. The PS3 was / is fully secured against attackers, of which the mere existence of a hypervisor layer is proof of. Producing an exploit required voltage glitching on physical hardware using an FPGA [1]. Perhaps an LLM can assist with mounting such an attack, but as there's no complete feedback loop, it still would require a lot of human effort.
[1] https://rdist.root.org/2010/01/27/how-the-ps3-hypervisor-was...
>... but as there's no complete feedback loop, it still would require a lot of human effort.
Not for long. Picture this: a robot receives instructions on what to physically solder in order to complete the desired modification task.
However, before it can send an image back to the vision-aware LLM guiding it, the PCB lights on fire along with the robot because said LLM confidently gave the wrong instructions.
Then, the robotic fire brigade shows up and mostly walks into walls unable to navigate anywhere useful.
The future is bright.
The hacking aspect has been hit and miss for me. Just today I was trying to verify a fix for a CVE and even giving the agent the CVE description + details on how to exploit it and the code that fixed it, it couldn't write the exploit code correctly.
Not to say it's not super useful, as we can see in the article
CVEs and all, but I just can't wait for firmwares for cheaper modern cameras from Sony, Nikon and Panasonic getting hacked and modified too add features from more expensive models.
They're all firmware restricted to justify buying more expensive models, in one way or another way.
DNG support would be pretty awesome too.
Minor correction. At 27c3's "Console Hacking 2010" talk. Geohot's Hypervisor work is mentioned at 4:25 or so. Described as "really unreliable" and "eh whatever" due to requiring hardware modification and only granting rudimentary hypervisor access.
These were the same people that then went on to explain how they reverse-engineered the encryption keys of the PS3 to enable "fakesigned" code to be installed
didn't PS3 have a hardcoded nonce for their ECDSA impl that allowed full key recovery? I would agree that I doubt LLMs let people mount side-channel attacks easily on consumer electronics though.
Yes indeed, that chain of exploits was all software and not hardware. Developed after the Hotz exploit and Sony subsequently shuttering OtherOS.
It didn't directly give access to anything however. IIRC they heavily relied on other complex exploits they developed themselves, as well as relying on earlier exploits they could access by rolling back the firmware by indeed abusing the ECDSA implementation. At least, that turned out to be the path of least resistance. Without earlier exploits, there would be less known about the system to work with.
Their presentation [1] [2] is still a very interesting watch.
[1] https://www.youtube.com/watch?v=5E0DkoQjCmI
[2] https://fahrplan.events.ccc.de/congress/2010/Fahrplan/attach...
> fully secured against attackers, of which the mere existence of a hypervisor layer is proof of
https://en.wikipedia.org/wiki/Virtual_machine_escape
The last one was 8 years ago. It's not a terribly common vuln anymore - not that it ever was.
> The last one was 8 years ago
Not true. There's way more than that list. I could immediately think of 2 more from last year: CVE-2025-22224 and CVE-2025-22225
> Perhaps an LLM can assist with mounting such an attack, but as there's no complete feedback loop, it still would require a lot of human effort.
LLMs have had no problem modifying software on an attached android phone. It's only a matter of time.
From the article, it sounds like he used Claude Code as an alternative to Wireshark and Google to decode USB HID traffic and find protocol documentation, respectively.
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
I used wireshark to capture the traffic, and looked thru the pcap for the area that looked like the updating, and gave the packet numbers and the pcap to claude code to find the details of how it worked instead of scribbling notes for an hour or two i’d guess
I’m very used to doing this stuff manually for various devices and software, but am also interested in tracking llm progress, and it seemed simple enough to get a rundown of what was happening while I did other work.
It was the first time I have messed around with hid devices though, so that was aided by claude
and yeah i’ve been bit by having to google how to get mkpasswd dozens of times over the years and used to have to do a lot of rootfs editing on a mac, so I got used to doing it in a container.
no real reason for wanting pw auth, I ended up turning it off afterwards but it’s been a bit since I wrote this
thanks for the comment!
> a bit of time
A bit of time is an understatement.
I used Wireshark to analyze various things (mostly smart home) over the years, but now CC does in minutes what it would take me a few hours before - and provides dedicated, custom made panels for whatever I want.
As an example - debugging KNX magistrale in my home, previously it was either wireshark and a ton of regexes, handwritten scripts (or official software that was terrible), now you just tell CC what you want to extract, and you get beautiful real-time views of the activity.
One thing is previewing the traffic, but then CC can easily fetch docs for any device it finds on the network, if it has an API (official or not), utilize it and do whatever you want.
This 1000% - I’ve used AI to enable SSH in one Phase One digital back I own, and to reverse engineer and patch the firmware on another to make the back think it’s a different back - Credo 50 to IQ250! The internals are literally the Sam.
I'm sorry, are you trusting an LLM to touch a camera that costs like a new car?
Only a little bit of touching for the really expensive one. The Credo 50 was less than 1K though.
Also Phase One Support/Repair is absolutely phenomenal and unless you toast the sensor; repairs are “fairly” economical.
its really nice to not have to spend hours looking thru packet captures and stuff, i enjoy digging but as i'm getting older I have less time to spend 16 hour days looking at random firmware blobs
LLM are not capable of doing that for most things. Having an open ssh device does not require any special "skill".
If it’s embedded Linux with no HAB it’s not hard to make “adjustments.” Just use file and binwalk to figure out what it is and break it open.
Damn, maybe I can throw an agent at trying to unlock IMEI spoofing on my Unifi LTE modem. That one guy on twitter who does all the LTE modem unlocking never replied to my tweet :(
there’s barely any hacking here
the guy found this through looking at the firmware but nmap -p 22 would have also found this
So like the first thing you would do to attack the device
I found an issue exactly like this on an ISP-provided router. I am nowhere near geohot but also didn’t even do as much as the guy in the article lmao
to me this is just normal to do with your devices. I think it’s interesting because it has no fw signing etc and because they left ssh, not because of figuring out how to do the patching.
I really want to know how he solved this problem, which I also face:
>last year i bought a Rodecaster Duo to solve some audio woes to allow myself and my girlfriend to have microphones to our respective computers when gaming together and talking on discord in the same room without any echo
the rodecaster can connect to two computers, and we are both generally in the same discord call. so we have both microphones routed into one input for a computer, and the other person joins with their mic muted and the audio just comes from one client. since the mixing is local there's no echo. email me if you have more questions :)
So both mics will pick up both people (at least somewhat, in the same room) - but because there is no, I assume 20-100ms latency going through the system, to discord, and back - it avoids a slight difference in timing of the two mics picking up the same sound slightly differently. Is that right?
Very cool!
correct
also the audio output of each computer is routed thru the box as well, so i can mix my girlfriend’s computer into her headphones as well as my microphone, so she can hear me with noise canceling headphones, or turn off my microphone if i’m working so she can do stuff without my mic in her ears.
Or if she’s watching a movie or something I can also add her computer audio to my headphones. There’s even a separate audio output for host 1 where you can put ‘chat’ on, like discord on a dedicated interface, so that your application audio is clear and isolated. It’s hella expensive but it really is a great device
Why connect it to both computers?
It saves on rewiring stuff. Maybe there's only one person talking today. Maybe they're using PC A, or perhaps they're using PC B instead.
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.
I get it! Thank you that is genius.
Not in the same league or form factor, but I have an old Jabra 65 headset, and the noise canceling is amazing. I can be playing my cello while unmuted on a call, and nobody can hear it.
I know headsets aren't everyone's cup of tea, but a mic close to the source (your mouth) with good noise canceling is a solid solution.
I recently vibe coded a jack mixer in Rust. It can ingest and relay audio via LAN. I have around 40 ms latency, 50-60 ms if relaying via wifi.
It would solve the issue in a similar way. One pc runs the mixer. The mixer has an input channel for local mic.
Other PC broadcasts their mic to the mixer, which comes in as 'channel 2'.
You can even have music playing on your local PC, either the mixer or broadcaster creates a local sink.
It's all then mixed in the mixer, there's 3 outputs. You could say use the main out to send to discord.
And the monitor line would be used to output Discord audio, which can then be relayed to the other PC for realtime listening.
Doesn't a headset with directional boom microphone do the trick? I may be misinterpreting the problem statement though :-).
Nice writeup and great domain. I don't know Zola and don't know if this is a common template or a custom jobbie but it's lovely.
Looks like the https://www.getzola.org/themes/radion/ theme
I understand the hacker rationale to have fun owning the device, and i would like it to stay that way.
But... please do not forget that the CRA will put a heavy blanket on that fire.
TLA syndrome strikes again, I have no idea what CRA refers to here.
Cyber Resilience Act [1], which is well-intentioned, and doesn't outright forbid user access to firmware, but most vendors will take the easy road and outright block user-modifiable software (if they didn't already), so that their completely closed source, obfuscated and vulnerable version is the only version allowed on their devices.
[1] https://en.wikipedia.org/wiki/Cyber_Resilience_Act
Ah, EU-only. That explains why I've never heard of it, among other things.
Well... if you look behind anything that plugs into a wall socket you will see that it has ( among many other things) a CE mark. Even things in the USofA have a CE mark.
If your new product cannot have its CE mark for whatever reason, you will not have the approbations to sell in the USA either.
What the CRA will do, is if you do not have a "CRA" compliant product, you will not have the CE mark. Which means you will not (with very high probability) have the other marks needed to sell outside Europe.
Maybe then you can just sell to your close family members who like you, but good luck if you get caught and it can be proven that your shitty device caused a fire ...
We don't place any value on the CE mark in the States.
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.)
>If your new product cannot have its CE mark for whatever reason, you will not have the approbations to sell in the USA either.
I worked for a US manufacturer that only sold directly in the US, and we never bothered getting CE certification on anything, just FCC. Lots of Europeans imported our products, but we left EU compliance up to them.
The size of the EU market didn't justify the costs of regulatory compliance.
> Lots of Europeans imported our products, but we left EU compliance up to them.
Yeah, compliance is almost voluntary unless you're absolutely huge.
why was disclosure the objective? wouldn't you want to keep this interface open?
not really an objective, I hope RODE continues to keep it open
https://github.com/ThomasStolt/Copy-Recordings-Off-Rodecaste...
It used to be completely open lol
That's sad.
Good old local Aussie guys write this. If you had something you wanted to report I'd just give them a call. We almost speak English down here.
It runs jack audio. This thing is literally jack in the box!
is he happy that rode has an ssh to his device? the guy is like too nice. where's the outrage?
I would like for SSH to be turned off, but I also like that I can just do that myself.
Normally when I look at these devices firmware they’re horrific beasts with insane issues everywhere. This just requires a config change to fix the single thing I don’t like about it. There’s plenty of outrage in the world :)
Hacker News doesn't know what to do with anyone that doesn't think the world is ending and that humanity is inherently evil and must be punished.
It's still better than Reddit, though.