Security & Anti-Tampering

The SDKs defend licenses with three independent layers. Each layer catches what the others miss:

Every license response your server issues is cryptographically signed. The SDK refuses to trust any license data whose signature doesn't verify.

1. You generate an RSA-2048 key pair (private key stays on your server / vendor dashboard; the public key ships inside your app as VendorPublicKey).
2. The server signs the license payload — expiry date, tier, features, machine binding — with the private key.
3. The SDK verifies the signature locally using the embedded public key before accepting the license, including for offline/cached validations.

// Signature verification is on by default.
var config = new UnifiedLicenseConfig
{
    VendorApiKey = "your-api-key",
    ProductKey   = "your-product-key",
    SignatureVerification = true,   // default
    VendorPublicKey = "-----BEGIN PUBLIC KEY-----..."
};

If an attacker edits the expiry date in a cached license file, or hand-crafts a "lifetime" license, verification fails with an invalid signature error — they'd need your private key to produce a valid signature, and forging RSA-2048 is not practical.

Trial periods and expiry dates are checked against the system clock — so the classic bypass is "set the clock back." The SDK counters by comparing wall-clock time against a monotonic source that users can't set from the OS settings:

• Backward jump: if the current UTC time is earlier than the last recorded validation, the clock was rolled back → tampering flagged.
• Forward jump: if wall-clock time advanced far more than the monotonic timer did between two checks, time was skipped ahead beyond a tolerance (60 seconds) → flagged.

This is the reference implementation from the .NET SDK; the JavaScript and Python SDKs apply the same two-check strategy during offline validation:

public bool DetectTampering()
{
    if (!_lastValidation.HasValue)
    {
        _lastValidation = DateTime.UtcNow;
        _lastTicks      = Environment.TickCount64;  // monotonic
        return false;
    }

    var now         = DateTime.UtcNow;
    var currentTicks = Environment.TickCount64;

    // Check 1: time moved backward
    if (now < _lastValidation.Value)
    {
        Console.WriteLine("Clock tampering detected: Time moved backward");
        return true;
    }

    // Check 2: wall clock jumped vs. monotonic elapsed time
    var elapsedMs   = currentTicks - _lastTicks;
    var expectedNow = _lastValidation.Value.AddMilliseconds(elapsedMs);
    var difference  = Math.Abs((now - expectedNow).TotalMilliseconds);

    if (difference > 60000)   // > 60s unexplained drift
    {
        Console.WriteLine($"Clock tampering detected: Time jump of {difference}ms");
        return true;
    }

    _lastValidation = now;
    _lastTicks      = currentTicks;
    return false;
}

When tampering is detected during offline validation, validation fails with a "Clock tampering detected" error instead of trusting the manipulated clock. The next successful online validation re-syncs trusted time from the server, so legitimate users who travel across time zones or fix a genuinely wrong BIOS clock recover automatically.

IntegrityGuard is a .NET-only runtime protection module. It runs five watchdog timers at randomized intervals that continuously re-check the process environment while your app runs. It is not available in the JavaScript, Python, or PHP SDKs — interpreted/web environments don't offer the process-level introspection it relies on.

IntegrityGuard is opt-in (disabled by default) and configured through the standard config object — there is no separate global switch to disable it at runtime:

var config = new UnifiedLicenseConfig
{
    VendorApiKey = "your-api-key",
    ProductKey   = "your-product-key",

    // Protection features (all opt-in)
    EnableIntegrityGuard = true,
    EnableAntiDebug      = true,
    EnableAntiTamper     = true
};

var manager = new UnifiedLicenseManager(config);

var config = new UnifiedLicenseConfig
{
    VendorApiKey = "your-api-key",
    ProductKey   = "your-product-key"
#if DEBUG
    ,
    EnableIntegrityGuard = false   // allow debugging
#endif
};

They can try — and client-side patching is always theoretically possible. That's why the architecture assumes the client will be attacked and puts the decisive checks server-side:

• The server database is the source of truth. A license only validates if it exists in your database with valid status. An attacker who patches the client binary still has to get a positive answer from your API — a patched client can't invent activations, and unknown keys are rejected server-side no matter what the client says.
• Licenses can't be forged. Even fully offline, editing a cached license breaks the RSA-2048 signature (Q2). Creating a new valid license requires your private key.
• Machines can't be faked cheaply. Activations are bound to a machine_id; the server enforces activation limits independently of what the client reports.

Key sharing is the most common piracy pattern, and it's handled by four cooperating mechanisms:

1. Machine locking. On first activation the key is bound to the device's machine_id. Every later validation presents the same fingerprint — a different machine doesn't match.
2. Activation limits. Each tier defines max_activations. Once the limit is reached, additional machines are rejected at activation time. You control the limit per tier, and can reset activations for legitimate customers (new PC, reinstall) from the vendor dashboard.
3. Heartbeats. SDKs report license_key + machine_id + fingerprint to the server on a schedule (daily / weekly / monthly, with 24-hour rate limiting built in). This gives you visibility into how many distinct machines are actually using a key — abnormal spread is visible in your dashboard.
4. Revocation. Because every online validation (and hybrid-mode background sync) checks current status server-side, you can kill a leaked key centrally. At the next sync the SDK stops accepting it — including cached/offline usage once the grace period ends.

Verify each layer independently, in a development environment with test keys — never against production licenses:

Obfuscation complements licensing: the SDK protects the license, obfuscation makes the surrounding code harder to analyze and patch. Whether it's worth it depends heavily on platform:

They're related but solve different problems, and UnifiedLicensing is a licensing system:

If you're shipping an application and want to enforce per-seat, per-tier, trial, and subscription rules — that's licensing, and it's exactly what these SDKs do. If you need to encrypt the media assets themselves so they're unusable outside an approved player, you need a DRM system alongside (or instead of) licensing.