Outil Babel Obfuscator ★Ultimate

Contenu du package

Babel.Obfuscator.Tool est un package d’outil .NET  qui installe la commande babel. Il s’agit du même outil en ligne de commande que celui des archives zip babel_net*, avec les mêmes options, et il est fourni avec l’édition Ultimate et avec les éditions de site de Babel Licensing (Server et Data Center). Le package contient un build de l’outil pour chaque runtime pris en charge, de .NET 6.0 à .NET 10.0, et le CLI dotnet choisit le build qui correspond au SDK de la machine. Chaque build contient :

• babel.dll, l’outil en ligne de commande, avec sa configuration de runtime.
• Le plugin BabelEncrypt, prêt à être chargé avec --plugin.
• Babel.Build.dll, l’assembly de la tâche MSBuild Babel, pour les scripts de build qui référencent la tâche Babel par un chemin de fichier.

Comme Babel.Obfuscator, le package de l’outil n’est pas publié sur nuget.org : hébergez-le sur votre propre flux, comme décrit dans Héberger le package.

Quand utiliser l’outil

Utilisez l’outil lorsque vous voulez exécuter Babel vous-même plutôt que comme étape d’un build MSBuild :

• Obfuscation d’assemblies déjà générés, par exemple des binaires .NET Framework produits par un autre système de build.
• Obfuscation par script ou par lots de nombreux assemblies, et automatisation pilotée par des agents grâce au mode adapté à l’IA.
• Exécution de l’outil en ligne de commande sur des machines et des agents de build Linux et macOS.
• Commandes utilitaires, comme le décodage d’une trace de pile (--stacktrace), la vérification de la licence (--license) ou la génération d’un projet MSBuild à partir d’une ligne de commande (--makeproject).

Installer l’outil

Outil global

Un outil global s’installe une fois par utilisateur et est disponible depuis tous les terminaux :

dotnet tool install Babel.Obfuscator.Tool -g

Si le flux ne figure pas dans un fichier NuGet.config, indiquez-le explicitement. La source peut être l’URL d’un flux ou un dossier local :

dotnet tool install Babel.Obfuscator.Tool -g --add-source ~/NuGet

Sous Linux et macOS, vérifiez que le dossier des outils figure dans le chemin de recherche, sinon la commande babel est introuvable :

export PATH="$PATH:$HOME/.dotnet/tools"

Outil local

Un outil local est épinglé à un dépôt au moyen d’un manifeste d’outils, de sorte que chaque développeur et chaque agent de CI exécutent la même version de Babel :

dotnet new tool-manifest
dotnet tool install Babel.Obfuscator.Tool

L’outil est ainsi inscrit dans .config/dotnet-tools.json, fichier que vous validez dans le dépôt. Sur toute autre machine, dotnet tool restore installe la version épinglée. Un outil local s’appelle par l’intermédiaire du CLI dotnet :

dotnet babel --version

Mettre à jour et désinstaller

dotnet tool update Babel.Obfuscator.Tool -g
dotnet tool list -g
dotnet tool uninstall Babel.Obfuscator.Tool -g

Omettez -g pour un outil local. Les mêmes commandes sont décrites dans Installation.

Fournir la licence à l’outil

L’outil nécessite la même licence que le produit. Comme un outil dotnet n’a pas de dossier d’installation où copier babel.licenses, fournissez la licence à Babel de l’une des façons suivantes :

• Réglez la variable d’environnement BABEL_LICENSE_PATH sur le chemin complet du fichier de licence. C’est la configuration recommandée sur les machines de développement et les agents de build :

export BABEL_LICENSE_PATH=~/Babel/babel.licenses

• Passez --license à chaque appel, avec le chemin du fichier de licence ou d’un dossier où le rechercher.
• Passez --license env:BABEL_LICENSE, où la variable contient une clé de licence : c’est le bon choix sur les serveurs de build, où la clé est conservée dans un secret. Pour une licence flottante, enregistrez la clé utilisateur sous la forme floating:<user key>.

