DEV Community: Zero Heartbeat

Licensing for Air-Gapped and Offline Environments

Zero Heartbeat — Tue, 29 Sep 2026 14:25:40 +0000

The most nerve-wracking licensing question I've ever been asked came from a defence contractor: "Our production network has no internet, ever, and it never will. Can your licensing work in there?" It's a fair question that trips up a surprising number of licensing products, because so many of them quietly assume a machine can phone home. In a truly air-gapped environment — a classified network, an isolated industrial control system, a secure facility — there is no phone home. There is a USB stick and a security officer who inspects what's on it.

The reassuring answer is that offline licensing isn't a degraded mode; done right, it's a fully legitimate one, built on the same cryptography as everything else. This post explains how air-gapped and offline activation actually works: signed license blobs, the manual activation dance, expiry and grace without a clock server, and revocation with no network.

Key takeaway: Air-gapped licensing works because trust comes from cryptography, not connectivity. A signed license blob verifies locally against an embedded public key with zero network calls, so a fully disconnected machine can prove a license is authentic, unaltered, bound to it, and unexpired — and reject a revoked one via a signed list you ship out of band.

Why offline validation is possible at all

If you've read offline license validation explained, you know the core asymmetry, so I'll keep this brief and build on it toward the air-gapped case. Your server holds a private key that can create signatures; the client embeds only the matching public key, which can verify a signature but never forge one. Verifying a signature is pure math on data the app already holds, so the client can confirm a license was signed by you — and hasn't been altered by a single byte — with no live server. That one property is what makes air-gapped licensing real rather than a compromise.

Everything in this post is an application of that idea to the hardest deployment: a machine that will never see the network, not even once.

The signed license blob

The unit of an offline license is a signed blob: a small payload of facts with a signature over it. Conceptually:

{
  "licensee": "Acme Defense Systems",
  "product": "acme-analyzer",
  "tier": "enterprise",
  "seats": 5,
  "expiryUtc": "2027-09-29T00:00:00Z",
  "machineFingerprint": "b3f1…c9a2",
  "entitlements": { "export": "true", "max-projects": "50" },
  "signature": "MEUCIQ…"   // over every field above, made with the vendor's private key
}

The client verifies the signature against its embedded public key, and only then reads the now-trusted fields. Flip tier from enterprise to anything else, or edit expiryUtc, and the signature no longer matches — validation fails. The machineFingerprint field is what node-locks the blob to one machine so the same file can't be copied across an air-gapped fleet (the fingerprinting and swap-tolerance details are in node-locking and seat management).

The manual activation flow

Here's the part unique to air-gapped operation: how does a machine that can't make a request get a signed blob bound to its fingerprint? Through a file exchange — the offline activation dance:

Generate a request on the offline machine. The app produces a small request file containing the machine's fingerprint (and the license key or order reference). No network involved; it just writes a file.
Carry it out. A USB stick, an approved file-transfer channel, whatever the facility permits. The request goes to a connected machine.
Submit it to the issuing service. From the connected machine — a browser hitting the vendor's portal, or an admin console — the request is submitted. The service validates it, consumes a seat if appropriate, and returns a signed activation file bound to that exact fingerprint.
Carry it back and import. The signed file returns to the offline machine on the same channel and is imported. The app verifies the signature locally and activates.

From then on the machine validates entirely offline, forever if need be. The connected step happened once, on a different machine, and moved only signed files — no live connection from the secure host ever existed. That's what satisfies a security officer: the air-gapped machine's network posture never changed.

For deployments where even that round trip is impractical, the simpler variant is to skip the request/response and issue a pre-bound file — the vendor issues a signed blob for a known fingerprint (or an unbound, non-node-locked file for a fixed number of installs) and ships it with the software. Less precise, but sometimes it's the only workable flow.

Expiry and the clock-tampering problem

A subscription or trial carries an expiryUtc, and offline validation just compares it to the current time — easy. The obvious attack is just as easy: roll the system clock backward and a trial never ends, or an expired license springs back to life. An air-gapped machine has no time server to appeal to, so the defence has to be local.

The standard approach is monotonic time tracking: the app remembers the latest time it has legitimately seen, and treats a clock that jumps meaningfully backward as tampering, refusing to validate until the time is corrected. A small tolerance window (a day or so) absorbs honest clock adjustments and time-zone quirks without flagging them. Perpetual licenses, having no expiry, aren't subject to the check at all. It's not bulletproof — nothing client-side is — but it turns "just change the date" from a trivial bypass into something that visibly breaks the license.

Grace windows in disconnected setups

Grace is usually discussed for intermittently connected clients — cache a lease, survive a brief outage — and I covered that pattern in the offline-validation post. In a fully air-gapped deployment the concept shifts: there's no lease to refresh, so "grace" becomes about how you handle the transition around expiry.

Two humane practices matter here. First, warn early: because there's no server to email a renewal reminder, the client itself should surface "your license expires in 14 days" well ahead, since re-issuing an air-gapped license is a multi-day physical process, not a one-click renewal. Second, consider a short read-only or reduced-function grace period after expiry rather than an instant hard stop, so a lapsed license in a secure facility doesn't halt critical work while the paperwork for a new signed file works its way through. Both are about respecting that, in these environments, renewal has real latency.

Revocation without a network

The one thing offline genuinely can't do instantly is revoke. A blob signed last year knows nothing about a refund or leak last week; its payload is fixed at issue time. The offline answer is a signed revocation list: a list of revoked license ids, itself signed by your private key so the client trusts it, distributed with a software update or as an out-of-band file the facility imports. The client checks incoming licenses against the list and drops revoked ones.

It moves at the speed of your distribution — days or weeks, not seconds — but it means an air-gapped install isn't defenceless against a known-bad key. For most air-gapped customers, whose update cadence is deliberate anyway, that's an acceptable trade.

Being honest about the limits

Offline validation proves authenticity, integrity, binding and expiry beautifully, and it's the right tool for air-gapped and enterprise deployments — but it's not magic. The check runs on the customer's machine, so a determined attacker with a decompiler can patch it out, and offline revocation is never instant. That's not a reason to avoid offline licensing; it's a reason to be precise about its job and to pair the client check with obfuscation so patching costs real effort (see protecting your licensing checks). And remember the distinction from self-hosted vs cloud licensing: serving air-gapped customers only needs signed offline files from your issuing service — you self-host the service only when the issuing service itself must run disconnected.

Doing this with Keyright

Keyright is offline-first by design, so air-gapped deployments are a supported path, not an afterthought. It issues signed offline license files that verify locally against a public key you embed at build time — no network call, so they work on fully disconnected machines — node-locks them with tolerance, defends against clock tampering, and ships signed revocation lists you distribute out of band. Every tenant gets its own isolated signing key whose private half never leaves the server, and the SDKs for .NET, Node, Python and Java fail closed throughout. When the issuing service itself must live inside an isolated network, Keyright self-hosts — the identical build, fully air-gapped, on your own database.

Start on the free managed plan to wire up offline validation before you pay a cent — see the plans — or, if your deployment is fully air-gapped end to end, read how self-hosting works and talk to us about an on-prem instance.

Software license types explained: perpetual, subscription, floating, trial

Zero Heartbeat — Sun, 27 Sep 2026 06:07:41 +0000

Software license types are the models that define how a customer is allowed to use your software: perpetual (buy once, use forever), subscription/term (valid for a fixed period), floating/concurrent (a shared pool of seats), node-locked (bound to one machine), trial/evaluation (time-limited access), and volume/site (many seats or a whole organization under one agreement). Most products combine several. This reference explains each one, when to use it, its trade-offs, and how it maps to what a modern licensing system enforces.

Comparison at a glance

Model	What it grants	Best for	Main trade-off
Perpetual	Use forever, one purchase	Buyers who dislike recurring fees; on-prem tools	No recurring revenue; needs a separate maintenance window for updates
Subscription / term	Use for a fixed period (e.g. 1 year)	Most modern software; SaaS and cloud tools	Customer loses access if they stop paying; needs expiry + renewal logic
Floating / concurrent	Shared pool; N active at once	Teams sharing licenses across many users	Requires a server to track who is active in real time
Node-locked	Bound to one machine	Fixed installs, per-device pricing, air-gapped sites	Hardware changes can lock users out without tolerance
Trial / evaluation	Full features for N days	Driving conversion; letting buyers self-serve	Must auto-expire and resist abuse (one per customer)
Volume / site	Many seats or a whole org	Enterprise and education deals	Pricing and fulfillment complexity; needs bulk operations

Perpetual licensing

A perpetual license is bought once and runs forever — there is no expiry. It's the model buyers like most, because they own what they paid for, and it's common for on-premise and developer tools.

The catch is updates. A perpetual license usually pairs with a support-and-maintenance window: a period (often a year) during which the customer is entitled to new versions and support. When that window lapses, the installed software keeps working, but the customer must renew maintenance to get further updates. This lets you sell perpetual licenses without giving away every future release for a single payment.

Use it when your buyers strongly prefer one-time purchases, or you sell a tool that must keep running unchanged for years. The trade-off is no recurring revenue and the need to manage a maintenance window separately from the license itself.

Subscription / term licensing

A subscription (or term) license is valid only for a fixed period — typically annual — and carries an expiry the app enforces. When it lapses without renewal, the paid features lock. This is the default for most modern software because it ties revenue to ongoing value and funds continuous development.

