Hackwrights and the Race to the Fastest AI Hackers

TL;DR

AI Racing

Last weekend, a lightweight harness I made around Codex finished 3rd in Flare-On 13, one of the hardest CTFs in reverse engineering. I had only one goal while making it: to build something faster, lighter, and easier to optimize than other people’s AI setups (regardless of model). My theory was that replacing the tools and skills with faster alternatives, like my own optimized decompiler Kuna, could help me eke out a decisive victory. I analyzed some of this data, and the core tools did in fact play a strong role. Of course, I had also tested it on multiple CTFs beforehand, but there is nothing like a good ol’ scoreboard to see the horses run live! This result, along with my experiences over the past year, has led me to believe that improving speed and reducing cost will be endgame goals for autonomous hackers.

This idea really took shape in my mind last summer at DEF CON CTF Finals, arguably the Olympics of hacking. Every top-notch group of hackers, including us, relied heavily on AI agents in the competition, often to solve challenges autonomously. Many points were decided simply by whose agent solved the challenge faster. Back then, we started benchmarking our autonomous system to see where we could optimize it (a much bigger, closed system than the one I described above). One area for optimization was how the decompiler helped agents reason about code.

I focused on optimizing one tool, the decompiler Kuna, around what I believed AI needed. It was fast and moved decompilation output out of MCP and into text files that looked more like source code. On a dataset from crackmes.one, we found our Kuna-based system solved challenges using about 45% fewer tokens than the system using IDA Pro 9.4 MCP. Its solve times were also about 9% faster than IDA’s or on par with them. These results are preliminary, and the dataset could always be bigger, but I suspect there are many more opportunities for this kind of optimization in AI hacking.

I like to think of those who build, optimize, and manage these autonomous hacking systems as Hackwrights. Hackwrights are builders with a hacker’s intuition. They may not be traditional hackers who have mastered the art themselves. I believe CTFs can continue to grow and satisfy both groups. But I understand that there is a lot of anger, fear, and grief surrounding this idea.

Responding to AI Doom in Hacking

There has been a strong sense of doom in the community around AI in hacking. Not everyone was happy to see AI on the Flare-On scoreboard; it has prizes, after all, and I won’t be claiming any. I argue all CTFs should have separate autonomous and human brackets, each with its own prizes, to mitigate some of this fallout. There should always be a place for humans to learn how to hack and compete, much as there is in chess. But there should also be room for Hackwrights and their constructions.

To my fellow hackers, can we not find joy in both directions hacking is evolving? Yes, CTFs have completely changed, and perhaps the balance of power has shifted away from humans. Yet, in part, this has been many teams’ goal since the early days of CTF. I have always fantasized about showing up to a CTF with a better tool to flex on other teams. That same motivation has helped us advance cybersecurity for society at large.

We have the chance to make a broader impact on society through fast and cheap automation. Luckily, that optimization process can also be incredibly fun and competitive. I want to see more hope and excitement back in my community. I want to see what the fastest AI hacker built by cunning Hackwrights looks like (ideally open source).

Race you to the flag!