babel --license sans argument affiche la licence utilisée. N’oubliez pas qu’un fichier de licence est valable pour une seule version du produit : utilisez le fichier fourni avec la même version que l’outil, et mettez les deux à jour ensemble.

Utiliser l’outil

La commande babel accepte la syntaxe et les options décrites dans Ligne de commande et dans la Référence de la ligne de commande. Un appel type indique l’assembly à obfusquer, le fichier de sortie et les fonctionnalités à activer :

babel MyApp.dll --output obfuscated/MyApp.dll --stringencryption stream --controlflow if=on --controlflow switch=on --iterations 3 --resourceencryption --rules babelRules.xml --mapout

Toutes les fonctionnalités décrites dans ce manuel sont disponibles depuis l’outil : les règles avec --rules, la fusion et l’incorporation avec des arguments d’assembly supplémentaires et --embed, les fichiers de mappage avec --mapin et --mapout, les plugins avec --plugin, et le déchiffreur AES managé avec --use encryption=aesmanaged. Avec un outil local, faites précéder la commande de dotnet.

Scripts et automatisation

Depuis la version 11.7, la ligne de commande dispose d’un mode adapté à l’IA conçu pour les scripts et les agents :

babel MyApp.dll --stringencryption stream --format ndjson --quiet --strict-exit

--format json ou ndjson transforme la sortie en flux lisible par machine et dirige les diagnostics destinés aux personnes vers la sortie d’erreur standard, --quiet supprime la bannière et fait échouer immédiatement toute invite interactive, et --strict-exit renvoie un code de sortie distinct pour les arguments non valides, l’entrée manquante et les échecs d’obfuscation, de licence et de signature.

Exécuter l’outil sur un serveur de build

L’outil convient aux pipelines qui obfusquent les artefacts de build dans une étape distincte. Avec un manifeste d’outils validé dans le dépôt et le flux configuré dans NuGet.config (voir l’exemple GitHub Actions pour une configuration qui s’authentifie auprès de GitHub Packages), un travail (job) GitHub Actions se présente ainsi :

steps:
  - uses: actions/checkout@v4
  - uses: actions/setup-dotnet@v4
    with:
      dotnet-version: '10.0.x'
  - name: Restore tools
    run: dotnet tool restore
    env:
      PACKAGES_TOKEN: ${{ secrets.PACKAGES_TOKEN }}
  - name: Obfuscate
    run: dotnet babel artifacts/MyLib.dll --license env:BABEL_LICENSE --stringencryption stream --strict-exit
    env:
      BABEL_LICENSE: ${{ secrets.BABEL_LICENSE_SECRET }}

Hôtes en mode FIPS

Depuis la version 11.8, les binaires de l’outil sont eux-mêmes obfusqués avec l’algorithme AES managé, si bien que babel démarre sur les hôtes dont le fournisseur FIPS d’OpenSSL est défaillant. Les assemblies que vous protégez sur ces hôtes ont tout de même besoin de leur propre déchiffreur managé : utilisez l’algorithme STREAM pour le chiffrement des chaînes et --use encryption=aesmanaged pour les autres fonctionnalités de chiffrement, comme expliqué dans Conformité FIPS.

Dépannage

• babel: command not found : le dossier des outils globaux ne figure pas dans le chemin de recherche ; ajoutez ~/.dotnet/tools à PATH, ou utilisez un outil local et exécutez dotnet babel.
• Un message demandant d’installer .NET : le build sélectionné de l’outil nécessite le runtime .NET correspondant, de 6.0 à 10.0. Installez ce runtime, ou définissez DOTNET_ROLL_FORWARD=Major pour exécuter l’outil sur un runtime plus récent.
• A valid license could not be found : vérifiez BABEL_LICENSE_PATH ou l’argument --license, puis exécutez babel --license pour voir ce que Babel a chargé. Un fichier de licence prévu pour une autre version est signalé comme non valide.
• Le résultat diffère de celui d’une exécution dans Babel Desktop : Babel Desktop applique les paramètres enregistrés dans son projet .babel, alors que l’outil n’applique que les options de la ligne de commande. Comparez les deux configurations, en particulier l’agent d’obfuscation et les règles.