Security & development
KokoKrypt: a coding exercise that stopped being one
What a childhood project taught me about responsibility, disclosure and the people who clean up after code. The story behind KokoKrypt.
I wrote KokoKrypt in 2016, when I was 11 or 12. I was born in 2004, and what I considered a coding exercise became something malware analysts examined. This is my account of why I made it, what I remember about its limits, and why those limits did not settle the question of responsibility once I shared it.
Quick answer
- I built KokoKrypt in Visual Basic, using Visual Studio 2010, out of curiosity and a wish to participate in an online community.
- My version targeted one hardcoded folder, used a static key and had a localhost control server that never worked properly.
- I posted it on a forum. Analysts picked it up, and I later published an apology and contacted Karsten Hahn around 2019 or 2020.
- Emsisoft provides a free KokoKrypt decryptor. Its current listing dates the release to April 13, 2020.
- Calling code a learning exercise does not control what someone else can do with it after you share it.
The childhood details and approximate outreach date here are my recollections. The linked Emsisoft material provides a separate public record of the recovery tool.
Why I wrote it
There was a YouTuber's forum with a series about viewer-made malware. I wanted to take part. I liked programming, I was curious about how this kind of software worked, and I wanted people in that community to notice something I had made.
Curiosity and attention are the honest explanation. I was not setting out to hurt somebody, but I was choosing a project whose basic behavior involved interfering with files. At that age, I gave much more thought to getting a program to work and having something to show than to what publishing it could mean.
That context matters because it explains the decision. It does not make the decision a good one. A reader does not have to accept my intention as a guarantee about the software.
Why the name was KoKo
I named it after my parrot, Coco, who died during development. I used the spelling "KoKo" because I thought it sounded catchier. That is the personal detail behind a name that later appeared in malware reports: it came from a pet I had lost, during a project I was too young to think through properly.
What it actually was
I wrote it in Visual Basic in Visual Studio 2010. The version I remember building only encrypted files under the hardcoded path C:/Batch. That was my attempt to keep it away from normal user data. It used a static key, and the control server was a buggy localhost experiment that never worked properly.
Those details describe an amateur project with deliberate restrictions. They explain what I thought I was containing. They do not establish the behavior of every copy or modification that might have existed afterward.
I am keeping this account at that level. The relevant facts are the folder restriction, the fixed key and the broken server, rather than instructions for reproducing them. None of those details answers the larger question of whether sharing the program was responsible.
There is also a distinction between a restriction in a program and permission from the person whose machine it runs on. Choosing a folder does not, by itself, give anyone permission to alter the files inside it.
When it left my hands
The only place I published it was that forum. Then malware analysts picked it up. Seeing something I had made treated as malware was worrying. I had wanted attention inside a community; now the program was being examined outside the setting in which I had introduced it.
My explanation of why I wrote it could not accompany every copy. Someone encountering the file had no reason to assume it was a harmless exercise or to trust that its restrictions would protect them. They had to judge what they were looking at.
That was the uncomfortable part: "I only posted it there" described my own action, but it did not tell me where the program went next. I cannot turn that uncertainty into a claim that it caused no harm. I also cannot turn it into a story about particular victims or later attacks without evidence.
Around 2019 or 2020: reaching out
Around 2019 or 2020, I contacted Karsten Hahn after watching his analysis videos. I was in my mid-teens by then. I also published an apology note. I do not remember the outreach date precisely enough to assign it a particular month or year within that period.
If a kid were in that position today, my advice would be to contact people who can help, and to do it early. Explain what you made, where you shared it and what you actually know about its behavior. Say when you are unsure. A trusted adult can help with that conversation, especially when you are frightened and tempted to avoid it.
An apology matters, but it does not replace useful information. The person investigating needs an accurate account, including the parts that are embarrassing. You do not have to make yourself sound more technically capable than you were, or claim that your intentions made everything safe.
The decryptor
Emsisoft's KokoKrypt page still offers a free decryptor. The listing shows April 13, 2020. That is a date attached to the tool; I am not using it to pin down my outreach or claim that my message caused its release.
A static key means a fixed secret is reused. Knowing that secret can make recovery possible for compatible encrypted files. That explains why the fixed key in my project mattered, without making a claim about the exact method Emsisoft used to build its tool.
Recovery still deserves care. Emsisoft's usage guide says to quarantine the malware first. It also explains that the decryptor keeps encrypted files by default because it cannot guarantee that recovered data is identical to the original. The availability of a tool is not a promise that every file or variant can be recovered.
The people doing that work deserve credit. Writing an experiment and leaving others to investigate it creates work for people who did not choose the project: identifying what it does, explaining the risk and helping with recovery.
Where this is not enough
"Limited scope" does not make something safe. A restriction can be removed, a copy can be modified, and a program can be run somewhere its author never expected. That possibility is part of the decision to publish it.
For learning, I would now choose exercises that leave other people's files alone: harmless simulations, deliberately prepared challenges, and analysis of behavior in an authorized environment. There are ways to learn about systems and cryptography without handing other people a working file-locking program.
Being young explains why I did not think that through. Looking back means acknowledging what I missed, rather than treating the folder restriction as the end of the discussion.
What it changed for me
Today I work across software architecture and integrations at Legacies. My selected projects include embedded systems and reverse engineering, subjects that still interest me deeply.
The responsibility extends beyond whether the code works on my machine. It includes the data it touches, the people who depend on it and the person who has to diagnose a failure afterward. In reverse engineering, it also means being clear about authorization and separating observed behavior from assumptions.
KokoKrypt belongs in that history. I would rather describe the mistake accurately, including what I do not know, than turn it into a story about being unusually clever at a young age.
Frequently Asked Questions
Is the decryptor still available?
Yes. As of November 5, 2026, Emsisoft lists the free KokoKrypt decryptor and its usage guide at the link above. Availability does not guarantee recovery for every variant or damaged file.
Did anyone get hurt?
I cannot establish that nobody was affected. My account of the original folder restriction is not evidence about every later copy, and I do not have a verified account of the full impact.
Would you do it again?
I would still learn programming, cryptography and reverse engineering. I would choose a harmless exercise and would not publish a working ransomware experiment as a way to get attention.
How old were you when you contacted the analyst?
I was born in 2004 and remember contacting Karsten Hahn around 2019 or 2020, so I was in my mid-teens. That is separate from writing the original project in 2016, when I was 11 or 12.
Even when you are building something for fun, be careful what you put into the world. You do not know who might take it and turn it against someone.