How to detect leaked builds of your software and respond when one appears

Sooner or later, most sellers of desktop software find a copy of their product somewhere it shouldn't be: a forum thread, a file-sharing link, a chat server. The first questions are always the same. How long has it been out there, where did it come from, and what can you do about it? Being able to detect leaked builds quickly, and trace them back to a license, is what turns those questions into a routine task.

This guide explains how leak tracing works in general, what PapelShip's Binary Trace and Build Control add, and gives you a step-by-step response plan for the day a build leaks, from the first hour to the next release.

What counts as a leaked build?

A leaked build is any copy of your software that is being used by people who didn't get it from you. It isn't always the result of a sophisticated attack. In practice, leaks tend to fall into a few groups.

• –A paying customer shares their copy with friends, a group or publicly, sometimes together with their key.
• –A customer's account or machine is compromised and their downloads end up elsewhere without their knowledge.
• –A modified build circulates, changed so that it tries to run without a valid license.
• –An internal or test build escapes, for example one sent to a tester or reseller.

The response differs for each. A shared copy calls for a conversation and a ban. A compromised account calls for help, not punishment. A modified build calls for technical containment. That is why the first job is always to find out where the copy came from.

How leak tracing works

The general idea behind tracing a leak is simple: make every copy you deliver attributable, and watch how those copies are used. When a copy appears where it shouldn't, you can connect it back to the order and license it was delivered under. Two kinds of signal usually make that possible.

• –The copy itself. If each delivery is tied to the license it was issued for, a copy found in the wild points back to its origin.
• –How it is used. Licensed software checks in with a server. A key that suddenly runs on many devices, from places its owner has never been, or alongside builds you didn't ship, stands out.

Systems differ in how they make a copy attributable. Some rely on server-side records of which build and file went to which account. Others tie something in each delivered copy to the license it was issued for. Either way, the record has to be created at delivery time; you can't attribute a copy after the fact if nothing linked it to a customer when it left your store.

Neither signal is magic. Leak tracing doesn't stop someone from sharing a file. What it does is remove anonymity: sharing your product stops being free of consequences, because the copy leads back to an account you can act on.

Binary Trace, Build Control and Suspicious Screenshot

PapelShip bundles three tools that are directly relevant to leaks, alongside the licensing basics in qPapel Auth.

Binary Trace answers the first question, where a copy came from, by tracking your builds and detecting whether your customers share your files with others. Build Control narrows what a leaked copy can do, by preventing your file from being modified, patched or opened by unauthorised tools. Suspicious Screenshot gives you something to look at when the activity around a copy looks wrong. Check pricing for which plans include each tool.

How to detect leaked builds: the signals to watch

You won't always find a leak by searching for it. More often, it shows up in your dashboard first. These are the patterns worth watching.

A single signal isn't proof. A customer with a new laptop may request a reset; a genuine hardware change can look odd. Treat the table as a list of reasons to look, and act on the combination of what you find.

It also helps to know what normal looks like before anything goes wrong. Spend a few minutes each week on the Computers page and the keys list: how many devices a typical key uses, how often resets happen, which versions are in use. Against that baseline, a leak tends to stand out quickly.

Step-by-step: what to do when a build leaks

When you learn that a build is out, the instinct is to ship a new version immediately. Usually the fastest containment is on the server, and a new release comes later, once you know what you're fixing.

1. 01

   Confirm and record

   Note where the copy was found, when, and which version it claims to be. Don't run an untrusted copy on your everyday machine; your own dashboard data is usually enough to confirm a leak.

2. 02

   Identify the source license

   Use Binary Trace together with key and device history on the Computers page to find which license the copy is tied to.

3. 03

   Contain the key

   Ban the license key in the dashboard. Every copy that relies on it is refused at its next check, with no release required.

4. 04

   Contain the devices

   Ban the devices that ran the leaked copy, so a fresh key on the same machine doesn't simply restart the problem.

5. 05

   Cut off the value

   Rotate any server-side strings that may have been exposed and tighten Remote Settings. Session Token Enforcement can limit session duration and lock sessions to IP addresses.

6. 06

   Talk to the customer

   Before deciding a ban is permanent, ask what happened. A compromised account deserves help and a replacement key, not the same treatment as deliberate sharing.

7. 07

   Request removal

   Report the copy through the hosting site's own process for unauthorised content. Keep your records from step one.

8. 08

   Fix the cause in the next build

   If the copy was modified, ship a build protected by Build Control, move more valuable data to the server and review which integrity checks run where.

What not to do during a leak

• –Don't name the customer publicly. You may be wrong about who is responsible, and a public accusation can't be taken back.
• –Don't rush out a release that breaks honest users. A hurried build with new checks that misfire costs more goodwill than the leak.
• –Don't ban a whole version. Containment on one key and its devices is precise; blocking everyone on a version punishes buyers who did nothing.
• –Don't stop at the ban. If the leaked copy still works without the server, the cause is in the product, and the next build should fix it.

How to make leaks less damaging before they happen

The best time to prepare for a leak is before one happens. A few design choices decide whether a leaked copy is a crisis or a minor event.

• –Deliver through accounts, not public links. The customer panel gives buyers download links for your files, and paid downloads are only available to buyers.
• –Keep the valuable parts on the server. Server-side strings and files are delivered only to authenticated sessions. A leaked file without them is incomplete, as explained in client-side protection vs server-side secrets.
• –Bind every key to hardware. HWID locking stops a shared key from working on other machines.
• –Load sensitive code in memory. In-memory loading streams encrypted DLLs into memory without writing them to disk.
• –Manage keys deliberately. Clear policies for bans, resets and replacements, covered in secure license key management, make every response faster.

All of this lives in one dashboard in qPapel Auth, next to the store that issued the keys in the first place.

Make every copy lead back to you

A leak is only a disaster when it is anonymous and the leaked copy works without you. Tie every build to a license, check every launch on the server, and keep the valuable parts of your product off the customer's disk.

Then, when a copy turns up, you'll follow a plan rather than react: trace it, contain it, talk to the customer, and harden the next build.