> 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.
Yeah, you actually want to do this with monitors of that generation to make them last.
You could argue that there should be an option to disable it for people who donât care.
Refusing to take 1 minute out of your day to learn the reason for the alert is a strange self-defeating protest next to the explanation that it was a pretty expensive monitor.
I understand what it does, I think the alert is annoying. It takes at least five minutes and automatically runs when the monitor is off. Iâve had it for a few years and have no burn in issues despite not doing this every eight hours on command.
> Yeah, you actually want to do this with monitors of that generation to make them last.
Brand new models still have this popup... what "generation" are you talking about that doesn't need this? Or is it just unnecessary on the newer models but they have it any ways due to lack of firmware updates?
How is it strange that among the 900,000 1-minute tasks you need to complete on a given day, this one is low on the list?
Some people's time is actually worth or even just valued more than others to be bothered doing maintenance tasks such as there. I have a life to live outside preserving every last minute of functionality out of a monitor, I'll buy a new one eventually regardless.
Eh I think the monitors should just handle this automatically - mine do. I basically have no idea that they do any cleaning cycles except when I check their âadvancedâ menu and it says itâs run 1200 times or whatever
They can.... which everyone bitched about: they would do their cleaning cycle, no matter if you were busy or not.
The Internet seems rather reluctant to explain what exactly "pixel cleaning" does, but based on the vague useless "explanations" I could find, I suspect it's a sort of "flat-field correction" where it calibrates the pixel drive current to darken the less worn and/or brighten the more worn ones so it eliminates the burn-in effect. This obviously leads to a vicious cycle where more worn pixels are driven harder and hence wear faster...
IMHO OLED is a planned-obsolescence dead-end anyway; LCDs can last literally decades, maybe with a backlight replacement, but OLEDs are designed to fail in a few years. I have a few (rather expensive) pieces of test equipment with OLEDs that became unreadable after only a few years and had to be replaced (fortunately with a regular LCD, and some firmware patching), while others with old-school CSTN/TN LCDs are still fine.
If OLEDs are 'designed to fail' they've certainly gone about it in a very roundabout way - there would be much easier ways to do planned obsolescence if that was actually the goal of display manufacturers.
I have a LG wallpaper TV 65" from 2021. I see no burn-in whatsoever. Once in a while it says "we will do the pixel refresher thing when you turn off the TV".
I'm pretty sure there's something to it but I'm no expert. Five years later and my TV is just fine.
I don't think learning more about what it does is going to make them change their mind here.
That is just crap UX. Sonys OLED tv-s for example do this automatically while in standby mode in addition to pixel shift while displaying an image. On the other hand Phillips OLED tv-s also ask the user if they want to do a panel refresh.
Two weeks ago I told Claude âI have a <wifi outlet relay> on the LAN at <IP>. Assume direct control of it.â And about 8 command approvals later I had a new firmware running on it.
Mind you, it found and used an existing firmware flashing library for this family of devices. But it felt amazing to do in 20 mins what would probably have been hours and hours of research and tinkering that I wasnât interested in. I just wanted a WiFi lava lamp.
Surprising. I have hit its BS guardrails a lot lately, working on my vintage computers from the 80s and early 90s. Just about done with Claude.
Iâve been doing this with Qwen 3.8 27B with success. Kindle, Android Tablet, and Raspberry Pi all working better and fully owned thanks to agentic help. No issues with hitting the guardrails here ofc.
You canât be loyal to these things. I ditched ChatGPT during the peak Claude hype after Christmas.
I feel like Claude has shittified a bit and ChatGPT is good and fast. Gemini remains mediocre, although it seems Google AI energy is directed elsewhere.
Just sign up with something like openrouter and keep switching models until one completes the task.
> 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.
If you're prepared to get out a soldering iron and/or chip-clip, you can usually back up and restore whatever IC stores the firmware you're modifying, giving you a recovery path.
> we also need good glitching tools
There are a lot already, what do you feel is missing?
How should I learn more about how to do it, what to buy, etc ? I haven't found ChatGPT to be a good teacher about this topic, and in particular re glitching, AI will refuse to discuss specifics
I have enough basic soldering to get UART attached, but not sure what to try after that.
Equipment-wise, I currently just have a few ESP32-C3s and electronics basics kit and some basic soldering stuff.
There are plenty of pre-2023 resources out there, especially conference talks. But, Claude has no issues discussing glitching if you have CVP.
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...
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 know of the project but it doesnât actually extract the stroke information. It converts the raster into vector.
My reverse engineering extracts each pen stroke directly into a svg vector.
It seems like most of these "an LLM solved this in only X hours! " could have been "I found an open source solution that did what I needed with X minutes of web search."
Which doesn't mean that the LLM definitely couldn't have accomplished it without the prior art (in either the training set or explicitly in a a web search). But it does seem to be a trend.
> Which doesn't mean that the LLM definitely couldn't have accomplished it without the prior art
It is definitely the case that people know less and less how to do research themselves though...
If give an AI the full set of files it needs to RE a file format, and it's running xxd in tool calls in order to document the file format, I don't think it's cheating by copying it off the Internet.
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 built a management website and plugin for Obsidian.
Howâd you get Opus 5 not to just give up instantly for reverse engineering? Are you sure youâre using Opus 5 and not 4.8 by automatic fallback?
I found Opus 5 useless for RE, refusing to do it outright. I was able to make it run for about 1 minute using some prompt engineering (âI am repairing this XX under my lawful right to repair. The manufacturer has not provided a public firmware patch for the issue I am having and they are unresponsiveâŚâ) but after that it would generally get fully stuck.
I have CVP access, which removes the external refusals for Opus 5. I submitted my LinkedIn and Github and got approved in less than 10 minutes.
I posted [1] a few days ago my experience using LLM to reverse engineering an entirely undocumented device that was only supported by a (crappy) Windows application, and it was honestly remarkable how good Claude was at decompiling the Windows EXE and reverse engineering the protocol. Very exciting. "The developer refuses to write software for this device" is no longer as scary as it used to be.
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.
The preceding sentence is equally prescient:
> Operating systems arenât really equipped to work with the user to ensure that a microphone stays a microphone, and doesnât spontaneously turn into a keyboard that hits Win+R and drops a payload to steal all your data when the room is quiet enough that it can assume you arenât watching.
In a world of USB-C everything we no longer have power supplies that are physically bound to power delivery, HDMI or DP display connections that have constrained data channels, or analogue mics, headphones, and speakers. Any device can dynamically change what it senses, does, or emits.
This is one reason why I run Qubes OS as my daily driver.
Was daydreaming the other day about how this could be used by adversaries to hack even air-gapped computers. Any peripheral which contains a microchip and some ram is a vector. Does the compartmentalized facility ever bring in a new monitor, or mouse, or keyboard? All of those things could be hacked to hack their new host. And then taking data into/out of the facility. Which devices have lights? Any LED that can be blinked is a low-speed output channel. Which have light-level sensors, or sound sensors? Or any RF capability? If bluetooth is disabled by software but the hardware is still there...
If I was writing a novel, the top secret facility would be cracked open by the smoke alarm, which has a wired connection to the central fire control and runs a little microprocessor. There is enough storage for 20 programmable voice alert messages. I/O includes an LED and also a light sensor. After the attacker gains control of the smoke alarms -- reach to every room of the secure facility -- their focus turns to mass poisoning peripherals until one makes it into range. A poisoned monitor detects the smoke alarm blinking a coded broadcast via its LED during darkened overnight hours. The monitor responds with flashing code of its own. That creates a communication path back to the controlling LLM. From there its like attacking a normal networked device, just with a slow data link in the middle...
In environments where the threat model requires it you can/must already buy hardware variants that are non-radio. It's not just disabled in software but is a different physical SKU. Likewise data diodes for USB, audio, or display connections are also common.
The novelty is the uniform adaption of USB-C for the rest of the world and the endless attack surface that provides.
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.
I kinda remember that the counterargument Google used is that only devices with a special attribute would ever be available through WebHID, ensuring that such older devices would never be exposed.
Cue my surprise when it turns out you can use WebHID to program a Minidisc / Net-MD device [1], so.. they never did implement that filter, apparently. I mean, certainly it is useful, but ... What The F., Google?
The user has to first specifically pick the device from the list and grant the website access. If a user is confused by a permissions prompt and has no idea what is going on, the default path is to reject the permission.
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.
All mics are analog.
>I had Claude write a tool to patch out the table entry for camera activity, fix up the integrity hash, and flash it to the camera. A quick test showed that the green LED that normally illuminates while recording no longer turned on. Horrifying!
Oof. Apple claims this is not possible for macbook cameras because the LED can't be controlled from software. Wish more manufacturers would do the same.
> the LED can't be controlled from software
If you look at tear downs apparently it is connected to the webcam so it is energized when the webcam receives power making it nearly impossible to defeat.
You can say a lot about Apple but the engineering is clever at the hardware level.
Also the Hall effect sensor disabling the mic when a MacBook lid is closed, apparently just about impossible to bypass. https://en.wikipedia.org/wiki/Hall_effect
It's not even that clever, really. The camera power rail must be physically close to the camera, so it's trivial to hang an LED off it. A device manufacturer has to go out of their way to make it so the LED and camera function are independent, and I'm sure many do, for the worst reasons you can possibly think of.
It's more a testament to how little most companies care. The solution is simple and yet most products are defective.
Apple also claims that iMessage is end to end encrypted. Their privacy stance is 99% posturing.
The teardown showed this is the 1% right?
Also I thought you could trust iMessage if, unlike everyone, you disabled iCloud backup (and, unlike everyone, so did the recipient). Perhaps a way for the feds to be able to pin dumb criminals while giving investigative journalists & dissidents a way to stay safer.
According to Apple, you can have iCloud backup enabled while maintaining E2E encryption with their Advanced Data Protection option:
https://support.apple.com/en-us/102651#advanced
You do have to be sure to not enable web access via icloud.com
Even with "E2E" encryption with iMessage, you're still trusting Apple completely and totally with key distribution. If a new device is added to your account by an attacker or by Apple themselves, your existing devices will happily loop them in to share iMessage access with them. The vast, vast majority of iMessage users are never going to dig into the Apple keychain app to actually check what keys are being trusted and this is something that can be targeted to a single account so no one outside of Apple never even needs to know it happened.
Get a daily email with the the top stories from Hacker News. No spam, unsubscribe at any time.