Allgemeine Funktionen

Schützt Ihren Code und Ihr geistiges Eigentum vor Reverse Engineering

Babel Obfuscator wendet auf eine kompilierte Assembly mehrere voneinander unabhängige Schutzebenen an: Es benennt Symbole in bedeutungslose Bezeichner um, verschlüsselt Zeichenfolgen, Konstanten und Arrays und Ressourcen, schreibt den Kontrollfluss von Methoden um, verbirgt Aufrufziele hinter dynamischen Proxys und kann ganze Methodenrümpfe verschlüsseln, die dann in einer verwalteten virtuellen Maschine ausgeführt werden. Die Anwendung behält ihr Verhalten und ihre öffentliche Schnittstelle. Was ein Decompiler wiederherstellt, ist nicht mehr der Quellcode, den Sie geschrieben haben.

Die Ebenen ergänzen einander. Die Umbenennung entfernt das Vokabular, auf das sich ein Leser stützt, die Zeichenfolgen- und Wertverschlüsselung entfernt die Hinweise, die die Umbenennung überstehen, die Kontrollflussverschleierung entfernt die Struktur, und die Codeverschlüsselung entfernt den Code selbst. Gemeinsam und gezielt dort eingesetzt, wo das geistige Eigentum liegt, treiben sie den Aufwand, die Assembly zu verstehen und zu verändern, weit über den Wert, den ein Angreifer aus ihr ziehen kann.

Kompatibel mit dem gesamten .NET-Ökosystem

Babel Obfuscator arbeitet auf der Ebene von IL-Code und Metadaten und unterstützt daher jede Laufzeit und jedes Anwendungsmodell, das standardkonforme .NET-Assemblys erzeugt:

• .NET 10 und alle früheren Versionen von .NET und .NET Core
• .NET Framework 2.0 bis 4.8
• Desktopanwendungen mit WPF, Windows Forms oder Avalonia
• .NET MAUI unter Android und iOS sowie Xamarin
• Blazor und ASP.NET Core
• .NET Standard, UWP, Mono und nanoFramework

Es verarbeitet Code in C#, bis C# 14, VB.NET und F# und folgt den Veröffentlichungsmodi des modernen SDK: frameworkabhängig, eigenständig, Einzeldatei, getrimmt und NativeAOT. Die Umbenennung von Symbolen, die STREAM-Zeichenfolgenverschlüsselung und die Kontrollflussverschleierung, einschließlich Chained State, überstehen Trimming und AOT-Kompilierung unverändert. Funktionen, die auf ein in den Speicher abgebildetes Abbild oder auf dynamischen IL-Code angewiesen sind, etwa Codeverschlüsselung, Dynamic Proxy und die Manipulationsprüfung für den Desktop, haben auf MAUI-, Blazor- und AOT-Zielen dokumentierte Grenzen. Jede Funktionsseite nennt sie, und die Beispiele .NET MAUI verschleiern und Blazor Web App zeigen funktionierende Konfigurationen.

Läuft unter Windows, macOS und Linux ★Ultimate

Jede Edition enthält das Befehlszeilentool und die MSBuild-Aufgabe für Windows (Zip-Pakete). Für Babel Desktop, für die Ausführung von Babel unter macOS und Linux sowie in Azure DevOps, GitHub Actions und ähnlichen CI-Buildpipelines ist die Ultimate-Edition erforderlich oder eine der Licensing-Editionen Server und Data Center, die sie einschließen. Nur diese enthalten die NuGet-Pakete von Babel Obfuscator, die Babel unter jedem Betriebssystem als dotnet-Tool ausführen und in dotnet build und dotnet publish integrieren. Die Enterprise-Edition ist auf das Befehlszeilentool für Windows und die MSBuild-Aufgabe des Zip-Pakets für .NET Framework beschränkt.

Da die Verschleierung auf IL-Ebene arbeitet, schränkt das Betriebssystem des Buildhosts das Ziel nicht ein: Ein Buildagent unter Windows kann Assemblys schützen, die für linux-x64, linux-arm64 oder osx-arm64 veröffentlicht werden, und ein Linux-Container kann eine Windows-Desktopanwendung schützen. Teams können also die Buildumgebung behalten, die sie bereits haben.