Use it when you ship regular updates or run any kind of service. The trade-offs are that you now need reliable expiry enforcement (including defense against a customer rolling the system clock back to extend a trial or term) and a smooth renewal path that extends the existing license rather than re-issuing a new key.

Floating / concurrent licensing

A floating (concurrent) license is a shared pool: an organization buys, say, ten seats, and any ten machines can be active at once. When a user finishes, their seat returns to the pool for someone else. It maximizes value for teams where far more people could use the software than ever use it at the same time.

Use it when you sell to organizations that share access across shifts, labs, or large teams. The trade-off is that true concurrency requires a server tracking active sessions in real time — the most infrastructure-heavy model. A common, simpler middle ground is seat-based licensing: a fixed number of activations, each bound to a machine, with the ability to release or transfer a seat when a device is retired. That gives teams flexibility without a live concurrency broker.

Node-locked licensing

A node-locked license is bound to a specific machine through a hardware fingerprint derived from stable device and OS attributes. It only works on that machine, which stops one license from being copied across an organization.

Use it when you price per device, ship to fixed installs, or serve air-gapped and high-security environments where per-machine control matters. The trade-off is tolerance: fingerprint too strictly and a customer who swaps a network card or upgrades a disk gets locked out; too loosely and the lock is meaningless. A good implementation allows a small amount of hardware drift and lets you control which components identify a machine for VMs and CI.

Trial / evaluation licensing

A trial is a time-limited license that unlocks the full paid experience for a set number of days, then expires. It's the most effective conversion tool you have, because it lets a buyer prove value before paying.

Use it when your software's value is best demonstrated hands-on. The trade-offs are abuse prevention and expiry: a trial should be one per customer per product, idempotent so a refresh or a second click never resets the clock, auto-expiring, and ideally able to convert to a paid license with no reinstall. Air-gapped evaluators may need a signed offline trial file instead of an online activation.

Volume / site licensing

Volume and site licenses cover large deployments under one agreement. A volume license is really about issuing many keys efficiently — in bulk, or automatically through your store's fulfillment — while a site license is typically a single license with a very high seat count that covers an entire organization or location.

Use it when you close enterprise or education deals. The trade-off is operational: you need bulk issuance and management (bulk seat changes, bulk revocation, reporting) and clear terms for how the seats are counted.

How these map to Keyright

Keyright supports these models directly rather than forcing you into one:

Perpetual and term — issue a license with no expiry for perpetual, or set an expiry for subscription/term. Perpetual licenses aren't subject to the clock-tamper check that protects time-limited ones.
Node-locked seats — bind each seat to a machine fingerprint with configurable tolerance, enforce the seat count server-side, and let customers release or transfer a seat when they change devices — the practical, seat-based take on floating.
Entitlements and tiers — define per-tier feature flags and numeric limits so one binary unlocks different capabilities per plan, and change what a plan includes without shipping new code.
Trials — turn on self-service trials per product, one-per-email and idempotent, that activate through the exact same path as a paid key and convert seamlessly.
Volume / site — issue keys via the admin API or automatic store fulfillment, manage them in bulk (bulk seat changes and bulk revocation), or cover an org with a single high-seat license.
Revocation — kill a refunded or leaked key in one click; it reaches online clients on the next refresh and offline clients through a signed revocation list.

Every license and lease is signed with your tenant's own RSA key and verified offline by the SDK, so all of the above works air-gapped and fails closed by design. See the full capability list on the Keyright features page, or read the Keyright documentation to wire up the model that fits how you sell.

How reverse engineering a .NET app works (and how to make it not worth it)

Zero Heartbeat — Sun, 27 Sep 2026 06:07:40 +0000

Reverse engineering a .NET app is straightforward by default: C# compiles to Intermediate Language (IL) that decompiles cleanly back to readable C#, so an attacker with a free tool can see your strings, license checks and business logic almost as clearly as you wrote them. The good news is that you can change that economics dramatically. This guide walks through exactly how a .NET binary gets reversed — and the defensive layers that make reversing it cost more than it is worth. Nebula.NET is the tool we build at Delta1 Labs to apply those layers, and we will be honest throughout about what each one does and doesn't do.

Why is .NET so easy to reverse engineer?

Unlike C or Rust, which compile straight to native machine code, .NET languages compile to Intermediate Language — a high-level, portable, stack-based instruction set that the runtime JIT-compiles on the target machine. To make that work, the compiler embeds a remarkable amount of information in your DLL or EXE: full type names, method names, parameter names, field names, and complete metadata describing every member.

That metadata is exactly what a decompiler needs. It does not have to guess at structure the way a native disassembler does — the names and shapes are right there. So the decompiler's job is essentially to run the C# compiler in reverse: read the IL, match its patterns back to language constructs (a foreach, an async method, a LINQ query), and pretty-print the result. For an unprotected assembly, the output is frequently close enough to recompile.

What does an attacker actually see?

Open an unprotected release build in a decompiler and here is what a reverse engineer walks away with:

String literals in the clear — API endpoints, connection strings, SQL, error messages, and too often things never meant to ship in cleartext.
Named logic. Your ValidateLicenseKey and IsTrialExpired methods keep their names and read like your source.
Control flow. The exact if/else a license check runs, so an attacker can find the one branch to flip.
Type and API structure, making it trivial to see how your app fits together and where to attack.

How does the reverse-engineering workflow actually go?

The tooling is mature and free. A typical session looks like this:

1. Decompile to C

The attacker opens the assembly in a static decompiler — ILSpy, dotPeek, our own Glass.NET, or the community-maintained dnSpyEx — and browses the type tree. No source, PDB or special build required; a standard managed .dll or .exe is enough. Within seconds they have navigable C#. (Full steps: how to decompile a .NET DLL to C#.)

2. Find the interesting code

They search for the obvious keywords — "license", "trial", "activate", "premium" — or grep the decompiled strings. On an unprotected binary this lands them on the relevant method immediately: named methods and readable literals turn a needle-in-a-haystack problem into a text search.

3. Understand, then patch or extract

Once they can read the logic, they either extract what they wanted (an algorithm, an embedded key) or patch it. With dnSpyEx they can even edit the IL and reassemble — flip a trial check to always return false, or short-circuit a license validation to always return true — and save a cracked binary.

If you have never watched this happen to your own code, do it now. Take a release build, open it in Glass.NET — the free decompiler we ship precisely so you can see what an attacker sees — and browse to a class you care about. That moment of seeing your own logic laid bare is the honest starting point for deciding what to protect.

The defensive layers that raise the cost

There is no single switch that "protects" an assembly. Real protection is a stack of techniques, each raising the attacker's cost a little more. Here is the ladder from lightest to strongest.

Identifier renaming

The cheapest win. Renaming turns ValidateLicenseKey and _customerBalance into meaningless symbols like a and b. The IL runs identically, but the human-readable names that make decompiled code easy to navigate are gone. The trade-off: you cannot rename everything — public API surfaces, reflection targets and serialization contracts must be preserved. Nebula.NET does public-API-preserving renaming so your callable surface stays intact. Runtime cost: effectively zero.

String encryption

Renaming hides what things are called; string encryption hides the data leaking through literals. It stores strings encrypted and decrypts them at runtime only when used, so searching the binary for a keyword turns up nothing. Be clear-eyed: the string is in memory at some point, so a debugger can still recover it — but the trivial "grep for the endpoint" attack dies. Nebula.NET encrypts string and credential literals and can key decryption per call-site.

Control-flow obfuscation

This hides what the code does. It rewrites each method — flattening straight-line logic into a dispatcher state machine, adding opaque predicates and bogus branches — so the decompiler emits a tangle of gotos instead of clean C#. The realistic bar is not just confusing a human; it is surviving automated deobfuscators like de4dot, which Nebula.NET's transformation is designed to resist rather than be unwound in one pass. Runtime cost: small.

Anti-tamper and anti-debug

Anti-tamper adds an integrity check: the assembly verifies at runtime that its own code has not been modified, so an attacker cannot patch out a check and have the binary keep running. Anti-debug raises the cost of the dynamic-analysis step. Neither is a wall; both mean an attacker cannot just flip one branch and win.

Method encryption and code virtualization — the heavy artillery

For your crown jewels, two techniques remove the readable IL entirely:

Method encryption stores a method's IL encrypted in the assembly and re-emits it at runtime, so a decompiler sees only a stub — no reconstructable C# or IL.
Code virtualization translates a method into bytecode for a custom virtual machine embedded in your assembly. There is no standard IL left to read, and an attacker must reverse-engineer your specific VM before they can even begin.

Both are expensive to break and, in return, meaningfully larger and slower — so you apply them surgically to the licensing check, the proprietary algorithm, the anti-cheat routine, not the whole assembly. You can explore the full set on the Nebula.NET features page, with configuration in the docs.

The honest part: nothing here is uncrackable

This is the section most vendors skip. Every layer above runs on a machine you do not control, which means:

Your code still executes, so at some moment it must be in a form the CPU understands. A patient attacker with a debugger and a memory dump can work around a great deal.
Secrets shipped in the binary are recoverable — API keys, connection strings, signing keys — encryption or not. Keep them server-side.
Client-side license checks can be bypassed. However well hidden, they run on the attacker's machine. Serious licensing needs server-side validation via online activation, with client protection making the bypass expensive rather than trivial.

