MSBuild-Aufgabe

Die MSBuild-Aufgabe Babel ist in jeder Edition von Babel Obfuscator verfügbar. Sie lässt sich jedem MSBuild-Projekt hinzufügen, indem Sie das passende Element UsingTask in die XML-Datei des MSBuild-Projekts einfügen:

<UsingTask TaskName="Babel" AssemblyName="Babel.Build, Version=10.0.0.0, Culture=neutral, PublicKeyToken=138d17b5bd621ab7" />

Das Attribut AssemblyName verweist auf den vollqualifizierten Namen der .NET-Komponente Babel.Build.dll, die im Global Assembly Cache installiert ist.

Die Eigenschaft Version von AssemblyName sollte auf die aktuell installierte Produktversion gesetzt werden. Wenn Sie zum Beispiel die Version x.y.z.w installiert haben:

Version=x.y.z.0

Die Revisionsnummer w sollte immer auf 0 gesetzt werden.

Wenn Sie den vollqualifizierten Assemblynamen nicht verwenden möchten, können Sie die Komponente Babel.Build.dll wie folgt über den vollständigen Pfad referenzieren:

<UsingTask TaskName="Babel" AssemblyFile="<Full path to Babel.Build.dll>" />

Sobald die Assembly Babel.Build referenziert ist, können Sie mit der Babel-Aufgabe Babel Obfuscator für eine bestimmte Ziel-Assembly starten:

<Target Name="AfterBuild">
  <Babel InputFile="$(TargetPath)" OutputFile="$(TargetPath)" />
</Target>

Die oben definierte Babel-Aufgabe wird nach dem Build ausgeführt, um die Ziel-Assembly zu verschleiern, und ersetzt sie durch die von Babel verarbeitete verschleierte Assembly.

Das Ziel „AfterBuild“ ist ein bekanntes MSBuild-Ziel , das in der Buildpipeline definiert ist. Es dient üblicherweise dazu, Aufgaben hinzuzufügen, die ausgeführt werden, sobald der Build abgeschlossen ist und alle Binärdateien im Ausgabeordner des Builds liegen, den die MSBuild-Variable  $(TargetPath) festlegt.

So wird die zuvor genannte Babel-Aufgabe nach dem Build ausgeführt, um die in der Variable $(TargetPath) angegebene Ziel-Assembly zu verschleiern, und ersetzt sie durch die von Babel verarbeitete verschleierte Version.

Die Ziele AfterBuild und Compile

Neuere .NET SDKs haben zusätzliche Optimierungsaufgaben eingeführt, die vor der Aufgabe „AfterBuild“ und nach dem Kompilierungsschritt ablaufen, der in der Aufgabe „Compile“ ausgeführt wird. Die Aufgabe „Compile“ unterscheidet sich von „AfterBuild“, das lediglich als Platzhalter in der Buildpipeline dient und von externen Buildprozessen überschrieben werden soll. Die Aufgabe „Compile“ ist der eigentliche Schritt, in dem kompiliert wird, und sie lässt sich nicht durch benutzerdefinierte Aufgaben ersetzen.

Weil die Verschleierung nach der Aufgabe „Compile“ und vor allen nachfolgenden Optimierungen des Buildsystems erfolgen muss, sollten Sie die Verschleierungsaufgabe von Babel unmittelbar nach dem Schritt „Compile“ einbinden. Das erreichen Sie mit dem Attribut AfterTargets des MSBuild-Ziels, wie unten gezeigt:

<Target Name="Obfuscate" AfterTargets="Compile">
  <Babel InputFile="$(ProjectDir)$(IntermediateOutputPath)$(TargetFileName)" 
         OutputFile="$(ProjectDir)$(IntermediateOutputPath)$(TargetFileName)" />
</Target>

Diese Einrichtung stellt sicher, dass die Verschleierung auf die kompilierte Ausgabe angewendet wird, bevor weitere Buildoptimierungen ausgeführt werden.

