Défis majeurs d'émulation et optimisations algorithmiques :

A un moment donné, le concepteur d'un engin d'émulation antiviral se retrouve confronté à des défis fonctionnels très complexes : que ce soit au niveau de l'implémentation ou au niveau du design de fonctionnement général. Tout d'abord, Il faut savoir que l'émulation du fonctionnement Tic par Tic d'un processeur sous une forme logicielle pure imbrique des contraintes fonctionnelles non négligeables au niveau de la qualité de fonctionnement et des performances d'exécution en général. La réussite opérative d'un quelconque engin antiviral dépend à mon propre avis de 3 axes globales de contraintes :

• Contraintes fonctionnelles liées aux performances générales et à la vitesse d'exécution de l'engin d'émulation.
• Contraintes fonctionnelles liées à la transparence et à la qualité d'interprétation des instructions décodées.
• Contraintes fonctionnelles liées à l'usage des ressources système pendant la phase d'exécution de l'engin d'émulation.

Défis de performances et de vitesse d'exécution :

- Dans une technologie antivirale de pointe et qui fonctionne en nano seconde, le défis de vitesse d'exécution est la 1ère contrainte fonctionnelle à prendre en considération. L'équilibre paradoxal entre la vitesse d'exécution et la précision de détection est un véritable casse tête chinois pour le plus futé des concepteurs, comment faire pour maintenir une vitesse assez élevée tout en étant obligé de faire des centaines de milliards d'itérations par analyse ?! Comment faire pour analyser aux moins 40 fichiers/seconde tout en maintenant un taux de détection aussi élevé que possible ? - C'est le défis le plus primordial des solutions Antivirus contemporaines;

- Sachant que l'algorithme le plus élémentaire d'émulation se résume à 3 étapes primaires ( Fetch - Decode - Execute ) : veuillez noter tout de même que le processeur physique ne demande en fait qu'environs 1 clock cycle pour lire, décoder et puis exécuter par exemple l'instruction : XOR EAX,EAX alors que l'émulateur logiciel aura besoin de plusieurs milliers, voir plusieurs millions de clock cycles pour refaire les mêmes étapes. Et même avec les configurations actuelles, il est strictement impossible d'obtenir une vitesse d'émulation et d'analyse 100% transparente; Il faut savoir aussi que la contrainte fonctionnelle de vitesse tend à s'accentuer avec le modèle d'émulation Antiviral, chose qu' il ne faut pas confondre avec le fonctionnement d'émulation d'un logiciel de type Boch / QEMU sachant que l'algorithme opérationnel du modèle Antiviral tend à introduire un overhead (travail) important au niveau de l'émulation...

- Le design général de l'engin antiviral doit maintenir une relation abstraite entre l'interface de détection principale de l'antivirus et l'engin d'émulation CPU. Plus encore, un modèle de guidage doit être implémenté de façon à ce l'interface principale puisse rester en contact permanent avec chaque cycle d'émulation de l'engin; C'est à dire que l'engin d'émulation CPU doit exporter un méchanisme de communication avec l'interface principale pour que le fonctionnement de ce dernier soit totalement commandé par le biais de cette même interface. Il serait prérèrable si en plus de son travail d'émulation, l'engin d'émulation est capable d'exécuter des routines externes à son tour : C'est à dire qu'il doit être capable d'assumer un rôle d'interprétation exécutionnel à son tour ! - Scriptable Engine - Je vous donnerais un exemple concrêt plus tard à propos de ce point...

- L'idée générale est : qu'il est préférable que le design général de la solution antivirale ne traite pas l'engin d'émulation comme une entitée isolée du système fonctionnel global, mais plutôt qu'il l'associe à l'orchestration de fonctionnement détéctif dans tous ses détails etc ...

- Le plus grand défis de performances de vitesse d'exécution est donc en relation directe avec l'architecture complexe de la solution Antivirale en général : ( protocoles et procédures de communications internes abstraites avec l'interface principale, latences induitent par les processus d'analyses et de détection complexes etc... ). Cette contrainte fonctionnelle de vitesse d'exécution à fait donc naitre beaucoup d'approches algorithmiques, qui ont été adoptées par différents systèmes d'émulation afin de minimiser l'impact de cette contrainte; mais dans le contexte actuel, je vais en fait évoquer quelques petits points sur l'exemple du Dynamic Translation Model développé par Fabrice Bellard dans son émulateur QEMU ( Une vraie révolution technologique :p ) et présenté par Mr Peter Szor, le fameux directeur de recherches de chez Symantec, comme modèle magique d'optimisation du fonctionnement d'émulation Antivirale.

