Dans la première partie de ce papier, nous avons vu comment les anti-virus ont dû s’adapter pour faire face aux malwares polymorphes et les limites de l’analyse polymorphique.

Nous allons désormais nous intéresser à l’analyse heuristique, qui elle, est en mesure de détecter des programmes malveillants en comparant leurs caractéristiques et comportements avec ceux de malwares préalablement détectés. Mais ce n’est qu’un des aspects de l’analyse heuristique.

Voici quelques propriétés de code qui peuvent aider à la reconnaissance heuristique de malwares :

• Un point d’entrée dans une section pour laquelle la permission en écriture est disponible (rwx). Si le contrôle est transféré à une section contenant un code exécutable et marqué comme ayant la permission en écriture, il est quasiment sûr qu’un code automodifiable est utilisé. Les sections de ce type sont typiques des virus et des programmes de protection.
• Une instruction jump au niveau du point d’entrée. Il n’y a pas de raison pratique pour laquelle placer une instruction jump au point d’entrée. Donc, lorsque cela arrive, cela indique qu’un code automodifiable est présent dans le fichier.
• Un point d’entrée dans la deuxième moitié d’une section. Le code du virus est généralement ajouté à la fin de la section d’un fichier. Ceci n’est pas typique des fichiers normaux et semble donc suspect.
• En-têtes cassés. Un fichier peut continuer à être opérationnel après son infection, mais son en-tête peut contenir des erreurs qui n’apparaîtraient pas durant le processus de liaison. Donc les erreurs de ce type soulèvent également la suspicion.
• Un format inhabituel dans certaines sections spécifiques. Les fichiers exécutables contiennent des sections spécifiques comme .ctors, .dtors,  nad .fini. Elles peuvent être utilisées pour infecter les fichiers. Si un changement de format est constaté dans ces sections, c’est également suspect.

….et il existe des centaines d’autres propriétés de code suspectes.

Les propriétés sont nombreuses, et chaque propriété possède un degré associé de risque différent. Certaines peuvent simplement indiquer une menace lorsqu’elles fonctionnent ensemble, mais peuvent toutefois être très utiles pour trouver des menaces et décider si une analyse plus poussée est requise. Contourner l’analyse heuristique n’est pas une tâche facile (par cela je veux dire l’empêcher même de produire une alerte). Ce but peut être atteint en utilisant des solutions indépendantes des plateformes et utilisant les fonctionnalités de compilateurs spécifiques et des frameworks qui pénètrent dans les bases heuristiques assez rapidement, ou en utilisant des outils d’infection sophistiqués capables de réarranger le code à travers un fichier.

Donc, les permutations n’empêchent pas les antivirus de détecter les malwares via leurs signatures, mais elles élèvent le niveau en termes de prérequis pour les développeurs d’antivirus.

Que trouve-t-on d’autre dans l’arsenal des attaquants ?

Beaucoup d’autres réjouissances. Nous avons déjà parlé de l’instruction NOP (dans une première partie). Les attaquants peuvent également s’assurer du fait que des instructions redondantes soient intégrées à un fichier infecté afin de masquer le code malveillant. Ceci peut également sembler facile mais ce n’est pas le cas, parce que le code doit rester opérationnel malgré un nombre important de commandes inutiles qui lui sont ajoutées.

Pour contrer cela, l’analyseur polymorphique devient encore plus complexe - il n’assemble pas uniquement des parties de code mais le « nettoie » également de ses fragments inutiles (si nous examinons le code de Windows, quelle proportion de ce code sera mise de côté ?). Dans ce cas, une erreur d’analyse peut avoir de lourdes conséquences.

Malwares métamorphiques

Contrairement aux permutations, où les blocs de code sont réarrangés, le code des malwares métamorphiques change réellement. En théorie, les malwares de ce type ne peuvent être détectés parce que la génération de signatures pour ce type de code malveillant n’a aucun sens.

Presque tous les programmes sont écrits dans un langage de programmation puis compilés en un code exécutable. Et le compilateur peut être configuré pour générer un code différent pour un même programme en activant certaines options comme les performances, l’optimisation de la taille etc. Le moteur métamorphique opère de manière similaire. Dès lors qu’il est lancé, il utilise un code basique pour générer un nouveau code.

Un code malveillant peut être obfusqué (obscurcissement de code) encore plus en modifiant les constantes, les registres etc. Illustrons cette assertion en établissant une analogie avec les mathématiques : par exemple, 6 peut être obtenu par 2+4, 3+3, et 8-2….Laquelle de ces opérations peut-elle considérée comme typique ?

Pour répondre à cela, l’analyse du code n’est pas suffisante. L’analyseur devient donc un émulateur. Ceci signifie qu’un programme est exécuté au sein d’un moteur antivirus qui ne recherche plus des correspondances entre signatures mais surveille les actions du programme « en train d’être lancé ».

Finalement, la « course aux armements » entre créateurs de virus et développeurs d’antivirus a rendu les malwares polymorphes plutôt rares car créer un programme de ce type est difficile et coûteux.