alt Hacker NewsEverything I own, owned
Comments
> 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.
I just reverse engineered the Supernote note file format with an agent a few weeks ago. For years the community had been asking for a document on the format. And in a few hours the agent, with 20 something file format example fixtures and 30 something prompts, was able to reverse out the format.
It would have been completely not worth the effort to do this by hand for a niche device. Now, in a few hours of effort there is working code and a doc.
https://github.com/philips/supernote-typescript/blob/main/pl...
I definitely love this article and this spirit. I've accumulated a lot of crap/cheap IoT, I'll probably owning them!
Two things:
- to rain on the parade, the European RED directive makes secure upgrades mandatory for anything connected to the internet (I suspect that's why Elgato Key Light Mini has signed firmwares). So OEMs are now required to prevent you from doing that. (EN18031-1). It even requires that network credentials (WiFi SSID/PSK) to be stored on secure storage (idk if you can pass that requirement without secure boot. I would guess Elgato does?). "secure upgrade" is loosely defined as "integrity and authenticity are valid at the time of installation" so this requirement doesn't forbid us from upgrading our hardware, but the most likely implementation of OEMs does.
- When you want to do that on Android smartphones (please do!): I recommend to go through GSI/Treble route: This way you quickly have an OS that boots. There are a lot of things to fix, but it will be mostly userspace stuff, which will be easier for the agent to work with. Agent will be able to decompile OEM's userspace and compare with AOSP's userspace, and implement the differences. (That's compared to the ""legacy"" or LineageOS official method which are more convoluted, including kernel stuff, and getting just to "it boots" can be complicated).
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 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.
Key takeaway:
> And the existence of WebUSB, WebHID, and WebBluetooth mean that for some devices, depending on the specifics of which classes are used, a moment of user indiscretion in accepting a permissions prompt could permanently backdoor one of their attached devices.
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!
TBH this is one of a few things that feels exciting about LLMs. I've recently revived a flip-dot panel from an old bus by reverse engineering and replacing its firmware -- https://www.bobek.cz/buse/
>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.
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.
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.
Inspired by this article I started to work on migrating my cat's feeder to ESPHome. Within 2 mere hours I'm am basically done but also wanted to RE their update path to avoid having to connect to UART to flash the new firmware. To my surprise, the stock firmware has some issue with the vendor's server where it downgrades to plain HTTP after 5 retries. It exposes all keys, device id and firmware upgrade path to MITM attacks. Absolutely bonkers and it shows how bad these IoT companies are at security.
Vendor is PetKit btw.
At this point manufacturers should just open-source their firmwares as there's no barrier for entry to reverse engineer it. They will instead gain from army of end-users willing to put their time and tokens into fixing their bugs for free.
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.
It's amazing to see LLMs give us software and hardware freedoms that the open source movement has only ever dreamed about.
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.
An Agent helped me get a Windows XP Korean MMORPG private server running on my Steam Deck last week. The community obviously got us most of the way there (huge props to them) but setting it up on Linux seemed like a brick wall. Now it works. Amazing for keeping old tech open and running: https://github.com/P0nk/Cosmic/discussions/350
People are praising how this new age of owning our stuff is here, while actually all this will bring is stricter lockdown in every level of the supply chain. Enjoy while it lasts, but I expect even more closed stuff, and less openness from these t.rends
I've been on a similar (if less ambitious) jam. I found that ping-ponging between Fable and Sol if one of them get stuck or refuse has been wildly succesful.
Firmware for Onyx Boox apps: https://github.com/hbmartin/onyx-android-sdk
Mac / Metal drivers for Kinect 360: https://github.com/hbmartin/libfreenect2-metal
Mac driver and control app for Razer's cooling pad: https://github.com/hbmartin/razer-cooling-pad-mac
AI PR department at it again: sell to hackers what they ostensibly used to love doing themselves babbling about the ideals of freedom and openness.
So much for the "hackers", I guess.
What I wish is that we started reverse-engineering audio receivers, many of which run regular Linux. Manufacturers tend to release the new models with hardly any hardware changes, sometimes only software updates. To be able to backport an Airplay2 to an older, fully functional receiver would be amazing.
I'd also love for someone to RE a Google Home or Alexa to be usable with custom models and Esp home/Home Assistant.
I did this just yesterday with a smart light. Used Deepseek-v4-flash. In about 2h I had a custom firmware on the smart light running that I could control from its api endpoints. Also now Im hosting a small web-server on there that lets me set schedules and sleep timers. No im not relying on their proprietary cloud anymore to toggle my lights. Which is insane to start with. Why should my phone that is in my home network need to send the "light on" command ot some cloud in a different country, only to then send the command back into my home network and turn the light on.
Im definitly very exited to try this our with more devices in my live.
Perhaps I’m daydreaming, but maybe some vendors will accept this new reality and begin just selling the hardware without locking users in. Perhaps they’ll even make it easier for users to truly own their products.
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 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.
How’d you get Opus 5 not to just give up instantly for reverse engineering? Are you sure you’re using Opus 5 and not 4.8 by automatic fallback?
I found Opus 5 useless for RE, refusing to do it outright. I was able to make it run for about 1 minute using some prompt engineering (“I am repairing this XX under my lawful right to repair. The manufacturer has not provided a public firmware patch for the issue I am having and they are unresponsive…”) but after that it would generally get fully stuck.
I 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 am wondering if there is a list of “things you should learn to do with your LLM” (But not the rubbish ads youtube keeps showing me)
Reverse engineering seems a good one (ev en if his RE nix sandbox looks fairly usable, it seems like a weekend to get this working.
I posted this on another thread but can someone please run this on some old iPads so we can be able to fully install Linux on them. If AI is so good surely it can do that and save millions of devices from turning into ewaste.
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.
My Sony TV also faced some issues in the past, which at least let me start some investigation. Unfortunately it confirmed my assumptions that the hardware is very limited and already runs on full load most of the time. Still thinking about putting some more effort into this, but killing the device was also one of my concerns.
A really fun project was extendending the abilities of my reMarkable Pro. I missed a decent Manga Reader on the device, so I created a native one which makes use of my custom server.
So any interesting alternative use for the Camlink ? All I can think of is dropping framerate (some of my cameras output 50p but are 25p). Or maybe adding a LUT ?
This a fascinating security write up. I had no idea the models were this capable for reverse engineering.
I heard CISA is getting defunded. I wonder if it'll become a common assumption for Americans that all their devices are just perpetually compromised.
> I can’t help but think about what an AI-equipped automatically-reverse-engineering worm could do today.
Everyone should read Daemon and Freedom, like right now.
The i2c over USB with no auth is just way way too common; I've also seen that on a device.
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?
I did something similar but with smart home devices. I use the homebridge interface to connect my smart home devices to Apple's homekit protocol. Some homebridge plugins for my devices were outdated and no longer maintained, so I asked Codex/Claude to help me create a patch of it as a local fork, so my smart home devices can still run without problems.
It does feel magical when these agents can debug in the real-world, like turning on/off my living room lights and using another living room camera to take a snapshot of the living room to see whether it worked or not.
Sidenote to the technical discussion. The article read like a Martha Wells murderbot novel to me. Fascinating.
Maybe this is what Jevon's Paradox looks like for LLMs.
Oh, I can have this thing read and write software for me? Great, I'm going to have it read and customize the software in every single computing device I own.
Printers are a juicy target, they can have enough CPU/RAM/storage to be a good hiding place for backdoors.
Or you just want to patch out rejection of 3rd party ink/toner.
this is interesting, while i greatly apreciate the ability with claude code to basically customize my own firmware. There are things that I am strictly speaking wondering about the authors choices. The Author removed Pixel Cleaning? As far as I understand Pixel Cleaning is a process to make sure your OLED Monitor lives longer, why would you want to not do that?
I've spent SO MUCH TIME in my life trying to get laboratory machinery, usually only ten of them in the world, to spit out their data nicely. They have UIs but usually god-awful, and all data is hidden away somewhere (they're written by biologists, for biologists). I wish I could go void some warranties....
This is great stuff. Wouldn't this be lovely to go "fix" misbehaving devices (LG TV)
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.
Did something like this to play RTMP-over-HTTP from a security camera, no server required. didn't poke for rce yet. And same for a capture card with a HDMI loop out that was dropping audio when the monitor you plugged into it didn't advertise sound support in its edid, now it works.
This is the first exciting thing I've seen done with LLMs in quite some time. Turning on or off an LED doesn't seem world shattering, but the idea that we might be able to unlock or add functionality to hardware we own makes me giddy
Honestly I do like this trend if it genuinely leads to more interoperability. Im not sure that is the case though and in fact I worry people will start to imagine that anybody can do that in no time and that future devices will remain hackable this way. I have no doubt it was fun for OP to do but I bet most people who try that, people with less understanding, will inevitably end up nowhere or, worst, with bricked device in unrecoverable states. I feel this is one of the best use of AI at the moment, namely gaining agency by having devices do what their own wants and I hope it will lead to manufacturers selling both safer AND more interoperable devices but I'll remain prudently skeptical.
I suspect all this will go away soon, even from Chinese models for, uh, security reasons.
I did this but with a dedicated machine for the Silicon Motion sm750 GPU. A budget single HDMI output GPU card for servers and a max resolution of 1080p. It is based on an older VGA/DVI version of the same hardware.
I'm still testing but oh wow. My new driver now works with my ultra wide 21:9 ratio at 2048x864, it also manages 2048x1152.
The driver works well, and now has full DRM and DKMS support. It also runs on modern Linux after the manufacturer decided only to go up to kernel 5.x, windows support obviously still fine.
It found many faults in the original source, like somebody didn't read the HDMI specs / didn't have any idea what they were doing.
The new driver is fully spec timings and sequence compliant, doesn't hang on shutdown anymore, and ignores EDID for the purpose of allowing more screen modes.
It also has double buffering, and shadow buffering, and a custom magic square dither mode for 16bit colour and it absolutely flies vs the 32bit mode. The dither I invented was derived from one I created years ago for some retro hardware, but it's so good it's (imho) indistinguishable from general jpeg artifacting and quite difficult to find/see. I've had to ask codex a few times to check the GPU isn't in 32bit colour.
The GPU still has an annoying bug and won't work over KVM consistently without losing sync in VESA modes, but I'm not convinced its the GPU hardware doing this, it works perfectly well directly connected.
I'm due to put a GitHub repo up for this as soon as it's battle tested, and obviously ensuring it uses EDID by default, rather than ignores it.
I'm hoping somebody can fix the KVM issue, or audits the source to confirm there's nothing that can be done, but that's the best thing about open source :)