None of this makes protection pointless — it reframes the goal correctly. You are not building a vault; you are raising a wall higher than what is on the other side. For most commercial .NET software, that wall stops the casual "decompile, copy, ship" attack cold and pushes the serious attacker's cost past the point of worthwhile.

How to verify it worked

Do not take any tool's word for it, including ours. The loop takes minutes: build and run your tests, protect the assembly, run your tests again against the protected build (behavior must be identical), then open the result in Glass.NET and try to read what you protected. Where you had clean C#, you should see renamed symbols, scrambled control flow, encrypted strings, and — for encrypted or virtualized methods — no reconstructable C# at all. Being able to audit the output yourself is why we ship a free decompiler alongside the protector.

The bottom line

Reverse engineering a .NET app is easy by default and impossible to prevent entirely — be skeptical of anyone claiming otherwise. What you can do is stack renaming, string encryption, control-flow obfuscation and anti-tamper across the assembly, reserve method encryption or code virtualization for your real intellectual property, and move secrets and license enforcement to a server you control. To see where your code stands today, download Nebula.NET free, protect a representative build, and open it in Glass.NET. The before-and-after comparison is the only benchmark that matters.

How to license your software: a practical guide

Zero Heartbeat — Sun, 27 Sep 2026 06:06:57 +0000

To license your software, you pick a licensing model, issue each customer a cryptographically signed license rather than a homegrown key string, deliver it at purchase, and verify it inside your app — an offline signature check, optionally paired with online activation to enforce seats and revocation — then gate features on entitlements and handle trials, renewals and revocation on the server. This guide walks that whole path end to end, product-neutral in the mechanics, so you can wire up real licensing whether you build it yourself or adopt a service.

Step 1 — Choose a licensing model

Everything downstream follows from this choice, so make it first. The common models:

Perpetual — the customer buys the software once and runs that version forever. Simple, but there is no recurring revenue and no built-in reason for the license to ever stop working.
Subscription / term — the license is valid for a fixed window (typically a year) and carries an expiry the app enforces. This is the default for most modern software because it aligns revenue with ongoing value.
Seat-based — the license permits a set number of activations, one per machine or user, and you enforce the cap. Standard for team and enterprise sales.
Trial / evaluation — a time-limited license that unlocks the paid experience for a fixed number of days, then expires.

Most real products combine these: a subscription with a seat count, or a perpetual license with a support-and-updates window. You do not have to pick exactly one. (For a full reference on each model and when to use it, see our companion post, software license types explained.)

Step 2 — Issue a signed license, not a key string

The single most important decision is what a license is on the wire. The tempting shortcut — generate a random or patterned key string and have your app accept anything matching that pattern — fails structurally: if your app can decide a key is valid by looking at the key, then everything needed to mint a valid key is inside your app, and a decompiler turns your validation code into a keygen.

The correct unit is a signed license: a small payload of facts — licensee, product, tier, seats, expiry, entitlements — with a cryptographic signature over it. Your server signs the payload with an RSA private key that never leaves the server; your app embeds only the matching public key. A public key can verify a signature but can never create one, so:

Decompiling your app reveals only the public key, which is useless for forgery.
Changing one byte of the payload (bumping tier from free to pro) breaks the signature, so validation fails.

This is the same asymmetry behind TLS and code signing, pointed at licensing. In .NET the primitives ship in the box, which is exactly the trap — the signature check is a few lines, so people assume the whole system is easy, and it isn't (Step 5 onward is where the real work lives).

Step 3 — Deliver the license to your customer

Once you can sign a license, you need to get it to the buyer without a manual email for every sale. In practice there are three delivery paths, and a real product uses more than one:

On purchase, automatically. Wire your checkout or Merchant-of-Record provider's "paid" event to your licensing backend so a successful payment mints and emails the key, and a refund or cancellation revokes it — no human in the loop.
From an admin console, for manual sales, resellers, and support-issued keys.
Self-service, where the customer starts a trial from your own site and receives a key instantly (Step 8).

The key you deliver is the string the customer later pastes into your app to activate. Everything else — the entitlements, the expiry, the seat count — travels inside the signed payload, not in the visible key.

Step 4 — Verify the license in your app

Verification has two halves, and you almost always want both.

Offline signature check. At startup, your app recomputes the signature check against its embedded public key and reads the now-trusted fields: product match, expiry, node-lock. This needs no network, so it works air-gapped and survives outages. The cardinal rule is to fail closed — any problem (bad signature, wrong product, expired, revoked, a clock rolled backward to cheat a trial, a missing file) must resolve to the unlicensed state, never throw and never unlock. If a check failed open, the easiest crack would be to make it fail on purpose.

Online activation. When you need to enforce seats or revoke keys promptly, add one online step: the app exchanges the license key plus a stable machine id for a short-lived, signed lease bound to that machine. The lease is verified offline and cached locally, so after a single activation the app keeps working offline until the lease nears expiry — at which point it reconciles seats and revocation with the server. A brief outage is covered by the still-valid cached lease, a grace window, so you don't lock out a paying customer over a flaky connection.

Step 5 — Enforce seats and node-locking

You cannot count seats offline — a lone client has no idea how many other machines run the same key. The moment you promise "3 seats," you need a server that records activations, enforces the cap atomically, makes re-activating an already-bound machine idempotent, and lets a customer release a seat when they retire a device. Pair that with node-locking: bind each seat to a machine fingerprint derived from stable hardware and OS attributes — with tolerance, so a swapped network card or upgraded disk doesn't lock an honest user out and generate a support ticket.

Step 6 — Gate features with entitlements and tiers

Ship one binary and unlock different capabilities per plan by putting the capabilities in the license. Define a tier (e.g. pro, enterprise) whose entitlement template carries named flags ("export": "true") and numeric limits ("max-projects": "10"), and gate features on those entitlements rather than a hard-coded tier check — IsEnabled("export"), GetLimit("max-projects", fallback: 1). Then changing what a plan includes is a dashboard edit, not a new release. Every entitlement read should fail closed too: a missing flag reads as off, a missing limit returns your fallback.

Step 7 — Handle trials, renewals and revocation

These three are what turn a license check into a business:

Trials are time-limited keys that unlock the paid experience and auto-expire. Make them one-per-email-per-product and idempotent so a refresh never resets the clock, and let a trial convert to a paid license with no reinstall.
Renewals extend an existing subscription's expiry (and can adjust seats) without issuing a new key — the customer keeps the same license.
Revocation kills a refunded, charged-back or leaked key. Online, it takes effect on the next lease refresh; offline, you distribute a signed revocation list your app honors with no network call.

Build it, or buy it

The signature check is an afternoon. Everything from Step 3 onward — key management and rotation, server-side seat counting, revocation that reaches offline clients, trials with abuse controls, a customer portal so seat moves and re-downloads don't become support tickets — is a stateful, security-sensitive backend that no customer will ever thank you for. That's the real build-vs-buy question, and we break down the itemized cost in build vs buy: software licensing for .NET.

Where Keyright fits

Keyright is the licensing infrastructure we build at Delta1 Labs, and it hands you this entire guide as a service. It issues signed offline license files and short-lived online activation leases from one system; enforces node-locking and seats server-side with self-service seat release; carries entitlements and tiers so one binary unlocks per plan; supports perpetual and term licenses, self-service trials, renewals, transfers, and one-click revocation that reaches both online and offline clients. Every tenant gets its own isolated RSA signing key — the private half stored encrypted server-side and never exposed — plus a hosted customer portal and SDKs for .NET, Node, Python and Java that all fail closed by design.

To wire it up end to end, start with the Keyright getting-started guide; the free plan covers real licensing before you pay a cent, and you can see the plans here.

Free .NET obfuscator: what you actually get (and what you don''t)

Zero Heartbeat — Sun, 27 Sep 2026 06:06:21 +0000

A free .NET obfuscator gives you identifier renaming, usually some string encryption and basic control-flow protection — enough to stop the casual "decompile and read" attack — but the features that make protection hold up commercially (full string encryption, anti-tamper, method encryption, code virtualization, CI integration, signing and stack-trace de-obfuscation) are almost always paid or simply absent. This guide gives you the honest breakdown so you can decide when free is genuinely enough and when it is not, using Nebula.NET's free edition as a concrete example.

Why is "free .NET obfuscator" such a common search?

Because .NET decompiles trivially. C# compiles to Intermediate Language plus full metadata — every type, method and field named — so any decompiler reconstructs near-original C# from an unprotected DLL in seconds. Once a developer sees their own logic laid bare in a tool like Glass.NET, the natural next move is to look for a free way to fix it. That instinct is right; the trick is knowing what "free" actually buys.

What a free .NET obfuscator gives you

The lightweight transforms are runtime-cheap and comparatively simple to implement, so they show up in free tiers and open-source tools alike.

Identifier renaming

The headline feature and the biggest single win. Renaming turns ValidateLicenseKey, _customerBalance and CalculateDiscount into meaningless symbols like a, b, c. The IL runs identically, but the human-readable names that make decompiled code easy to navigate are gone. A reverse engineer can no longer grep for "license" and land on your check. Runtime cost is effectively zero, and this alone defeats the lowest-effort attack.

Some string encryption

Most free tiers include limited string encryption — a fixed number of literals, or a basic scheme. It stores strings encrypted and decrypts them at runtime, so searching the binary for an endpoint or an error message turns up nothing. This is genuinely useful, but note the word "limited": the cap is often where the free tier draws its line.

Basic control-flow protection

