Building the second one is the only reason I learned anything from the first.

an obfuscator always looks like it works

This is the trap, and it's structural rather than a mistake anyone makes out of carelessness.

You run your tool. You open the output in a decompiler. It's unreadable — names are gone, the control flow is soup, the strings aren't there. It looks like exactly what you set out to build, and every instinct says you're done.

But "I can't read this" and "this is expensive to reverse" are different claims, and only the second one matters. The first is guaranteed by construction: you scrambled it, so of course it looks scrambled to you. You're the least qualified person to judge, because you're reading output you already know the shape of and grading it on how alien it feels.

The gap between those two claims only becomes visible when somebody sits down and actually tries to undo it. The fastest way to arrange that is to be them.

bytecode, not source

Worth saying what layer this operates at, because it changes what's available.

The tool doesn't rewrite Java and recompile. It reads the .class files javac already produced and rewrites those directly. ASM is a visitor over the class format — you hand it a reader, it walks the structure, and you intercept the parts you care about:

class Renamer extends ClassVisitor {
    @Override
    public MethodVisitor visitMethod(
            int access, String name, String desc, String sig, String[] ex) {
        return super.visitMethod(access, rename(name), desc, sig, ex);
    }
}

Two things follow from working down here. The first is that the tool never needs source, which is the entire premise of the deobfuscator — if you had the source you wouldn't be running it. The second is that the JVM will happily execute class files javac would never emit. There are shapes down there that no Java file can describe, and a source-level tool simply cannot reach them.

what the reverser kept killing

The pattern that repeated: I'd add a transformation, admire how bad the output looked, then write the undo for it and find out it was a lot less work than the obfuscation had been.

That's the useful signal. A transformation that a mechanical pass reverses completely isn't protection — it's noise. It costs you real things: bigger artefacts, slower loading, sometimes a genuine behaviour change you don't notice for weeks. And it buys nothing against anyone with the patience to write the reversal.

Renaming is the clearest case. Stripping every identifier down to a, b, aa feels devastating and mostly isn't, because names were never load-bearing — the structure survives untouched, and a reverser doesn't need your names, only consistent ones they can assign themselves. It raises the cost of reading without raising the cost of understanding, and the second is the one an attacker is paying.

What survived my own reversing attempts were the transformations where undoing them meant reasoning about what the program actually does, not just pattern matching on what it looks like. Anything a visitor could spot and rewrite mechanically, a visitor did.

the part that generalises

I stopped working on the JVM a long time ago and this is still the project I think about most, because the lesson wasn't about bytecode at all:

You learn almost nothing about a defence by admiring it. You learn everything by attacking it.

Anyone can build the half that looks strong. The half that tells you the truth is the one that tries to break it, and it's the half people skip, because it's less fun and it mostly produces bad news about work you already did.

That instinct is the thing that carried forward. It's why I care about the race in an auction system where two bids land in the same instant, and about the booking slot two people click at once — not because those failures showed up in testing, but because the interesting case is the adversarial one and you only find it by going looking on purpose.

Nobody reports the double-booking bug. They just don't come back.

The concrete version of all this — what happened when the deobfuscator was pointed at ProGuard and Allatori, and why encrypted strings hand you the key along with the lock — is a separate note.

The interesting part isn't that I'm rewriting it. It's that the thing forcing the rewrite isn't the encryption, the realtime layer, or the mobile client. It's that a message never had a written-down shape.

the tool that was actually a bug report

At some point I built a logger for my own WebSocket traffic, because I couldn't tell what was going over the wire. This is the line that matters:

type: data.type ?? "unknown",

I wrote that, shipped it, used it for months, and read it as tooling. It isn't. It's a defect report about the system it's pointed at.

That ?? exists because the logger cannot know which shapes are legal. It's reaching for a field that might not be there, on an object it parsed out of a string that might not have been JSON. Every hedge in that expression is describing something the protocol declined to guarantee.

Here's the test I wish I'd applied: if you need to build an instrument to discover the shape of your own messages, the shape doesn't exist. Not "isn't documented" — doesn't exist. There was no artefact anywhere in that codebase that could answer "what is a legal message", because the answer lived distributed across every handler that had ever been written, in the heads of nobody but me, and only for as long as I remembered.

