> 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?
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
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 looked it up, his monitor does do it automatically after it's been powered off for a few minutes. He's getting the nag message because the monitor has been on and displaying a picture for over 8 hours.
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.
Perhaps you didn't read the text you just copied and pasted, but here it is for you:
"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."
No need for ackshually, the guy is clear with what he desires. That is, by the way, the point of TFA. I want my devices to do what I want, not what a product manager wants or what a dude on hacker news wants.
The author even dropped a comment here doubling down on his intent. That is the main problem, when the smaht guys think they know better, to a pathological extent where they tell other people what they ought to do with their things .
The user should be the final authority over what his computer does. Not the computer manufacturer. Not the OS developer. Not the 3P app developer. Not some product manager at a software company. The end user.
Even time computer says no, or does something without your permission, or does something counter to your wishes, or alerts you to do something, or urges you to do something, or makes you opt-out, is a failure.
The end user disables pixel cleaning because the pop-up annoys them. They then start bitching about burn-in within 6 months, RMA the monitor even though it was their choice to do so, and spread negative sentiment about your brand going forward for being "prone to burn in".
>...the smaht guys think they know better, to a pathological extent where they tell other people what they ought to do with their things .
Not just tell, actually nag, coerce and force, often in the teeth of their own total idiocy.
"Your password needs to be between 8 and 15 characters and include an upper case letter, a symbol and a number. (And an actually good, strong password will be rejected).
See that all the time, still, in 2026. So very smaht.
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.
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.
> 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.
I guess this is a fine reply but just seeing your earlier comment, mentioning there are tons of glitching tools out there, I would've hoped to hear about some specifics here. Just my 2c
Is this the zoomer syndrome I am hearing about lately? My friend says zoomer coworkers increasingly start asking easily searchable questions, and also (this part is not your comment, just my 2c) in a demanding tone like you owe them money. Allegedly they spend all their time in LLMs and lose the ability to gather information
I wonder what humanity will look like in 20 years if this doesn't stop.
Look, he doesn't know what to search for. He doesn't have your experience to know what is crap and what is good info, and the big models will ninny-nanny him for '''safety reasons.''' There is so much more shit to wade through today than a decade ago. Cut the kid some slack and be a mentor! Gatekeeping kills.
This is timely! I'm trying to take control of my Echo Wall Clock which connects to an Alexa device that I want to get rid of. There's very little info on it but Claude was able to find the FCC filings and now we've got lo-res images of the circuit board. It's inspecting the test pads on the circuit board now to see if it can figure out how to replace the firmware.
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 :)
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.
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 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.
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.
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.
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.
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.
> 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.
> 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.
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.
In the real world the default action for a user when presented with a permissions popup is to accept it because they get asked 20 times a day, have no idea what the implications of it are and just want to get on with their day.
So software designers need to avoid asking the users to approve potentially highly dangerous things.
This is untrue. Chrome's "acceptance rates" for proceeding through its bad SSL cert warnings used to be pretty high, but with a redesign they basically flipped the numbers so most people didn't proceed to connect to the site. Similarly with cookie banners, where making it more difficult to say no (by e.g. moving a decline button to a second interaction layer) meaningfully raises acceptance rates; if users were just blindly accepting everything, then there'd be no reason to make it harder to say no. Apple's App Tracking Transparency (ATT) prompt has users overwhelmingly answering no even years after introduction (though of course opt-in is increasing). A study on permission prompts in Android found that the main factor in first-use denial rates was whether users thought the app needed the permission it was requesting or not, showing some actual comprehension of what they're being asked. Another found higher denial rates if the frequency of the prompt was on every access instead of once, rather than apathetic blanket acceptance.
Design prompts for potentially dangerous actions so refusal is easy and what's being asked is legible, and people will refuse plenty.
I think Safari does this with popups & downloads. Tiny little icons that barely appear [to change]. Can annoy me when I miss them but sometimes I figure maybe it’s for The Greater Good.
You realize that most of the time that you are giving access to an older HID device, you are giving the website permission to convert that device into a persistent backdoor forever? No matter if you later close the browser or revoke the permission -- the damage has already been done? Most devices predating WebHID and the like have almost no protection (why would they?), and you can corrupt or even entirely replace the firmware quite easily. heck, NetMD is one example (the browser can overwrite its firmware with no trouble!), as are the devices listed in TFA .
It is basically the same reason most desktops do not give the logged in user access to /dev/hidraw*, even though it makes a shitton of sense and would simplify many things greatly.
This is one of the few areas where I think Mozilla did the right thing without question.
WebUSB has been live in Chrome for 9 years and nothing happened. Compare to all the features that result in people getting hacked every day. Your threat model is ridiculous.
Look, I find it funny that I find myself arguing on the other side of the discussion that I'm frequently on, but here is where I draw the line, and I think what is ridiculous is to think otherwise.
How many hoops Google asks you to go to install an Android app ? (Androids amounts to basically the most sandboxed environment one can have today; malware installed there can practically do _nothing_) MANY. Centralized register of apps and remote blacklisting, a lot of permission prompts, password check, and they are even literally pushing to even have a physical 24h cool-off period if you skip the centralized register.
How many hoops does Google ask you to go an allow a random website unfettered access to destroy your hardware? One. Permission. Prompt. In a bubble prompt, that barely registers above noise compared to other permission prompts browsers ask.
Of course these are two ridiculous extremes, but they exemplify the point. There is a reason a browser won't allow a random website to write over random sectors of your hard disk just because you said "accept" to a bubble-style permission prompt about wanting to "save files to your hard disk". The line has to be drawn somewhere, and allowing what basically amounts to raw access to IO ports just after a single permission prompt listing the device name is where I draw it. Any user, even knowledgeable ones, is simply going to be _incapable_ of truly understanding the risks behind allowing this access.
I would be much more in favor of allowing random IPC to services in your local computer (after a permission prompt) than this., something that is equally useful if not more than allow raw access to HID.
Devices need to be hidden behind drivers that multiplex and control access to the device at the OS level. A bus that was never meant to be exposed to user-level access should not be exposed to random programs much less websites. This is not security, this is "mistake prevention" level, in the same way operating systems disallow a random user-level program from overwriting the hard disk.
And do not read this as "devices should sign their firmwares and what not". That is (for me) definitely the wrong take but literally the only take that is left on the table due to Google's stupid behavior.
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.
You make a good point: hardware should not be default-locked from owner control and manipulation in the name of security. In fact, in the name of security, the default should be open enough to not only manipulate and reflash through owner accessible channels, it should also be easily flashable through chip clips in the worst case compromise scenario. Owner control of all Universal Machines in an object he owns must be a paramount right, akin to the first and second amendments in the bill of rights! This includes your game consoles, vehicles, stoves, washing machines, TVs, microwaves, and even that Qualcomm processor in cellphone basebands. If it is a Universal Machine which executes code from writeable storage (or firmware/microcode provided to it, like during OS boot or driver initialization), it must permit owners to change it. If it comes with cryptographic integrity check keys, the owner must be able to both write his own keys and purge the OEM's keys. Behavior should not change, even the warning Google Pixels give immediately on turn-on are unacceptable, unless it does it by default for the OEM's keys and firmware too; no change in product behavior or appearance when an owner exercises his right to modify his Universal Machines, except where the change arises from the firmware itself that the owner applies.
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.
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.
We have a Samsung Frame TV. I told Codex to scan our network to find it and then build a custom tool for updating the image gallery that it uses when it's in "art" mode. It did that, and now I can tell a Codex session controlled from my phone to "use this image" and it shows up on the TV a few moments later.
I desperately want this, but our Frame has never been connected to the Wifi, and I'm really reluctant to do so, as it will probably start snitching and/or delivering ads...
Nice! I actually built something similar back in early 2023 [1], which used a collection of SDXL models to generate a new random painting every hour upscaled to 4K and then broadcasted to my frame using the Samsung WS API wrapper [2].
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!
We were already there. For most people, we are still there. For most devices (especially popular ones, with enough manufacturing volume) there's just enough hardening, downgrade prevention, encrypted or signed firmware blobs, on top of already rare reverse engineering skills and patience, to make it infeasible for most people to give it a crack. Using an LLM for that also isn't a mainstream idea either (plus you're unlikely to have a Claude subscription if you're not a software developer in the first place).
Open systems are great and all in the idea, but the facts are that for profit companies do the research and produce most of the things.
>We were already there. For most people, we are still there. For most devices (especially popular ones, with enough manufacturing volume) there's just enough hardening, downgrade prevention, encrypted or signed firmware blobs, on top of already rare reverse engineering skills and patience, to make it infeasible for most people to give it a crack.
This should be illegal. Any politicians who run on [economically, financially] doing to these companies what is being done to Russia and Iran, if they refuse to immediately publish their hardware private keys, I will vote for. Up to and including jailing boards, stiffing bond and equity holders, and selling their assets as scrap, if they choose to purge their keys to prevent disclosure or if disclosure is impossible. Maybe if a few trillion dollars worth of businesses suddenly vaporize into legal smoke, the remainders will start behaving for the next hundred years...
I think that this is not true -- the achievements mentioned here are hardly ground breaking and mostly build on work that was already done years before LLMs were a thing.
There are things that the "open source movement" dreams about, and one just has to search around... E.g. like codecs, Qualcomm's aptX lossless, adaptative, and other more recent variations.
It's not new capabilities, it's new levels of access. Reverse engineering this stuff used to be a very tedious process which required a lot of specialised skill. Which is why most devices haven't been reverse engineered or hacked despite being full of low hanging fruit.
"only ever" feels like a stretch. Libratbag, QMK, OpenWRT, Nouveau and Asahi all took up the task without much or any AI help. They're not all just dreamers.
There's a difference between the people sitting at the table and the mice scurrying around catching the crumbs. Freedom is sitting at the table. The OP, sadly, is catching the crumbs.
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 have one of their dry food ones and no longer need it. Sad story, but it happens.
My cat scarfed and barfed periodically, and I always wanted the Petlibro (the simple one) to slow feed by incrementally turning the auger, just to see if it helped. I might dig it out and try my hand at this.
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 kind of funny, but AI can also use an oscilloscope. My friend vibe coded a software synth on a Raspberry Pi Pico. When he realized his oscilloscope had a network interface, he had Claude figure out how to connect to it over the network and analyze the actual audio output.
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 certain if it can be “tricked” into using it with the LED off, there is certainly a feature being sold to “enterprises” where it happens on purpose.
I guess there is this dream that AI will help us finally close the Linux driver gap, and maybe even conquer the android phone closed hardware driver conundrum making almost every phone locked down. One can hope.
I can see the benefit of from-scratch personalized software, but in the spirit of open-source, how about all the world contributes to useful software for everyone else?
Better than each person doing “4.2 hours of Claude churn, 32 prompts” for each device. And of course LLMs can help personalize existing things for your use case.
I'm starting to believe that bespoke, personalized software is the only way to combat feature bloat. Every software (proprietary or open source) I download and use has features I don't want getting in the way and bugs that the developers/maintainers are not prioritizing.
I ended up vibe coding my own Android TV media player because every single other one out there has too much feature bloat and show stopping bugs. My version has exactly the features I want and (very importantly) no more.
I spent a decade in robotics and have built firmware for dozens of devices. And yet I was never able to successfully fix my webcam device driver on linux with Claude. I'm jealous of this person's prompting skills! Or perhaps pwning is easier than fixing the nightmare that is Intel open source device drivers?
Built custom firmware for my Line 6 Pod GO HD guitar multi-fx the other day. Turned into a complete midi controller so it wasn't gathering dust. Fun times!
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.
we could have ended planned obsolescence decades ago if we put strong policies in place. I would really like a systemic solution instead of every-man-for-himself vibe coding. I've been following the "stop killing games" movement for that reason. fingers crossed.
This looks like an ad for a bunch of products as "hackable". The Authors only other blog post is also about using Claude for similar ideas, without actually showing the end product from a kick skim.
Anthropic has been run "Use Claude for hardware" ads nonstop. Seems very suss.
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.
Sure, someone at the bottom of the totem pole may not have autonomy to make decisions. There are others who can dictate policy. Is there no LG salesman who wants to take home this unit and becomes embarrassed about the behavior? A LG VP who might have this very unit on the desk?
The second day of owning this monitor and seeing the same message should be a wake up call to everyone in the LG product line to fix the annoyance.
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?
As FW engineer, I am both horrified and intrigued.
The fact that there are so many devices lack even basic security features horrified me. A webcam that activity light can be turned off remotely, that's a big no no for me.
But the use of LLM is also very interesting, we may put LLM in the loop to harden our devices.
Sorry community, but it's our job to make the reverse engineer harder.
If you can use a custom chip yep, if it's commodity hardware probably not. You could use secure boot/secure memory etc but that can be a footgun in itself later.
I have been tinkering with various firmwares of devices around the house lately as well. I have an agent hooked up to various GPIO pinouts and play lab monkey for it. Honestly they are getting better and better at exploratory research and self-supervision for these kinds of tasks and it's fun to watch. I don't often have to interject, though sometimes I do.
I watched an agent identify and find the correct firmware for a device by taking photos of its circuit boards and comparing them to those found online in internal documentation, patents, parts sheets, etc.
It's pretty fun! If you have your HAM license you can do some fun stuff letting an agemt control an SDR, too. Still a lot of fun to be had even in passive mode.
It will be interesting watching what kind of tinkerer/hacker/enthusiast cultures arises from these new paradigms. Wait til people start suping up their vehicles with natural language agents that have access to subsystems. Imagine entire automated labs hooked up to agents.
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.
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.
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?
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.
I'm pretty sure there's something to it but I'm no expert. Five years later and my TV is just fine.
Or ask for a patch so it runs after the monitor has been powered off for a while...
I use an LG OLED 42inch TV as a monitor and it has a setting to do just this.
"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."
No need for ackshually, the guy is clear with what he desires. That is, by the way, the point of TFA. I want my devices to do what I want, not what a product manager wants or what a dude on hacker news wants.
The author even dropped a comment here doubling down on his intent. That is the main problem, when the smaht guys think they know better, to a pathological extent where they tell other people what they ought to do with their things .
Even time computer says no, or does something without your permission, or does something counter to your wishes, or alerts you to do something, or urges you to do something, or makes you opt-out, is a failure.
Not just tell, actually nag, coerce and force, often in the teeth of their own total idiocy.
"Your password needs to be between 8 and 15 characters and include an upper case letter, a symbol and a number. (And an actually good, strong password will be rejected).
See that all the time, still, in 2026. So very smaht.
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.
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.
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.
> we also need good glitching tools
There are a lot already, what do you feel is missing?
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.
I wonder what humanity will look like in 20 years if this doesn't stop.
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/
My reverse engineering extracts each pen stroke directly into a svg vector.
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.
It is definitely the case that people know less and less how to do research themselves though...
https://supernote.ifup.org/
https://youtu.be/ihRh_F43-iQ
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.
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 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.
https://support.apple.com/en-us/102651#advanced
You do have to be sure to not enable web access via icloud.com
Much easier to use a 3rd party app like Signal.
> 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.
> 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.
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...
The novelty is the uniform adaption of USB-C for the rest of the world and the endless attack surface that provides.
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?
[1] https://web.minidisc.wiki/
So software designers need to avoid asking the users to approve potentially highly dangerous things.
Design prompts for potentially dangerous actions so refusal is easy and what's being asked is legible, and people will refuse plenty.
It is basically the same reason most desktops do not give the logged in user access to /dev/hidraw*, even though it makes a shitton of sense and would simplify many things greatly.
This is one of the few areas where I think Mozilla did the right thing without question.
How many hoops Google asks you to go to install an Android app ? (Androids amounts to basically the most sandboxed environment one can have today; malware installed there can practically do _nothing_) MANY. Centralized register of apps and remote blacklisting, a lot of permission prompts, password check, and they are even literally pushing to even have a physical 24h cool-off period if you skip the centralized register.
How many hoops does Google ask you to go an allow a random website unfettered access to destroy your hardware? One. Permission. Prompt. In a bubble prompt, that barely registers above noise compared to other permission prompts browsers ask.
Of course these are two ridiculous extremes, but they exemplify the point. There is a reason a browser won't allow a random website to write over random sectors of your hard disk just because you said "accept" to a bubble-style permission prompt about wanting to "save files to your hard disk". The line has to be drawn somewhere, and allowing what basically amounts to raw access to IO ports just after a single permission prompt listing the device name is where I draw it. Any user, even knowledgeable ones, is simply going to be _incapable_ of truly understanding the risks behind allowing this access.
I would be much more in favor of allowing random IPC to services in your local computer (after a permission prompt) than this., something that is equally useful if not more than allow raw access to HID.
Devices need to be hidden behind drivers that multiplex and control access to the device at the OS level. A bus that was never meant to be exposed to user-level access should not be exposed to random programs much less websites. This is not security, this is "mistake prevention" level, in the same way operating systems disallow a random user-level program from overwriting the hard disk.
And do not read this as "devices should sign their firmwares and what not". That is (for me) definitely the wrong take but literally the only take that is left on the table due to Google's stupid behavior.
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.
1: https://news.ycombinator.com/item?id=49353141
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.
[1] - https://mordenstar.com/projects/save-our-screens
[2] - https://github.com/xchwarze/samsung-tv-ws-api
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!
There’s no substitute for having open systems that aren’t cryptographically locked down by the manufacturer.
Open systems are great and all in the idea, but the facts are that for profit companies do the research and produce most of the things.
This should be illegal. Any politicians who run on [economically, financially] doing to these companies what is being done to Russia and Iran, if they refuse to immediately publish their hardware private keys, I will vote for. Up to and including jailing boards, stiffing bond and equity holders, and selling their assets as scrap, if they choose to purge their keys to prevent disclosure or if disclosure is impossible. Maybe if a few trillion dollars worth of businesses suddenly vaporize into legal smoke, the remainders will start behaving for the next hundred years...
There are things that the "open source movement" dreams about, and one just has to search around... E.g. like codecs, Qualcomm's aptX lossless, adaptative, and other more recent variations.
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.
Weird question anyway. Why eat food at all if you can't be bothered to farm it yourself.
My cat scarfed and barfed periodically, and I always wanted the Petlibro (the simple one) to slow feed by incrementally turning the auger, just to see if it helped. I might dig it out and try my hand at this.
Better than each person doing “4.2 hours of Claude churn, 32 prompts” for each device. And of course LLMs can help personalize existing things for your use case.
I ended up vibe coding my own Android TV media player because every single other one out there has too much feature bloat and show stopping bugs. My version has exactly the features I want and (very importantly) no more.
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.
Everyone should read Daemon and Freedom, like right now.
Anthropic has been run "Use Claude for hardware" ads nonstop. Seems very suss.
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?
Yet for some reason I can’t escape these annoying pixel cleaning interruptions. Seems like a bug in the firmware.
Why hasn't that happened?
The second day of owning this monitor and seeing the same message should be a wake up call to everyone in the LG product line to fix the annoyance.
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.
Programming has always been about putting more power into the tools.
Sadly, there doesn’t seem to be as much need for hardcore engineers.
The fact that there are so many devices lack even basic security features horrified me. A webcam that activity light can be turned off remotely, that's a big no no for me.
But the use of LLM is also very interesting, we may put LLM in the loop to harden our devices.
Sorry community, but it's our job to make the reverse engineer harder.
I watched an agent identify and find the correct firmware for a device by taking photos of its circuit boards and comparing them to those found online in internal documentation, patents, parts sheets, etc.
It's pretty fun! If you have your HAM license you can do some fun stuff letting an agemt control an SDR, too. Still a lot of fun to be had even in passive mode.
It will be interesting watching what kind of tinkerer/hacker/enthusiast cultures arises from these new paradigms. Wait til people start suping up their vehicles with natural language agents that have access to subsystems. Imagine entire automated labs hooked up to agents.