> And the existence of WebUSB, WebHID, and WebBluetooth mean that for some devices, depending on the specifics of which classes are used, a moment of user indiscretion in accepting a permissions prompt could permanently backdoor one of their attached devices.
This is why most of the browsers rejected these specs. They are super useful, but the security risks are incredible. Most USB devices were not designed to hold up to being exposed to the internet.
The key takeaway for me was he bought a $300 microphone and is acting indignant that he has full access to his own hardware via — gasp — a command shell.
Do we live in a bizarro world now where we expect — no, demand — our hardware be locked down?
It's worth mentioning all USB mics are toys anyway. Analog interfaces have gone away — artificially so — now they cram them into the device.
I mean that’s just not true. Maybe you don’t see usb mics being used in professional recording studios, but that doesn’t mean their toys. They are targeted tools, and are capable of recording audio quality way beyond what’s needed for the how the typical user will listen to it (ie on tik tok or YouTube)
> I haven’t actually been brave enough to write a modified firmware to the thing yet - it’s a pretty expensive monitor - but I’ll get there at some point.
Honestly if you don't have working patches, it's really not owned.
I would love to get a better understanding of how to safely iteratively patch firmware. I bricked a router last week trying to add a TFTP boot path to the boot partition. It just sucks that it's so risky.
Relatedly, we also need good glitching tools, as some firmware even for cheap devices are not available unencrypted, and flash read is disabled...
We are NOT there yet but I hope we get there soon.
I just reverse engineered the Supernote note file format with an agent a few weeks ago. For years the community had been asking for a document on the format. And in a few hours the agent, with 20 something file format example fixtures and 30 something prompts, was able to reverse out the format.
It would have been completely not worth the effort to do this by hand for a niche device. Now, in a few hours of effort there is working code and a doc.
While it’s impressive work from the LLM and a TS implementation is novel, there’s at least a couple of pre-existing Python REs eg. https://github.com/jya-dev/supernote-tool :)
I personally own a Supernote, but I'm not a heavy user of it. For the sake of my own curiosity, what benefits will you get out of having reverse engineered the Supernote note file format? It would be super rad to be able to move my notes between other devices, which is one big plus that comes to my mind.
I had used codex to reverse engineer an electric skateboard to unbrick it. It was a bit more involved because it required soldering wires directly to the UART headers in a very awkward location.
Took about 10 hours and it now works fine. Without codex, this would have taken me significantly more weekends having little experience with skateboard firmware.
This is giving me the confidence to RE my cat feeder. The company (Petlibro) has an outage and now my chilled wet feeder that should be a dumb, offline feeder is basically bricked now.
The device reports fine wifi but the backing services are totally busted.
I initially thought, but why would you want a "webcam whose activity LED I can switch off while it records"? But then I think I got the point: why would one want a webcam which _could be hacked_ so that its activity LED didn't go on.
I'm hopeful that in the future we can end planned obsolescence from devices that require companion apps which eventually get shut down. Just vibe reverse engineering replacements.
Using LLMs for RE and bug hunting is a lot of fun. Today I reported an absolute doozy of a bug to Google's VRP. The vuln was in an HTTP API endpoint I don't have the source for, only RE'd client logic.
The idea behind the bug was mine, it was of the "surely they weren't stupid enough to forget to do xyz" variety. Writing the code to probe for the vulnerability by hand would've taken a few hours of grunt work, including reconstructing protobuf schemas etc. In the past I just wouldn't have bothered, because in my view the odds of success were too low to be worth it. But it was a one-sentence prompt so why the hell not. And it worked!
The pixel cleaning warning turns out to have no native way to disable it, and it’ll always show up after 8 hours of runtime.
Come on, does anyone dog food their own products anymore? How could a single person developing the monitor actually believe consumers want to be bothered with this every day? If the hardware is really so terrible this must happen, find some way to incrementally do it silently or off hours. Anything else.
So is an actionable lesson here to favor devices that aren't USB/wifi connected if they don't have to be? Or perhaps just choose low-tech versions that don't attempt fancy features?
> And the existence of WebUSB, WebHID, and WebBluetooth mean that for some devices, depending on the specifics of which classes are used, a moment of user indiscretion in accepting a permissions prompt could permanently backdoor one of their attached devices.
Do we live in a bizarro world now where we expect — no, demand — our hardware be locked down?
It's worth mentioning all USB mics are toys anyway. Analog interfaces have gone away — artificially so — now they cram them into the device.
All mics are analog.
I mean that’s just not true. Maybe you don’t see usb mics being used in professional recording studios, but that doesn’t mean their toys. They are targeted tools, and are capable of recording audio quality way beyond what’s needed for the how the typical user will listen to it (ie on tik tok or YouTube)
Honestly if you don't have working patches, it's really not owned.
I would love to get a better understanding of how to safely iteratively patch firmware. I bricked a router last week trying to add a TFTP boot path to the boot partition. It just sucks that it's so risky.
Relatedly, we also need good glitching tools, as some firmware even for cheap devices are not available unencrypted, and flash read is disabled...
We are NOT there yet but I hope we get there soon.
It would have been completely not worth the effort to do this by hand for a niche device. Now, in a few hours of effort there is working code and a doc.
https://github.com/philips/supernote-typescript/blob/main/pl...
https://philips.github.io/supernote-typescript/
Took about 10 hours and it now works fine. Without codex, this would have taken me significantly more weekends having little experience with skateboard firmware.
The device reports fine wifi but the backing services are totally busted.
Reverse engineering seems a good one (ev en if his RE nix sandbox looks fairly usable, it seems like a weekend to get this working.
The idea behind the bug was mine, it was of the "surely they weren't stupid enough to forget to do xyz" variety. Writing the code to probe for the vulnerability by hand would've taken a few hours of grunt work, including reconstructing protobuf schemas etc. In the past I just wouldn't have bothered, because in my view the odds of success were too low to be worth it. But it was a one-sentence prompt so why the hell not. And it worked!
Yet for some reason I can’t escape these annoying pixel cleaning interruptions. Seems like a bug in the firmware.
I heard CISA is getting defunded. I wonder if it'll become a common assumption for Americans that all their devices are just perpetually compromised.
> Network-connected devices seem near universally fucked at this point?
I’d say John Deer will be among first ones requesting a halt.
It was similar with Napster vs recording companies… and then Spotify bulldozed everything with its attitude.
With LLM it could be much faster.