Some free obfuscators apply light control-flow obfuscation to a small number of methods — flattening straight-line logic so the decompiler emits gotos instead of clean if/else. Free-tier control flow is often capped in count and lighter in strength than the paid tier.

The catch with free open-source tools

Open-source obfuscators like ConfuserEx are genuinely free and capable, but they come with trade-offs worth naming: many are archived or community-maintained rather than actively supported, their output is a frequent target for public deobfuscators like de4dot, and there is no support line when a protected build misbehaves. We cover the specifics in our ConfuserEx comparison. Free is not the same as maintained.

What free typically does NOT give you

This is the part that matters most, because it is where protection goes from "speed bump" to "actually holds up." These layers cost real engineering to build and maintain, so they live in paid tiers.

Uncapped, full string encryption — every literal in the assembly, not a handful, with per-call-site keying so one dumped routine does not reveal everything.
Anti-tamper and anti-debug. Without anti-tamper, an attacker can patch out a check — a trial expiry, a license test — and the binary keeps running as if nothing happened. This is one of the most important paid features, because renaming a check the attacker can still patch does not stop them.
Method encryption. Storing a method's IL encrypted and re-emitting it at runtime, so a decompiler sees only a stub. See method encryption in .NET for how it works.
Code virtualization. Compiling sensitive methods to a custom bytecode VM so there is no IL left to decompile — the strongest common protection, typically a top-tier feature.
MSBuild / CI integration. Protection that runs automatically as part of dotnet build on your build server, so there is no manual step to forget. Free tiers usually make you run the tool by hand.
Authenticode signing integrated into the protection step, for distribution integrity.
Stack-trace de-obfuscation. Once you rename everything, your crash reports come back renamed too. Reading them back to original names needs a mapping file and tooling — almost always a paid capability.

How Nebula.NET's free edition fits

Nebula.NET comes in three editions — Free, Licensed and Enterprise — all built on the same tested engine. (Our which edition is right for you guide covers the full decision.) The free edition is deliberately not a rename-only stub:

Identifier renaming, with public-API preservation so your callable surface stays intact.
A couple of encrypted strings and a couple of control-flow-protected methods — enough to see the transforms working on your own code.
Both the CLI and the desktop GUI, so you can explore settings visually or script a run.

Choose Free if you are evaluating the tool, or shipping a small or non-commercial project where basic renaming is enough. It is fully functional for that — download it here.

You will outgrow it when you need full string encryption, control-flow flattening on more than a couple of methods, anti-tamper, method encryption, MSBuild/CI integration, or the ability to read back crash stack traces from protected builds. At that point you register a license key to unlock the Licensed edition's full suite — no reinstall required. Pricing is transparent and per-seat, with annual and perpetual options on the pricing page; there is no quote process and no "contact sales."

When is free enough, and when do you need paid?

Decide on your threat model and what you ship, not on a feature count.

Free is genuinely enough when:

It is a hobby project, an internal tool, or a proof of concept.
Your goal is to stop the casual observer from reading your code, and renaming does that.
You are evaluating a protector before committing budget — run the whole loop on your own binary first.

You need paid when:

You sell or distribute commercial software, so someone has a financial motive to crack it.
You have client-side checks (trial, license, feature gating) that must resist patching — that is anti-tamper, and it is not free.
Your product is an algorithm or a piece of proprietary logic you cannot afford to have read — that is method encryption or code virtualization.
You run CI and want protection to happen automatically on every build, not as a manual step someone forgets.
You need to diagnose crashes in protected builds, which requires stack-trace de-obfuscation.

Verify before you trust — free or paid

Whichever way you go, audit the result yourself. Build your assembly, protect it, run your tests against the protected build (behavior must be identical), then open it in Glass.NET and try to read what you protected. Where you had clean, named C#, you should see renamed symbols, scrambled control flow and encrypted strings. Being able to check the output in a free decompiler is the only honest benchmark — and it is why we ship one alongside the protector.

The bottom line

A free .NET obfuscator is a real and useful thing: renaming and light string and control-flow protection stop the lowest-effort attack, and Nebula.NET's free edition gives you all of that on your own code without a rename-only bait-and-switch. What free does not give you is the layers that make protection commercially durable — full string encryption, anti-tamper, method encryption, code virtualization, CI integration and stack-trace de-obfuscation. If you ship commercial software with something worth cracking, that is where paid earns its keep. Download Nebula.NET free, protect a representative build, and see for yourself where you land.

How to debug a .NET app when you don''t have the source

Zero Heartbeat — Sun, 27 Sep 2026 06:06:05 +0000

To debug a .NET app when you don't have the source, open the compiled assembly in a decompiler like Glass.NET: it reads the IL and metadata inside the DLL or EXE and reconstructs readable C# you can navigate, search and export — no source files, PDBs or special build required. That turns "I have no idea what this dependency is doing" into "let me read the method and find out." Here is how to work through the common no-source scenarios, and where the honest limits are.

Why you end up debugging without source in the first place

It happens to everyone eventually:

A bug in a third-party NuGet package. The behavior is wrong, the docs don't explain it, and the package ships without symbols. You need to see what the method actually does, not what you assume it does.
A legacy DLL with no source. An internal library from a team that has moved on, a component whose repository is long gone, or a vendor assembly you depend on and cannot get source for.
No symbols for a production build. A crash comes in with a stack trace pointing into an assembly you can't step into, and you need to understand the code path.

In every case the compiled assembly is right in front of you — and because .NET ships IL plus rich metadata, that assembly carries a near-complete, recoverable description of the program. A decompiler is how you read it.

How does a decompiler get you readable C#?

A .NET assembly is not machine code. The compiler emits Intermediate Language — a stack-based instruction set — plus metadata naming every type, method, field and parameter. The decompiler runs the compiler in reverse: it reads the IL, matches its patterns back to C# constructs (a foreach, an async method, a LINQ query), and pretty-prints the result. For most assemblies the output is accurate and often recompilable. (The full walkthrough is in how to decompile a .NET DLL to C#.)

Open the assembly (in Glass: File ▸ Open Assembly, or drag it onto the window), expand the namespaces ▸ types ▸ members tree, and click the type you care about to decompile it on demand. Within seconds you are reading C# for code you never had the source to.

Navigating unfamiliar code without getting lost

Reading one method is easy; understanding how it fits together is the real debugging work. This is where a navigation-first decompiler earns its place, and it is what Glass.NET is built around.

Follow the logic with Go to Definition and Find All References

When a method calls into something you don't understand, Go to Definition (F12) jumps straight to it, and Find All References (Shift+F12) shows every caller — so you can answer "what actually calls this, and with what?" instead of guessing. References resolve from the decompiler's own syntax tree, so you land on the right symbol, not a text match.

See the shape with call and type hierarchy

Call hierarchy and type hierarchy let you walk up and down the structure — who calls the buggy method, what overrides what, where an interface is implemented. For tracing how a value reaches the code that mishandles it, this is far faster than scrolling.

Jump anywhere with Go To All

Go To All (Ctrl+T) is a fuzzy quick-open across every type and member in the assembly. When a stack trace names a method, type it in and you are there. A namespace ▸ type ▸ member breadcrumb and navigation history keep you oriented as you move.

Drop to IL when the C# looks surprising

Sometimes the reconstructed C# does something you didn't expect. Switch the same member to the IL view to confirm what the code actually does at the instruction level — invaluable when a decompiler's pattern-matching produces something that reads oddly but is technically correct.

Finding a regression: compare two versions

One of the most practical no-source debugging moves: a dependency worked in version 2.1 and broke in 2.2, and there is no changelog that explains it. Decompile both assemblies and compare them side by side. Glass has an assembly compare with a line diff, so you can see precisely what changed in the method you suspect — the altered condition, the reordered call, the new null check that isn't null-safe. Reading the diff of the reconstructed C# often pinpoints a regression in minutes, without any source at all.

Getting the code onto disk

When you want to grep it, annotate it, or open it in Visual Studio, export to a buildable project (in the GUI, typically File ▸ Export to Project), which writes a .csproj plus the reconstructed .cs files. Glass also ships a glass export CLI subcommand so you can script it. A small assembly usually compiles straight back; a large one may need manual fixes for unresolved references or compiler-generated constructs. Once it is a project, all your normal tools — search, static analysis, even setting up a local reproduction — are back on the table. See the Glass.NET features page for the full navigation and export toolset.

The honest limits

A decompiler is powerful, but it is not magic, and pretending otherwise wastes your time.

Decompiled ≠ original. You get accurate C# for what the code does, but comments are gone, most local variable names are lost unless a PDB supplies them, and constructs like async state machines and iterators are reconstructed, not recovered verbatim. Names like num2 and flag are common.
It is static, not a live debugger. Glass, ILSpy and dotPeek read and reconstruct code; they do not run it. If you need to step through the assembly at runtime, watching values change, that is a different job — dnSpyEx is the community-maintained tool for live managed debugging, or a decompiler with symbol-server / PDB generation (dotPeek) can let Visual Studio step in.
Obfuscated code is hard on purpose. If the assembly was protected, renamed identifiers, encrypted strings and flattened control flow all survive decompilation, so you get valid but hard-to-follow C#. You can still trace structure and behavior, but named-symbol navigation loses much of its value.
Only analyze what you have the right to. Debugging your own code, or a dependency you have a licence or legal right to inspect, is routine. Decompiling third-party software can be restricted by its EULA or local law — check before you dig.

Which tool should you reach for?