Vollständig verwaltete Codeverschlüsselung und Virtualisierung

Die Codeverschlüsselung schreibt den IL-Code einer Methode in einen eigenen Anweisungssatz um, verschlüsselt ihn und hinterlässt an seiner Stelle einen Stub, der die Kontrolle an die Babel Virtual Machine (BVM) übergibt, eine schlanke verwaltete Laufzeit, die in die verschleierte Assembly eingebettet ist. Die BVM entschlüsselt die Methode und führt sie aus, wenn sie aufgerufen wird. Der Methodenrumpf liegt in der Assembly nicht mehr in einer Form vor, die ein Decompiler lesen kann, und die Anweisungen lassen sich nicht patchen.

Die Lösung ist vollständig verwaltet: Verschlüsselte Methoden werden nicht durch nativen Code für eine bestimmte Plattform ersetzt. Der plattformübergreifende Charakter von .NET bleibt also erhalten, und der JIT-Compiler optimiert weiterhin für die Ziel-CPU. Verschlüsselter Code lässt sich in externen Codedateien ablegen, die zusammen mit einer Lizenz bereitgestellt werden, oder mit einem Passwort schützen, das zur Laufzeit übergeben wird. Darauf baut die funktionsbasierte Lizenzierung auf. Der Artikel Hardware-Dongle-Bindung zeigt, wie sich verschlüsselter Code an ein physisches Gerät binden lässt. Weil die Codeverschlüsselung Leistung kostet, ist sie für die sensiblen Teile der Codebasis gedacht, während die anderen Schutzfunktionen den Rest abdecken.

Gehärtet gegen automatisierte Deobfuskierung ★Ultimate

Die klassische Verschleierung hält einen menschlichen Leser auf. Eine Klasse automatisierter Tools kann einen Teil davon jedoch in einem einzigen Durchgang rückgängig machen, indem sie die Reihenfolge einer abgeflachten Methode statisch wiederherstellt oder den Schlüssel liest, der neben einer verschlüsselten Zeichenfolge liegt. Version 12.0 ergänzt zwei Transformationen, die für diesen Gegner entworfen wurden:

• Chained State flacht eine Methode um einen Dispatcher herum ab, dessen ursprüngliche Reihenfolge sich mit statischer Analyse allein nicht wiederherstellen lässt. In internen Tests mit einem gängigen automatisierten Deobfuskator wurden Methoden, die mit dem gewöhnlichen Algorithmus switch abgeflacht waren, wiederhergestellt, während dieselben Methoden mit chain unversehrt blieben. Der Algorithmus gibt verifizierbaren IL-Code aus, fügt keine Laufzeitabhängigkeiten hinzu und ist nur wenige Prozent langsamer als die gewöhnliche Abflachung.
• Die STREAM-Zeichenfolgenverschlüsselung verschlüsselt jede Zeichenfolge einzeln mit einer authentifizierten Chiffre, entschlüsselt sie verzögert bei der ersten Verwendung und legt den Schlüssel nie inline ab. Identische Zeichenfolgen ergeben unterschiedliche Bytes, zu keinem Zeitpunkt liegt die gesamte Menge der Zeichenfolgen im Klartext vor, und die vollständig verwaltete Entschlüsselungsroutine lässt sich mit Trimming, NativeAOT und im FIPS-Modus unverändert veröffentlichen.

Erkennt Debugging und Manipulation, auf Desktop und Mobilgeräten

Der in die Assembly eingefügte Code für den Debugging-Schutz erkennt einen angehängten Debugger und beendet den Prozess oder ruft eine Ihrer Methoden auf. Die Manipulationserkennung prüft beim Start, ob die Assembly diejenige ist, die Babel erzeugt hat: Auf Desktopzielen bildet sie den Hash des geladenen Abbilds im Speicher und vergleicht ihn mit einem Hash, der bei der Verschleierung hinterlegt wurde.

