Fonctionnalités générales

Protège votre code et votre propriété intellectuelle contre la rétro-ingénierie

Babel Obfuscator applique plusieurs couches de protection indépendantes à un assembly compilé : il renomme les symboles avec des identifiants dénués de sens, chiffre les chaînes, les constantes et les tableaux ainsi que les ressources, réécrit le flux de contrôle des méthodes, masque les cibles des appels derrière des proxys dynamiques et peut chiffrer des corps de méthode entiers pour les exécuter dans une machine virtuelle managée. L’application conserve son comportement et son interface publique ; ce qu’un décompilateur récupère n’est plus le code source que vous avez écrit.

Ces couches se combinent. Le renommage supprime le vocabulaire sur lequel s’appuie un lecteur, le chiffrement des chaînes et des valeurs supprime les indices qui subsistent après le renommage, l’obfuscation du flux de contrôle supprime la structure, et le chiffrement du code supprime le code lui-même. Appliquées ensemble, et de façon sélective là où se trouve la propriété intellectuelle, elles portent le coût de la compréhension et de la modification de l’assembly bien au-delà de la valeur qu’un attaquant peut en tirer.

Compatible avec tout l’écosystème .NET

Babel Obfuscator opère au niveau de l’IL et des métadonnées ; il prend donc en charge tous les runtimes et tous les modèles d’application qui produisent des assemblies .NET standard :

• .NET 10 et toutes les versions antérieures de .NET et de .NET Core
• .NET Framework 2.0 à 4.8
• Applications de bureau créées avec WPF, Windows Forms ou Avalonia
• .NET MAUI sur Android et iOS, et Xamarin
• Blazor et ASP.NET Core
• .NET Standard, UWP, Mono et nanoFramework

Il traite le code écrit en C#, jusqu’à C# 14, en VB.NET et en F#, et il suit les modes de publication du SDK moderne : dépendant du framework, autonome, fichier unique, découpé (trimming) et NativeAOT. Le renommage des symboles, le chiffrement des chaînes STREAM et l’obfuscation du flux de contrôle, état chaîné compris, résistent sans modification au découpage et à la compilation AOT. Les fonctionnalités qui reposent sur une image mappée en mémoire ou sur de l’IL dynamique, comme le chiffrement du code, le proxy dynamique et le contrôle de falsification des cibles de bureau, ont des limites documentées sur les cibles MAUI, Blazor et AOT ; la page de chaque fonctionnalité les indique, et les exemples Obfusquer .NET MAUI et Application web Blazor montrent des configurations qui fonctionnent.

Fonctionne sous Windows, macOS et Linux ★Ultimate

Toutes les éditions incluent l’outil en ligne de commande et la tâche MSBuild pour Windows (archives zip). Exécuter Babel Desktop, ou exécuter Babel sous macOS et Linux et dans Azure DevOps, GitHub Actions et les pipelines de build CI similaires, nécessite l’édition Ultimate, ou les éditions Server et Data Center de Babel Licensing qui l’incluent : elles seules fournissent les packages NuGet Babel Obfuscator, qui exécutent Babel en tant qu’outil dotnet sous n’importe quel système d’exploitation et l’intègrent à dotnet build et à dotnet publish. L’édition Enterprise se limite à l’outil en ligne de commande pour Windows et à la tâche MSBuild de l’archive zip .NET Framework.

Comme l’obfuscation opère sur l’IL, le système d’exploitation de l’hôte de build n’impose rien à la cible : un agent de build Windows peut protéger des assemblies publiés pour linux-x64, linux-arm64 ou osx-arm64, et un conteneur Linux peut protéger une application de bureau Windows. Les équipes peuvent donc conserver l’environnement de build dont elles disposent déjà.

Chiffrement du code et virtualisation entièrement managés

Le chiffrement du code réécrit l’IL d’une méthode dans un jeu d’instructions personnalisé, le chiffre et laisse à sa place un stub qui passe le contrôle à la machine virtuelle Babel (BVM), un runtime managé léger incorporé dans l’assembly obfusqué. La BVM déchiffre et exécute la méthode lorsqu’elle est appelée. Le corps de la méthode n’existe plus dans l’assembly sous une forme lisible par un décompilateur, et les instructions ne peuvent pas être modifiées par un patch.

La solution est entièrement managée : les méthodes chiffrées ne sont pas remplacées par du code natif propre à une plateforme, ce qui préserve le caractère multiplateforme de .NET et laisse le compilateur JIT optimiser pour le processeur cible. Le code chiffré peut être conservé dans des fichiers de code externes déployés avec une licence, ou protégé par un mot de passe fourni à l’exécution, ce qui est la base des licences basées sur des fonctionnalités. L’article Liaison à un dongle matériel montre comment lier le code chiffré à un périphérique physique. Comme il pèse sur les performances, le chiffrement du code est destiné aux parties sensibles du code, les autres protections couvrant le reste.