Beachten Sie, dass die Eigenschaften InputFile und OutputFile nicht auf TargetPath gesetzt sind, weil die kompilierte Assembly in dieser Phase des Buildprozesses noch nicht an den Speicherort TargetPath kopiert wurde. Sie liegt stattdessen im Zwischenordner des Builds, $(IntermediateOutputPath), der als Quelle für alle nachfolgenden Buildschritte dient.

Dieser Zwischenordner enthält die Assembly und weitere Artefakte, die in der Kompilierungsphase entstehen. So können verschiedene Aufgaben, darunter die Verschleierung, auf der kompilierten Ausgabe ausgeführt werden, bevor der endgültige Build abgeschlossen ist. Durch die Angabe des Zwischenpfads stellen wir sicher, dass die Verschleierung auf die richtige Version der Assembly angewendet wird, nämlich so, wie sie vor allen Kopier- oder weiteren Verarbeitungsschritten vorliegt, die die Buildausgabe verändern könnten.

Dieser Ansatz vereinfacht nicht nur den Buildprozess, sondern stellt auch sicher, dass die verschleierte Ausgabe korrekt erzeugt und für weitere Optimierungsaufgaben oder Bereitstellungsschritte vorbereitet wird.

Die Babel-Aufgabe konfigurieren

Die Babel-Aufgabe bietet zahlreiche Eigenschaften, mit denen Sie die Verschleierung an Ihre Anforderungen anpassen können. Eine vollständige Liste dieser Eigenschaften finden Sie im Abschnitt Referenz der Babel-Aufgabe der Dokumentation. Standardmäßig schaltet die Babel-Aufgabe nur die Umbenennung von Symbolen ein. Sie ändert die Namen von Klassen, Methoden und anderen Symbolen im Code, um das Reverse Engineering zu erschweren.

Für erweiterte Verschleierungsfunktionen wie Kontrollflussverschleierung, Zeichenfolgenverschlüsselung und andere anspruchsvolle Techniken ist eine gültige Lizenz erforderlich. Ohne gültige Lizenz arbeitet die Babel-Aufgabe im Evaluierungsmodus, der auf die Umbenennung von Symbolen beschränkt ist. Außerdem funktionieren im Evaluierungsmodus verschleierte Assemblys nach einem bestimmten Datum nicht mehr, worauf der Warncode W00000 im Buildprotokoll hinweist. Zum Beispiel:

Warning [W00000]: This is an evaluation version, the obfuscated assembly will no longer work after 15/08/2024 17:16:27

Wenn Sie eine gültige Lizenz erwerben und anwenden, steht Ihnen der volle Umfang der Verschleierungsfunktionen von Babel zur Verfügung, und alle Beschränkungen entfallen, sodass die verschleierten Assemblys ohne Ablaufdatum laufen.

<Target Name="Obfuscate" AfterTargets="Compile">
  <Babel InputFile="$(ProjectDir)$(IntermediateOutputPath)$(TargetFileName)" 
         OutputFile="$(ProjectDir)$(IntermediateOutputPath)$(TargetFileName)" 
         ControlFlowObfuscation="goto=on;if=on;switch=on;case=on;call=on;true"
         ControlFlowIterations="3" StringEncryption="hash" 
         ResourceEncryption="true" />
</Target>

So profitiert Ihre Anwendung von umfassenden Schutzfunktionen, die Ihr geistiges Eigentum und Ihren Quellcode vor unbefugtem Zugriff und vor Manipulation schützen.

Buildleistung in Visual Studio mit Codeanalysetools

In Visual Studio sind Codeanalysetools eng in den Entwicklungsablauf eingebunden. Diese Analysetools laufen ständig im Hintergrund und geben im Editor von Visual Studio Rückmeldungen in Echtzeit. Das erleichtert das Programmieren, weil mögliche Probleme schon beim Tippen hervorgehoben werden. Diese Funktion hat jedoch einen Preis: Sie löst den Buildprozess bei jeder Iteration aus, was zu Leistungsengpässen führen kann, vor allem wenn Aufgaben wie die Babel-Verschleierung zum Build gehören.

