Obfuscator für Sourcedateien (*.cs)

Hallo Zusammen,

ich suche einen Obfuscator welcher die Sourcedateien verändert.
Ich habe schon einige getestet (List of obfuscators for .NET), leider gehen diese davon aus, dass eine DLL oder EXE geschützt wird.

Hintergrund:
Die Dateien werden in einem Programm als API-Erweiterungen geladen. Hier ist es nur möglich eine *.cs-Datei zu laden.
Ich habe auch schon getestet eine DLL zu kompilieren und diese dann zu obfuscaten, danach das Decompilat zu laden, aber hier klappt auch was nicht, da in dotPeek einige Issues angezeigt werden.

Hat jemand Tipps bzw. einen möglich Workflow?

Danke im Voraus.

Naja ein Obfuscator funktioniert ja so, dass er zB eine Methode umbenennt und auch dahingehend alle Referenzen, die diese Methode nutzen.
Der Name ergibt sich aus einem Zufallsmuster.

Wie soll nun eine einzelne Datei verschleiert werden, wenn dann die Konsumenten die Referenzen auf eine Methode nicht mehr finden können, einfach weil der Name nun irgendwas ist?
Sinn macht es also in diesem Fall nur, dass die Methode und die Klasse die gleichen Namen haben und nur die jeweiligen Inhalte verschleiert werden.

Da frag ich mich aber wiederum: das ist doch binnen Minuten selbst mit menschlicher Kraft wieder auf lesbaren Code zu bringen.

Davon abgesehen, dass 99% aller Obfuscators schon lange geknackt sind und es schon lange Software gibt, die verschleierten Code lesbar machen:
was erhoffst Du Dir durch das verschleiern einer einzelnen Datei?

Mir ist bekannt dass es keinen 100% Schutz gibt. Dennoch möchte ich es jemand schwer machen, der den Code verändern möchte.

Bezüglich Referenzen:
Hier gibt es kein Problem, da alles wie beschrieben in einer Datei vorhanden sein muss.

Es würde mir reichen wenn alle Variablen und Methoden umbenannt werden, aber wie gesagt, können die aufgelistet Obfuscator die nur auf DLLs bzw. EXE.

Schau doch mal ob du https://github.com/asbjornu/Uglify.NET anpassen kannst

Vielleicht bin ich zu blöd...

Welchen zusätzlichen Schutz versprichst du dir davon?
Ob du den Source randomized oder ob der Obfuscator das Assembly randomized kommt doch unterm Strich auf das gleiche raus?

Es gibt kein Assembly.
Die *.cs-Dateien werden an Kunden weitergegeben.

Ich verspreche mir ein "bisschen mehr" Schutz dadurch, dass Änderungen nicht so einfach gemacht werden können.

Uglify ist eine Variante; ich würde für die Zukunft aber über ein ordentliches Pluginsystem nachdenken statt die Zeit mit einem Ofuscator zu vergeuden.
Was Du machst ist von Hinten durch die Brust ins Auge...

Hallo cyntonix,

ich könnte mir vorstellen, dass man die .NET Compiler Platform Roslyn nutzen könnte, um selbst einen Quellcode-Obfuscator zu erstellen. Denn ...

The .NET Compiler Platform ("Roslyn") provides open-source C# and Visual Basic compilers with rich code analysis APIs. It enables building code analysis tools with the same APIs that are used by Visual Studio.

Wobei ich es - was die Verschleierung generell angeht, egal auf welcher Ebene - die Meinung meiner Vorredner teile, dass dies nicht viel bringt. Das Thema Obfuscation ist so alt wie .NET und - in allen wesentlichen Aspekten - in den aus der FAQ [FAQ] NET Assembly vor Disassembling schützen (Obfuscator) verlinkten Threads behandelt, auch was Sinn- und Unsinn sowie die Grenzen angeht.

Nur so am Rande: Bei der Obfuscation von Assemblies ist es immerhin möglich, den IL-Code (häppchenweise) so zu verändern, dass es kein passenden C# Konstrukt mehr gibt, dss diesem IL-Code-Häppchen direkt (d.h. ohne Compileroptimierungen) entspricht (Beispiel: Swap von zwei Variablen durch über den Stack ohne explizite Variable, in IL geht das, lässt sich aber nicht direkt in C# ausdrücken, siehe Modhinweis in Das Programmier-Spiel: nette Übungsaufgaben für zwischendurch). Bei der Obfuscation von Quellcode ist diese Möglichkeit per se nicht gegeben.

herbivore

Für Obfuscation ist C# bzw. .NET einfach die falsche Adresse, das lässt sich in den meisten Fällen problemlos wieder in lesbaren Code umwandeln. Variablen umbenennen ist für einen geübten Entwickler pillepalle. Und wer dann gar noch mit IL-Code umgehen kann, dem ist die Verschleierung eh relativ egal.

Warum willst du es schwer machen, den Code zu verändern? Hat das einen bestimmten Zweck? Falls du Zugriff auf das Hauptprogramm und damit die Laderoutine hast, kannst du dir was überlegen mit Hashes den Code zu prüfen, ob er noch dem entspricht, was du geschrieben hast. Aber auch das dürfte nicht unglaublich schwer zu knacken sein. Ist halt so.

Ich denke er will einfach nicht, dass jemand auch nur einen Int-Wert in seinem CS-File ändert, der vom Programmieren nicht viel Ahnung hat aber evtl. kombinatorische Logik.
Einen Startwert in einer cs-Datei zu ändern sollte jeder beherrschen, aber nicht jeder durchführen können - zB Muddi.

Und dafür reicht - bis zu einem gewissen Grad - Uglify.

Vielen Dank erstmal für die vielen Antworten und Tips.

Abt hat Recht, ich will weniger mich schützen eher den User.

Uglify hab ich kurz angeschaut, hänge aber noch bisl da Abhängigkeiten fehlen. Wenn ich es zum laufen bekomme dann Committe ich es mal.
Denke da stimmt mit IronJS was nicht.

Leider habe ich eben keine andere Möglichkeit als die CS-Datei im Hauptprogramm (welches von einem dritten ist) zu laden.

Hallo

Ich hatte vor Jahren so ein ähnliches Problem, damals mit Delphi 1.0 (Pascal). Ich habe es damals so gelöst, das ich eine Checksumme über die Datei gebildet und diese vor dem Laden überprüft habe. Hatte der Benutzer etwas im File geändert, stimmt diese natürlich nicht mehr und das Laden wurde abgebrochen.

Thomas

ich könnte mir vorstellen, dass man die .NET Compiler Platform Roslyn nutzen könnte, um selbst einen Quellcode-Obfuscator zu erstellen.

Mit Roslyn könnte man sowas sehr leicht umsetzen. Identifier umbenennen, whitespaces entfernen, unnötige Klammern hinzufügen, konstante Ausdrücke verkomplizieren, vielleicht noch schön hässliche gotos einfügen sollten sehr einfach sein