Renforcé contre la désobfuscation automatisée ★Ultimate

L’obfuscation classique met en échec un lecteur humain ; une catégorie d’outils automatisés peut en défaire une partie en une seule passe, en retrouvant par analyse statique l’ordre d’une méthode aplatie ou en lisant la clé placée à côté d’une chaîne chiffrée. La version 12.0 ajoute deux transformations conçues contre cet adversaire :

• L’état chaîné aplatit une méthode autour d’un répartiteur dont l’ordre d’origine ne peut pas être retrouvé par la seule analyse statique. Lors de tests internes face à un désobfuscateur automatisé standard, les méthodes aplaties avec l’algorithme switch ordinaire ont été reconstituées, alors que les mêmes méthodes aplaties avec chain sont restées intactes. Il émet de l’IL vérifiable, n’ajoute aucune dépendance à l’exécution, et ses performances restent à quelques pour cent de celles de l’aplatissement ordinaire.
• Le chiffrement des chaînes STREAM chiffre chaque chaîne séparément avec un algorithme de chiffrement authentifié, ne la déchiffre qu’à sa première utilisation et ne stocke jamais la clé en ligne. Des chaînes identiques donnent des octets chiffrés différents, l’ensemble des chaînes n’est à aucun moment présent en clair, et le déchiffreur entièrement managé se publie sans modification avec le découpage, NativeAOT et le mode FIPS.

Détecte le débogage et la falsification, sur les cibles de bureau et mobiles

Le code de protection contre le débogage injecté dans l’assembly détecte un débogueur attaché et arrête le processus ou appelle l’une de vos méthodes. La détection de falsification vérifie au démarrage que l’assembly est bien celui que Babel a produit : sur les cibles de bureau, elle calcule le hachage de l’image chargée en mémoire et le compare à un hachage inscrit lors de l’obfuscation.

Depuis la version 12.0, la détection de falsification couvre .NET MAUI, où la technique des cibles de bureau ne peut pas s’appliquer. Sur Android, l’application obfusquée compare le certificat avec lequel l’APK en cours d’exécution a été signé aux empreintes des signataires approuvés que vous épinglez lors de l’obfuscation, de sorte qu’une application reconditionnée ou signée de nouveau est rejetée. Sur iOS, elle vérifie son propre identifiant de bundle et son identifiant d’équipe Apple. Les deux contrôles examinent le paquet du système d’exploitation plutôt que l’image managée ; ils continuent donc de fonctionner avec le découpage et l’AOT complet. Dans tous les cas, vous choisissez la réaction : arrêter le processus, ou exécuter un gestionnaire personnalisé qui peut écrire dans un journal, dégrader des fonctionnalités ou avertir votre serveur.

Simplifie le déploiement en fusionnant et en incorporant les dépendances

La fusion et l’incorporation transforment une application et ses dépendances en un seul fichier. La fusion regroupe le code des assemblies référencés dans la cible et le renomme avec le vôtre : les types fusionnés peuvent ainsi être internalisés et obfusqués comme un tout, ce qui simplifie le déploiement et réduit la surface de code lisible. L’incorporation stocke un assembly entier, sous forme de ressource chiffrée chargée à l’exécution, pour les assemblies tiers ou à nom fort qui ne doivent pas être modifiés. Les deux peuvent être combinées dans un même projet.

Optimise le code et les métadonnées

Au-delà de la protection, Babel optimise l’assembly qu’il produit. La suppression du code mort élimine les méthodes, les champs, les propriétés et les types qui ne sont jamais utilisés. Les optimisations des métadonnées scellent automatiquement les classes et suppriment les attributs personnalisés inutiles, les types System.Enum ainsi que les constructions de propriétés et d’événements. Les optimisations du code appliquent l’expansion en ligne aux petites méthodes et propriétés et suppriment les champs const. Il en résulte un assembly plus petit sur le disque, plus rapide à charger et plus difficile à lire, car les métadonnées sur lesquelles s’appuie la rétro-ingénierie ont été réduites à ce dont le runtime a besoin.

Intégré à Visual Studio, à MSBuild, à NuGet et aux serveurs de build