Um unnötige Leistungseinbußen zu vermeiden, können Sie Ihre MSBuild-Konfiguration so ändern, dass die Verschleierungsaufgabe von Babel nur beim vollständigen Build läuft (das heißt, wenn Sie die Projektmappe tatsächlich erstellen) und nicht bei den Entwurfszeitbuilds, die die Analysetools im Hintergrund verwenden. So gehen Sie vor:

<Target Name="Obfuscate" AfterTargets="Compile" 
        Condition="'$(DesignTimeBuild)' != 'true'">
    <Babel … />
</Target>

Durch das Hinzufügen von Condition=”’$(DesignTimeBuild)’ != ‘true’” stellen Sie sicher, dass das Ziel Obfuscate bei den Entwurfszeitbuilds (den Hintergrundprozessen, die die Codeanalysetools verwenden) übersprungen wird. Diese Änderung verringert die CPU-Zeit, die bei der normalen Programmierarbeit verbraucht wird, erheblich, ohne den endgültigen Buildprozess zu beeinflussen. Die Verschleierung läuft weiterhin, wenn sie gebraucht wird: beim eigentlichen Build des Projekts.

Babel-Aufgabe und NuGet-Paket von Babel Obfuscator

Das NuGet-Paket von Babel Obfuscator, das mit der Ultimate-Edition verfügbar ist, vereinfacht die Einbindung der Babel-Aufgabe in die Buildpipeline. Sobald das Paket in einem .NET-Projekt referenziert ist, bindet es die Babel-Aufgabe automatisch an der passenden Stelle des Buildprozesses ein, ohne dass eine manuelle Konfiguration nötig ist. Entwickler müssen also weder die Using-Direktive für die Babel-Aufgabe ausdrücklich hinzufügen noch die Babel-Aufgabe von Hand in das Buildskript einfügen.

Das Paket bestimmt die richtige Position der Babel-Aufgabe selbstständig anhand des Projekttyps und der verwendeten Version des .NET SDK. Diese Automatisierung sorgt dafür, dass die Verschleierung an der optimalen Stelle der Buildpipeline stattfindet, und berücksichtigt dabei die Buildkonfigurationen und Anforderungen der verschiedenen Projekttypen. Die vereinfachte Einbindung verringert die Fehleranfälligkeit und erleichtert es Entwicklern, die Verschleierung anzuwenden, ohne die Einzelheiten der Buildpipeline genau zu kennen.

Hauptvorteile des NuGet-Pakets von Babel Obfuscator

1. Automatische Steuerung: Das NuGet-Paket von Babel Obfuscator steuert die Verschleierung im Buildprozess selbstständig. Es sorgt dafür, dass sie nur bei vollständigen Builds läuft und bei den Entwurfszeitbuilds der Analysetools übersprungen wird.

2. Geringere CPU-Last: Weil das Paket den Verschleierungsschritt bei Hintergrundbuilds automatisch überspringt, bleibt die Systemleistung erhalten. Unnötige CPU-Last entfällt, und Visual Studio läuft während der Entwicklung flüssiger.

3. Einfachere Konfiguration: Sie müssen Ihre MSBuild-Skripte nicht von Hand ändern. Das Paket fügt sich nahtlos in Ihr Projekt ein und erledigt alles im Hintergrund. Das spart Zeit und verringert die Komplexität.

4. Einheitliche Ergebnisse: Die Verschleierung wird stets nur in den abschließenden Buildphasen angewendet. So ist Ihr Code geschützt, ohne dass die tägliche Entwicklungsarbeit beeinträchtigt wird.

Außerdem sorgt das NuGet-Paket von Babel Obfuscator für Einheitlichkeit über Projekte hinweg: Alle für die Verschleierung nötigen Schritte werden korrekt umgesetzt, unabhängig von der Komplexität des Projekts und davon, wie vertraut das Team mit dem Prozess ist. Das ist besonders in größeren Projekten oder Teams von Vorteil, in denen einheitliche Buildprozesse schwer durchzuhalten sind.