I had truly good “hacking” session with Codex. It’s not hacking, I wasn’t breaking anything, just jumping over the fences TP-Link put for me, owning the router, inside the network, knowing the admin password. But TP-Link really tried everything so you cannot access the router you own via API. They really tried to be smart with some very very broken and custom auth and encryption scheme. It took some half a day with Codex, but in the end I have a pretty Python API to access my router, tested, reliable, and exporting beautiful Prometheus metrics.
I’m sure there is some over eager product manager sitting in such companies, trying to splits markets into customer and enterprise sections, just by making APIs not useable by humans and adding 200% useless “security by obscurity”.
Many eons ago I wrote a Python version of tmpcli for this exact reason. Made some minor improvements a few years ago but haven’t touched it since. Curious what methodology Codex came up with, I haven’t revisited it since models got really good.
The idea is that tmpServer listens on localhost, but dropbear allows port forwarding with admin creds (you’ll need to specify -N). That program has full device access and is the API the Tether app primarily uses to interact with the device.
I have one of these Smiirl flip counters. It runs a version of OpenWrt without the web UI, but has a uhttpd to serve an api. I'm hoping Mythos can help me find an exploit to get into it and enable ssh since they have now disabled the simple api switch that would let you turn it on.
I've had good success doing something similar. Recording requests into an .har file using the web UI and providing it for analysis was a good starting point for me, orders of magnitude faster than it would be without an assistant.
I did something similar with an LED display on my computer case. The display required a proprietary UI program from the manufacturer to display GPU/CPU temps which unfortunately only worked on Windows.
Since it needs sensor data, WINE would not work here and I didn't want to do something funky with editing WINE or granting non-typical permissions.
I was able to reverse engineer the software using Claude, some Python, and a few hours of probing sensor data to understand how it worked and what was available.
I wrote most of the code myself (it was dead simple), but Claude was extremely useful in understanding what byte packets were being sent to the USB controller, what they meant, and what the controller was expecting.
I was able to make it into a service so now it Just Works(tm).
Probably the first time I've used it to "hack" something, but now I have a service that works great, I understand it, and I learned a ton about how Linux controls some low-level hardware.
If you're into it, you could always re-flash your TP-Link hardware with some open-source firmware that is more automation friendly. I used to be intimidated by it, but a friend showed me how to do it and it's remarkably simple and pain-free (provided it's a commonly supported router of course).
Would definitely be interested in this. Moved to TP Link at the start of the year and I am generally very happy with it, but would like to be able to interact with my router in something other than their phone app.
Any tips to share? I tried to do something similar but failed.
My router has a backup/restore feature with an encrypted export, I figured I could use that to control or at least inspect all of its state, but I/codex could not figure out the encryption.
Not as cool as this, but I had a fun Claude Code experience when I asked it to look at my Bluetooth devices and do something "fun". It discovered a cheap set of RGB lights in my daughter's room (which I had no idea used Bluetooth for the remote - and not secured at all) and made them do a rainbow effect then documented the protocol so I could make my own remote control if needed.
It’s important to note that Codex was given access to the source code. In another comment thread that is currently on the front page (https://news.ycombinator.com/item?id=47780456), the opinion is repeatedly voiced that being closed source doesn’t provide a material benefit in defending against vulnerabilities being discovered and exploited using AI. So it would be interesting to see how Codex would fare here without access to the source code.
My Philips smart tv started to give hints of programmed obsolescence this week, after 4 or 5 years. Besides the fact that I cannot install any real apps other than the ones built in this model (YouTube, Netflix and Prime). How I wish I could hack it and install another os. Honestly I don't think I have the time anymore to investigate this kind of thing. I decided to leave this comment here in hopes of someone pointing me in the right direction, if there's one. For now I'm thinking about getting a TV box and ditching the smart features all together.
It hacked a weak TV OS with full source. Next-level, aka full access to the main controls (vol, input, tint, aspect, firmware, etc.) is still much too hard for LLMs to understand.
While cool and slightly scary news - Samsung TV's have been incredibly hackable for the past decade, wouldn't be surprised if GPT2 with access to a browser could hack a Samsung!
> Reading the matching ntkdriver sources is also where the Novatek link became clear: the tree is stamped throughout with Novatek Microelectronics identifiers, so these ntk* interfaces were not just opaque device names on the TV, but part of the Novatek stack Samsung had shipped.
Lol, a true classic in the embedded world. Some hardware company (it appears these guys make display panel controllers?) ships a piece of hardware, half-asses a barely working driver for it, another company integrates this with a bunch of other crap from other vendors into a BSP, another company uses the hardware and the BSP to create a product and ships it. And often enough the final company doesn't even have an idea about what's going on in the innards of the BSP - as long as it's running their layer of slop UI and it doesn't crash half the time, it's fine, and if it does, it's off to the BSP provider to fix the issues.
But at no stage anywhere is there a security audit, code quality checks or even hardware quality checks involved - part of why BSPs (and embedded product firmwares in general) are full of half-assed code is because often enough the drivers have to work around hardware bugs / quirks somehow that are too late to fix in HW because tens to hundreds of thousands of units have already been produced and the software people are heavily pressured to "make it work or else we gotta write off X million dollars" and "make it work fast because the longer you take, the more money we lose on interest until we can ship the hardware and get paid for it", and if they are particularly unlucky "it MUST work until deadline X because we need to get the products shipped to hit Christmas/Black Friday sales windows or because we need to beat in time-to-market, it's mandatory overtime until it works".
And that is how you get exploits so braindead easy that AI models can do the job. What a disgusting world, run to the ground by beancounters.
Codex exploited or you exploited? It's like saying a hammer drove a nail, without acknowledging the hand and the force it exerted and the human brain behind it.
"Browser foothold: we already had code execution inside the browser application's own security context on the TV, which meant the task was not "get code execution somehow" but "turn browser-app code execution into root.""
Finding the initial foothold is the hardest part. Codex didn't have anything to do with it.
Putting aside the fact this was "cheating" because it got access to source code.
I am very here for a world where we can take back control, at scale, of the enshittified, you'll-own-nothing, ad-ridden consumer electronics our capitalist overlords have decided we deserve, by investing some amount of collective token-$, instead of having to pray one smart adhd nerd buys the same TV and decides to take a look.
OTOH, as with anything LLMs take over, I'm concerned we'll soon have very few smart adhd nerds left to work on liberating the next generation of hardened devices.
All the news regarding AI finding weaknesses or "hacking" stuff - is that actually hacking? Isn't it also a kind of bruteforce attack? Just throw resources at something, see what comes out. Yea, some software security issues haven't been found for 15 years, but not because there were no competent security specialists out there who could have found it, but most likely because there is a lot of software and nobody has time to focus on everything. Of course, an AI trained on decades of findings, lots of time and lots of resources, can tackle much more than one person. But this is not revolutionary technological advance, it is an upscaling of a kind based on the work of many very talented people before that.
132 comments
I’m sure there is some over eager product manager sitting in such companies, trying to splits markets into customer and enterprise sections, just by making APIs not useable by humans and adding 200% useless “security by obscurity”.
The idea is that tmpServer listens on localhost, but dropbear allows port forwarding with admin creds (you’ll need to specify -N). That program has full device access and is the API the Tether app primarily uses to interact with the device.
https://github.com/ropbear/tmpcli
https://www.smiirl.com/en/counter/facebook/5d/
> It’s not hacking, I wasn’t breaking anything
That's a very narrow read of the word "hacking".
We're literally on a website called "Hacker News". We're not all trying to break things.
Since it needs sensor data, WINE would not work here and I didn't want to do something funky with editing WINE or granting non-typical permissions.
I was able to reverse engineer the software using Claude, some Python, and a few hours of probing sensor data to understand how it worked and what was available.
I wrote most of the code myself (it was dead simple), but Claude was extremely useful in understanding what byte packets were being sent to the USB controller, what they meant, and what the controller was expecting.
I was able to make it into a service so now it Just Works(tm).
Probably the first time I've used it to "hack" something, but now I have a service that works great, I understand it, and I learned a ton about how Linux controls some low-level hardware.
My router has a backup/restore feature with an encrypted export, I figured I could use that to control or at least inspect all of its state, but I/codex could not figure out the encryption.
> Reading the matching ntkdriver sources is also where the Novatek link became clear: the tree is stamped throughout with Novatek Microelectronics identifiers, so these ntk* interfaces were not just opaque device names on the TV, but part of the Novatek stack Samsung had shipped.
Lol, a true classic in the embedded world. Some hardware company (it appears these guys make display panel controllers?) ships a piece of hardware, half-asses a barely working driver for it, another company integrates this with a bunch of other crap from other vendors into a BSP, another company uses the hardware and the BSP to create a product and ships it. And often enough the final company doesn't even have an idea about what's going on in the innards of the BSP - as long as it's running their layer of slop UI and it doesn't crash half the time, it's fine, and if it does, it's off to the BSP provider to fix the issues.
But at no stage anywhere is there a security audit, code quality checks or even hardware quality checks involved - part of why BSPs (and embedded product firmwares in general) are full of half-assed code is because often enough the drivers have to work around hardware bugs / quirks somehow that are too late to fix in HW because tens to hundreds of thousands of units have already been produced and the software people are heavily pressured to "make it work or else we gotta write off X million dollars" and "make it work fast because the longer you take, the more money we lose on interest until we can ship the hardware and get paid for it", and if they are particularly unlucky "it MUST work until deadline X because we need to get the products shipped to hit Christmas/Black Friday sales windows or because we need to beat in time-to-market, it's mandatory overtime until it works".
And that is how you get exploits so braindead easy that AI models can do the job. What a disgusting world, run to the ground by beancounters.
> [1] Browser foothold: we already had code execution inside the browser application's own security context on the TV,
Does anyone know what the author meant by this? Are they talking about a web browser run on the TV?
Give an experienced human this tool at hand he can achieve exploitation with only a few steering inputs.
Cool stuff
Finding the initial foothold is the hardest part. Codex didn't have anything to do with it.
I am very here for a world where we can take back control, at scale, of the enshittified, you'll-own-nothing, ad-ridden consumer electronics our capitalist overlords have decided we deserve, by investing some amount of collective token-$, instead of having to pray one smart adhd nerd buys the same TV and decides to take a look.
OTOH, as with anything LLMs take over, I'm concerned we'll soon have very few smart adhd nerds left to work on liberating the next generation of hardened devices.