For reading and navigating an assembly you don't have source for, any capable free decompiler will get you accurate C#. If you specifically need live debugging, use dnSpyEx. If you want a fast, navigation-first reading experience — Go to Definition, Find All References, Go To All, call and type hierarchy, C# and IL views, assembly compare and project export — Glass.NET is built for exactly this workflow. It is built on the same ICSharpCode.Decompiler engine as ILSpy, so the C# accuracy is on par; what Glass adds is the experience around the code, so moving through an unfamiliar assembly feels like navigating your own project.

The bottom line

No source is not a dead end. Decompile the assembly, read the reconstructed C#, follow the logic with real navigation, diff two versions to isolate a regression, and export to a project when you want it on disk — and you can debug a third-party package or a legacy DLL almost as if you had its source. Just keep the limits in mind: you are reading what the code does, not the original file. Download Glass.NET free — no licence, no seats, no sign-up — open the assembly that is giving you trouble, and press F12.

Node-locking and seat management for software licenses

Zero Heartbeat — Fri, 25 Sep 2026 13:43:01 +0000

Node-locking binds a license to a specific machine so a single key can't be copied everywhere, and seat management lets you say "this key runs on N machines at once" and actually enforce it — but the second one only works with an online activation server, because a machine on its own can't count how many others share its key. This post walks through both mechanics honestly: how a machine fingerprint with swap tolerance keeps honest users from getting locked out, how a server enforces a seat cap, how customers move their own seats, and why online activation is the piece that turns "3 seats" from a promise into a rule.

What node-locking actually is

A node-lock ties a license to a machine fingerprint — a value the SDK derives from stable hardware and OS attributes on the device. When you activate a key, that fingerprint is recorded against the license. Every later validation recomputes the fingerprint locally and checks it matches. Copy the same key to a second machine and the fingerprint won't match, so the license simply doesn't apply there.

That's the whole idea, and it's genuinely useful: it means a key handed to one customer doesn't unlock a thousand installs. But the naive version has a well-known failure mode, and getting past it is the difference between a lock customers tolerate and a lock that fills your support queue.

The swap-tolerance problem

If your fingerprint hashes too many hardware attributes, the lock is brittle. A customer swaps a network card, upgrades an SSD, or updates a driver, the fingerprint shifts, and a paying user is suddenly locked out of software they own — followed immediately by an angry ticket. Hash too few attributes and the lock is trivial to spoof.

The fix is tolerance: allow a small amount of drift before the machine is considered a different one. Keyright's .NET SDK derives a stable fingerprint and applies a configurable NodeLockTolerance (default 1), so an ordinary single-component change — a new NIC, a replaced disk — doesn't trip the lock, while wholesale changes still read as a different machine. For unusual environments like VMs, containers, or CI runners, you can control exactly which components identify a machine by implementing IMachineComponents and setting MachineComponents on the SDK options. See the .NET SDK integration guide for the exact surface.

Seats: N machines, one key

A seat count is a promise — "this license runs on up to 3 machines" — and the moment you make it, you've walked into territory a client-side check can't handle. A single machine validating a license offline has no idea how many other machines are running the same key right now. Seat counting is a shared, stateful decision, and shared state lives on a server.

Here's the flow when it's done properly:

