Nach dem Umbenennen enthält eine Fehlerspur Namen wie a.b(c d). Eine Umbenennungsdatei aus Pro, die zur selben Build-Version gehört, stellt Methodennamen und ihre Typen wieder her.
Der Decoder stellt Methodennamen und die zugehörigen Typen wieder her, nicht aber Parameternamen, Parametertypen oder Zeilennummern. Zeilennummern stammen aus der PDB des nicht obfuskierten Builds; archiviere sie daher mit jeder Version.
Assembly schützen und Ergebnis prüfen
- Erstelle einen Release-Build und bewahre Original, Symbole und Konfigurationsdateien auf.
- Lade eine verwaltete .NET-DLL oder EXE hoch. Verwende einen unsignierten Build und lade niemals private Schlüssel hoch.
- Lade das Ergebnis herunter, setze es in einer Testumgebung ein und führe dieselben Funktionstests aus.
Umfang der kostenlosen Version
Die kostenlose Stufe verarbeitet eine Datei bis 1 MB ohne Benutzerkonto. Umbenennung erschwert das Lesen interner Symbole. Block ILDasm betrifft das ältere Werkzeug und verhindert nicht jede Dekompilierung. Pro bietet zusätzliche Optionen wie Zeichenfolgenverschlüsselung und Kontrollflussverschleierung. Aktuelle Preise und Grenzen stehen auf der Tarifseite.
Free / Pro →Wirksamkeit nachvollziehbar prüfen
Vergleiche Original und Ergebnis mit ILSpy. Prüfe geänderte interne Namen und bei aktivierter Verschlüsselung die betroffenen Zeichenfolgen. Starte anschließend die Anwendung und vergleiche die Ergebnisse. Erfolgreiches Laden allein prüft nicht jeden Ausführungspfad. Obfuskation erhöht den Analyseaufwand; im Client gespeicherte Geheimnisse werden dadurch nicht sicher.
ILSpy · .NET →