Adding licensing to your .NET app? Protect the license check too

Adding licensing to a .NET application is straightforward. Making that licensing hard to bypass is the part most developers underestimate. This post covers both.

Common .NET licensing approaches

• Offline signed license files/keys. You sign a license (e.g. with RSA) and the app verifies it against an embedded public key. Simple, works offline, but can’t be revoked once issued.
• Online activation. The app contacts a server to activate a key, binding it to a machine and enforcing a seat limit. Supports revocation and subscriptions; needs a backend.
• Node-locking. Tie a license to a hardware/machine fingerprint so a key can’t be freely shared.
• Feature gating. Unlock “pro” features based on the license tier.

All of these are good patterns. But they share one weakness.

The weak point: the check itself

Every one of these approaches eventually runs code like:

if (license.IsValid)
    EnableProFeatures();

In an unprotected .NET assembly, that check is trivial to defeat. An attacker opens your binary in dnSpy, finds the method, edits the IL so IsValid always returns true (or removes the check entirely), and saves a patched build. Your carefully signed, node-locked, online-activated license — bypassed in minutes, because the verification code was readable and editable.

What actually makes licensing hold

• Obfuscation — rename and flatten the license logic so it’s hard to locate and understand in a decompiler.
• String encryption — hide the URLs, keys, and messages that make the licensing code easy to search for.
• Anti-tamper — detect that the assembly was modified after signing, so a patched binary refuses to run.
• Anti-debug — detect an attached debugger like dnSpy so attackers can’t step through and edit the check live.

In other words: your licensing design provides the policy; obfuscation and hardening protect its enforcement. Skip the second half and the first is decorative.

Practical checklist

1. Choose a licensing model (offline signed, or online activation with revocation and seats).
2. Keep any real secrets — signing keys, server credentials — off the client.
3. Obfuscate and harden the Release build, including the licensing code, with anti-tamper enabled.
4. Verify the protected build still activates and runs identically.
5. Sign the binary so tampering is detectable.

Nebula.NET handles step 3–5 — obfuscation, string encryption, anti-tamper/anti-debug, and Authenticode signing — for .NET Framework 4.8 and .NET 6–10. See how it works, and note how the same techniques that hide your algorithms also protect your license enforcement.

Start free from the download page.