From the article, it sounds like he used Claude Code as an alternative to Wireshark and Google to decode USB HID traffic and find protocol documentation, respectively.
I suppose this could save a bit of time if you don't already have Wireshark installed, with a minor risk of hallucinations.
Other than this, he used Docker for some reason* to edit ~root/.ssh/authorized_keys and /etc/shadow in the firmware tarball, then wrote a quick Python script to send the relevant HID messages and copy the modified tarball to a volume mounted from a USB drive exposed by the device in response to one of the HID messages.
Maybe he used Claude to do some of this other stuff. Who knows? But the only thing in the post or the linked scripts that wasn't immediately obvious to me is why he installed the whois package in his Ubuntu container, but it turns out that, in Debian, the mkpasswd utility is installed by the whois package for historical reasons[1].
So basically, you have to be an insane hacker, or else have a basic working knowledge of Linux system administration (or at least know how to use the man(1) command; then again Google would probably suffice as an alternative) and how to write trivial programs in any language with bindings to a USB HID library.
* Presumably because he was on a Mac and didn't have a Linux box handy to generate the hashed password (which requires using glibc crypt(3) in a way that isn't compatible with macOS libc crypt(3), so nontrivial on a Mac).
Not sure why he needed password authentication in the first place, but, at the author's request, I won't shoot him.
I will, however, point out that, unless the sshd_config file on the device already set PermitRootLogin to something other than the default "prohibit-password", password authentication wouldn't have worked to log in as root, even with PasswordAuthentication set to "yes".
[1] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=116260
I used wireshark to capture the traffic, and looked thru the pcap for the area that looked like the updating, and gave the packet numbers and the pcap to claude code to find the details of how it worked instead of scribbling notes for an hour or two i’d guess
I’m very used to doing this stuff manually for various devices and software, but am also interested in tracking llm progress, and it seemed simple enough to get a rundown of what was happening while I did other work.
It was the first time I have messed around with hid devices though, so that was aided by claude
and yeah i’ve been bit by having to google how to get mkpasswd dozens of times over the years and used to have to do a lot of rootfs editing on a mac, so I got used to doing it in a container.
no real reason for wanting pw auth, I ended up turning it off afterwards but it’s been a bit since I wrote this
thanks for the comment!
> a bit of time
A bit of time is an understatement.
I used Wireshark to analyze various things (mostly smart home) over the years, but now CC does in minutes what it would take me a few hours before - and provides dedicated, custom made panels for whatever I want.
As an example - debugging KNX magistrale in my home, previously it was either wireshark and a ton of regexes, handwritten scripts (or official software that was terrible), now you just tell CC what you want to extract, and you get beautiful real-time views of the activity.
One thing is previewing the traffic, but then CC can easily fetch docs for any device it finds on the network, if it has an API (official or not), utilize it and do whatever you want.