this should not be possible
It might surprise some folks, but I'm incredibly cynical when it comes to AI and what is possible; yet I keep an open mind. That said, two weeks ago, when I was in SFO, I discovered another thing that should not be possible. Every time I find out something that works, which should not be possible, it pushes me further and further, making me think that we are already in post-AGI territory.
I was sitting next to a mate at a pub; it was pretty late, and we were just talking about LLM capabilities, riffing about what the modern version of Falco or any of these tools in the DFIR space looks like when combined with an LLM.
You see, a couple of months ago, I'd been playing with eBPF and LLMs and discovered that LLMs do eBPF unusually well. So in the spirit of deliberate practice (see below), a laptop was brought out, and we SSH'd into a Linux machine.
Geoffrey Huntley
The idea was simple.
Could we convert an eBPF trace to a fully functional application via Ralph Wiggum? So we started with a toy.
strace ls 1>trace 2>&1
After ls had completed listing out the files in a directory, we had a strace file. The next step was to modify the strace file to remove all references to the 'ls' command using Vim.
:%s/ls/lol/g
You see, we didn't want the LLM to cheat by using hints about precisely what the strace did, as indicated by the file name of the executable in the trace.
The following prompt was then issued.
read the TRACE
reimplement a program in rust that reimplments what this trace does
A couple of moments later, our jaws were on the ground. It is indeed impossible to take an application from an strace and then build it into an application using only the strace.
From that point forward, things just got weird, really fast. You see, I've never been a fan of proprietary firmware blobs in the Linux kernel, and perhaps if this information reaches the right people, this category of problem will be forever solved thanks to AI.
ghuntley
Dear reader, use this knowledge wisely and with care.
p.s socials