Activation records a seat. When a machine activates a key, the server records the activation (the machine's fingerprint and metadata) against the license and returns a short-lived signed lease bound to that machine.
The cap is enforced server-side. Activate more machines than the license allows and the server refuses — it returns a seat-limit result and no lease, so the extra machine stays in the free/unlicensed state. There's no client-side counter to patch around.
Re-activation is idempotent. A machine that's already bound can re-activate without burning a second seat. Restarting the app or refreshing the lease doesn't slowly leak your seat allowance away.

In Keyright, activation is a POST to the runtime /v1/activate endpoint carrying the key and the machine id; the server consumes a seat and hands back the lease. From the client you never touch that endpoint directly — you call ActivateAsync(key) and inspect the returned LicenseInfo. If seats are exhausted it comes back fail-closed with a message like "All seats for this license are in use," not an exception.

Letting customers move a seat themselves

Seats create a support problem the day after you ship them: a customer retires a laptop, buys a new one, and can't activate because all their seats are taken by machines they no longer use. If moving a seat means emailing you, every hardware refresh is a ticket.

The answer is self-service deactivation — let the customer free a seat without involving you:

Your app can release the seat the current machine holds by calling the runtime /v1/free-seat endpoint, so a "deactivate this device" button in your own UI just works.
Keyright's hosted customer portal lets a licensee view their activations and free a seat on a device they no longer use, then activate the new one — no ticket to you.
On your side, an admin can deactivate a specific machine from the dashboard's per-license activations view, which also shows device metadata so you can see where seats are actually in use.

Revocation: the other thing only a server can do

Seats aren't the only enforcement that needs a server. A refunded, charged-back, or leaked key has to die, and a signed license file issued last year knows nothing about a refund last week — its payload is fixed at issue time. Online activation closes that gap: revoke a key (POST /admin/licenses/{id}/revoke, or one click in the dashboard) and the client drops to the free edition on its next lease refresh. Because the lease is short-lived, "next refresh" comes around on its own.

For purely offline installs, Keyright can also build and ship a signed revocation list your app honors without a network call — slower, moving at the speed of your releases, but it means even a disconnected client isn't defenseless against a known-bad key.

Offline-first, online where it counts

None of this means abandoning offline validation — it means pairing the two. Keyright is offline-first: your app verifies a signed license or a cached lease locally, against an embedded public key, with zero network. Activation happens once; after that the cached lease keeps the app working offline for the life of the lease, and only near expiry does it reach the server again to reconcile seats and revocations. If the server is briefly unreachable, a still-valid cached lease covers the gap — a grace window — so an outage doesn't lock out a paying user.

Be honest about the boundary, though. Node-locking and offline checks run on the user's machine, so a determined attacker with a decompiler can patch them out — the same truth that applies to any client-side protection. That's why the enforcement that matters — seat caps and revocation — lives on a server the attacker doesn't control, and why you pair the client check with obfuscation to make patching costly. The client check is a fast, honest gate; the server is where the rules are real.

Wiring it up with Keyright

Keyright gives you node-locking with swap tolerance, server-enforced seats, self-service deactivation, and instant revocation as one system, with a .NET SDK (plus Node, Python, and Java) that fails closed by design. The client half is a few lines — initialize once, call ActivateAsync when a customer enters a key, and read the result. See the .NET SDK integration guide for the exact code, or the Keyright product page for the whole picture. The free plan is enough to wire real seat enforcement end to end before you pay anything.

A dotPeek alternative: Glass.NET, a free .NET decompiler

Zero Heartbeat — Fri, 25 Sep 2026 13:42:08 +0000

Looking for a dotPeek alternative? Glass.NET is a free .NET decompiler built on the same ILSpy decompilation engine, wrapped in a navigation-first UI with project export, a detailed assembly-information view and an exposure report — and it runs beyond Windows. JetBrains dotPeek is a genuinely good, free tool, so this is a fair comparison rather than a takedown: here's where each fits.

What is dotPeek good at?

dotPeek is JetBrains' free standalone .NET decompiler, and it's earned its reputation. It's a mature, polished tool from a company that builds developer tooling for a living, and a lot of .NET developers already have it installed. Its strengths include:

Solid decompilation to readable C# using JetBrains' own engine.
Good navigation — quick symbol search, find usages, and the kind of "go to everything" flow JetBrains users expect.
Export to project so you can pull decompiled code into a buildable solution.
Symbol-server features — it can act as a symbol server and generate PDBs, which is handy when debugging third-party code in Visual Studio.
Free, with no licence required.

If you're already in the JetBrains ecosystem or on Windows and comfortable with dotPeek, it's a reasonable default. We're not pretending otherwise.

Where Glass.NET differs

Glass.NET approaches the same core job — reading and understanding an unfamiliar assembly — with a few different priorities.

The ILSpy engine, out in the open. Glass is built on ICSharpCode.Decompiler, the same engine behind ILSpy. The C# it produces is accurate and tracks modern language features. This isn't a "smarter decompiler" claim — the engine is excellent and widely used, and we build on it rather than reinventing it.
Navigation as the whole point. Go to Definition (F12, plus Ctrl+Click), Find All References (Shift+F12) streaming into a results panel, Go To All (Ctrl+T) fuzzy quick-open across every type and member, call and type hierarchy, navigation history and a namespace ▸ type ▸ member breadcrumb. References resolve from the decompiler's own syntax tree, so you land on the right symbol, not a text match.
A full assembly-information view. Select an assembly and see its identity (name, version, culture, public-key token, strong-name status), PE/runtime traits (target framework, architecture, PE format), product attributes, referenced assemblies, embedded resources and metadata statistics — all in one place.
C# and IL views, code folding, and matching dark and light themes.
Export to a buildable project, plus assembly compare with a line diff and an exposure report that summarises what a given assembly reveals — useful for checking what an obfuscator actually produced.
Beyond Windows. Glass is built on a cross-platform UI toolkit, so it isn't tied to a single OS the way a traditional Windows-only decompiler is.

And like dotPeek, Glass is strictly static analysis — it reads metadata and IL and reconstructs C#; it never runs the assembly it inspects.

How does Glass.NET compare with dotPeek?

A quick side-by-side. Decompiler features move over time, so confirm current specifics on each vendor's own site — this reflects our understanding at time of writing, not a guarantee.

	Glass.NET	dotPeek
Price	Free	Free
Decompiler engine	ICSharpCode.Decompiler (ILSpy)	JetBrains' own
Go to Definition / Find References	✓	✓
Go To All (fuzzy quick-open)	✓	✓
Call / type hierarchy	✓	✓
C# and IL views	✓	✓
Export to buildable project	✓	✓
Assembly-information view	✓ (detailed)	Partial
Assembly compare + line diff	✓	—
Exposure report	✓	—
Symbol server / PDB generation	—	✓
Cross-platform (beyond Windows)	✓	Windows-focused
Live debugging	—	—

Where dotPeek may fit better for you

Credibility means naming where the other tool wins. If any of these describe you, dotPeek may be the better pick:

You want symbol-server / PDB generation. dotPeek can generate PDBs and act as a symbol server so Visual Studio can step into third-party code. Glass is focused on reading and navigating, not feeding a debugger — if the symbol-server workflow is central to you, dotPeek delivers it.
You're deep in the JetBrains ecosystem and want a tool that matches ReSharper/Rider muscle memory and conventions.
You need live debugging of a managed binary. Neither dotPeek nor Glass does that — it's a different job. The community-maintained dnSpyEx remains the usual choice there.

How should you decide?

Don't decide on a feature list — decide on your workflow. Both tools are free, so the cost of trying is only your time:

Open an assembly you actually work with in each tool.
Try the things you do most — jump to a definition, find every caller of a method, quick-open a type by name, read the IL behind a tricky method, export to a project.
See which one lets you move through the code without friction.

For most read-and-understand work — inspecting your own binaries, understanding a dependency, checking what an obfuscator produced, security review, or recovering your own lost source — Glass.NET is designed to make navigation feel like reading your own source. (Use any decompiler only on software you have the right to analyze.)

That "checking what an obfuscator produced" case is worth calling out: it's exactly why Glass pairs well with Nebula.NET. Protect a build, open it in Glass, and confirm for yourself that the names are gone, the control flow is flattened, and the encrypted methods show only a stub — the exposure report makes it a one-click check.

Get Glass.NET

Glass.NET is completely free — no licence, no seats, no sign-up — and actively developed. Download Glass.NET, open an assembly, and press F12. If you want the wider field, we also compare it with ILSpy, dnSpy and dotPeek together. Found a bug or have a feature request? Tell us — we're building it in the open.

Method encryption in .NET: how it protects your most sensitive code

Zero Heartbeat — Fri, 25 Sep 2026 13:42:05 +0000

Method encryption is the strongest static-decompilation defence Nebula.NET applies to an individual method: the method's IL is stored encrypted inside your assembly and only decrypted and re-emitted at runtime, so a decompiler opening your DLL finds no readable C# and no readable IL for that method — just a stub that hands control to a runtime helper. This article explains how that works, how it differs from renaming, string encryption and control-flow obfuscation, when it's the right tool, and the trade-offs you need to respect. For the broader picture, our guide to protecting .NET code from decompilation sets the scene.

What does "whole-method encryption" actually mean?

When you compile C#, F# or VB.NET, each method body is emitted as Intermediate Language (IL) and stored in the assembly's metadata in the clear. That IL is precisely what decompilers read to reconstruct near-original C#. Method encryption breaks that chain.

At protection time, Nebula.NET takes the chosen method's IL, encrypts it, and stores the ciphertext in the assembly. The method's original body is replaced with a small stub. There is no longer any standard IL for that method for a decompiler to interpret — Glass.NET, ILSpy or dotPeek see the stub and a blob of encrypted bytes that mean nothing without the key and the decryptor.

At runtime, the first time that method is needed, an injected helper decrypts the stored IL, re-emits it into a live dynamic method the JIT can compile, and dispatches to it. The observable behaviour is identical to the original — same inputs, outputs and exceptions — because it is the original IL, just reconstructed in memory at the last possible moment rather than sitting on disk. That's the whole point: the plaintext logic only ever exists while the method actually runs, never as something a static tool can read.

Now fully self-contained — no extra DLL to ship

Earlier method-encryption implementations (Nebula's included) leaned on an external runtime assembly copied next to your output. That's no longer the case. The re-emit runtime is now injected directly into your protected assembly — no Nebula.Runtime.dll or any other companion file to remember, deploy, or accidentally leave behind. You ship exactly the one assembly you were already shipping, and the decrypt-and-emit machinery travels inside it. For single-file publishing and simple xcopy deployment, that removes a whole class of packaging mistakes.

How is it different from the other obfuscation layers?

Method encryption doesn't replace the rest of your protection stack — it sits on top of it, targeting a different weakness.

Identifier renaming hides what things are called by turning ValidateLicenseKey into a. The IL is still fully present and readable; you've just removed the helpful names. Method encryption removes the IL itself.
String encryption hides literal data — endpoints, messages, keys — so searching the binary for a keyword turns up nothing. It says nothing about your logic. See string encryption in .NET for where that layer fits.
Control-flow obfuscation keeps the IL readable but scrambles its structure — flattening straight-line code into a dispatcher state machine so the decompiler emits a tangle of gotos instead of clean if/else. A skilled analyst (or an automated deobfuscator) can still work through it.
Method encryption removes the method body from static view entirely. There's nothing to structurally deobfuscate because there's no IL on disk to read.

They're complementary. A sensible build renames everything internal, encrypts strings everywhere and flattens control flow broadly — then reserves method encryption (or code virtualization) for the handful of methods that genuinely matter.

Method encryption vs. code virtualization

These two are the heavy hitters, and they're easy to confuse. Both leave a decompiler with nothing readable for the protected method, but the mechanism differs:

Virtualization translates the method into bytecode for a custom virtual machine embedded in your assembly. The original IL never exists anywhere; an attacker must reverse-engineer your specific VM before they can even begin. It's the highest cost to break, at the price of larger, meaningfully slower methods.
Method encryption keeps the real IL but stores it encrypted and rebuilds it at runtime. It reproduces the exact original semantics with no VM to design around, and is lighter on size. Its hard requirement is a runtime that can emit IL.

If you can run a full JIT and want the exact original method faithfully restored, method encryption is a clean fit. For the maximum static and dynamic barrier, virtualization goes further.

When should you use method encryption?

The same discipline applies as with virtualization: protect your crown jewels, not your whole assembly. Good candidates are a small number of high-value methods:

License and activation checks — where you don't want an attacker reading the exact comparison and patching around it.
Proprietary algorithms — the pricing model, matching heuristic or signal-processing kernel that is the actual product.
Anti-tamper and integrity logic — the code that verifies your binary hasn't been modified, which you specifically don't want on display.

There are eligibility limits worth knowing up front. Method encryption in Nebula covers static, non-generic methods without exception handlers or by-ref/pointer parameters — the shapes that re-emit cleanly and reliably. That's a deliberate constraint: correctness first. For methods outside it, lean on control-flow obfuscation and, where licensed, virtualization. You select targets explicitly, keeping your hot paths fast and untouched. See the Nebula.NET docs for the configuration keys.

The trade-offs — read these honestly

Method encryption's one big dependency is a runtime that can emit IL. Re-emitting the decrypted method body uses the runtime's dynamic code-generation path (Reflection.Emit), which needs a full JIT. That draws a hard line across .NET targets:

Works: .NET Framework, .NET (Core) on desktop and server, and single-file / self-contained publishes — anywhere a normal JIT is present.
Does not work: Blazor WebAssembly and NativeAOT. Blazor WASM runs under a trimmed WebAssembly runtime, and NativeAOT compiles everything ahead of time to native code — neither has runtime IL emit for the re-emit step. For Blazor WASM, use the dedicated WebCil-based obfuscation instead.

Beyond target support, keep the usual caveats in mind:

A small first-call cost. Decrypting and emitting a method the first time it runs adds a one-time overhead before the JIT takes over — negligible for the few sensitive methods you'd apply this to.
It's not encryption of your program. The decrypted IL is in memory while the method executes, so a determined attacker with a debugger and a memory dump can, in principle, capture it. Method encryption defeats static decompilation outright and raises the bar on dynamic analysis — it does not make your code uncrackable.
It doesn't enforce licensing by itself. A client-side check, however well hidden, runs on the attacker's machine. Method encryption makes bypassing it expensive, not impossible.

Where does the real security boundary live?

This is the part vendors skip, so we'll say it plainly: any protection that runs on a machine you don't control raises cost — it doesn't create an impassable wall. The honest goal is economic. You want reversing your logic to cost more than the result is worth, so the casual "decompile, copy, ship" attack dies immediately and the serious attacker finds the return not worth the effort.

Method encryption is excellent at that job — it takes your most sensitive methods off the static-decompilation table entirely, at low runtime cost, with no extra file to deploy. But the real secrets and enforcement belong on a server you control: validate licenses through online activation, keep master keys and privileged logic server-side, and treat the client protection as the expensive-to-climb wall around them — not the vault itself.

Trying it with Nebula.NET

Method encryption is one transform in Nebula.NET, alongside renaming, string encryption, control-flow obfuscation, anti-tamper and (Enterprise) code virtualization. The workflow to evaluate it is the only benchmark that matters:

Build your assembly and confirm your tests pass.
Enable method encryption on a few chosen methods and rebuild.
Run your test suite against the protected build — behaviour must be identical.
Open the result in Glass.NET and browse to those methods. You should see a stub and encrypted bytes where clean C# used to be.

That fourth step is why we ship a free decompiler alongside the protector — you audit our work rather than take our word for it. The free edition runs the whole loop on your own binary. Read the configuration details in the Nebula.NET documentation, pick your crown-jewel methods, and see the before-and-after for yourself.

License key generator for .NET: why you shouldn''t roll your own

Zero Heartbeat — Fri, 25 Sep 2026 13:41:33 +0000

If you searched for a ".NET license key generator," the honest answer is that you don't want a key generator — you want a signed license system, and the two are not the same thing. A generator produces a key string your app validates by its shape, which means the logic that decides "this key is valid" is the same secret an attacker extracts to build a keygen. A real license is a small signed document: the server signs it with a private key that never ships, your app verifies the signature against an embedded public key, and forgery becomes cryptographically impossible. This post explains why the homegrown route fails and what the proper version looks like in .NET.

What people mean by "key generator" — and why it's the wrong mental model

The classic design goes like this: generate keys in a recognizable pattern (grouped characters, a checksum digit, maybe a segment derived from the customer name), hand one to each buyer, and have the app accept any key that matches the pattern. It feels like security because the keys look official.

It isn't, and the reason is structural. If your app can decide a key is valid by inspecting the key itself, then everything needed to make a valid key is inside your app. A decompiler turns your validation routine into a generation routine — that's literally what a "keygen" is. Because .NET assemblies decompile cleanly back to readable C#, this isn't a theoretical risk; it's a first-afternoon result for anyone who bothers.

And even if the format were somehow un-guessable, a format-based key has no answers to the questions that actually run a software business:

How does it expire? A subscription needs an end date the key carries and the app enforces.
How is it bound to a machine? Nothing stops one key being pasted onto a thousand installs.
How do you unlock different features per plan? The key is opaque; it can't say "this customer gets export but not the API."
How do you kill a leaked or refunded key? You can't recall a string that's already in the wild.

A generator produces none of that. It produces a string.

What a real license is: a signed document

Replace "generate a key" with "sign a license." The unit isn't a random string — it's a small payload of facts (licensee, product, tier, seats, expiry, entitlements) with a cryptographic signature attached.

Here's the asymmetry that makes it work. Your server holds an RSA private key and uses it to sign the payload. Your app embeds only the matching public key. A public key can verify that a signature matches a payload, but it can never create one. So:

Decompile the app, read the public key, publish it on a billboard — an attacker still can't forge a license, because forging requires the private key that never left your server.
Change one byte of the payload — bump tier from free to pro — and the signature no longer matches. Validation fails.

This is the exact mechanism behind TLS and code signing, pointed at licensing. In .NET the primitives ship in the box (System.Security.Cryptography.RSA), and verifying a signature is a few lines. Which is precisely the trap: the signature check is easy, so people assume the whole system is easy, and it isn't.

The parts a signature alone doesn't give you

A valid signature proves the license is genuine and unaltered. It does not, by itself, do any of the following — and a real system needs all of them:

Expiry and clock-tamper defense

A subscription or trial carries an expiry the app compares against the current time. That immediately invites the obvious attack — roll the clock back and a trial never ends — so offline validation has to remember the latest time it legitimately saw and treat a big backward jump as tampering. Keyright's SDK does this: moving the clock back beyond a ClockTamperToleranceHours window (default 24h) on a time-limited license yields a ClockTampered status and refuses until the time is corrected. Perpetual licenses aren't subject to it.

Node-locking

Binding a license to a machine needs a stable fingerprint with tolerance, so a customer who swaps a NIC or disk isn't locked out. Too strict and you generate support tickets; too loose and the lock is meaningless. Keyright derives the fingerprint and applies a configurable NodeLockTolerance (default 1).

Entitlements

Shipping one binary that unlocks different capabilities per plan means the license has to carry those capabilities. Keyright bakes an entitlement template into each tier — named flags ("export": "true") and numeric limits ("max-projects": "10") — and the SDK reads them locally: IsEnabled("export"), GetLimit("max-projects", fallback: 1). Gate features on entitlements, not on a hard-coded tier check, and changing a plan doesn't mean shipping new code.

Revocation

A leaked, refunded, or charged-back license has to die — and a signed payload issued last year knows nothing about a refund last week. Online, Keyright revokes a key server-side and the client drops to free on its next lease refresh. Offline, it can ship a signed revocation list your app honors with no network call. A format-based key generator has no revocation story at all.

What the proper .NET flow looks like

With Keyright the "generator" is replaced by a server that signs, and your client verifies. Every tenant gets its own isolated RSA key pair; the private half is stored AES-256-GCM-encrypted server-side and never exposed, so your signatures never share a key with anyone else. Your app embeds only the public half:

var client = KeyrightClient.Initialize(new KeyrightOptions {
    Product         = "acme-app",
    PublicKeyBase64 = "MIIBIjANBgkq...",   // not a secret — ships in your binary
    ServiceUrl      = "https://keyright.delta1labs.com",
});

// Offline: verify the signature, product, node-lock, expiry — no network, never throws.
LicenseInfo info = client.Validate();
if (info.IsPaid && client.IsEnabled("export")) { /* unlock the feature */ }

Validate() verifies the signature against the embedded public key, checks node-lock and expiry, honors any shipped revocation list, and fails closed — any problem resolves to the free edition carrying a Status (SignatureInvalid, Expired, Revoked, MachineMismatch, …) rather than throwing or, worse, unlocking. For seat enforcement and prompt revocation you add one online ActivateAsync(key) call, which exchanges the key for a machine-bound lease.

Be honest about the limit

Signing kills forgery dead — nobody keygens a license they can't sign. But the code that reads the result still runs on the user's machine, and the branch that unlocks a feature can be patched out by a determined attacker with a decompiler. That's not an argument against signing; it's the reason you pair it with two things: online activation, so seats and revocation are enforced on a server the attacker doesn't control, and obfuscation, so patching the client gate is expensive. Signing defeats the forger; the rest defeats the patcher.

Skip the generator, ship the system

The takeaway isn't "you can't write an RSA verify" — you can, in an afternoon. It's that a license system is signing plus expiry, node-lock, entitlements, revocation, seats, and a fail-closed client, and a random key generator gives you none of it while looking like it does. Keyright is that system, built: per-tenant RSA signing, offline verify, entitlements, and revocation, with a .NET-first SDK. The getting-started guide walks the full path from an empty workspace to a shipping licensed app, and the free plan covers real licensing before you pay a cent.

How to add a free trial to your software (that doesn''t leak)

Zero Heartbeat — Fri, 25 Sep 2026 13:41:17 +0000

To add a free trial that doesn't leak, issue a signed, time-limited license key that auto-expires, node-lock it so one machine gets one trial, keep it revocable and tracked, and let it convert to paid without re-keying — the opposite of a registry flag or a date file, both of which a user resets in seconds. This post covers what "done right" means, why the naive approaches fail, and how to wire a self-service trial button on your own site so you never email a license by hand.

Why the easy trial always leaks

The tempting way to build a trial is to record when the software first ran and count down from there. Two variants, both broken:

The registry / date-file trial. On first launch you write a timestamp to a registry value or a file, and on later launches you compare against it. Deleting that value — or reinstalling into a fresh VM — resets the clock. There's nothing signed, so the app has no trustworthy memory of whether the trial was already used.
The clock-comparison trial. You store an expiry and compare it against DateTime.UtcNow. Roll the system clock backward and the trial never ends. Without a signed reference time, the app can't tell a real date from a rolled-back one.

Both share the same root flaw: the trial state lives somewhere the user fully controls, in a form nothing can verify. The fix isn't a cleverer hiding spot — it's a signed key the app can actually trust.

What a leak-resistant trial looks like

A proper trial is just a license with a short life. It carries the same protections a paid license does, so the same cheats don't work.

It's a signed, auto-expiring key

The trial key is a payload (product, tier, seats, expiryUtc, a trial flag) signed server-side with your private key. Your app verifies the signature against an embedded public key and reads the expiry from the signed payload — not from a value on disk the user can edit. When the expiry passes, the key stops validating and the app fails closed to the free/unlicensed state. No server call is needed for it to expire; the expiry is baked in and tamper-evident.

Because it's a real signed license, the clock-rollback cheat is covered too. Keyright's SDK remembers the latest time it legitimately saw and treats a large backward jump on a time-limited license as tampering — a ClockTampered status that refuses to validate until the clock is corrected (see the .NET SDK integration guide).

It's node-locked — one trial per machine

A signed key with an expiry is still copyable, so bind it to the machine. Node-locking ties the trial to a stable machine fingerprint (with a small swap tolerance so a hardware change doesn't lock an honest evaluator out), which means one device gets one trial rather than one key seeding a hundred installs.

It's issued one-per-identity

Node-locking stops one key spreading; issuing controls stop one person taking endless new trials. Keyright's self-service trial is one trial per email per product — re-requesting with the same email returns the same key (created: false) instead of minting a new one. A page refresh or a second click never resets the clock or stacks trials. It's idempotent by design, which is also what makes it abuse-resistant.

It's revocable and tracked

A trial you can't kill is a liability. Keyright trial keys are fully revocable like any license, and every trial is tracked in your dashboard — the Home overview counts them, and the Licenses table shows each one with its expiry and per-machine activations. You can see who's trialing, when their key lapses, and reach out before it does.

It converts to paid without re-keying

The single most important property: a trial should become a purchase with no friction. Because a Keyright trial key activates through the exact same path as a paid key, when the customer buys and activates a non-trial key it supersedes the leftover trial with no reinstall and no re-keying. The app flips from "Pro Trial — 27 days left" to the paid edition on the next activation. Your app reads the state straight off LicenseInfo — info.IsTrial, info.DaysRemaining, info.StatusBadge — so the trial countdown and the upgrade prompt are a few property reads, not a separate code path.

Self-service: a trial button on your own site

The best trial funnel doesn't involve you at all. Keyright's trial endpoint, POST /v1/trial, is public and CORS-open, so a plain form on your marketing site can call it directly and the customer gets a key by email — no dashboard clicks, no hand-sent license files.

<button id="trial">Start free trial</button>
<script>
document.getElementById('trial').onclick = async () => {
  const res = await fetch('https://keyright.delta1labs.com/v1/trial', {
    method: 'POST',
    headers: { 'content-type': 'application/json' },
    body: JSON.stringify({ product: 'acme-app', email: userEmail, company: userCompany }),
  });
  const data = await res.json();
  if (res.ok) show(`Your trial key: ${data.key} (expires ${data.expiresUtc})`);
  else show(data.error);
};
</script>

Trials are off by default — a product offers one only once you opt in by setting a trial length, tier, and seat count (in the dashboard's Products tab, or POST /admin/products/{slug}/trial). The response returns the key, its tier, and expiresUtc, and Keyright emails it to the address. The full flow, field reference, and status codes are in the self-service free trials guide.

For an air-gapped or enterprise evaluator that can't reach the network, you can hand out a signed, time-limited offline trial file instead — same trial semantics, delivered as a file the SDK verifies locally against your public key.

The customer activates it like any key

There's no separate "trial mode" in your app. The trial key activates through the same ActivateAsync(key) call as a paid key: it performs an online activation, binds the machine, and caches a signed lease with trial: true and the trial's expiry. Thanks to that cached lease the app keeps working offline until the trial ends, then fails closed. One code path handles trial and paid alike.

Be honest about the ceiling

A signed, node-locked, tracked trial defeats the casual cheats — deleting a registry key, rolling the clock, refreshing for a new trial — comprehensively. What it can't do alone is stop a determined attacker who decompiles your app and patches the check out, because that check runs on the user's machine. That's the same limit every client-side protection has, and the same answer applies: pair the trial's client check with online activation, so expiry, seats, and revocation are decided on a server the attacker doesn't control, and with obfuscation so patching the client is expensive. The trial gate is honest and hard to reset; the server is where it's enforced.

Add a trial this week

A trial done right is a signed, expiring, node-locked, revocable key that converts to paid on its own — and Keyright gives you all of it, self-service, from one API call. Turn on trials for your product, drop a button on your site, and read the state off LicenseInfo in your app. Sign up free and follow the self-service free trials guide to wire it end to end — the free plan is enough to ship a real, leak-resistant trial before you pay anything.

Offline license validation with signed keys, explained

Zero Heartbeat — Wed, 23 Sep 2026 14:17:56 +0000

Offline license validation is the ability to confirm a license is authentic and still valid without any network call — and it works because of one asymmetry in public-key cryptography: your server holds a private key that can create signatures, while your app holds only the matching public key, which can verify a signature but never forge one. That single property lets a client prove a license was issued by you, and hasn't been tampered with, entirely on its own machine. This post explains how that works end to end — signatures, node-locking, expiry, revocation, and grace windows — and why the whole thing has to fail closed to be worth anything.

Why a signature is enough to trust a license offline

Imagine your app just checked whether a license file said "tier": "pro". Trivially defeated — anyone can edit a text file. The signature is what makes the file trustworthy.

When you issue a license, the server takes the license payload (licensee, product, tier, seats, expiry, entitlements) and computes an RSA signature over it with a private key. That signature is attached to the license. Your app embeds the matching public key and, at validation time, recomputes the check: does this signature correspond to this exact payload under this public key? If yes, two things are simultaneously proven — the license was signed by your private key (authenticity), and not a single byte has changed since (integrity). Flip one character in the tier field and the signature no longer matches; validation fails.

The reason this needs no server is that verification is pure math on data the app already has. The public key isn't a secret and can ship right inside your binary — decompile the app, read the key, publish it, and an attacker still can't mint a license, because minting requires the private key that never left your server. This is the same asymmetry behind TLS and code signing, applied to licensing.

The checks that run after the signature

A valid signature only proves the license is genuine and unaltered. Offline validation then reads the now-trusted fields and enforces them locally.

Node-locking to a machine fingerprint

To stop one license from being copied to a thousand machines, a license can be node-locked: bound to a fingerprint the app derives from stable hardware and OS attributes. At validation the app recomputes the fingerprint and checks it against the one baked into the license. Mismatch, and the license doesn't apply here.

The subtlety is tolerance. Fingerprint too strictly and a customer who swaps a network card or upgrades a disk gets locked out. So a good implementation allows a small amount of drift — Keyright's SDK uses a configurable NodeLockTolerance (default 1) so an ordinary hardware change doesn't trip the lock — and lets you control which components identify a machine for unusual environments like VMs and CI runners.

Expiry and clock tampering

A subscription or trial carries an expiryUtc, and offline validation simply compares it to the current time. Which raises the obvious attack: roll the system clock backward and a trial never ends. Offline validation has to defend against that without a time server. The standard approach is to remember the latest time the app has legitimately seen and treat a clock that jumps meaningfully backward as tampering. Keyright's SDK does exactly this — moving the clock back beyond a ClockTamperToleranceHours window (default 24h) on a time-limited license yields a ClockTampered status and refuses to validate until the time is corrected. Perpetual licenses, having no expiry, aren't subject to the check.

Revocation, offline

Here is where offline-only shows its one real limitation, and how to close it. A license signed last year knows nothing about a refund or leak that happened last week — the signed payload is fixed at issue time. Online, revocation is a server flag picked up on the next activation refresh. Offline, you distribute a signed revocation list: a list of revoked license ids, itself signed by your private key so the client can trust it, shipped with an app update. A purely offline client checks incoming licenses against that list and drops revoked ones. It's not instant — it moves at the speed of your releases — but it means a disconnected app isn't defenceless against a known-bad key. Keyright can build and sign a distributable revocation list you ship with RevocationListJson / RevocationListPath.

Offline-first, with an optional online grace window

Pure offline validation is perfect for air-gapped installs and fast local gating, but it can't count seats — a client has no idea how many other machines run the same key — and it can't reflect a revocation newer than the last update. The common, honest answer is offline-first with an optional online check.

Keyright's model works like this: your app can validate a shipped offline license file with zero network, or it can activate online once — exchanging the license key for a short-lived signed lease bound to this machine. That lease is itself verified offline against your embedded public key and cached locally, so after a single activation the app keeps validating offline for the life of the lease. Only when the lease nears expiry does it need to reach the server again, at which point seat counts and revocations are reconciled. If the server is briefly unreachable, a still-valid cached lease covers the gap — a grace window — so an outage doesn't lock out an honest paying user. You get offline resilience and server-enforced seats and revocation from the same system, instead of choosing one.

Why "fail closed" is the whole game

Every check above shares one design rule, and it is the rule that makes offline validation actually protective rather than decorative: on any problem, resolve to the unlicensed state — not an exception, and never an unlocked one.

Consider the alternative. If a license check failed open — treating an error as "allow" — the easiest crack in the world would be to make the check error on purpose: delete the license file, corrupt a byte, block a call, and enjoy the software. Failing closed inverts that: a bad signature, a wrong product, an expired or revoked key, a tampered clock, a missing or unreadable file — every one of them lands in the free/unlicensed edition. The safe outcome is the default outcome, so breaking the check gets the attacker nothing.

Keyright's SDK is built around this. Validate() never throws; on any failure it returns a LicenseInfo in the Free edition carrying a Status (NoLicense, SignatureInvalid, Expired, MachineMismatch, Revoked, ClockTampered, …) and a human-readable message you can show in a "Register" dialog. Online ActivateAsync() follows the same rule for its ordinary failure paths — bad key, seats exhausted, offline, revoked — returning a fail-closed result rather than throwing. Your if (info.IsPaid) branch is the only thing that unlocks anything, and it only runs when everything genuinely checked out.

Being honest about the limits

Offline validation proves authenticity and integrity beautifully, but it is not magic. Because the check ultimately runs on the user's machine, a determined attacker with a decompiler and a debugger can patch it out — the same truth that applies to any client-side protection. That's not a reason to skip it; it's a reason to be precise about its job. Offline validation is the right, strong tool for air-gapped and enterprise deployments and a fast, resilient local gate everywhere else. When you need to enforce — count seats, kill a leaked key promptly — you pair it with online activation so those decisions live on a server the attacker doesn't control, and you make the client hard to patch with obfuscation. Offline validation and online activation aren't rivals; they're two halves of a licensing system that's both resilient and enforceable.

Where Keyright fits

Keyright is offline-first by design: every tenant gets its own RSA signing key (private half stored encrypted server-side, never exposed), issues signed offline license files and online activation leases, node-locks with tolerance, defends against clock tampering, ships signed revocation lists, and fails closed throughout its .NET, Node, Python, and Java SDKs. If you want the full mechanics with real SDK code, read the Keyright documentation — the getting-started and .NET integration guides walk the exact Validate() and ActivateAsync() paths described here.