Obfuscation, surveillance et gestion des applications

Cette page explore les fonctionnalités d'obfuscation et Analytics-Community Edition, un outil de durcissement post-construction gratuit fourni avec Visual Studio 2017. Comprendre comment l'obscurcissement peut être utilisé pour empêcher la décompilation facile de vos assemblys. Utilisation de la protection contre les falsifications pour protéger vos assemblys d'application contre les modifications non autorisées.

Le désassembleur IL (IL Disassembler)

Avant de voir comment vous pouvez protéger votre code des autres et surveiller son comportement «dans la nature», il est important de réfléchir à la manière dont vous pouvez créer de meilleures applications en premier lieu. Un outil utile pour cela est le désassembleur Microsoft .NET Framework IL Disassembler, ou ILDasm. Vous pouvez exécuter ILDasm en lançant le prompt de commande Developer. Si vous exécutez Windows 8 ou Windows 10, entrez le prompt de commande dans la zone de texte Rechercher (pour Windows 8, vous devez utiliser l'icône Rechercher pour afficher la zone de texte). Dans Windows 7, vous pouvez trouver le prompt de commande du développeur dans Tous les programmes de Microsoft Visual Studio 2017 Visual Studio Tools, Invite de commande Visual Studio. Une fois le prompt de commande en cours d'exécution, entrez ILDasm pour lancer le désassembleur.

Décompilateurs

L'un des décompilateurs les plus utilisés est JustDecompile de Telerik (disponible en téléchargement sur https://www.telerik.com/products/decompiler.aspx). JustDecompile peut être utilisé pour décompiler n'importe quel assembly .NET en C# ou Visual Basic .NET.

Lors de l'utilisation de JustDecompile, vous remarquerez peut-être que certains des assemblys de bibliothèque de classes de base cadre d'application .NET sont répertoriés, tels que System, System.Data et System.Web. Étant donné que l'obscurcissement n'a pas été appliqué à ces assemblys, ils peuvent être décompilés tout aussi facilement à l'aide de JustDecompile. Cependant, Microsoft a déplacé de grandes parties du .NET Framework réel (un sous-ensemble connu sous le nom de CoreCLR) vers l'open source, ce qui signifie que vous pouvez parcourir le code source d'origine de ces assemblages, y compris les commentaires en ligne.

Si la génération du nombre magique était un véritable secret dont dépendait votre organisation pour gagner de l'argent, la possibilité de décompiler cette application poserait un risque important. Cette fonctionnalité doit affecter non seulement la manière dont vous livrez votre code, mais également la manière dont vous pouvez concevoir votre application. L'obscurcissement, abordé dans la section suivante, est une approche possible pour atténuer (mais pas complètement éliminer) ce risque.

Obscurcissement de votre code

Jusqu'à présent, cette page a mis en évidence la nécessité d'une meilleure protection de la logique intégrée dans vos applications. L'obscurcissement est l'art de renommer les symboles et de modifier les chemins de code dans un assemblage afin que la logique soit inintelligible et ne puisse pas être facilement comprise si elle est décompilée. De nombreux produits peuvent obscurcir votre code, chacun utilisant ses propres astuces pour rendre la sortie moins susceptible d'être comprise. Le Visual Studio 2017 est livré avec l'édition communautaire de Dotfuscator et Analytics de PreEmptive Solutions, que cette page utilise comme exemple de la façon dont vous pouvez appliquer l'obscurcissement à votre code.

L'obscurcissement n'empêche pas la décompilation de votre code; cela rend simplement plus difficile pour un programmeur de comprendre le code source s'il est décompilé. L'utilisation de l'obfuscation a également des conséquences devant être prises en compte si vous devez utiliser la réflexion ou donner un nom fort à votre application.

Dotfuscator et Analytics

Bien que Dotfuscator puisse être lancé à partir du menu Outils de Visual Studio 2017, il s'agit d'un produit distinct avec sa propre licence. L'édition communautaire (CE) ne contient qu'un sous-ensemble des fonctionnalités de l'édition commerciale du produit, la suite Dotfuscator. Si vous envisagez sérieusement d'essayer de masquer les fonctionnalités intégrées à votre application, vous devriez envisager une mise à niveau. Vous pouvez trouver plus d'informations sur la version commerciale de Dotfuscator sur https://www.preemptive.com/products/dotfuscator/compare-dotfuscator-editions/.

Dotfuscator CE utilise son propre format de projet pour garder une trace des assemblys que vous obscurcissez et des options que vous spécifiez. Après avoir démarré Dotfuscator à partir du menu Outils, il s'ouvre avec un nouveau projet non enregistré. Sélectionnez le noeud Inputs dans l'arborescence de navigation, puis cliquez sur le bouton avec le signe plus sous la liste Inputs pour ajouter les assemblys .NET que vous souhaitez masquer.

Mots de prudence

Dans quelques endroits, il convient de considérer ce qui peut se produire lorsque l'obscurcissement - ou plus précisément, le changement de nom - se produit, et comment cela peut affecter le fonctionnement de l'application.

Réflexion

Le cadre d'application .NET fournit un modèle de réflexion riche grâce auquel les types peuvent être interrogés et instanciés dynamiquement. Malheureusement, certaines des méthodes de réflexion utilisent des recherches de chaîne de caractères pour les noms de type et de membre. De toute évidence, l'utilisation de l'obfuscation de renommage empêche ces recherches de fonctionner, et la seule solution est de ne pas mutiler les symboles pouvant être invoqués à l'aide de la réflexion. Notez que l'obscurcissement du flux de contrôle n'a pas cet effet secondaire indésirable particulier. La fonction d'obfuscation intelligente de Dotfuscator tente de déterminer automatiquement un ensemble limité de symboles à exclure en fonction de la façon dont l'application utilise la réflexion. Par exemple, supposons que vous utilisiez les noms de champ d'un type enum. L'obscurcissement intelligent peut détecter l'appel de réflexion utilisé pour récupérer le nom de champ de l'énumération, puis exclure automatiquement les champs d'énumération du changement de nom.

Assembly avec nom fort

L'un des objectifs derrière l'attribution d'un nom fort à un assembly est d'empêcher que l'assembly ne soit falsifié. Malheureusement, l'obscurcissement repose sur la prise d'un assembly existant et la modification des noms et du flux de code avant de générer un nouvel assembly. Cela signifierait que l'assembly n'a plus de nom fort valide. Pour permettre à l'obscurcissement de se produire, vous devez retarder la signature de votre assembly en cochant la case Différer la signature uniquement (Delay Sign Only) dans l'onglet Signature de la fenêtre Propriétés du projet, comme illustré dans l'image suivante :

Après avoir construit l'assembly, vous pouvez l'obscurcir de la manière habituelle. La seule différence est qu'après l'obscurcissement, vous devez signer l'assembly obscurci, ce que vous pouvez faire manuellement à l'aide de l'utilitaire Strong Name, comme illustré dans cet exemple en ligne de commande :

L'utilitaire Strong Name n'est pas inclus dans le chemin par défaut, vous devez donc l'exécuter à partir d'une prompt de commande Visual Studio (Démarrer tous les programmes Microsoft Visual Studio 2017 Visual Studio Tools) ou entrer le chemin complet vers sn.exe.

Débogage avec signature différée

Comme affiché dans la fenêtre Propriétés du projet, cocher la case Différer la signature uniquement empêche l'exécution ou le débogage de l'application. En effet, l'assembly échouera au processus de vérification du nom fort. Pour activer le débogage d'une application avec signature différée, vous pouvez enregistrer les assemblys appropriés pour ignorer la vérification. Cette opération est également effectuée à l'aide de l'utilitaire Strong Name. Par exemple, le code suivant ignore la vérification pour l'application ObfuscationSample.exe :

De même, les éléments suivants réactivent la vérification pour cette application :

C'est pénible pour vous à chaque fois que vous construisez une application, vous pouvez donc ajouter les lignes suivantes aux événements post-build de l'application :

En fonction de votre environnement, vous devrez peut-être modifier l'événement post-build pour vous assurer que le chemin d'accès correct à sn.exe est spécifié.

La première ligne ignore la vérification pour l'application compilée. Cependant, Visual Studio utilise un fichier vshost supplémentaire pour amorcer l'application lorsqu'elle s'exécute. Cela doit également être enregistré pour ignorer la vérification lors du lancement d'une session de débogage.

Surveillance et gestion des applications

La version de Dotfuscator fournie avec Visual Studio 2017 dispose de nombreuses fonctionnalités pour ajouter des fonctionnalités de surveillance et de gestion de l'exécution à vos applications. Comme pour l'obscurcissement, ces fonctionnalités sont injectées dans votre application en tant qu'étape post-build, ce qui signifie que vous n'avez généralement pas besoin de modifier votre code source de quelque manière que ce soit pour en tirer parti.

Les fonctionnalités de surveillance et de gestion des applications incluent :

• Tamper Defense : Quitte votre application et vous avertit éventuellement si elle a été modifiée de manière non autorisée.
• Application Expiry : configurez une date d'expiration pour votre application, après laquelle elle ne fonctionnera plus.
• Application Usage Tracking : instrumentez votre code pour suivre l'utilisation, y compris les fonctionnalités spécifiques de votre application.

Bien que vous puissiez utiliser la case à cocher Honor Instrumentation Attributes pour activer et désactiver l'injection du code d'instrumentation, le comportement par défaut consiste à activer l'instrumentation. La spécification de la fonctionnalité à injecter dans votre application s'effectue en ajoutant des attributs Dotfuscator, soit en tant qu'attribut personnalisé dans votre code source, soit via l'interface utilisateur Dotfuscator.

Tamper Defense

La Tamper Defense vous permet de détecter si vos applications ont été modifiées de manière non autorisée. Alors que l'obscurcissement est un contrôle préventif conçu pour réduire les risques liés à une rétro-ingénierie non autorisée, la protection anti-fraude est un contrôle de détection conçu pour réduire les risques liés à une modification non autorisée de vos assemblages gérés. L'appariement des contrôles préventifs et de détection est un modèle de gestion des risques largement accepté, par exemple, la prévention et la détection des incidents.

La défense contre les falsifications est appliquée méthode par méthode et la détection des falsifications est effectuée au moment de l'exécution lorsqu'une méthode protégée est appelée.

Pour ajouter Tamper Defense à votre application, sélectionnez le noeud Analytics sous la partie options de configuration du menu de navigation, puis sélectionnez l'onglet Attributs. Vous voyez une arborescence contenant les assemblys que vous avez ajoutés au projet Dotfuscator avec une hiérarchie des classes et des méthodes que chaque assembly contient. Accédez à la fonction HiddenGenius.GenerateMagicNumber, cliquez dessus avec le bouton droit de la souris et sélectionnez Ajouter un attribut. Ceci affiche la liste des attributs Dotfuscator disponibles, comme illustré dans l'image suivante :

Sélectionnez l'attribut InsertTamperCheckAttribute, puis cliquez sur OK. L'attribut est ajouté à la méthode sélectionnée. Vous pouvez maintenant créer le projet Dotfuscator pour injecter la fonctionnalité de défense contre les manipulations dans votre application.

Pour vous aider à tester la fonctionnalité de défense anti-fraude, Dotfuscator est livré avec un utilitaire simple simulant la falsification d'un assemblage. Appelé TamperTester, vous pouvez trouver cet utilitaire dans le même répertoire dans lequel Dotfuscator est installé (par défaut dans C:\Program Files\Microsoft Visual Studio 15.0\PreEmptive Solutions\Dotfuscator and Analytics Community Edition). Cela doit être exécuté à partir de la ligne de commande avec le nom de l'assembly et le dossier de sortie comme paramètres :

Assurez-vous d'exécuter l'utilitaire TamperTester sur les assemblys ayant été générés par Dotfuscator et non sur les assemblys d'origine créés par Visual Studio.

Par défaut, votre application se ferme immédiatement si la méthode a été falsifiée. Vous pouvez éventuellement configurer Dotfuscator pour générer un message d'avertissement vers un point de terminaison de votre choix. L'édition commerciale de Dotfuscator comprend deux extensions principales de la version CE ; il vous permet d'ajouter un gestionnaire personnalisé à exécuter lorsqu'une falsification est détectée, prenant en charge une défense anti-sabotage personnalisée en temps réel au lieu du comportement de sortie par défaut ; et PreEmptive Solutions propose un service d'avertissement acceptant les alertes de sabotage et avertissant automatiquement votre organisation en cas de réponse à un incident.

Instrumentation et analyse des applications

En tant que développeur, l'objectif est de créer une ap0plication répondant aux besoins de vos utilisateurs tout en réduisant les problèmes pouvant être rencontrés. Pour atteindre cet objectif, il est important de pouvoir comprendre ce que vos utilisateurs vivent, à la fois en bien et en mal, dans votre application. C'est là que l'analyse entre en jeu. Les analyses sont capables de fournir une vue complète de votre application. Cela inclut non seulement les exceptions ou autres comportements inattendus, mais également les parties de l'application étant utilisées.

Pour que les analyses soient utiles, il doit y avoir un mécanisme pour les capturer et en faire rapport. Dans le cadre de la plateforme Azure, Microsoft fournit la plateforme Application Insights. Application Insights n'est pas nouveau ; il faisait partie de Visual Studio Online. Il a maintenant été intégré à Azure et est disponible via le portail Azure.

Pour que votre application participe, vous devez instrumenter votre application de manière appropriée. Heureusement, Visual Studio 2017 inclut quelques outils pour faciliter cela.

Selon le type de projet que vous avez créé, le SDK Application Insights est automatiquement inclus dans votre liste de références. Pour les projets existants (et, en général, Application Insights est prévu pour être utilisé avec des applications Web ou UWP), vous pouvez ajouter le SDK Application Insights en sélectionnant Ajouter Application Insights dans le menu contextuel du projet à partir de l'Explorateur de solutions (Solution Explorer) :

Une fois que vous vous êtes connecté à votre abonnement Azure, deux options supplémentaires s'offrent à vous. Si votre compte est associé à plusieurs abonnements Azure, sélectionnez l'abonnement que vous souhaitez utiliser pour ce projet. Vous pouvez également spécifier la ressource à laquelle la télémétrie Application Insights doit être envoyée. Si vous créez une nouvelle ressource, cliquez sur le lien Configurer les paramètres pour afficher la boîte de dialogue apparaissant dans l'image suivante :

Grâce à cela, vous pouvez spécifier le groupe de ressources (correspondant à la région dans laquelle la télémétrie sera collectée), le nom de la ressource et la région dans laquelle le service sera hébergé.

Si vous regardez la différence que l'ajout d'Application Insights à votre projet a faite, vous constaterez que ce n'est pas significatif. Il existe un fichier de configuration (appelé ApplicationInsights.config) contenant des informations sur les modules de télémétrie et les classes utilisées pour générer les données. Il inclut également la clef secrète utilisée pour communiquer avec votre compte Azure.

Le deuxième ajout dépend du type d'application que vous avez créé. Dans l'exemple, il s'agissait d'une application Web ASP.NET MVC. Pour permettre l'envoi de la télémétrie, un petit script JavaScript est ajouté au fichier _Layout.cshml. Ce script instancie un objet appInsights et appelle la méthode tracePageView. Cela envoie un événement de vue de page à la ressource Application Insights.

Pour différents types d'applications, le mécanisme d'envoi des détails de télémétrie changera. Le fichier ApplicationInsights.config est cohérent dans les différents projets. Cependant, alors que les applications Web ASP.NET ont un emplacement évident pour placer l'appel tracePageView, ce n'est pas le cas avec une application de plate-forme Windows universelle. Au lieu de cela, ces applications créent une propriété nommée TelemetryClient au niveau Application. Ensuite, vous pouvez instrumenter votre application avec des appels à TrackPageView, TrackEvent ou à d'autres méthodes pour pousser différentes métriques de votre application vers la ressource Application Insights.