Tâche MSBuild

La tâche MSBuild Babel est disponible avec toutes les éditions de licence de Babel Obfuscator et peut être ajoutée à tout projet MSBuild en insérant l’élément UsingTask approprié dans le fichier XML du projet MSBuild :

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

L’attribut AssemblyName désigne le nom complet du composant .NET Babel.Build.dll installé dans le Global Assembly Cache.

La propriété Version d’AssemblyName doit correspondre à la version du produit actuellement installée. Par exemple, si vous avez installé la version x.y.z.w :

Version=x.y.z.0

Le numéro de révision w doit toujours être 0.

Si vous ne souhaitez pas utiliser le nom complet de l’assembly, vous pouvez référencer le composant Babel.Build.dll par son chemin complet, comme suit :

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

Une fois l’assembly Babel.Build référencé, vous pouvez utiliser la tâche Babel pour lancer Babel Obfuscator sur un assembly cible donné :

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

La tâche Babel définie ci-dessus s’exécute après le build pour obfusquer l’assembly cible, qu’elle remplace par l’assembly obfusqué produit par Babel.

La cible « AfterBuild » est une cible MSBuild  bien connue, définie dans le pipeline de build. Elle sert en général à ajouter des tâches exécutées une fois le build terminé, lorsque tous les binaires se trouvent dans le dossier de sortie du build défini par la variable MSBuild  $(TargetPath).

Par exemple, la tâche Babel présentée plus haut s’exécute après le build pour obfusquer l’assembly cible désigné par la variable $(TargetPath) et le remplace par la version obfusquée produite par Babel.

Cibles AfterBuild et Compile

Les SDK .NET récents ont introduit des tâches d’optimisation supplémentaires, qui interviennent avant la tâche « AfterBuild » et après l’étape de compilation, laquelle a lieu pendant la tâche « Compile ». La tâche « Compile » se distingue de « AfterBuild », qui n’est qu’un emplacement réservé dans le pipeline de build, destiné à être redéfini par des processus de build externes. La tâche « Compile » est l’étape où la compilation a réellement lieu, et elle ne peut pas être remplacée par des tâches définies par l’utilisateur.

Comme l’obfuscation doit avoir lieu après la tâche « Compile » et avant toute optimisation ultérieure effectuée par le système de build, la tâche d’obfuscation Babel doit être insérée immédiatement après l’étape « Compile ». Vous pouvez le faire avec l’attribut de cible MSBuild AfterTargets, comme ci-dessous :

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

Cette configuration garantit que l’obfuscation s’applique à la sortie compilée avant toute autre optimisation du build.

Notez que les propriétés InputFile et OutputFile ne sont pas réglées sur TargetPath, car à ce stade du build l’assembly compilé n’a pas encore été copié à l’emplacement TargetPath. Il se trouve dans un dossier de build intermédiaire, $(IntermediateOutputPath), qui sert de source à toutes les étapes suivantes du build.

Ce dossier intermédiaire contient l’assembly et les autres artefacts produits pendant la phase de compilation, ce qui permet à différentes tâches, dont l’obfuscation, de s’appliquer à la sortie compilée avant la fin du build. En indiquant le chemin intermédiaire, vous faites en sorte que l’obfuscation s’applique à la bonne version de l’assembly, telle qu’elle existe avant toute copie ou tout traitement supplémentaire susceptible de modifier la sortie du build.

Cette approche simplifie le processus de build et garantit que la sortie obfusquée est correctement générée et prête pour les tâches d’optimisation ou les étapes de déploiement qui suivent.

Configurer la tâche Babel

La tâche Babel offre de nombreuses propriétés qui permettent d’adapter l’obfuscation à vos besoins. La liste complète de ces propriétés figure dans la section Référence de la tâche Babel de la documentation. Par défaut, la tâche Babel n’active que le renommage des symboles, qui modifie les noms des classes, des méthodes et des autres symboles du code pour rendre la rétro-ingénierie plus difficile.

Les fonctionnalités d’obfuscation plus avancées, telles que l’obfuscation du flux de contrôle, le chiffrement des chaînes et d’autres techniques élaborées, nécessitent une licence valide. Sans licence valide, la tâche Babel fonctionne en mode d’évaluation, limité au renommage des symboles. En outre, les assemblies obfusqués en mode d’évaluation cessent de fonctionner après une date donnée, comme l’indique le code d’avertissement W00000 dans le journal du build. Par exemple :

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

