Défis majeurs d'émulation et optimisations algorithmiques - Partie II :

Let's do it english this once.. hehe.. Je suis fou sometimes :p

As i understood, and as all people already know : the classical 3 ways Fetch - Decode then Execute is too slow to maintain in a antivirus scanning engine. I will talk about some things i implemented so far... now i have to go sleep, tomorrow i will speak about it. good night.

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...

Le Design du Kernel d'émulation CPU :

L'émulation est une technologie de pointe crée depuis les années 90 par les pionniers de l'industrie Antivirus de l'époque pour faire face aux menaces ascendantes des virus Polymorphiques du type MTE et compagnies. Un émulateur, est par définition un module qui imite partiellement ou totalement le fonctionnement d'un ordinateur; c'est à dire qu'il permet de faire exécuter un quelconque fichier cible sous un environnement contrôlé et purement virtuel indépendamment de l'ordinateur et des ses composants. L'utilité d'un tel module se résume à pouvoir analyser le fonctionnement potentiel d'un fichier cible afin d'anticiper un quelconque comportement malicieux du fichier en question au cas où il serait exécuté en mode réel :

• Suppression de fichiers.
• Formatage ou destruction du disque dur.
• Infections des autres fichiers.
• Propagation par le réseau.
• Désactivation des Firewalls / Antivirus installés.
• Corruption du système d'exploitation.
• etc..

En général,l'architecture d'un système virtuel d'émulation doit prendre en compte 4 éléments capitaux reliés en chaînes :

• Émulation Processeur ( Pentium, AMD, ARM etc... ).
• Émulation Mémoire.
• Émulation Hardware (Disque dur virtuel,Carte réseau etc..)
  
• Émulation Système d'exploitation (Windows / Linux / Solaris etc.. ).

Comme vous pouvez déjà le constater : techniquement, la mise au point et l'implémentation d'une telle technologie au sein d'un système d'analyse Antiviral est vraiment très difficile à faire. Faut il le dire encore, ça demande vraiment des compétences en informatique de haut niveau; et c'est ce qui explique le nombre restreint de solutions Antivirus qui l'utilisent actuellement, du moins qui ont réussi à l'implémenter correctement et efficacement, je cites à titre d'exemples : Nod32 de la firme Tchécoslovaque ESET, F-PROT de la firme Islandaise FRISK ainsi que Norman Virus Control de la firme Norvégienne Norman ASA.

Maintenant en parlant de mon propre travail : j'ai essayé de maintenir un niveau d'abstraction élevé pendant toute la phase de développement afin de pouvoir offrir une architecture d'émulation évolutive et adaptative. L'abstraction des méthodes et de l'interface générale d'émulation est un peu coûteuse en terme de performances, mais elle a l'avantage de me permettre d'avoir une plus grande flexibilité de travail pour la prise en charge des différentes combinaisons de configurations liées au processus d'émulation. L'avantage d'une telle approche se résume au faite que le Kernel d'émulation sera indépendant et portable en terme de fonctionnement entre les différents systèmes d'exploitation et les différents Processeurs que j'ai implémenté et que j'implémenterai dans un proche futur. Pour être plus clair sur ce point :

• Un seul Kernel est capable d'émuler plusieurs Processeurs : Pentium, AMD, ARM etc..
  

• Un seul Kernel est capable d'émuler plusieurs systèmes d'exploitation Windows, Linux, Solaris etc..

Tout dépend de la configuration d'émulation, c'est juste une question de connectivité d'interfaces et de sous modules de traitement. Prenez à titre d'exemple ce scénario qui peut se produire au cours du processus de scanning :

• L'engin principal rencontre un fichier exécutable Linux de type ELF sous un environnement exécutif Windows, le Kernel d'émulation se connecte alors dynamiquement à l'interface d'émulation du système d'exploitation Linux et commence le processus d'émulation.

