Analyse boîte blanche du moteur de détection

La conception d’un moteur de détection comprend plusieurs parties, qui peuvent être qualifiées sur la base de ces critères théoriques :

ALGORITHME CRITERE

Unpacking Critères cryptographiques WBAC : diversité et ambiguïté. Cryptanalyse d’une génération environnementale de clé. Complétude de l’analyse dynamique. Représentation intermédiaire Correction de l’analyse statique, Complétude de l’analyse dynamique. Réécriture Confluence, terminaison d’une stratégie de réécriture

Schéma de détection Simulabilité, rigidité, correction, complétude

Remarquons que ces parties ne sont pas toutes nécessairement présentes. À titre d’exemple, un moteur de détection fondé sur une simple recherche de motifs ne comporte pas d’algorithme dédié à l’extraction et à la normalisation d’une représentation intermédiaire.

Dans le cas des moteurs d’analyse spectrale étudiés au chapitre précédent, il est possible d’identifier une étape d’ex- traction d’une représentation intermédiaire (un modèle représentatif de la distribution des instructions assembleur) puis une réécriture de cette représentation, lors de la phase d’entrainement du modèle.

Le moteur de détection doit permettre la suppression du loader sécurisé, lorsque le virus a été protégé par uti- lisation d’un packer du marché. Nous avons vu que plusieurs algorithmes dynamiques ont été proposés pour opérer la suppression automatique du loader de protection d’un exécutable packé. Ces algorithmes souffrent tous de limita- tions importantes, et doivent se fonder sur des heuristiques pour retrouver le point d’entrée original de l’exécutable packé. Une méthode classique consiste à identifier le packer utilisé, en se fondant sur une base d’information. Le processus de détection virale commence alors par une phase de détection des packers ! Dans ces conditions, il est évident de définir un critère de complétude de cette base d’information : celle-ci doit permettre d’identifier tous les packers du marché susceptibles d’être utilisé par un concepteur de virus.

La représentation intermédiaire du programme peut être le code assembleur, ou la représentation du programme sous forme de graphe CFG. Il peut s’agir d’une représentation plus complète du flot de contrôle permettant par exemple de raisonner sur le flot de données d’un programme comportant du code auto-modifiable. Une telle représentation a été proposée dans [AMD06] et appelée State-Enhanced CFG (SE-CFG). Constatant que la représentation sous forme de graphe CFG traditionnelle ne permet pas de mener une analyse statique suffisament précise du flot de données, les auteurs ont proposé une représentation étendue du graphe de flot, permettant de s’affranchir de l’hypothèse d’un code constant. Ce modèle est présenté de manière plus détaillée au chapitre 3, section 3.3.3. Le graphe SE-CFG peut être linéarisé, c’est-à-dire que partant de la seule information du graphe SE-CFG d’un programme comportant du code auto-modifiable, il est possible de reconstruire la section de code d’origine. Le graphe SE-CFG contient une information supplémentaire permettant d’améliorer la précision de l’analyse du flot de données, et donc d’améliorer le processus de normalisation de cette représentation intermédiaire.

Ces exemples illustrent l’importance des critères de correction et de complétude associés à la représentation inter- médiaire du code choisie (le choix d’un graphe CFG traditionnel comme représentation intermédiaire du programme est aussi conservatif que celui d’un graphe SE-CFG, mais l’abstraction correspondante est moins précise). Elle condi- tionne l’efficacité de l’étape suivante, visant à obtenir une représentation intermédiaire normalisée par application d’une statégie de réécriture. L’application de ces transformations de réécritures est généralement gouvernée par le résultat d’une analyse du flot de données. Nous pouvons observer que le choix d’une représentation intermédiare influe notamment sur la complétude de l’analyse du flot de données.

La stratégie de réécriture peut se dispenser complétement des résultats d’une analyse du flot de données. C’est le cas des transformations visant à supprimer les sauts inutiles d’un graphe CFG, que l’on trouve implémentées dans plusieurs moteurs de détection récents [CJS+_{05,BMM06] proposant une méthode de détection dit structurelle}

ou morphologique, fondée sur la recherche d’un sous-graphe viral. Une telle stratégie de réécriture est efficace au regard d’une classe de mécanismes d’obfuscation du flot de contrôle. Elle s’avère plus limitée face à des transfor- mations d’obfuscation plus évoluées, permettant de fusionner les flots de contrôle du virus et du programme hôte [Z0m00b] ou de rendre les sauts inutiles plus difficiles à supprimer, par utilisation de prédicats opaques par exemple. Remarquons que les moteurs viraux n’implémentent pas encore cette technologie.

L’utilisation de sélecteurs de similarité [DR05] pour construire un isomorphisme de graphe CFG paraît à ce dernier égard correspondre à une stratégie de réécriture plus complète, bien que fondée sur l’application d’heuristiques pouvant entâcher sa correction.

Lorsque la stratégie de réécriture se fonde sur une analyse du flot de donnée, la correction et la complétude des algorithmes correspondant jouent naturellement un rôle primordial. Nous avons vu au chapitre4que le cadre formel de l’interprétation abstraite se prète naturellement à la caractérisation des méthodes d’analyse du flot de donnée en terme de correction et de complétude.

La stratégie de réécriture elle-même peut être qualifiée au regard de critère tels que la confluence et la termi- naison. Les auteurs de [BKM08] proposent une représentation sous forme de termes d’un graphe CFG mais ne définissent pas leur statégie de réécriture de graphe CFG dans ce cadre formel. Ils évoquent cependant la possi- bilité d’utiliser les résultats d’une théorie de la réécriture de termes commutative et associative pour améliorer la correction de leur stratégie de réécriture et l’algorithme d’isomorphisme de graphe CFG en prenant en compte des aspects commutatifs, comme par exemple la permutation des arcs d’un saut conditionnel.