Outils d’analyse

Une analyse de sécurité ne peut pas se dispenser de tests intrusifs, visant à éprouver la sécurité d’une application en exploitant ses failles pour lever la protection, c’est à dire dans notre contexte parvenir à exhiber les algorithmes propriétaires d’un programme ou parvenir à contourner une fonction de contrôle des droits. Nous avons vu que l’analyse hybride statique-dynamique est probablement la méthode la plus efficace en pratique. L’analyse manuelle d’un programme protégé nécessite la maîtrise de plusieurs types d’outils spécialisés :

– instrumentation du contexte d’exécution, – analyse statique,

– analyse dynamique.

Instrumentation du contexte d’exécution

Concernant l’instrumentation du contexte d’exécution, de très nombreux outils sont disponibles. Les kits de dévelop- pement en proposent pour chaque plate-forme d’exécution (outils Windows Driver Devel Kit [BB97] par exemple). Les outils de diagnostic système peuvent également être utilisés (outils MS. SysInternals [RS05] par exemple).

7_{A titre d’exemple, les contraintes liées à l’implémentation de primitives cryptographiques dans un contexte boîte blanche ne sont}

pas prises en compte dans le référentiel documentaire de la DCSSI (règles et recommandations concernant la gestion des clés et le dimensionnement des primitives cryptographiques). Voirhttp ://www.ssi.gouv.fr/fr/sciences/publications.html.

En outre, certains outils d’analyse dynamique spécialisés proposent des mécanismes d’instrumentation furtive de l’environnement d’exécution [BH99, BKK06,Jos07b].

Analyse statique

De très nombreux outils d’analyse statique dédiés à la vérification ou à l’optimisation de programme ont été développés ces vingt dernières années, et peuvent potentiellement servir de support à la rétro-ingénierie. L’ambition de ce chapitre n’est pas de les présenter. Citons simplement une suite logicielle développée récemment et permettant d’éprouver par la pratique les quelques concepts que nous avons évoqués dans ce papier. Loco [MVD06a], est un outil permettant d’implémenter à la fois des transformations d’obfuscation et de désobfuscation. Il s’appuie sur l’outil Diablo [DVCD07], un éditeur de liens (édition statique de liens uniquement) particulier, permettant de réécrire un exécutableELFaprès avoir effectué des modifications sur son graphe PCG (link-time binary rewriting framework). Ces deux outils s’appuient sur une interface graphique appelée Lancet [VDM+05]. Nous pouvons également citer la suite logicielle SOLAR [SOL07], qui comprend des systèmes d’optimisation link-time pour trois architectures : ALTO (pour l’architecture Compaq Alpha), PLTO (pour l’architecture IA-32) et ILTO (pour l’architecture Intel/HP IA-64).

Analyse dynamique

Les outils d’analyse dynamique spécialisés pour la rétro-ingénierie logicielle sont plus rare. Certains débogueurs proposent des fonctionnalités intéressantes (script d’OllyDbg [Ope07] ou d’IDAPro [Dat07], par exemple), mais imposent à l’attaquant de laborieux efforts pour surmonter certaines protections logicielles. Les outils les plus efficaces pour récupérer de l’information sur un exécutable sans être détecté (et parfois lever automatiquement les premières protections) sont probablement les machines virtuelles spécialisées. Les outils CWSandbox [WHF07], Norman SandBox [Nor07], TTAnalyze [Bay05], Cobra [VY06] et VxStripper [Jos07b] permettent de charger un exécutable dans une machine virtuelle et de l’analyser automatiquement.

L’outil d’analyse VxStripper permet en outre de supprimer automatiquement le loader de protection mis en place par la pluspart des packers du marché et de défaire automatiquement certaines transformations d’obfuscation. Il propose également des fonctionnalités avancées d’instrumentation du contexte d’exécution et d’analyse forensique du système d’exploitation, permettant de surveiller les interactions du programme cible avec celui-ci.

