> My ASUS ROG Swift PG42UQ monitor was actually where I started, because I got annoyed at the pop-up overlay that comes up every once in a while that tells me to run “pixel cleaning”. I have never intentionally run pixel cleaning on this monitor and I never will, I don’t care, and I would like for that overlay to go away forever. Maybe there’s a debug menu or something that can turn it off, or worst case we patch a branch in the firmware?

Note that this is an OLED monitor, so the "pixel cleaning" thing is probably some sort of anti-burn in feature. You could probably ask the AI to look at the firmware and describe what it does.

Ah, I remember when reversing hardware took weeks / months, an oscilloscope, logic analyzer, Ghidra/IDA, Wireshark, breakout boards, wireless sniffers... back in the olden days of... 2019.

It's amazing to see LLMs give us software and hardware freedoms that the open source movement has only ever dreamed about.

Key takeaway:

> 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.

> 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.

https://github.com/philips/supernote-typescript/blob/main/pl...

https://philips.github.io/supernote-typescript/

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.

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 am wondering if there is a list of “things you should learn to do with your LLM” (But not the rubbish ads youtube keeps showing me)

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.

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 i2c over USB with no auth is just way way too common; I've also seen that on a device.

This a fascinating security write up. I had no idea the models were this capable for reverse engineering.

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.

  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?

The larpcoding epidemic needs to be stopped

All this ownage will get shut down when manufacturers start whining to politicians and the AI companies will ask how high to jump.

holy crap how ! i'd love to jailbreak my old quest 2. its such a good device too bad about all the facebook spyware!