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.
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.
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.
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.
It might be reverse-engineering it, but it also might be kayfabe. (Kayfabe is what professional wrestlers do - the storyline and matches are scripted, but it's presented as real. LLMs excel at doing this.) Similar to how Anthropic showed that their LLMs appear to "think ahead" when writing poetry to come up with a rhyme[1], so too might the knowledge of a file's structure influence how the LLM approaches analysis.
As a simplistic example, suppose one section of the file is known by the model to be bzip2 compressed - the LLM may use xxd to scan for common magic numbers that "just so happens" to include 42 5A (Bz). Every step of analysis is like this - what threads to look for, and which ones to pull on. Somebody or something who mostly-remembers the answer is going to find the answer quicker than if they'd gone in blind.
For all the agentic loops people seem to have come up with, the research loop or as I call it the “Desperate 10th page on Github’s crappy search results” is still not up to the mark.
Either it might be genuine rate limiting these LLM’s face or just that, they are trained to focus on implementing a solution which would be faster and user acceptable solution. (which seems to be a true looking at people pushing LLM generated code as is).
At least in my personal experience with niche projects and heck even with well documented and famous libraries, along with fancy mcp’s, llms.txt and skills; RTFM has been more relevant than usual for code that I have asked an agent to generate, since it is too eager to reimplement functionality which already exists, only if it RTFM!!
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!
> 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.
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.. anything. 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.
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.
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.
WebHID being used to access a microphone is risky though. Microphones are already often exposed to web browsers, so asking for microphone access wouldn't be out of the ordinary.
Maybe MD drives aren't really at risk, but things like HID peripherals definitely are.
Note that when you say “rejected”, Mozilla’s position has actually shifted a bit. At the end of 2022, it shipped MIDI in the form of an extension that it will prompt to install for the purpose, with more detailed information and a couple of other details that make it less unsafe. After a few years of that, consensus has grown that this seems to be working acceptably, and that the technique may be considered for other risky areas. They haven’t said anything about USB publicly, to my knowledge, which is definitely way more dangerous than MIDI (even SysEx), but I have heard one rumour (of dubious provenance) that they may cautiously proceed with USB and such too some time soon. Though this sort of thing definitely weighs against that, showing that maybe they were right the first time.
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?
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)
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), 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).
> 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.
> HDMI or DP display connections that have constrained data channels
HDMI has theoretical support for 100 MBit/s Ethernet [1] but in practice I agree, haven't seen that one used in practice.
IIRC it came in 2009 with HDMI 1.4, at that time Wifi in practice was mostly 802.11g with IIRC 20-ish MBit/s as 802.11n was still formally a draft... the idea was to give high-bandwidth networking to home entertainment devices without requiring to run physical Ethernet to each tiny device, but it quickly became superseded by 802.11n Wifi on one side, and on the other side, the "enrichment" of stuff on DVDs or broadcast TV with internet-based content never truly materialized.
I recently realized something similar. I think that usb-proxy[1] could be used to force what looks like a mass storage device to stay a mass storage device, and likely could be built to be a sort of firewall. usb-proxy is a toy project showing that you can physically "MITM" USB with an RPi, but it could be a starting point.
> > 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
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?
> 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 flashed coreboot on an x220 once [0], and I think that can give you a good overall idea of how backing up and reprogramming an SPI memory works. From that you could do your own research checking the ICs in your hardware, and extrapolating to the correct tools you will need to read/write.
Please make sure you fix the 3.3 V output if you get that device. Most revisions have a PCB layout issue that will output 5V even in 3.3 V, which has bricked stuff before. There are many ways to fix it, one trace cut and one jumper is how I did it.
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 product 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.
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 due to technical design. 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.
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.
"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.
Did the open source movement dream of outsourcing what they loved to do themselves for free, as in both beer and freedom, to products which are trained on the corpus of their own knowledge without any consent and sold by behemoth corporations on a subscription basis?
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 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.
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.
> 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.
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
And thats why we have the warning that everyone bitches about: "Hey, the timer is up, but I'm not gonna make you do it, its just gonna wear the display out faster".
Early OLEDs really did need to be pixel cleaned every 8 hours according to manufacturer estimates, the choice isn't have warning or not, its have a lifespan or not.
I don't want to blame early adopters for being early adopters, but they early adopted, and this is the early adoption problem.
Because the run a full blown OSes on monitors now, and for some reason it cannot figure out the simple "wait until you're off for at least 10 minutes to do the cycle instead of bothering the user at random intervals"
I have an MSI OLED monitor, and if I accidentally turn it off (trying to find the input switcher), and then back on, it shows this warning.
But it automatically runs when it's turned off. The warning is shown because I interrupted it running early.
The warning, for my purposes, is completely useless, and only an annoyance. The automatic feature is more than enough, and I don't need to know if it was aborted early.
Then turn off the warning: all modern OLED monitors that do not force you to run it can both change when the timer fires, but also just disable the notification altogether.
This is what I have done on mine, and mine as well also runs it when its off.
If your monitor is a Samsung OLED panel, yours is a near identical sibling of mine.
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.
Agreed.. and it has an incredibly frustrating and hostile UX.
I've been sharing my screen in work in meetings and suddenly screen nagged, and then I'm struggling to find the dumb buttons under the monitor and confused which button does what to make it go away.
I would rather suffer burn in than be nagged. I've had other brand OLEDs that haven't been this annoying, so I'll never buy an Asus monitor again.
AOC/Agon OLEDs also have the annoying nag that fires repeatedly to say "Your monitor will go into pixel cleaning mode in 10/5/4/3/2/1 minutes". I still haven't figured out how to easily defer that, and it's super annoying when in the middle of a Rocket League match that the monitor just turns itself off to pixel clean for 10 minutes.
> 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.
My MSI monitor does it, I don't object to it in principle. What I do object to is a tool, that I own, demanding this is done on its own schedule rather than mine in a way I can't always dismiss. There's no reason it shouldn't be configurable to do it at three in the morning rather than when I'm trying to run the standup for example.
Definitely will be checking more carefully the next time I buy an OLED monitor that it'll let me do this.
And yet, they own the device. If they choose to not care about burn-in and want their device to respect that, that's their prerogative, not anyone else's.
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 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.
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".
..which then forces the manufacturers to develop better solutions - people who are annoyed by manual maintenance tasks or disruptions buy them - Not a bad scenario for both sides.
Yes? Are you a human or a corporation talking? Has Samsung achieved singularity status and is now posting on HN?
Besides, the negative sentiment that OP shares here sis for me much stronger than any burned pixel, annoyances like this are a sure way for me to not buy a product if I read this in reviews
Why would Samsung care if he burns out his OLED panel? The alert is there only as far as shielding the manufacturer from legal culpability if the unit fails. If they can point and say "Nah, no RMA, this guy only did 3 pixel refreshes in a year or installed unauthorized firmware" then you're on the hook for a new display. Assuming that Samsung has any more investment in enforcing you to pixel refresh is inane.
Do you also skip oil changes thinking "Fuck you, not today, Hyundai!"
OP wants his property to behave in a specific way, clearly knowing the risks.
I'm not seeing how a hypothetical bad review about a $200B company is at all relevant here. The manufacturer's reputation is not in any way OP's problem.
If you own the hardware, it is yours to abuse, break, and do all manner of things that would make the engineers who designed it cringe: you do not owe any allegiance to them.
I think there are actions a user may sometimes wish to take that software should simply refuse, ideally. Some actions are, and can only be, mistakes. I don't think it's a bad idea for software and hardware to defend itself against misinformed, confused, or clumsy users.
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.
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 use it as a monitor as well. I think the key here is what LG calls "screen shift" which makes obvious sense. No magic, just move the pixels around to prevent stuff like HUD and logos from burning the screen.
Yeah OLEDs are the first display tech we've had that is on par or better than CRTs in all aspects. On balance the tradeoffs were probably worth it for the various LCD panel options but motion clarity, colour intensity and black levels were all still beaten by a CRT in a dark room until we got OLEDs.
OLED burn in is not "planned obsolescence" any more than the "self-emptying gas tank". That's pure ignorance.
OLEDs burn in because of simple physics. The same reason your car's gas tank empties when you use it instead of some secret cabal stealing your gas to make you buy more. Ignorant nonsense.
It's not "simple" physics. Or can you explain the physics?
Every display technology tries to suffer burn in if there's any long-term physical change at all from lighting up a pixel, because it will affect the ones that are lit up more often. That part is simple. However we did get around it with every other technology so please explain why it's not even theoretically preventable with OLED.
I have an ASUS PG32UCDM and an ASUS XG27UCDMG, and both can permanently disable the "pixel cleaning reminder." Have you tried update firmware and look in the monitor UI?
Yep, Claude did well here. From the experiment, to the website design, to more than likely all the writing/summaries. What is truly fascinating is not that long ago people were doing hard experiments regularly like this without any LLMs.
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.
>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.
That's not what people mean by 'bypassing', turning it off is obviously easy. The point is that activating the microphone while the lid is closed is pretty much impossible.
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.
Yeah, and then came people hiding cameras in places where you clearly did not want a camera to be. Bathrooms in public areas, hotels, workplaces and AirBnBs are a much too common issue, it's like daily news some creep gets busted for running cameras.
Yeah, my implication was just that the worst thing I could think of were cameras where the owners don't realize that some third-party is recording them.
LEDs won't stop creeps — the camera owner can always disable LEDs with a bit of electrical tape.
> Yeah, my implication was just that the worst thing I could think of were cameras where the owners don't realize that some third-party is recording them.
At the point we are in time... honestly, I don't expect this thing called "privacy" any more. And I'm, notably, German. Glassholes, camera surveillance everywhere, our police is more and more turning into the rabid hellscape that is American police with far-right authoritarians at the helm and more and more forces joining up with Palantir or working on a European alternative.
I'm dead sure that at least law enforcement plus dedicated individuals with access to ad data brokers can work out precisely when I had a wank and what I wanked to, now there being a video of me wanking would only be the icing on the cake.
> LEDs won't stop creeps — the camera owner can always disable LEDs with a bit of electrical tape.
Many even forget about that piece of opsec, which is why they get caught in the first place, eventually the tape falls off.
It could be a typical design that the camera and LED always have power, and the LED is switchable.
Giving the camera plus LED a separate power supply means that the camera has to boot or come online, which maybe increases the dwell time. And the camera is not visible on the USB bus when powered off.
I think there's more engineering to Apple's design than it first seems.
The thing visible on the bus is the interface chip, not the sensor. Most cameras which I've seen hardwire their activity LEDs (it is impossible to grab stills or record video without lighting up the LED) do so by connecting the activity LED to the sensor power rail. With the sensor powered off, the device is still visible on the bus but you get no usable image data.
This still would allow one to "strobe" the power line making it impossible for a human to see the LED but the camera could still capture snapshots and at a decent framerate even.
Naw the LED stays on a little longer after you stop capturing image data. They either have burned in firmware or a simple circuit (RC and comparator) that stops your attack.
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.
> An unrecognized new device was added to that person’s Apple Account. This alert might mean that the person you are messaging has an issue with one of their devices, or that a sophisticated attacker might be attempting to eavesdrop on the conversation.
My understanding is that iMessage implements PFS. To get around PFS and access older messages, one needs to get their hand on a backup, which needs fully enrolling a device, not just messaging key exchange hackery.
And as far
as trusting Apple with key exchange, well, if you're running their OS and hardware, I suppose that trust of key exchange is the least of your concern (or part of the whole deal anyway depending on how you look at it)
Uh-oh, I have that turned off. I’m used to seeing a message when someone on Signal gets a new phone, but I’d be none the wiser with a snooper on iMessage. Any downsides to enabling you know of? Assuming all my logged-in devices are on a current/supported version.
One of my old Logitech webcams have its recording light wired up to V4L2 protocol directly. I can change its recording light mode (on/off/blink) from software by changing recording light mode directly. Wonder whether that Insta360 also had that.
I'd have tried that first before diving into the firmware head-first.
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.
A highly modular plugin system would solve this though. A great base product, with plugins (both community & official) which could expand feature sets.
Isn't this just a short-lived renaissance? I assume manufacturers will use the same tools to "armor" new firmware and devices against "attack". Consumer rights regulations that require devices to be open for owner modification is the real answer.
308 comments
[ 0.25 ms ] story [ 19.0 ms ] threadI 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?
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/
https://supernote.ifup.org/
https://youtu.be/ihRh_F43-iQ
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...
As a simplistic example, suppose one section of the file is known by the model to be bzip2 compressed - the LLM may use xxd to scan for common magic numbers that "just so happens" to include 42 5A (Bz). Every step of analysis is like this - what threads to look for, and which ones to pull on. Somebody or something who mostly-remembers the answer is going to find the answer quicker than if they'd gone in blind.
[1] https://www.anthropic.com/research/tracing-thoughts-language...
For all the agentic loops people seem to have come up with, the research loop or as I call it the “Desperate 10th page on Github’s crappy search results” is still not up to the mark.
Either it might be genuine rate limiting these LLM’s face or just that, they are trained to focus on implementing a solution which would be faster and user acceptable solution. (which seems to be a true looking at people pushing LLM generated code as is).
At least in my personal experience with niche projects and heck even with well documented and famous libraries, along with fancy mcp’s, llms.txt and skills; RTFM has been more relevant than usual for code that I have asked an agent to generate, since it is too eager to reimplement functionality which already exists, only if it RTFM!!
LLMs make low-quality output in high volumes, and sometimes we find a situation where that's actually good - like this one!
My reverse engineering extracts each pen stroke directly into a svg vector.
https://philips.github.io/supernote-web-component/
Click the "Pen" icon then the "Play" button.
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!
Ah, there's the rub.
> 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.
Cue my surprise when it turns out you can use WebHID to program a Minidisc / Net-MD device [1], so.. anything. I mean, certainly it is useful, but ... What The F., Google?
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.
Maybe MD drives aren't really at risk, but things like HID peripherals definitely are.
Do we live in a bizarro world now where we expect - no, demand - our hardware be locked down?
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)
> 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.
HDMI has theoretical support for 100 MBit/s Ethernet [1] but in practice I agree, haven't seen that one used in practice.
IIRC it came in 2009 with HDMI 1.4, at that time Wifi in practice was mostly 802.11g with IIRC 20-ish MBit/s as 802.11n was still formally a draft... the idea was to give high-bandwidth networking to home entertainment devices without requiring to run physical Ethernet to each tiny device, but it quickly became superseded by 802.11n Wifi on one side, and on the other side, the "enrichment" of stuff on DVDs or broadcast TV with internet-based content never truly materialized.
[1] https://en.wikipedia.org/wiki/HDMI#HEC
[1] https://github.com/AristoChen/usb-proxy
Some operating systems can protect you from that. See: https://qubes-os.org.
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.
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.
[0] https://stoisavljevic.com/articles/coreboot
https://libreboot.org/docs/install/spi.html#do-not-buy-ch341...
Programming has always been about putting more power into the tools.
Sadly, there doesn’t seem to be as much need for hardcore engineers.
Yet for some reason I can’t escape these annoying pixel cleaning interruptions. Seems like a bug in the firmware.
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 due to technical design. 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.
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.
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.
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.
Early OLEDs really did need to be pixel cleaned every 8 hours according to manufacturer estimates, the choice isn't have warning or not, its have a lifespan or not.
I don't want to blame early adopters for being early adopters, but they early adopted, and this is the early adoption problem.
But it automatically runs when it's turned off. The warning is shown because I interrupted it running early.
The warning, for my purposes, is completely useless, and only an annoyance. The automatic feature is more than enough, and I don't need to know if it was aborted early.
This is what I have done on mine, and mine as well also runs it when its off.
If your monitor is a Samsung OLED panel, yours is a near identical sibling of mine.
I've been sharing my screen in work in meetings and suddenly screen nagged, and then I'm struggling to find the dumb buttons under the monitor and confused which button does what to make it go away.
I would rather suffer burn in than be nagged. I've had other brand OLEDs that haven't been this annoying, so I'll never buy an Asus monitor again.
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?
It comes down to the joy of doing things, and if the joy of using said monitor depends on a popup not being shown, then so be it.
I hope that the popup can be removed :)
Definitely will be checking more carefully the next time I buy an OLED monitor that it'll let me do 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 .
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.
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.
Besides, the negative sentiment that OP shares here sis for me much stronger than any burned pixel, annoyances like this are a sure way for me to not buy a product if I read this in reviews
Do you also skip oil changes thinking "Fuck you, not today, Hyundai!"
I'm not seeing how a hypothetical bad review about a $200B company is at all relevant here. The manufacturer's reputation is not in any way OP's problem.
If you own the hardware, it is yours to abuse, break, and do all manner of things that would make the engineers who designed it cringe: you do not owe any allegiance to them.
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.
A monitor displays items that can stay fixed in place a long time, hours or even days.
Not the same at all.
Extremely accurate and vivid colors due to their low black level.
And VERY fast pixel response times, 0.01ms to 0.03ms compared to 1ms to 5ms for the fastest LCD gaming monitors.
OLEDs burn in because of simple physics. The same reason your car's gas tank empties when you use it instead of some secret cabal stealing your gas to make you buy more. Ignorant nonsense.
Every display technology tries to suffer burn in if there's any long-term physical change at all from lighting up a pixel, because it will affect the ones that are lit up more often. That part is simple. However we did get around it with every other technology so please explain why it's not even theoretically preventable with OLED.
Like Dublin, in the rare ould times.
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.
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.
I’m at a loss for how you would signal all of that without a GPIO.
LEDs won't stop creeps — the camera owner can always disable LEDs with a bit of electrical tape.
At the point we are in time... honestly, I don't expect this thing called "privacy" any more. And I'm, notably, German. Glassholes, camera surveillance everywhere, our police is more and more turning into the rabid hellscape that is American police with far-right authoritarians at the helm and more and more forces joining up with Palantir or working on a European alternative.
I'm dead sure that at least law enforcement plus dedicated individuals with access to ad data brokers can work out precisely when I had a wank and what I wanked to, now there being a video of me wanking would only be the icing on the cake.
> LEDs won't stop creeps — the camera owner can always disable LEDs with a bit of electrical tape.
Many even forget about that piece of opsec, which is why they get caught in the first place, eventually the tape falls off.
Giving the camera plus LED a separate power supply means that the camera has to boot or come online, which maybe increases the dwell time. And the camera is not visible on the USB bus when powered off.
I think there's more engineering to Apple's design than it first seems.
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/118246
https://support.apple.com/en-us/118247
> An unrecognized new device was added to that person’s Apple Account. This alert might mean that the person you are messaging has an issue with one of their devices, or that a sophisticated attacker might be attempting to eavesdrop on the conversation.
My understanding is that iMessage implements PFS. To get around PFS and access older messages, one needs to get their hand on a backup, which needs fully enrolling a device, not just messaging key exchange hackery.
And as far as trusting Apple with key exchange, well, if you're running their OS and hardware, I suppose that trust of key exchange is the least of your concern (or part of the whole deal anyway depending on how you look at it)
I'd have tried that first before diving into the firmware head-first.
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.