3.5

Conclusion

Nous avons présenté dans ce chapitre les caractéristiques, en terme d’architecture, des solutions de protection logi- cielle du marché civil et décrit les mécanismes fondamentaux qu’elles implémentent.

Nous avons présenté les problèmes théoriques et pratiques rencontrés lors d’une tentative de lever la protection d’une application, ainsi que les principales méthodes d’analyse pouvant être mises en oeuvre par un attaquant. Nous avons proposé une démarche et des outils permettant de mener à bien une analyse de robustesse des méca- nismes, sur la base de critères théoriques et empiriques. Une telle approche peut être utilisée par un évaluateur, pour mesurer le niveau de confiance qu’il peut porter à une solution ; par le concepteur de solution, afin d’en amé- liorer l’efficacité ; ou par l’utilisateur, afin d’intégrer une ou plusieurs solutions et éventuellement développer des protections supplémentaires.

Nous avons observé lors de cette introduction (aux aspects techniques et théoriques liés à la protection et à la rétro-ingénierie logicielle au regard de la théorie de la complexité et de l’optimisation des programmes) que les cri- tères et preuves de sécurité des mécanismes de protection semblent mal adaptés à la mesure de résistance face à une attaque approximative, dynamique ou hybride statique/dynamique. Nous avons observé en outre que si l’analyse statique et dynamique sont clairement duales, elle apparaissent souvent complémentaires. L’utilisation conjointe de méthodes statiques et de méthodes dynamique donne de meilleurs résultats que l’utilisation seule d’une des deux approches.

Nous avons en outre remarqué que les méthodes existantes d’analyse statique et dynamiques présentent souvent une approche technique similaire. Il semble même qu’elles se heurtent souvent aux même limitations. Nous avons en particulier vu l’importance des modèles de contrôle de flot et de données d’un programme en analyse dynamique. Ces modèles ont d’abord été conçus pour l’analyse statique des programmes et correspondent à un important savoir

faire hérité des travaux portants sur l’optimisation et la vérification statique de programme. Ce savoir-faire se révèle fort utile dans le cadre d’une activité visant à augmenter la lisibilité d’un programme, comme c’est le cas pour la rétro-ingénierie. Les difficultés technique et les limites théoriques rencontrées servent de base dans la construction de programme difficile à comprendre ou à rétro-analyser, et sont donc des fondamentaux de la protection logicielle.

Les méthodes d’analyse statiques et dynamiques font encore aujourd’hui l’objet de travaux de recherches sépa- rés. Dans le cadre de la rétro-ingénierie, cette séparation paraît artificielle et à certains égards contre-productive. Il apparaît nécessaire de supprimer la frontière entre ces deux spécialités et de concevoir des méthodes d’analyse unifiées qui puissent soit opérer dans les deux modes, soit opérer dans un mode qui tire partie au mieux des deux approches.

Nous présentons dans le chapitre suivant un des modèles fondamentaux de l’analyse statique, celui de l’interpréta- tion abstraite. Ce modèle permet de formaliser la plupart des méthodes d’analyse statique comme une abstraction de l’ensemble des exécutions possibles d’un programme. Remarquons que ce qui réunit le plus l’analyse statique et l’analyse dynamique est que dans les deux cas, elles proposent un modèle de l’ensemble des chemins d’exécution d’un programme, qui leurs est propre et supporte une classe spécifique de questionnements et de raisonnement. Toutes ces techniques présentent une abstraction du programme sous la forme d’un modèle comportant généralement un nombre fini d’états.

Nous proposons dans le cadre formel de l’interprétation abstraite une formalisation de la rétro-ingénierie comme approximation discrète des sémantiques concrètes d’un programme. L’objectif est de poser les premières bases d’une reflexion permettant de définir des critères objectifs permettant de qualifier les transformations de désobfuscation dans le contexte de l’analyse statique et de l’étendre au cas de l’analyse dynamique.