rymga Lock Master
Cloud protection for Java bytecode. Send a JAR, get one back that's genuinely hard to reverse-engineer — and that still runs exactly the same.
What it is
Lock Master takes your compiled .jar, applies a stack of protections in the cloud, and returns a new JAR. Your code behaves identically; what changes is how much work it takes someone to read it.
It does several things at once: it encrypts your strings so nothing readable is left in the class files, renames classes and members, rewrites the control flowso no clean Java reproduces it, can encrypt whole classes so what ships on disk isn't even loadable bytecode, and watermarks the build so a leak traces back to a license.
Who it's for
These docs are written for two people, and both should be able to follow them:
- You're shipping your first plugin. You wrote a Minecraft plugin (or any Java app), it works, and you don't want someone to open it in a decompiler and copy it in five minutes. You'll mostly use a preset and a couple of keep rules — no deep knowledge needed.
- You're technical and want control. You know your way around bytecode and want to tune each transform, wire it into CI, keep stable name mappings across releases, or turn on class encryption. Every knob is documented in Configuration.
How it works
- You install the CLI and grab a seat key from your account.
- You write a small JSON config describing what to protect.
- You run
rymga obfuscate. The CLI uploads your JAR, the cloud protects it, and you download the result. Each run spends tokens based on the build's size. - Every build is re-checked against the JVM's own verification rules before you get it — so protection never turns into a crash on your side.
What it protects (honestly)
There is no honest way to make compiled software impossible to reverse. Anyone telling you their Java obfuscator is "unbreakable" is lying. What Lock Master does is raise the cost of reversing your code past the point where it's worth it:
- Static analysis stalls. With strings encrypted and (optionally) classes sealed, decompilers produce garbage or bail out.
- Running it under observation is blocked too. The anti-debug guard refuses to unseal encrypted classes when a debugger is attached.
- Leaks are attributable. An invisible watermark ties every build to the license it was issued under.
What it is not: a guarantee. A determined, well-resourced attacker with enough time can still make progress. The goal is to make that not worth their while.
Where to start
- New here? Read Access & accounts to get in.
- Ready to protect something? The CLI then Configuration.
- Stuck? FAQ and Support.