• L'engin principal rencontre un fichier exécutable Windows de type PE sous un environnement exécutif Linux, le kernel d'émulation se connecte alors dynamiquement à l'interface d'émulation du système d'exploitation Windows et commence le processus d'émulation.

Pour le support d'émulation des processeurs, j'ai implémenté un support unifié des plages d'instructions IA32 et IA64, c'est à dire que le module d'émulation CPU supporte parallèlement le mode d'exécution 32bit et le mode d'exécution 64bit !

• Le processus de scanning lancé depuis un environnement 32bit fonctionne de cette manière :

• Si l'engin principal rencontre un fichier exécutable 32bit, le kernel d'émulation invoque alors l'interface d'émulation processeur 32bit.
  

• Si l'engin principal rencontre un fichier exécutable 64bit, le kernel d'émulation invoque alors l'interface d'émulation processeur 64bit.

• Le processus de scanning lancé depuis un environnement 64bit fonctionne de cette manière :

• Si l'engin principal rencontre un fichier exécutable 64bit, le kernel d'émulation invoque alors l'interface d'émulation processeur 64bit.
  

• Si l'engin principal rencontre un fichier exécutable 32bit, le kernel d'émulation invoque alors l'interface d'émulation processeur Legacy Mode.

Quelques petites notes virtuelles...

Il ya de plus en plus de virus qui incorporent des routines et des méthodes anti-émulation et anti-virtualisation... Faut bien le dire; la scène virale sous Windows est entrain d'évoluer à plein régime, à plein gaz et à feu de guerre. A ce que je vois, les auteurs de virus se sont bien instruits, ce n'est plus comme dans les années 1998-2001, puisque nous faisons face maintenant à des gens intelligents, bien organisés, très bien informés et surtout de plus en plus compétents dans l'art du reverse engineering.

"Quel rapport entre le monde viral et la science du reversing ?"; vous pouvez bien dire; Bein, en 2007-2008, l'architecte anti-viral est obligé de prendre un facteur de plus dans le design de son engin de détection, c'est à dire en plus du design principal de fonctionnement qui se résume à la détection virale, il doit prendre en considération plusieurs autres facteurs en relation étroite avec le reverse engineering :

• 1 - Son engin sera analysé par une ou plusieurs autres firmes Antivirales concurrentes. Oui, en effet c'est une pratique courante dans tous les domaines et surtout dans ce monde de sécurité où tout le monde espionne tout le monde. C'est ce que j'ai toujours fais, et c'est ce qu'on va me faire lorsque je vais rendre mon engin exposé au public. Beaucoup d'engins de détection bâtis entre 1998 et 2001 n'ont pas prévu le reverse engineering dans son état actuelle en fin 2007, je ne veux pas citer des noms précis, mais croyez-moi il y en a beaucoup.

• 2 - Son engin sera analysé par les créateurs de virus en personnes ! Avant, ils testaient leurs créations virales à l'aveuglette en comparaison avec l'époque actuelle; le créateur de virus de l'ancienne époque agissait en artiste, en pure programmeur; L'effort principal était principalement réparti dans la création des méthodes de cryptages et d'évolutions polymorphiques et métamorphiques, c'est à dire ne prenant en compte principalement qu'un seul axe de détection : la fameuse méthode dite SCAN STRING. De plus, pour tester la furtivité de sa création, le créateur de virus de cette époque là, entretenait une relation contre-productive avec les engins de détection virales. Il commençait par construire son code viral et puis à le tester en temps réel contre des engins pré-installés dans son propre ordinateur; et si nécessaire, le modifiant entre temps afin d'obtenir une parfaite furtivité. Cette furtivité soit disant parfaite avait le plus grand défaut de n'être furtive qu'à très court terme, c'est à dire, juste le temps d'être analysée par les architectes antivirus avant que des nouvelles méthodes de détection ou des modifications sur des méthodes pré-existentes soient implémentées; ce qui avait pour conséquences : la détection de toutes les variantes du code viral développé par ce triste créateur. C'était le jeu du chat et de la souris; honnêtement, c'était du moins plus facile de détecter un virus que de le rendre indétectable. Pour conclure sur ce petit point, le réel mode de fonctionnement des engins de détection antiviraux était comme une boîte noire pour les créateurs de virus, qui focalisaient leurs champs d'actions sur le virus en question et non pas sur la détection en soit, l'image est : c'était les architectes Antivirus qui déboguaient les virus et non pas les créateurs de virus qui déboguaient les engins de détection.