Seit Version 12.0 deckt die Manipulationserkennung auch .NET MAUI ab, wo die Desktoptechnik nicht anwendbar ist. Unter Android vergleicht die verschleierte App das Zertifikat, mit dem die laufende APK signiert wurde, mit den Fingerabdrücken vertrauenswürdiger Signierer, die Sie bei der Verschleierung pinnen, sodass eine neu verpackte oder neu signierte App abgelehnt wird. Unter iOS prüft sie ihre eigene Bundle-ID und ihre Apple-Team-ID. Beide Prüfungen untersuchen das Paket des Betriebssystems und nicht das verwaltete Abbild, sodass sie auch mit Trimming und vollständiger AOT-Kompilierung funktionieren. In jedem Fall bestimmen Sie die Reaktion: den Prozess beenden oder einen benutzerdefinierten Handler ausführen, der protokollieren, Funktionen einschränken oder den Vorfall an Ihren Server melden kann.

Vereinfacht die Bereitstellung durch Zusammenführen und Einbetten von Abhängigkeiten

Zusammenführen und Einbetten macht aus einer Anwendung und ihren Abhängigkeiten eine einzige Datei. Die Zusammenführung integriert den Code referenzierter Assemblys in das Ziel und benennt ihn zusammen mit Ihrem eigenen um. Die zusammengeführten Typen lassen sich so internalisieren und als Einheit verschleiern, was die Bereitstellung vereinfacht und die Fläche lesbaren Codes verkleinert. Die Einbettung legt eine Assembly als Ganzes ab, als verschlüsselte Ressource, die zur Laufzeit geladen wird. Sie eignet sich für Assemblys von Drittanbietern oder mit starkem Namen, die nicht verändert werden dürfen. Beide Verfahren lassen sich im selben Projekt kombinieren.

Optimiert Code und Metadaten

Über den Schutz hinaus optimiert Babel die erzeugte Assembly. Die Entfernung ungenutzten Codes beseitigt Methoden, Felder, Eigenschaften und Typen, die nie verwendet werden. Die Metadatenoptimierungen versiegeln Klassen automatisch und entfernen nicht benötigte benutzerdefinierte Attribute, System.Enum-Typen sowie Eigenschafts- und Ereigniskonstrukte. Die Codeoptimierungen erweitern kleine Methoden und Eigenschaften inline und entfernen const-Felder. Das Ergebnis ist eine Assembly, die auf dem Datenträger kleiner ist, schneller lädt und schwerer zu lesen ist, weil die Metadaten, auf die sich das Reverse Engineering stützt, auf das reduziert wurden, was die Laufzeit benötigt.

In Visual Studio, MSBuild, NuGet und Buildserver integriert

Babel läuft im Build und nicht danach. Die MSBuild-Aufgabe Babel verschleiert aus Visual Studio heraus und auf jedem Buildserver, der MSBuild ausführt, und jede Eigenschaft der Aufgabe ist in der Projektdatei mit IntelliSense dokumentiert. Das NuGet-Paket Babel.Obfuscator ★Ultimate geht für Projekte im SDK-Stil weiter: Eine einzige Paketreferenz setzt die Aufgabe an die richtige Stelle der Pipeline von dotnet build und dotnet publish, bevor Trimming und AOT-Kompilierung die Assembly umschreiben. Nur in dieser Reihenfolge lassen sich diese Veröffentlichungsmodi schützen. Die Buildserver-Beispiele behandeln Azure DevOps, GitHub Actions, AppVeyor und App Center und zeigen, wie Unit-Tests gegen die verschleierte Ausgabe laufen. Wie das NuGet-Paket setzen sie die Ultimate-Edition voraus.

Als Befehlszeilentool verfügbar, mit einem KI-freundlichen Modus

Alles, was Babel kann, steht über die Befehlszeile zur Verfügung, unter Windows, Linux und macOS. Seit Version 11.7 bietet das Tool außerdem einen KI-freundlichen Modus für Pipelines und Agenten: --format=json oder --format=ndjson geben einen strukturierten, versionierten Ereignisstrom auf stdout aus, während die Diagnosemeldungen nach stderr gehen, --quiet unterdrückt das Banner und bricht sofort mit einem Fehler ab, statt auf eine Eingabe zu warten, und --strict-exit schaltet semantische Exitcodes ein, die zwischen ungültigen Argumenten, fehlender Eingabe sowie Fehlern bei Verschleierung, Lizenzierung und Signierung unterscheiden. Dasselbe Flag macht aus --help eine maschinenlesbare Beschreibung aller Optionen.

