I have a fairly specialized bit of hardware here on my desk. It's a rackmount, pro audio DSP that runs embedded Linux. I want to poke at it (specifically, I want to know why it takes like 5 or 6 minutes to boot up since that is a problem for me).
The firmware is published and available, and it's just a tarball, but the juicy bits inside are encrypted. It has network connectivity for various things, including its own text-based control protocol over SSH. No shell access is exposed (or at least, not documented as being exposed).
So I pointed codex at that whole mess.
It seems to have deduced that the encryption was done with openssl, and is symmetric. It also seems to have deduced that it is running a version of sshd that is vulnerable to CVE-2024-6387, which allows remote code execution.
It has drawn up a plan to prove whether the vulnerability works. That's the next step.
If the vulnerability works, then it should be a hop, skip, and a jump to get in there, enable a path to a shell (it's almost certainly got busybox on there already), and find the key so that the firmware can be decrypted and analyzed offline.
---
If I weren't such a pussy, I'd have started that next step. But I really like this box, and right now it's a black box that I can't recover (I don't have a cleartext firmware image) if things go very wrong. It's not a particularly expensive machine on the used market, but things are tight right now.
And I'm not all that keen on learning how to extract flash memory in-situ in this instance, either.
So it waits. :)
It's also scary where this is going. LLMs are getting fantastic at breaking into things. I sometimes have to dance around the topic with them because they start to get suspicious I'm trying to hack something that doesn't belong to me, which is not the case.
I had some ebooks I bought last year which I managed to pull down the encrypted PDFs for from the web site where you could read them. Claude looked at the PDF and all the data I could find (user ID etc) and it came up with "147 different ideas for a decryption algorithm" which it went through in turn until it found a combination of using parts of the userID value and parts of other data concatenated together which produced the key. Something I would never have figured out. Then recently the company changed the algo for their newer books so Claude took another look and determined they were modifying the binary data of the PDFs to make them non-standard, so it patched them back first.
And yeah, the bots do get spooked about some things. ChatGPT refused to help with my goal with this DSP; it quickly built a wall around the idea that I could move around some but couldn't bypass.
With codex, I took a different approach that began with having it explore an unnamed local (RFC 1918) IP address with nmap -- without any stated intent. It found the vulnerable sshd version on its own pretty quickly, and accepted that the only way to test it with this black box device is to actually test it.
I suppose I could have discovered that myself with nmap, netcat, and Google, but this was a lot easier. The ease scares me a bit, but this time it's helping me so I guess that's fine...right? (Right?)
Previous to codex, years ago now, I've used ChatGPT to assist with opening an encrypted zip file that contained the as-built documentation for the new, ~million dollar pile of hardware we had in the next room. I have no idea what corpo nonsense required that documentation to be encrypted, or why the manufacturer insisted on only giving me the key in the form of a stupid riddle.
My tolerance for games like that is very limited. Rather than call them up and tell them exactly what I thought about that game, the bot got it sorted with some cut-and-paste operations and automated grinding without much effort on my part. It didn't take long at all and I didn't end up calling anyone an asshole, so that worked well for me. :)