La situation actuelle en 2007-2008 est tout à fait inverse de la situation de celle de l'ancienne époque, les méthodes de détection ne sont plus comme une boite noire, pire encore les méthodes de travail des architectes antiviraux n'est plus un secret; En plus des compétences ardues de programmation, les auteurs de virus ont développé des connaissances approfondies dans la science du Reverse Engineering ce qui a élargit leur champs d'actions et par conséquent l'ampleur de leurs dégâts.

Armé d'un savoir faire ardue, de flux informationnels de plus en plus amples et précis et des outils de déboguage de plus en plus sophistiqués : le créateur de virus de l'époque actuelle est tout à fait apte à construire un virus capable d'évader toutes les méthodes de détections conventionnelles sachant qu'il est tout à fait capable de déboguer la majorité des engins antiviraux actuels jusqu'au plus fin détail de leur fonctionnement. Le monde d'émulation n'est plus un secret, il est même devenu OPEN-SOURCE : citant à titre d'exemple les fameux bochs.sourceforge.net ou fabrice.bellard.free.fr/qemu. Cette évolution colossale du savoir faire du grand public a induit à ce que le créateur de virus contemporain n'est plus par définition un simple enfant de 14-18 ans, un petit génie ou un artiste de programmation; Non ! Aujourd'hui il faut être préparé à faire face à un informaticien professionnel, je veux dire un criminel professionnel armé d'un savoir faire de plus en plus évolué et surtout prêt à offrir ses CYBER services à quiconque but lucratif. L'évolution du phénomène des BOTS et des technologies Root-kits, le fait que la cyber criminalité contemporaine regroupe toutes les disciplines criminelles : Cracking, Carding, Spam, Trojans, Rootkits, Spywares, Dialers, Bots... et que celles-ci se rejoignent et peuvent se fusionner sous un même objet : je me permets de penser que nous sommes face à des vraies organisations cyber criminelles internationales construites en nid d'araignée; et que le design de tout engin antiviral contemporain doit prendre en comptes en plus de la somme de toutes ces menaces citées : il doit surtout prendre en compte l'élément humain et de son savoir faire concrétisé par la science du Reverse Engineering.

La matérialisation de mes propos se résume techniquement à ceci : attendez-vous de voir des virus qui ciblent les limitations des technologies de Virtualisation / Emulation; Déjà il ya un grand nombre de nouveaux virus qui contient des routines qui vérifient si le virus en question est entrain de s'exécuter en mode réel ou qu'il est entrain de se faire exécuter en mode virtuel c'est à dire à l'intérieur d'un OS Virtuel émulé par VMWARE / VIRTUAL PC / BOCH / QEMU et par conséquent ou bien il refuse de fonctionner ( c'est moins intelligent ) ou bien fonctionne incorrectement ( CRASH !!). Pire encore, attendez-vous de voir des routines anti-émulation qui visent l'émulation CPU des Antivirus : des instructions invalides, manipulations des flags, instructions insolites, appel intensif à des API Windows qui ne peuvent pas être émulées correctement etc.. Maintenant, qu'ils savent le principe d'émulation, son mode de fonctionnement et qu'ils ont le savoir faire qui leur permet de déboguer les engins de détections qui n'ont pas été préparé à être investis d'aussi prêt : attendez-vous au pire, attendez-vous à toute sorte d'idées et d'astuces qui vont rendre votre travail d'architecte antiviral aussi vain que possible.