If you’ve sold a plugin on SpigotMC, Polymart, or BuiltByBit, you’ve probably run into this: someone buys your plugin once, then shares the JAR with dozens of others. Or it ends up on a free download site within hours of release.
It’s not just frustrating — it directly eats into your revenue and makes it harder to justify the time you spend building and maintaining your work.
In this post we’ll cover what plugin piracy actually looks like, why naive protection methods fall short, and how modern cryptographic licensing solves the problem properly.
What plugin piracy looks like in practice
The most common form is simple JAR sharing. A buyer downloads your plugin, extracts the JAR, and posts it to a free resources site or a Discord server. No effort required.
More sophisticated cases involve:
- Decompilation — Tools like Recaf or Jadx let anyone reverse-engineer your plugin’s bytecode, strip out license checks, and recompile a cracked version in minutes.
- Replay attacks — Capturing a valid license validation response from the network and replaying it on unlicensed servers, bypassing checks without a real key.
- Key sharing — A single purchased key being distributed to hundreds of servers simultaneously.
Why simple protection methods don’t hold up
A lot of developers try to protect their plugins with approaches like:
- Hardcoded secret strings compared against user input
- A remote endpoint that just returns
trueorfalse - JAR obfuscation using tools like Allatori
These share a common weakness: once a decompiler or network inspector gets involved, they collapse quickly. Hardcoded secrets can be extracted. Plain HTTP responses can be replayed. Obfuscation slows an attacker down by minutes, not days.
How RSA-secured licensing actually works
The solution is asymmetric cryptography — the same foundation that secures HTTPS and SSH.
Here’s the approach MC License uses:
- When a server starts and calls the validation endpoint, the request includes the license key, plugin ID, and server details.
- Our server signs its response using a private RSA key that never leaves our infrastructure.
- Your plugin verifies the response using a public key embedded in your JAR at compile time.
- Because the response is cryptographically signed, it cannot be forged or replayed — even if an attacker captures the exact bytes from a valid check.
Breaking this requires cracking RSA-2048, which isn’t happening.
What you can do today
If you’re selling plugins and haven’t implemented licensing yet, the practical path is:
- Sign up for MC License — it’s free to start and takes minutes to integrate via our Java SDK.
- Import your plugin directly from SpigotMC, Polymart, or BuiltByBit — no manual setup required.
- Set server limits — cap how many servers a single license can run on simultaneously to stop key sharing dead.
- Enable expiration — time-limited licenses for customers who paid for a specific period.
- Enable the Discord bot — let customers manage their own licenses without ever contacting you.
Protecting your plugins should be invisible to legitimate customers and only block bad actors. Done right, it is.