Ihre Lizenzprüfungen automatisch härten

Jeder Funktions-Flag, jeder „ist das lizenziert?”-Zweig, jede Sitzplatzprüfung läuft letztlich durch eine kleine Menge Code: die Methode, die die Lizenz prüft und ein Ja oder Nein zurückgibt. Diese Methode ist das Ziel mit dem höchsten Wert in Ihrer ganzen Anwendung. Ein Angreifer muss Ihre Geschäftslogik nicht verstehen — er muss diese eine Methode finden und sie immer true zurückgeben lassen. Härten Sie alles andere und lassen das Tor lesbar, haben Sie jede Tür verriegelt außer der Haustür.

Die Lizenzprüfung ist also genau der Code, der Ihren stärksten Schutz verdient. Das Problem ist, daran zu denken, ihn dort anzuwenden — namentlich, während Sie refaktorisieren, über jede Methode, die Lizenzierung berührt. Nebula.NETs autoProtectLicensing erledigt dieses Zielen für Sie.

Schalten Sie es ein

Es ist ein einziger Flag:

{
  "rename": true,
  "controlFlowObfuscation": true,
  "autoProtectLicensing": true
}

Damit gesetzt findet Nebula die Methoden in Ihrem Assembly, die Ihr Lizenz-SDK aufrufen, und fügt sie automatisch dem stärksten Schutz hinzu, den Ihre Edition erlaubt — aggressive Kontrollfluss-Obfuskierung und, in Enterprise, Methodenvirtualisierung — ohne dass Sie einen einzigen Methodennamen auflisten.

Wie es den Lizenzcode findet

Das Zielen ist Aufrufstellen-Analyse, kein Raten an Namen. Bevor die Schutz-Durchläufe laufen, durchläuft Nebula jeden Methodenrumpf und inspiziert jeden call, callvirt und newobj. Gehört das aufgerufene Mitglied zu einem der konfigurierten Lizenz-Namespaces — Keyright standardmäßig — wird diese Methode als Lizenzcode markiert:

// Diese Methode ruft Keyright auf, also markiert die Auto-Protection sie:
public bool CanExport()
{
    var lease = Keyright.License.Current;          // ← Aufruf in den Keyright-Namespace
    return lease.IsValid && lease.Entitlements.Has("export");
}

Nebula erfasst die voll qualifizierte Identität der Methode und faltet sie in die Einschlussmenge der Kontrollfluss-Obfuskierung (und der Virtualisierung, wo lizenziert) neben allem, was Sie ausdrücklich aufgelistet haben. Das Ergebnis: CanExport — und jede andere Methode, die in die Lizenzierung greift — wird in eine Dispatcher-Zustandsmaschine verflacht (oder in Enterprise zu VM-Bytecode kompiliert), während der Rest Ihrer App den leichteren Standardschutz behält.

Wenn Ihre Lizenzierung hinter Ihrem eigenen dünnen Wrapper lebt, richten Sie den Detektor auch auf diesen Namespace:

{
  "autoProtectLicensing": true,
  "licensingNamespaces": ["Keyright", "MyApp.Licensing"]
}

Nun wird eine Methode, die MyApp.Licensing.Gate.Check() aufruft, erfasst, selbst wenn sie Keyright nie direkt nennt — so ist eine einzige interne Lizenzschicht vollständig abgedeckt, und Sie müssen Methoden nicht neu auflisten, während Sie sie hinzufügen.

Warum zielen statt alles zu schützen

Die naheliegende Frage lautet: warum nicht die ganze App virtualisieren? Weil die schweren Transformationen etwas kosten. Aggressives Kontrollfluss-Verflachen und Virtualisierung fügen Größe hinzu und laufen langsamer als das ursprüngliche IL — vernachlässigbar bei einer Methode, die einmal beim Start läuft, aber nichts, was Sie über jede heiße Methode einer großen Codebasis multipliziert wollen. Die realistische Strategie ist also immer, den starken Schutz zu zielen, und die Lizenzprüfung ist der Lehrbuchfall, auf den man zielt:

• Sie ist klein — eine Handvoll Methoden, die Kosten sind also trivial.
• Sie läuft selten — beim Start oder an einer Funktionsgrenze, nicht in einer engen Schleife.
• Sie ist entscheidend — sie zu besiegen schaltet das ganze Produkt frei, also verbringt ein Angreifer dort seine Zeit.

autoProtectLicensing macht „das Schutzbudget auf den Lizenzcode verwenden” automatisch und refaktorisierungssicher. Sie liefern nie einen Build aus, bei dem eine neu hinzugefügte Lizenzprüfungs-Methode durchrutschte, weil niemand die Einschlussliste aktualisiert hat.

Es greift mit den anderen Schichten ineinander

Die Auto-Protection entscheidet, was zu schützen ist; sie stapelt sich mit den Transformationen, die entscheiden, wie. Die Lizenzprüfung profitiert am meisten, wenn mehrere Schichten gleichzeitig landen:

• Kontrollfluss-Obfuskierung / Virtualisierung (was die Auto-Protection anwendet) verbirgt die Logik der Prüfung — die Zweige, den Vergleich, der das Urteil zurückgibt.
• Referenz-Obfuskierung verbirgt den Aufrufgraphen, sodass selbst die Tatsache, dass diese Methode eine Lizenz-API aufruft, an der Aufrufstelle nicht lesbar ist.
• String-Verschlüsselung verbirgt die Berechtigungsnamen und Meldungen, die die Prüfung verbraucht.
• Manipulationsschutz bedeutet, dass das nachträgliche Patchen des Urteils eine Integritätsprüfung auslöst.

Jede schließt eine andere Abkürzung. Umbenennung allein ließe die Logik des Tors lesbar; die Auto-Protection garantiert, dass das Tor in der Menge des starken Schutzes ist; die anderen Schichten entfernen die umgebenden Hinweise. Zusammen verwandeln sie „finde die Methode und kippe den Bool” in echte, langsame, manuelle Arbeit — was der ganze Sinn ist.

Eine Lizenz ist nur so stark wie der Code, der sie prüft. Zum Hintergrund, warum das so ist, und zu den gängigen .NET-Ansätzen siehe Ihre Lizenzprüfungen schützen; die Auto-Protection ist, wie Nebula sicherstellt, dass dieser Schutz tatsächlich auf den richtigen Methoden landet, bei jedem Build, ohne eine von Hand gepflegte Liste. Wenn Sie ein Lizenzsystem zum Kombinieren wählen, ist Keyright dasjenige, das Nebula von Haus aus erkennt.