Ich habe berufsbedingt sehr viel mit .NET Obfuscatoren zu tun und bin in den letzten Jahren immer wieder auf diesen Thread gestossen welcher mich dann letztendlich dazu brachte hier meinen ersten Post zu verfassen. Zumindest in Google ist dieser Thread noch sehr präsent und eine kleine Auffrischung kann ja nicht schaden. In neueren Threads wird ja immer wieder darauf hingewiesen, dass das Thema schon zig mal durchgekaut wurde und auf ältere Threads verwiesen. 😉

Es gibt wirklich keinen einzigen Deobfuscator welcher (nur anhand der obfuskierten Assembly) Name Obfuscation rückgängig machen kann - also originale Klassen und -Methodennamen wiederherstellen. Es sei denn man liefert seine Debug-Datei (.pdb) gleich mit. PDB Dateien enthalten normalerweise genug Informationen um den kompletten Quellcode wiederherzustellen.

Sorry, stimmt - von Kopierschutz war bislang nicht die Rede. Das Wort "geknackt" hat nur nicht wirklich zu Name Obfuscation gepasst.

Hallo Abt,

bitte nicht "Name Obfuscation" und "String Encryption" verwechseln. Name obfuscation kann nicht geknackt werden (sogar nicht vom berühmten de4dot-Deobfuscator) da es technisch nicht möglich ist. Wenn Klassen -und Methodennamen umbenannt werden und nicht die originalen Namen irgendwo in der Assembly gespeichert werden (warum auch) kann man höchstens versuchen die originalen Namen zur erraten. Es gibt sogar noch Varianten bei denen man nur schwer erkennt, dass die Assembly überhaupt obfuskiert wurde da glaubwürdige Klassen -und Methodennamen verwendet werden und nicht irgendein String-Wirrwarr.

Obfuscation hat eher etwas mit dem Schutz des geistigen Eigentums zu tun (zumindest erschwert es den Diebstahl) als mit einem Kopierschutz welcher oft sehr schnell ausgehebelt werden kann.

Hallo,

ich würde nicht sagen, dass Obfuscators nutzlos sind.

Klar, mit genügend Zeit und Aufwand kann jede Anwendung geknackt werden. Eine ungeschützte Assembly lädt aber gerade dazu ein im Code rumzuschnüffeln. 😉 Zumindest "Name Obfuscation" sollte aktiviert werden. Diese Verfahren kann nicht geknackt werden (die Klassen und Membernamen werden ja überschrieben), beeinflusst nicht die Performance und hält die meisten Script-Kiddies davon ab sich näher mit der Anwendung zu beschäftigen.

Mit einem AuthentiCode/CodeSigning-Zertifikat lassen sich die meisten Features von .NET Reactor oder SmartAssembly nutzen ohne das ein Virus erkannt wird. Mit entsprechende minimalen Settings (nur Obfuscation in .NET Reactor) geht es auch ganz ohne Zertifikat.

Die "List of obfuscators for .NET" Wikipedia-Webseite wurde mittlerweile gelöscht. Eine recht vollständige Liste findet man aber hier:
obfuscators.io