Une identité, pas un chiffrement
Un nom fort comprend notamment nom, version, culture et informations de clé publique. Il ne chiffre pas le code IL et n’empêche pas sa décompilation. Microsoft déconseille de le considérer comme une frontière de sécurité. La signature d’éditeur Authenticode est distincte. Identifiez la signature réellement exigée par votre distribution.
Préparer une entrée non signée
FreeObfuscator refuse les assemblies à nom fort ou à signature différée. Préparez une compilation Release non signée séparée et conservez la distribution initiale. La commande d’exemple convient aux projets SDK simples ; des targets importés et références peuvent nécessiter une configuration dédiée. Ne retirez pas simplement les métadonnées de signature d’un fichier publié. N’envoyez ni .snk, ni .pfx, ni mot de passe.
Valider le processus de nouvelle signature
Vérifiez que votre outil sait signer correctement l’assembly transformé. Un fichier non signé peut ne pas réserver l’espace requis par une simple commande de nouvelle signature ; sn -R n’est pas une recette universelle. Signer une dépendance peut modifier l’identité attendue par ses appelants. Gérez signature, références et assemblage du paquet ensemble, localement.
Tester le consommateur final
Comparez les identités et vérifiez les signatures avec les outils adaptés à votre plateforme. Un jeton de clé publique ne démontre pas une signature valide. Testez un consommateur existant, le chargeur d’extensions et l’installateur sur le paquet final. Gardez une version de retour arrière. Ne livrez pas un substitut non signé si le contrat de signature ne peut pas être respecté.
dotnet build MyLibrary.csproj -c Release -p:SignAssembly=false -p:DelaySign=false -o ./unsigned-check
# Inspect identity only; this is NOT signature validation:
[System.Reflection.AssemblyName]::GetAssemblyName((Resolve-Path './unsigned-check/MyLibrary.dll')).FullName