Your Software Got Cracked or Copied: What Indie Developers Can Actually Do

You found your paid desktop app on a warez site. Someone posted a keygen. A GitHub repository contains a modified build with your payment screen removed. Or a Unity asset you sell has been repackaged and uploaded under someone else's name.

The first reaction is usually a mix of anger and urgency: take it down, rotate everything, add more obfuscation, lock every legitimate customer out until the leak is contained. That reaction is understandable. It is also how developers turn one piracy incident into a support incident.

If you are searching for what to do if your software is cracked, the realistic answer has two tracks. Preserve evidence and pursue the copies you can remove. At the same time, make the unauthorized copy less useful without making the legitimate product worse.

Crack, keygen, or re-upload: identify what happened

Do not use “pirated” as the only diagnosis. Different incidents need different responses:

• Cracked binary: your executable was patched so a local license check always succeeds, an expiry branch never runs, or a feature flag is forced on.
• Keygen or leaked key: attackers generate keys your app accepts, or one genuine key is being redistributed and activated across many devices.
• Re-upload: someone republishes your binary, source, web bundle, Unity package, documentation, branding, or screenshots—possibly with ads, telemetry, or payment code removed.
• Clone: another product imitates the behavior or appearance without necessarily copying protected code or assets. This is harder to evaluate from a screenshot alone.
• Impersonation: the copy uses your product name, logo, domain-like name, or publisher identity in a way that can confuse customers.

Save the exact URLs, repository owner, commit hashes, release files, package identifiers, screenshots, timestamps, download hashes, and the original files that show your earlier authorship. Record what is copied rather than only stating that the project is “a crack.” If the download might be malicious, do not run it on your development machine or upload customer data to it.

The distinction matters. A copied codebase can support a copyright complaint. A fake publisher using your name may create a trademark or impersonation issue. A single leaked license is primarily an access-control incident. A clean-room competitor implementing the same idea may be frustrating without being a copy of your protected expression.

Why nothing shipped to a customer's machine is unbreakable

A desktop, Unity, or Electron application eventually runs instructions on hardware the customer controls. A sufficiently motivated analyst can inspect the binary, modify branches, intercept calls, replace bundled JavaScript, or patch the code that handles a server response. Obfuscation raises the time and skill required; it does not change that boundary.

That does not make licensing pointless. A lock does not need to defeat every specialist forever. It needs to stop casual copying, keep one legitimate key from becoming a public key, give paying customers a smoother path than piracy, and let you react when abuse becomes visible. The useful question is not “can this ever be cracked?” It is “what value does the cracked build lose, how quickly can we respond, and what does enforcement cost honest users?”

Avoid the common overreaction of stacking invasive anti-tamper checks until antivirus tools flag the app or legitimate users lose access offline. For most indie products, server-authoritative entitlements, sensible device activation, signed offline state, and predictable recovery provide a better trade than an escalating war against debuggers.

Takedowns in practice: use the right claim

A recent Hacker News discussion about copied Photopea builds is a useful caution. The developer said GitHub replied after a month that it could not confirm a violation of 17 U.S.C. §1201. That section concerns circumvention of technological protection measures. It is not interchangeable with the ordinary notice-and-takedown process for material that copies a copyrighted work.

For an unauthorized copy of your code, binary, art, documentation, or package, the relevant route may instead be a copyright notice under §512. The U.S. Copyright Office's §512 guidance says a notice generally identifies the protected work and the material to remove, provides contact information, includes good-faith and accuracy statements, and carries the owner or agent's signature. Registration is not required merely to send a notice, although U.S. works generally must be registered before filing an infringement lawsuit.

GitHub publishes a separate guide for submitting a DMCA takedown notice and explains its process publicly. Follow the platform's current form, identify specific files or releases, and explain where the original work appears. Do not casually make a sworn claim about material you have not compared.

Use this escalation order:

1. Preserve evidence before the repository, listing, or account changes.
2. Use the host or marketplace's copyright, impersonation, malware, or trademark channel that matches the facts.
3. If the copy is hosted elsewhere, identify the hosting provider and its designated copyright contact rather than arguing with the uploader indefinitely.
4. Report search results separately when a search engine exposes a persistent infringing URL.
5. Escalate to counsel when a counter-notice arrives, the platform rejects a complete notice, the copy impersonates your business, or the commercial damage justifies it.

Trademark can help when someone is presenting the copy as your product or confusing buyers about its source. It does not give ownership of a generic feature or software idea. Keep release records, dated screenshots, package-signing history, and consistent use of your product name; if the brand is valuable, discuss registration and enforcement strategy with a trademark professional.

How to make a crack worth less

The strongest practical defense is to keep changing value outside the copied binary. A pirated build may launch today, but it should not automatically receive every benefit of an active customer relationship.

• Updates: deliver signed releases through an authenticated update channel. A copied old build can keep running without silently becoming the latest paid version.
• Cloud or team features: keep collaboration, sync, managed assets, usage quotas, or hosted processing behind an account and current entitlement when those features genuinely need a server.
• Support and recovery: give customers device resets, account recovery, invoices, and responsive help that an anonymous download cannot provide.
• Entitlements: return a product, edition, expiry, activation limit, and explicit feature set—not one permanent boolean. Feature-based licensing lets the product evolve without shipping a different security model for every tier.
• Authenticity: code-sign installers and updates so customers can distinguish your release from a modified upload.

