Durcir automatiquement vos vérifications de licence

Chaque indicateur de fonctionnalité, chaque branche « est-ce sous licence ? », chaque vérification de siège finit par passer par une petite quantité de code : la méthode qui vérifie la licence et renvoie un oui ou un non. Cette méthode est la cible de plus grande valeur de toute votre application. Un attaquant n’a pas besoin de comprendre votre logique métier — il lui faut trouver cette seule méthode et la faire toujours renvoyer true. Durcissez tout le reste et laissez la porte lisible, et vous avez verrouillé toutes les portes sauf celle d’entrée.

La vérification de licence est donc précisément le code qui mérite votre protection la plus forte. Le problème est de penser à l’appliquer là — par nom, au fil de vos refactorisations, sur chaque méthode qui touche à la licence. Le autoProtectLicensing de Nebula.NET fait ce ciblage pour vous.

Activez-le

C’est un seul indicateur :

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

Avec ce réglage, Nebula trouve les méthodes de votre assembly qui appellent votre SDK de licence et les ajoute automatiquement à la protection la plus forte que votre édition permet — obfuscation agressive du flux de contrôle et, en Enterprise, virtualisation des méthodes — sans que vous listiez le moindre nom de méthode.

Comment il trouve le code de licence

Le ciblage est de l’analyse de sites d’appel, pas une supposition sur les noms. Avant l’exécution des passes de protection, Nebula parcourt chaque corps de méthode et inspecte chaque call, callvirt et newobj. Si le membre invoqué appartient à l’un des espaces de noms de licence configurés — Keyright par défaut — cette méthode est marquée comme code de licence :

// Cette méthode appelle Keyright, donc l'auto-protection la marque :
public bool CanExport()
{
    var lease = Keyright.License.Current;          // ← appel à l'espace de noms Keyright
    return lease.IsValid && lease.Entitlements.Has("export");
}

Nebula enregistre l’identité pleinement qualifiée de la méthode et l’intègre à l’ensemble d’inclusion de l’obfuscation du flux de contrôle (et de la virtualisation, là où elle est sous licence) aux côtés de ce que vous avez listé explicitement. Le résultat : CanExport — et toute autre méthode qui atteint la licence — est aplatie en une machine à états à répartiteur (ou compilée en bytecode de VM en Enterprise), tandis que le reste de votre app conserve la protection par défaut plus légère.

Si votre licence vit derrière votre propre enveloppe fine, pointez aussi le détecteur vers cet espace de noms :

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

Désormais une méthode qui appelle MyApp.Licensing.Gate.Check() est captée même si elle ne nomme jamais Keyright directement — ainsi une unique couche de licence interne est entièrement couverte, et vous n’avez pas à re-lister les méthodes au fur et à mesure que vous les ajoutez.

Pourquoi cibler plutôt que tout protéger

La question naturelle est : pourquoi ne pas virtualiser toute l’app ? Parce que les transformations lourdes coûtent quelque chose. L’aplatissement agressif du flux de contrôle et la virtualisation ajoutent de la taille et s’exécutent plus lentement que l’IL d’origine — négligeable sur une méthode qui s’exécute une fois au démarrage, mais pas quelque chose que vous voulez multiplié sur chaque méthode chaude d’une grande base de code. La stratégie réaliste est donc toujours de cibler la protection forte, et la vérification de licence est le cas d’école à cibler :

• Elle est petite — une poignée de méthodes, le coût est donc trivial.
• Elle s’exécute rarement — au démarrage ou à une frontière de fonctionnalité, pas dans une boucle serrée.
• Elle est décisive — la vaincre débloque le produit entier, c’est donc là qu’un attaquant passe son temps.

autoProtectLicensing rend « dépenser le budget de protection sur le code de licence » automatique et à l’épreuve des refactorisations. Vous ne livrez jamais une build où une méthode de vérification de licence nouvellement ajoutée est passée entre les mailles parce que personne n’a mis à jour la liste d’inclusion.

Elle se compose avec les autres couches

L’auto-protection décide quoi protéger ; elle s’empile avec les transformations qui décident comment. La vérification de licence profite le plus quand plusieurs couches atterrissent en même temps :

• L’obfuscation du flux de contrôle / virtualisation (ce que l’auto-protection applique) masque la logique de la vérification — les branches, la comparaison qui renvoie le verdict.
• L’obfuscation des références masque le graphe d’appels, de sorte que le fait même que cette méthode appelle une API de licence n’est pas lisible au site d’appel.
• Le chiffrement des chaînes masque les noms de droits et les messages que la vérification consomme.
• L’anti-altération fait que patcher le verdict après coup déclenche une vérification d’intégrité.

Chacune ferme un raccourci différent. Le renommage seul laisserait lisible la logique de la porte ; l’auto-protection garantit que la porte est dans l’ensemble de protection forte ; les autres couches retirent les indices alentour. Ensemble, elles transforment « trouver la méthode et inverser le booléen » en un travail réel, lent et manuel — ce qui est tout l’objectif.

Une licence ne vaut que le code qui la vérifie. Pour le contexte sur le pourquoi et les approches .NET courantes, voyez protéger vos vérifications de licence ; l’auto-protection est la façon dont Nebula s’assure que cette protection atterrit vraiment sur les bonnes méthodes, à chaque build, sans liste maintenue à la main. Si vous choisissez un système de licence à y associer, Keyright est celui que Nebula reconnaît d’emblée.