En toute honnêteté, je ne vais pas me comparer avec Mr Szor qui est déjà dans le domaine depuis le début des années 90 : c'est un véritable expert dans la matière et il me dépasse de très loin... Mais apparamment, au moment où je me suis concentré sur le développement de mon propre engin, l'évocation de l'utilisation de cette option algorithmique dans des solutions Antivirus m'a paru, il faut le dire impossible, voir contre productive du point du vue antiviral biensur. Qu'est ce que ça veut dire ? Bein, si les allocutions de Mr Szor sont justes, il faut prévoir de voir que l'engin Antivirus de Symantec est l'un des engins les plus rapides au monde, n'est ce pas ?! Norton Antivirus à la notoriété d'être très lent surtout très gourmand pour les ressources systèmes. En parlant de l'optimisation fonctionnelle importante obtenue par le modèle algorithmique de QEMU, il faut commencer par savoir que le gain en performances est basée sur un élément, dit engin de re-compilation; voici une illustration algorithmique générale et très simple du fonctionnement de ce modèle d'émulation :

• Fetch ( Lire ) instruction depuis la mémoire.
• Decode ( Désassembler ) le buffer vers une instruction prise en charge par le processeur émulé ( RISC / CISC ).
• Re-Encode ( Re-assemble) l' instruction déjà décodée vers une instruction prise en charge par le processeur physique de l'ordinateur.
• Store ( Stocke ) cette instruction dans un buffer mémoire de taille prédéfinie.
• Execute ( Exécution Native ) de la totalité des instructions traduites dans le buffer temporaire par le processeur physique.
• Processus Complexe de prise de décision pour savoir s'il faut ou bien maintenir l'exécution du buffer traduit par le processeur physique, ou bien retourner vers l'étape initiale d'émulation ( Fetch ).

Bien que l'idée de Mr Fabrice Bellard n'est pas une exclusivité algorithmique en soit, puisque un modèle plus évolué a déjà été élaborer par la Firme Sun Microsystems avec leur Technologie HotSpot. J'ai peut être tort, mais disant que l'optimisation alogrithmique de QEMU n'est rien qu' une adaptation générale du modèle d'émulation de Java Virtual Machine de Sun. Puisque ils attaquent le même problème : Les Boucles ! C'est à dire que le modèle de traduction dynamique ne porte ses fruits que lorsqu'il ya une certaine répétitivité du Flow Path d'exécution et il n'y a pas plus pire que les boucles pour un processeur : C'est le grand pourquoi du Cache Line et du parallélisme exécutionnel des processeurs modernes.

Maintenant, la grande question qui se pose est : Est-ce possible d'adopter un tel algorithme dans une technologie Antivirus ? Mr Peter Szor à déjà confirmé cette possibilité, plus encore, il a déjà fais allusion à l'adoption d'une telle technologie dans les engins antiviraux modernes. Pire encore, une certaine firme VirusBlokAda de Biélorussie affirme formellement l'utilisation de ce modèle algorithmique dans leur technologie d'émulation !

Pures mensonges commerciales et publicités mensongères de bas niveau, cette firme possède une technologie d'émulation très classique; du moins, je n'ai vu aucun signe confirmant leurs propos en étudiant leur engins; bien qu'ils possèdent tout de même un très bon module d'analyze heuristique statique, mais bon c'est un point à savoir quand même...

J'ai déjà définis le processus d'émulation par le fait qu'il se résume au fait de lancer un quelconque fichier cible sous un environnement totalement controllé afin d'entrevoir de possibles activitées suspectes de ce fichier; le processus d'émulation est vraiment très sécurisé, sachant que le fichier fonctionne sous un environnement purement virtuel. Et sachant que le modèle algorithmique de tarduction binaire dynamique admet l'exécution directe des instructions re-compilées par le processeur physique; à ma connaissance, l'application d'un tel modèle algorithmique dans une technologie antivirale hautement sécurisée introduit 2 problèmes majeurs :

• 1 - Pendant la phase d'exécution native, l'engin d'émulation est totalement OUT-OF-CONTROL ( déconnecté ) du fonctionnement du fichier cible. C'est à dire que le contrôle total du fonctionnement du fichier émulé instruction par instruction n'est plus possible, sinon ça ne serait plus une traduction dynamique.
  
• 2 - Bien qu'il reste tout de même quelques possibilités de supervisation, par exemple : en patchant on the fly le buffer dynamique par des Breakpoint 'Int 03' ou bien en obligeant le code dynamique à retourner après chaque instruction exécutée en forceant l'exécution du buffer à passer en mode TRAP FLAG. Il est clair que telle quelle soit la méthode de supervisation implémentée, elle aura un impact contraire à celui voulu par l'utilisation du modèle de traduction dynamique; pire encore : le code dynamique aura plus de chance de détécter qu'il est investigué par un émulateur ( Memory CRC Checks - Décryptage dynamique par le biais du TRAP FLAG aka Running Line etc...) .
  

=> Ce qui constitue une claire violation du principe d'éxecution transparente, controlée et totalement sécurisée d'un engin antivirus qui est censé isoler l'environnement réel de toute menace virale. Apparamment, Mr Peter Szor à donné une fausse information, sinon j'espère que j'ai vraiment tort.

To be continued...