Your Minecraft plugin leaked. Here's how to find who leaked it and stop the copies

You search your plugin's name and there it is: your premium jar, free to download on a leak forum. It happens to almost every plugin that sells well, and it tends to happen the week of a big release or sale.

Here's what to do in the first hour, in order, and how to set things up so the next leak takes five minutes instead of a weekend.

1. Don't run the leaked file

Leak sites are a common way to spread malware: "cracked" jars often carry a backdoor that was added after the leak. Download the file only to inspect it, in a throwaway folder or a VM. Never put it on a server, not even a test one.

2. Find out whose copy it is

This only works if every buyer got a unique copy. If they did, you have three ways to find the buyer.

Look for the key in the jar. If you sell on BuiltByBit with an External license key placeholder, or on Voxel Shop or SpigotMC with their buyer placeholders, the store wrote something unique into each download. A jar is just a zip file:

mkdir leak && cd leak && unzip -q ../leaked.jar
grep -r "%%__" .                                   # a placeholder nobody replaced?
grep -rlE "[A-Z0-9]{4}-[A-Z0-9]{4}-[A-Z0-9]{4}" .  # files that contain a key
strings path/to/Match.class | grep -E "[A-Z0-9]{4}-"

If the placeholder was replaced, you'll find the buyer's key or user ID in a class file or in config.yml. If the class is hard to read, open it in a decompiler (Recaf, JD-GUI) and look at its constants.

Look for a watermark. If your downloads carry a mark (a line in the manifest, an archive comment, an ID compiled into a class), read it back the same way.

Ask your license server. Search for the key you found. It points to the license, and the license to the buyer. Its activations tell you more: a key on twelve servers in four countries is a shared key, not a stolen account.

A careful leaker may have swapped the key for another, or cut the check out entirely. Then the watermark and your license server's logs (which key started showing up on new servers when the leak appeared) are your best leads.

If every buyer got the same jar, you can't trace this leak. Skip to step 5, and make sure the next version is traceable.

3. Stop the leaked copies

Revoke the buyer's key. If your plugin checks its license on startup and re-checks every few hours, every copy of that jar stops at its next check, on every server that downloaded it. Your other buyers notice nothing.

Two things make this work:

• Re-check while running. A startup-only check stops new installs, but servers that were already running keep going until they restart. A re-check every few hours reaches them.
• Don't punish a network outage. Only stop on a clear "revoked" or "suspended" answer, never on a timeout. That keeps you on the right side of BuiltByBit's DRM rules, and keeps paying customers safe when your license server has a bad day.

If your plugin has no license check yet, this is the step you can't do today. How to add license keys to a Minecraft plugin in 10 minutes fixes that for the next version.

4. Deal with the buyer

Look at their history before you assume the worst. Sometimes their account was compromised, or a staff member they trusted shared it. Then:

• Refund or chargeback? If they charged back, revoke and move on. Stores don't always tell your license server about refunds (BuiltByBit's placeholder doesn't), so check.
• Report them to the marketplace with your evidence: the key, the leak URL, the date.
• Give a second chance if it was an accident: issue a new key and ask them to keep it private.

5. Get the post taken down

Most leak sites are hosted somewhere that responds to copyright notices. Send a DMCA takedown to the site, or to its host if the site ignores you, with:

• a link to your original listing,
• the exact leak URL,
• a statement that you own the copyright and didn't authorise the copy.

BuiltByBit has its own DMCA form for copies uploaded there. Expect reposts, and don't spend your week chasing every mirror: revoking the key in step 3 already made those copies useless for anyone who restarts.

6. Make the next leak traceable

If this leak was hard to trace, fix it for the next version:

1. One key per buyer, written into each download by your store's placeholder.
2. A server limit per key, so a shared key gets refused on the third server.
3. A startup check with a re-check every few hours, that keeps running when your license server can't be reached.
4. Alerts for shared keys: one key on many servers, or in two countries an hour apart.
5. Obfuscation and a sealed core, so the check is hard to cut out of the leaked jar. See How to obfuscate a Minecraft plugin.

How I handle this with SunLicense

I build SunLicense, so here's the same process in it:

• Each BuiltByBit download gets the buyer's key through the placeholder. The license is named after their BuiltByBit user ID, so the key in a leaked jar points straight at the buyer.
• Obfuscated jars stay traceable: classes that hold a download placeholder are never string-encrypted, so the key is still readable in step 2.
• Sentinel flags keys being shared (too many servers, impossible travel, a revoked key still in use, a key posted in your Discord) and offers one-click fixes you can undo.
• Revoke from the dashboard, the CLI or Discord. The free Paper template re-checks every few hours and keeps running when SunLicense can't be reached.
• On Standard, downloads from SunLicense carry a watermark, Whose copy is this? names the customer when you upload a leaked file, and the web patrol looks for copies offered online.

The free plan covers 3 products and 100 licenses, with no cut of your sales. See how it works for Minecraft plugins before your next release, so the next leak takes five minutes.

This article was written with the help of an AI assistant and reviewed by me before publishing.