Babel s’exécute pendant le build et non après. La tâche MSBuild Babel obfusque depuis Visual Studio et depuis tout serveur de build qui exécute MSBuild, et chaque propriété de la tâche est documentée par IntelliSense dans le fichier de projet. Le package NuGet Babel.Obfuscator ★Ultimate va plus loin pour les projets de style SDK : une seule référence de package place la tâche au bon moment du pipeline dotnet build et dotnet publish, avant que le découpage et la compilation AOT ne réécrivent l’assembly, seul ordre dans lequel ces modes de publication peuvent être protégés. Les exemples pour serveurs de build couvrent Azure DevOps, GitHub Actions, AppVeyor et App Center, et montrent comment exécuter des tests unitaires sur la sortie obfusquée ; comme le package NuGet, ils nécessitent l’édition Ultimate.

Disponible sous forme d’outil en ligne de commande, avec un mode adapté à l’IA

Tout ce que Babel sait faire est disponible depuis la ligne de commande, sous Windows, Linux et macOS. Depuis la version 11.7, l’outil propose aussi un mode adapté à l’IA pour les pipelines et les agents : --format=json ou --format=ndjson émettent un flux d’événements structuré et versionné sur stdout tandis que les diagnostics vont sur stderr, --quiet supprime la bannière et échoue immédiatement au lieu de poser une question, et --strict-exit active des codes de sortie sémantiques qui distinguent les arguments non valides, les entrées manquantes et les échecs d’obfuscation, de licence et de signature. La même option transforme --help en une description lisible par machine de toutes les options.

Piloté par les assistants IA au moyen de MCP

Babel Desktop peut héberger un serveur Model Context Protocol, de sorte qu’un assistant tel que Claude Code se connecte à l’application en cours d’exécution et la pilote : créer un projet, ajouter des assemblies, écrire des règles, choisir ce qu’il faut fusionner ou incorporer, obfusquer, lire les avertissements et les statistiques, décoder une trace de pile, créer un thème et faire une capture d’écran pour vérifier le résultat. Des outils couvrent les opérations que vous effectuez le plus souvent, auxquels s’ajoutent des outils pour les paramètres, Babel Licensing et les mises à jour de l’application. Avec les éditions Server et Data Center, le même serveur gère la base de données des licences : clients, produits, commandes, licences, clés de signature, génération et export des licences.

Le serveur est désactivé par défaut, n’écoute que sur l’adresse de boucle locale et peut exiger un jeton d’accès à chaque requête. Babel Licensing propose un serveur MCP distinct pour le Babel Licensing Service hébergé.

Décode les traces de pile obfusquées

Le renommage change les noms qui apparaissent dans les traces de pile des exceptions ; Babel produit donc un fichier de mappage XML pour chaque assembly obfusqué et fournit les outils qui permettent de retraduire une trace. Le Décodeur de pile de Babel Desktop et l’option de ligne de commande --stacktrace rétablissent les noms d’origine, avec la prise en charge facultative des fichiers PDB pour les numéros de ligne. Lorsque le proxy dynamique est activé, le décodeur nomme la méthode qui se trouve derrière chaque frame de pont de proxy et peut masquer entièrement les frames générées par Babel, ce qui donne une trace identique à celle que produirait l’application non obfusquée. Les fichiers de mappage servent aussi au renommage entre assemblies : une application et ses bibliothèques peuvent être obfusquées dans des builds distincts tout en s’accordant sur les symboles renommés.

Prêt pour FIPS

Les assemblies protégés avec Babel s’exécutent sur des hôtes en mode FIPS. Les fonctionnalités qui déchiffrent du contenu à l’exécution (chiffrement du code, chiffrement des chaînes, chiffrement des ressources et chiffrement des valeurs et des tableaux) peuvent être configurées pour utiliser un déchiffreur AES managé autonome : le runtime injecté ne dépend alors jamais du fournisseur cryptographique de la plateforme, et l’application démarre même dans un conteneur dépourvu du fournisseur FIPS d’OpenSSL. La page Conformité FIPS explique l’état de l’environnement en cause, le correctif appliqué lors de l’obfuscation et le correctif appliqué au niveau de l’environnement.

Extensible par des règles, des attributs et des plugins

Chaque fonctionnalité peut être ajustée symbole par symbole. Les règles XML sélectionnent des types et des membres par motif, attribut, visibilité ou héritage, puis activent, désactivent ou configurent une fonctionnalité pour eux ; les attributs personnalisés font de même depuis le code source. L’agent d’obfuscation analyse l’assembly avant l’obfuscation et génère les règles qui préservent le fonctionnement de la réflexion, de la sérialisation, de la liaison de données et du code dynamique. Pour aller plus loin, des plugins écrits en .NET peuvent ajouter des algorithmes de chiffrement des chaînes et des valeurs, des schémas de renommage personnalisés, des règles générées et des transformations de code, avec des exemples open source sur GitHub comme point de départ.