Identität ist keine Geheimhaltung
Ein Strong Name umfasst Name, Version, Kultur und öffentliche Schlüsselinformationen. Er verschlüsselt keinen IL-Code und verhindert keine Dekompilierung. Microsoft warnt davor, Strong Names als Sicherheitsgrenze zu verwenden. Authenticode ist eine separate Herausgebersignatur. Kläre zuerst, welche Signatur deine Auslieferung tatsächlich benötigt.
Einen unsignierten Eingang erstellen
FreeObfuscator lehnt Strong-Name- und verzögert signierte Eingaben ab. Erstelle einen separaten unsignierten Release-Build und bewahre das Original auf. Der Beispielbefehl eignet sich für einfache SDK-Projekte; importierte Targets und Referenzen können eine eigene Konfiguration erfordern. Entferne nicht einfach Signaturmetadaten eines veröffentlichten Pakets. Lade weder .snk noch .pfx oder Kennwörter hoch.
Erneute Signierung ist ein Build-Schritt
Prüfe, ob dein Werkzeug die veränderte Assembly korrekt signieren kann. Einer unsignierten Datei kann die für einfaches Nachsignieren benötigte Signaturreservierung fehlen; sn -R ist kein allgemeingültiges Rezept. Eine signierte Abhängigkeit kann außerdem die von Aufrufern erwartete Identität verändern. Signierung, Referenzanpassung und Paketbau gehören zusammen in eine vertrauenswürdige lokale Umgebung.
Den endgültigen Verbraucher testen
Vergleiche die Identitäten und prüfe Signaturen mit den zur Plattform passenden Werkzeugen. Ein vorhandenes Public-Key-Token beweist keine gültige Signatur. Teste einen bestehenden Verbraucher, Plugin-Lader und Installer gegen das fertige Paket. Bewahre eine Rückfallversion auf. Liefere keinen unsignierten Ersatz, wenn der benötigte Signaturvertrag nicht erhalten werden kann.
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