The kratt problem

The story stuck with me the first time I heard it, because it fits what I do for a living.

Capability is assembled from spare parts. Nobody invents browser exploitation, protocol analysis, or VM reverse engineering from nothing. You collect techniques from public research, from other people's tools, from your own failures. What makes the assembly dangerous is that it works without rest and without judgment.

A kratt does not decide what to steal. Its maker decides. The creature contributes the tireless execution and nothing else. That is the uncomfortable part of the metaphor, because it is also true of the person holding the skills. The skills do not have a moral position. They do what they are pointed at.

In the stories, the danger isn't malice. The kratt has none. The danger is idleness: it is most dangerous exactly when it has nothing to do.

I think that is right, and I think the cybersecurity industry mostly looks the other way. Its controls are aimed at the intent of people who can build things: export rules for intrusion software, bug-bounty terms, safe-harbor policies. Much less is said about what happens to capability when nobody has given it work. Idle skill doesn't stay idle. Its owner finds work for it, and unchosen work is rarely good work.

I reverse engineered browser security, TLS fingerprinting, and anti-fraud systems — and for a while, I broke them for money. I don’t hide that. It ultimately led to a conviction in 2024, an outcome I take full responsibility for. The full statement is on the About page.

The folklore is also clear about the price. Three drops of blood. The maker pays something real up front, and the payment is what makes the creature run.

Building offensive capability has an up-front price too, and it is usually paid in judgment. Every exploit, every tool, every piece of automation is a small decision about what deserves to be taken apart and who gets to hold the result. I do not present my own history as a credential. It is the reason I think the pointing question is the one that matters.

A kratt needs constant direction, not a single decision. The same is true of capability.

No line settles it once. What works is keeping the work visible and its direction checkable, and the discipline that does that for me is publicity. The research is published under my name, and where it touches live systems, the findings go to the people who can act on them before they go to everyone else, as the disclosure policy describes. If the work is visible, anyone can check where it is aimed.

The About page on this site sums up the kratt metaphor in one paragraph. The rest of the site works that paragraph out.

The story also has an ending worth keeping. You do not destroy a kratt by fighting it. You give it a task it cannot finish, and it burns itself out.

I'm deliberately turning the tale around here. The impossible task that destroys the kratt is, for capability, what keeps it safe. Capability cannot be destroyed anyway. What you can do is give it work that takes its full attention and points it somewhere it cannot come back to bite the maker. The work has to be real, and hard enough that it is never finished, so the capability never goes idle and its owner never goes looking for other work for it.

Give it real work: research that gets published, systems that get built, disclosures that get made. That is the ladder out of bread.