Do not move arbitrary functionality to a server only to punish pirates. A calculator that becomes unusable on a flight has lost product quality, not gained security. Keep the online boundary where it creates real value or where current state matters, and use explicit offline policy for the rest.

Signed responses beat a local true/false check

The easiest licensing check to patch looks like this: read a local file, compare a string, return true. The attacker only needs to change one branch or replace the file.

A better online design sends the key's lookup value, product identity, app version, and device identity to the licensing service over TLS. The service decides the current state and returns structured data: valid or invalid, reason, expiry, edition, features, activation allowance, and trial state. Your app should fail safely when the response is malformed and should not accept a response for a different product.

For offline use, cache a short-lived payload signed by a private key held only by the service. Ship only the public verification key in the application. The app verifies the signature, product, device, expiry, and allowed offline window before trusting it. The C# signed-token walkthrough and C++ offline validation tutorial show the model in concrete code.

A signature prevents an attacker from inventing or editing an authentic entitlement payload without detection. It does not prevent someone from patching your application so it skips verification entirely. That is why signed state is one layer, not a claim of uncrackable software. Keep the decision distributed across meaningful product boundaries, and avoid a single obvious function whose only job is to unlock everything.

For the current server-side contract, see the validation API and the security boundaries in PermitCore's security documentation.

Detecting and revoking leaked license keys

If a genuine key leaks, do not rotate every customer's key. Identify the affected license first. Look for a sudden increase in unique devices, impossible geography, repeated activation-limit failures, unusual app versions, or validation volume that does not match the customer's plan.

Then choose a proportionate response:

1. Verify the signal. A new laptop, VPN, classroom, render farm, or shared team license can look unusual without being abuse.
2. Stop new activations. Freeze or reduce the affected key's activation allowance while preserving the evidence.
3. Contact the customer. A buyer may be the victim of malware, a public support paste, or an ex-employee rather than the source of deliberate redistribution.
4. Revoke and replace. Revoke the leaked credential, issue a replacement to the verified owner, and invalidate active sessions or devices that should no longer work.
5. Shorten stale access. Previously signed offline tokens remain usable until their expiry. Use an offline window that matches the product's real needs, not an effectively permanent cache.

Activation limits are not just a purchase-time restriction; they create the operational signal that one key is spreading. The activation-pool documentation, license controls, and guide to preventing license-key sharing cover the mechanics and the false-positive tradeoffs.

How to turn some pirates into customers

Not every unauthorized user was a lost full-price sale. Some could not evaluate the product, could not pay in their region, feared a subscription, needed it once, or did not trust a small vendor enough to buy before trying. Others simply will not pay. Treating all of them as the same customer leads to bad pricing and worse product decisions.

Make the legitimate route obviously better:

• Offer a useful trial that starts server-side and survives reinstall attempts without collecting invasive hardware data. See the software trial implementation guide.
• Price for the audience you actually have: indie, commercial, team, education, and regional cases may need different paths.
• Let a buyer deactivate an old machine and recover access without waiting days for support.
• Explain perpetual versus subscription rights, offline behavior, update eligibility, and refund terms before checkout.
• For Unity tools, make the official package easier to update and verify than a forum re-upload. The Unity asset licensing tutorial shows a product-scoped flow.

A respectful “this copy cannot receive updates; start a trial or enter a valid license” screen usually converts better than deleting user files, shaming the user, or pretending a network error is corruption. Never make anti-piracy code destructive. The person seeing the message may have bought the product and hit a recoverable licensing problem.

Checklist for the first 30 minutes

1. Minute 0–5: preserve. Save URLs, screenshots, timestamps, account names, hashes, repository commit IDs, and a copy of the relevant public material. Do not interact with suspicious binaries on your normal machine.
2. Minute 5–10: classify. Decide whether this is a cracked binary, leaked key, keygen, copied source/assets, re-upload, impersonation, or a combination.
3. Minute 10–15: contain. If a specific credential is confirmed leaked, block new activations or suspend that license. Do not revoke unrelated customers or ship an emergency build without testing.
4. Minute 15–20: notify. Use the platform channel that matches the evidence—copyright, trademark, impersonation, malware, or licensing-key abuse. Be specific and truthful.
5. Minute 20–25: protect customers. Publish a short notice only if users could confuse the copy with your release or run malware. Point to your canonical download and code-signing identity.
6. Minute 25–30: plan the next build. Add one measured improvement: shorter signed offline state, product-scoped validation, clearer feature entitlements, activation telemetry, authenticated updates, or better trial conversion.

After the immediate response, write a short incident record: what leaked, when it was discovered, which users or keys were affected, what you changed, and what you deliberately did not change. That keeps the next incident from becoming another improvised emergency.

You cannot make client-side software impossible to copy. You can make unauthorized copies stale, disconnected, harder to trust, and less convenient than buying. More importantly, you can build an incident process that protects revenue without treating every legitimate customer as an attacker.