Building the instrument felt like rigour. It was avoidance with a nice console prefix.

why this is worse than untidy when it's encrypted

If it were an ordinary chat app, no schema is a maintenance problem. Handlers drift, a field gets renamed in three places and not the fourth, you fix bugs for a while. Unpleasant, survivable, fixable incrementally.

End-to-end encryption changes the category, because every message is now a negotiation about what the server is allowed to know.

Some of a message has to be readable by the server — you cannot route what you cannot read. The recipient, the channel, roughly when: that's metadata, and it's load-bearing infrastructure. The rest is ciphertext the server must never be able to open. The line between those two sets is not an implementation detail. It is the security model. It's the entire answer to "what does someone who seizes this box learn?"

Now: where was that line written down in my system?

Nowhere. It was wherever a given handler happened to put a field. Adding a feature meant adding a property to an object, and nothing anywhere would tell me whether I'd just quietly moved something from the encrypted side to the plaintext side. No type error. No failing test. No review comment, because it was only me. The system would keep working perfectly while its security properties changed underneath it.

You cannot audit a boundary that was never drawn. That's the sentence the whole project turns on, and I didn't have it at the time.

Yunoa dodges this by being single-user — one reader, one writer, same person, so almost everything can be ciphertext and the question barely comes up. Put a second participant in the room and the question is the entire design.

this is also why it's a rewrite

The usual advice is that rewrites are a trap, and it's usually right. I'd defend this one on a narrow ground: a schema is not a layer you can add later.

Most things are addable. You can bolt on logging, caching, rate limiting, even authentication, and the existing code mostly doesn't need to know. A schema isn't like that, because every handler, every stored message and every encryption decision was already written against its absence. Introducing one means touching all of them simultaneously, and there is no intermediate state where half the system has a contract and the other half doesn't — that state is strictly worse than either end, because now you have a guarantee that's only sometimes true, which is the same as no guarantee plus false confidence.

"Retrofit the schema" and "rewrite it" describe the same amount of work. One of them is honest about it.

what I'm doing differently

Schema first, before any transport code exists. Every message type declared in one place, with the encrypted fields and the routable fields separated in the declaration itself, so that moving something across that line is a visible change to a file whose only job is to describe the boundary.

Then the protocol on top of the socket that I skipped last time — message IDs, acknowledgements, an explicit reconnect handshake — instead of calling send and hoping. And a client that cannot send a message the schema doesn't describe, which is the property that makes all of the above stay true rather than being true on the day I wrote it.

still unsolved

• Multi-device history. A new device has to read messages it wasn't present for, and every clean answer to that is some flavour of "trust something new".
• Group membership changes. What someone who joins today can read of yesterday, and what someone removed can still read tomorrow.
• Notifications that are useful without leaking who a message is from.

None of these are new problems and none of them are things I'll solve better than the people who already have. The difference is that this time I'll be answering them against a schema that says what a message is — rather than discovering the answers I'd accidentally already committed to by reading my own logs.

proguard was the more annoying one

As best I remember it, ProGuard-obfuscated jars were the side that actually made me do work. I ran into something like five different methods for deriving or decrypting a key, and which one a given jar used didn't seem consistent from jar to jar — possibly tied to a version or a build setting, but I never actually isolated which.

That's the honest shape of that half: not one algorithm, a catalogue. You recognise a pattern, write the reversal, and go looking for the next variant. I don't have a clean account of why there were around five rather than three or eight — that's just how many distinct methods I ran into before I stopped looking.

allatori's obstacle wasn't the encryption

Allatori's actual hurdle was different in kind, and simpler than I originally described it: a deliberately malformed class, built to crash decompilers like Luyten rather than to resist a targeted tool. It's a cheap trick — it does nothing against something that isn't a general-purpose decompiler — but it's effective against exactly the tool most people would reach for first.

Once that class was out of the way, decrypting the strings underneath it wasn't the hard part. Which is worth sitting with, because it's the general shape of this problem regardless of which tool you're pointed at:

You cannot ship someone a program that runs on their machine and also withhold from them what the program needs in order to run.

