Jean-Yves Marion : « Passer les codes malveillants aux rayons X pour mieux les identifier »

Pour se protéger des codes malveillants, il y a les anti-virus. Qu’est-ce que votre approche apporte de plus ?

Il existe une grande variété de codes malveillants : il y a les codes espions, les botnets qui constituent un réseau d’ordinateurs infectés de façon à les faire travailler ensemble pour envoyer du spam par exemple, les attaques par déni de service (afin qu’un serveur ne réponde plus), ou encore les ransomware, c’est-à-dire des attaques où le pirate bloque votre ordinateur ou chiffre votre disque dur, et vous demande de payer 100€ par exemple pour retrouver l’usage de votre machine. Alors oui, pour se protéger de tout ça, il y a des anti-virus, mais il faut pour cela qu’il y ait eu suffisamment de machines infectées et de personnes qui déclarent qu’il s’agit d’un code malveillant pour que le nouveau virus soit répertorié. 

Mon approche est différente. J’essaie de déterminer ce qu’est un code malveillant, quelles sont les fonctionnalités uniques que comportent ces programmes. Par exemple, quand quelqu’un télécharge un jeu, pourquoi y aurait-il une fonction de géolocalisation ? On peut s’interroger sur les raisons pour un logiciel de comporter des fonctionnalités qui ne sont pas nécessaires à son fonctionnement. Pour mettre en place ces nouvelles méthodes de détection, nous avons développé des techniques que nous appelons analyse morphologique, et qui correspondent à extraire d’un code sa structure interne, comme si on lui faisait passer une radio pour ne regarder que les os ! On s’intéresse alors à l’organisation du squelette, qui reflète la structuration du code et l’identifie, formant ainsi une signature. Mais les codes malveillants ne dévoilent pas leur code d’un coup : ils sont généralement protégés et presque toujours auto-modifiants, c’est-à-dire qu’ils s’exécutent en vagues, une vague de code en générant une autre, le code final du programme étant difficilement observable. Notre but est de réaliser une analyse automatique pour récupérer ces vagues de codes, et réassembler les morceaux du squelette du programme. Ainsi, nous espérons disposer d’un outil pour analyser des fonctionnalités embarquées dans un code et donc avoir une détection plus précise. Pour réaliser ces expériences et lancer des expérimentations grandeur nature, nous nous appuyons sur un outil formidable : le Laboratoire de Haute Sécurité, un laboratoire qui dispose aujourd’hui de 6 millions de virus informatiques.

Les innovations des pirates informatiques sont aussi pour vous une source d’inspiration sur le plan théorique.

Tout à fait, les hackers inventent de nouvelles façons de coder, c’est très intéressant ! Comme nous l’avons dit, les codes malveillants, pour éviter d’être détectés, rendent incompréhensibles l’objectif de leur code et utilisent pour cela différentes méthodes dont l’auto-modification. L’ordinateur exécute des instructions, qui génèrent de nouvelles instructions qui n’étaient pas dans la mémoire de l’ordinateur, et ainsi de suite, ce qui est très loin de la programmation que l’on apprend en cours. Mais un programme qui se modifie ne signifie pas nécessairement que le code est malveillant, l’auto-modification est aussi utilisée par exemple par ceux qui souhaitent protéger la propriété intellectuelle de leur programme. Pour mener à bien nos travaux, nous utilisons différents concepts provenant des méthodes formelles. Ceci dit, nos analyses sont faites à un très bas niveau, au niveau de l’ordinateur, ce qui est peu fait dans la communauté. Contrairement à de plus hauts niveaux de programmation, il y a peu d’outils de vérification à ce niveau, ce qui est passionnant. 

D’un point de vue plus fondamental, les travaux sur les codes auto-modifiants ont commencé avec le théorème de récursion de Stephen Kleene qui avait formalisé ce principe en 1935, et se sont poursuivis avec les résultats de John von Neumann sur des systèmes auto-reproduisants. Nous pouvons donc nous demander quel est le retour théorique sur le sujet des développements actuels des techniques d’auto-modification, et ce que cela peut impliquer dans la conception d’un calcul. 

Parallèlement, je m’intéresse toujours à la complexité implicite des calculs, pour comprendre quelle est la structure mathématique des problèmes que l’on peut résoudre facilement et ceux où l’on ne peut pas, entre les classes de complexité comme P ou NP. J’emploie des outils logiques qui ne sont finalement pas si éloignés que cela de ceux de la théorie des codes auto-modifiants et des principes de réfléxivité.