Bedienung durch KI-Assistenten über MCP

Babel Desktop kann einen Model-Context-Protocol-Server hosten, sodass sich ein Assistent wie Claude Code mit der laufenden Anwendung verbindet und sie steuert: ein Projekt anlegen, Assemblys hinzufügen, Regeln schreiben, auswählen, was zusammengeführt oder eingebettet wird, verschleiern, Warnungen und Statistiken lesen, einen Stacktrace decodieren, ein Design erstellen und einen Screenshot aufnehmen, um das Ergebnis zu prüfen. Die Tools decken die Vorgänge ab, die Sie am häufigsten ausführen, hinzu kommen Tools für Einstellungen, Babel Licensing und Anwendungsupdates. In den Editionen Server und Data Center verwaltet derselbe Server die Lizenzdatenbank: Kunden, Produkte, Bestellungen, Lizenzen, Signaturschlüssel sowie das Erzeugen und Exportieren von Lizenzen.

Der Server ist standardmäßig ausgeschaltet, bindet sich nur an die Loopback-Adresse und kann bei jeder Anfrage ein Zugriffstoken verlangen. Babel Licensing bietet einen separaten MCP-Server für den gehosteten Licensing Service.

Decodiert verschleierte Stacktraces

Die Umbenennung ändert die Namen, die in den Stacktraces von Ausnahmen erscheinen. Babel erzeugt deshalb für jede verschleierte Assembly eine XML-Map-Datei und liefert die Tools, mit denen sich ein Stacktrace zurückübersetzen lässt. Der Stack-Decoder in Babel Desktop und die Befehlszeilenoption --stacktrace stellen die ursprünglichen Namen wieder her, mit optionaler PDB-Unterstützung für Zeilennummern. Wenn Dynamic Proxy eingeschaltet ist, nennt der Decoder die Methode hinter jedem Brücken-Frame eines Proxys und kann die von Babel generierten Frames ganz ausblenden. Übrig bleibt ein Stacktrace, der mit dem der nicht verschleierten Anwendung identisch ist. Map-Dateien steuern auch die assemblyübergreifende Umbenennung, sodass eine Anwendung und ihre Bibliotheken in getrennten Builds verschleiert werden können und trotzdem dieselben umbenannten Symbole verwenden.

Bereit für FIPS

Mit Babel geschützte Assemblys laufen auf Hosts im FIPS-Modus. Die Funktionen, die Inhalte zur Laufzeit entschlüsseln, also Codeverschlüsselung, Zeichenfolgenverschlüsselung, Ressourcenverschlüsselung sowie Wert- und Arrayverschlüsselung, lassen sich so konfigurieren, dass sie eine eigenständige verwaltete AES-Entschlüsselungsroutine verwenden. Die eingefügte Laufzeitkomponente hängt dann nie vom Kryptografieanbieter der Plattform ab, und die Anwendung startet sogar in einem Container, dessen OpenSSL-FIPS-Anbieter fehlt. Die Seite FIPS-Konformität erläutert die Bedingung in der Umgebung, die Korrektur bei der Verschleierung und die Korrektur auf Umgebungsebene.

Erweiterbar mit Regeln, Attributen und Plugins

Jede Funktion lässt sich für jedes Symbol einzeln abstimmen. XML-Regeln wählen Typen und Member nach Muster, Attribut, Sichtbarkeit oder Vererbung aus und schalten eine Funktion für sie ein, aus oder konfigurieren sie. Benutzerdefinierte Attribute leisten dasselbe im Quellcode. Der Verschleierungs-Agent analysiert die Assembly vor der Verschleierung und generiert die Regeln, mit denen Reflexion, Serialisierung, Datenbindung und dynamischer Code weiter funktionieren. Für alles, was darüber hinausgeht, können in .NET geschriebene Plugins Algorithmen für die Zeichenfolgen- und Wertverschlüsselung, eigene Umbenennungsschemata, generierte Regeln und Codetransformationen hinzufügen. Open-Source-Beispiele auf GitHub dienen als Ausgangspunkt.