A program that has to decrypt a string to use it has to carry the routine, the key, and the call site into that decryption, all in the same artefact it hands you. The string isn't protected. It's inconvenienced — one indirection away from plaintext, with the indirection included in the download. That's true of string encryption generally, independent of which specific tool I was pointed at, and it's the part of this whole project I'm actually confident about.

what I'm not confident about anymore

I'd previously ranked name mangling, string encryption, and control-flow obfuscation by how much they resisted the deobfuscator, with control flow as "the one that actually cost me." I don't have a solid memory of testing control flow obfuscation specifically as part of this project, so I'm dropping that ranking rather than keep repeating a claim I can't back up.

What I'll stand behind: name mangling destroys information rather than hiding it, so there's nothing to reverse, only to relabel. String encryption is reversible in principle for the reason above. Past that, I'd rather say "I don't remember clearly" than restate specifics that didn't hold up the first time I wrote them down.

the part I still use

I wrote about why building both halves was the point separately, and the lesson from that post is the one part of this project I'd still defend without hedging: you cannot tell which of your own transformations are strong by admiring the output. You find out by writing the thing that comes at it from the other side — and, apparently, you should also double-check your own memory before writing it up years later.

So I asked my friend about cool name (he had acod.in at the time)

and after a while "keroton.in" was born. I've made a quick temporary website (placeholder) in 2024... but it stayed that way till 2026.

Why you ask?

Most of all, laziness prolly (okay, yeah it was laziness). And didn't really know what I could put it on there. Blogs? Media hosting?

So this is the replacement. One page that says who I am, one page listing the hardware I actually use, and this notes section.

what goes here

Dev logs, mostly. Short ones. Things like "the VM broke in a funny way" or "I picked X over Y and here's the reason I'll forget in three weeks." I'm not writing tutorials and I'm not writing thought leadership.

The bar for posting is low on purpose. A post that's four paragraphs and useful to future me beats a post I never finish.

how it's built

Next.js App Router, Tailwind, MDX for these posts. No CMS, no database, no comment section. Posts are .mdx files in the repo, so writing one is the same motion as writing code: edit, commit, push.

The whole thing is static. It could run off a folder on any web server, which felt like the right amount of infrastructure for a personal site.

the pink

The domain is .pink. Ignoring that would have been a waste. It's a couple of accents on a near-black background — links, a marker next to headings, a glow behind the hero. Any more than that and it stops being readable.

The fix is scripts. The excuse is that I wanted to learn Rust properly, so I'm writing the whole thing myself: a small language, a compiler, and a VM to run the bytecode.

it started in C++

The first version was C++, which made sense at the time — the game is already C++, so the VM could just reach into game state directly. It worked. It was also the kind of code where a crash three frames later was caused by something I did three functions ago.

Rewriting it in Rust was supposed to be a learning exercise. It turned into the version I actually use.

stack-based, for now

It's a stack VM. Every tutorial starts with a stack VM, and after the port I never had a good enough reason to move off it — the interpreter is small, the compiler is almost trivially simple, and none of my scripts are hot enough for dispatch count to be the thing that hurts.

enum Op {
    LoadConst(u16),
    Add,
    JumpIfFalse(u32),
    Call { func: u16, argc: u8 },
    Return,
}

The cost is obvious when you read the bytecode: push, push, add, store for what is conceptually one operation. Registers are where I want to take it — wider instructions, far fewer dispatches per line of script — but that means writing a register allocator, and I'd rather have hot reload working first.

what rust actually taught me

The borrow checker is the reason this works. The C++ version did the obvious thing: hand the VM a pointer to the host game state and let it write wherever. Rust refused to let me port that straight across, so I ended up with an explicit host interface — the script asks, the host answers, nothing reaches across.

That boundary is the good part of the design and I didn't come up with it. The compiler forced it on me.

still missing

• Garbage collection. Strings currently live forever. I'm going to pretend that's a feature until it isn't.
• Debug info. A runtime error gives you a bytecode offset, which is useless. Line numbers next.
• Hot reload, the whole reason for the project. Swapping a function's bytecode mid-frame without invalidating live call frames is the interesting problem, and I haven't solved it yet.

Gets rewritten roughly every other month. That's fine — the rewrites are where the learning is.