L’obtention et l’installation d’une licence valide donnent accès à toutes les fonctionnalités d’obfuscation de Babel et lèvent toutes les limites : les assemblies obfusqués s’exécutent alors sans date d’expiration.

<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>

Votre application bénéficie ainsi d’une protection complète, qui préserve votre propriété intellectuelle et votre code source contre les accès non autorisés et la falsification.

Performances du build dans Visual Studio avec les analyseurs de code

Dans Visual Studio, les analyseurs de code sont étroitement intégrés au flux de travail de développement. Ils s’exécutent en permanence en arrière-plan pour fournir un retour en temps réel dans l’éditeur de Visual Studio et signalent les problèmes potentiels au fil de la saisie. Cette fonctionnalité implique toutefois un compromis : elle déclenche le processus de build à chaque itération, ce qui peut créer des goulets d’étranglement, en particulier si des tâches comme l’obfuscation Babel font partie du build.

Pour éviter ce surcoût inutile, vous pouvez modifier votre configuration MSBuild afin que la tâche d’obfuscation Babel ne s’exécute que pendant le build complet (c’est-à-dire lorsque vous générez réellement la solution) et non pendant les builds au moment de la conception que les analyseurs lancent en arrière-plan. Voici comment procéder :

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

En ajoutant Condition=”’$(DesignTimeBuild)’ != ‘true’”, vous faites en sorte que la cible Obfuscate soit ignorée pendant les builds au moment de la conception (les processus d’arrière-plan qu’utilisent les analyseurs de code). Cette modification réduit nettement le temps processeur consommé pendant les sessions de codage habituelles, sans incidence sur votre build final. L’obfuscation s’exécute toujours quand elle est nécessaire, c’est-à-dire pendant le build réel du projet.

Tâche Babel et package NuGet Babel Obfuscator

Le package NuGet Babel Obfuscator, disponible avec l’édition Ultimate, simplifie l’intégration de la tâche Babel dans le pipeline de build. Une fois le package référencé dans un projet .NET, il insère automatiquement la tâche Babel au bon endroit du processus de build, sans configuration manuelle. Les développeurs n’ont donc pas à ajouter explicitement la directive Using de la tâche Babel ni à insérer la tâche Babel à la main dans le script de build.

Le package détermine l’emplacement de la tâche Babel d’après le type de projet et la version du SDK .NET utilisée. Cette automatisation garantit que l’obfuscation a lieu au meilleur moment du pipeline de build, quelles que soient les configurations de build et les exigences propres aux différents types de projet. Cette intégration réduit le risque d’erreur et permet aux développeurs d’appliquer l’obfuscation sans connaître en détail les subtilités du pipeline de build.

Principaux avantages du package NuGet Babel Obfuscator

1. Gestion automatique : le package NuGet Babel Obfuscator gère l’obfuscation pendant le processus de build et veille à ce qu’elle ne s’exécute que pendant les builds complets, et non pendant les builds au moment de la conception utilisés par les analyseurs.

2. Charge processeur réduite : en ignorant automatiquement l’étape d’obfuscation pendant les builds d’arrière-plan, le package préserve les performances du système, évite une charge processeur inutile et laisse Visual Studio fonctionner plus fluidement pendant le développement.

3. Configuration simplifiée : vous n’avez pas à modifier vos scripts MSBuild à la main. Le package s’intègre à votre projet et s’occupe de tout en arrière-plan, ce qui fait gagner du temps et réduit la complexité.

4. Résultats cohérents : l’obfuscation ne s’applique systématiquement qu’aux dernières étapes du build, de sorte que votre code est protégé sans gêner le développement au quotidien.

En outre, le package NuGet Babel Obfuscator assure la cohérence entre les projets : toutes les étapes nécessaires à l’obfuscation sont correctement mises en œuvre, quelles que soient la complexité du projet et la connaissance qu’a l’équipe du processus. Cet avantage est particulièrement utile dans les projets ou les équipes de grande taille, où il peut être difficile de maintenir des processus de build uniformes.