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.

Etat des lieux

Bein, c'est un Dimanche soir très froid, je suis devant mon ordinateur, en pleine phase de développement du module 'OS Virtualizer' de mon antivirus; c'est un module, qui est un peu semblable aux modes de fonctionnement de Norman Sandbox et/ou BitDefender B-HAVE. C'est un module qui est censé apporter un environnement virtuel et transparent afin de renforcer le travail de l'émulateur d'instructions,déjà implémenté depuis le mois de Ramadan. Le minimum que je puisse dire, c'est vraiment trop compliqué et il ya tant de petits détails à prendre en compte lorsque vous osez émuler le mode de fonctionnement d'un OS comme celui de Windows ! Je suis fou de rage, je stagne depuis plus d'une semaine sur l'approche algorithmique à suivre pour la prise de l'Import Table Descriptor. Vu, que j'ai implémenté un mode de lecture des fichiers sur le disque dur indépendant des fonctions I/O de Windows, I'idée globale a été prise de la technologie 'Anti-Stealth' de chez ESET - Nod32 ; ce n'est sans doute pas la même implémentation, le même algorithme de fonctionnement, mais le but et l'idée en générale est la même. Donc, mon implémentation I/O exclue tout modification mémoire et/ou physique de l'image du fichier traité, et là pour pouvoir connecter l'emulateur OS à l'emulateur CPU : je dois implémenter un redirection transparente de la table des imports ( IAT) du fichier traité comme ceci :

Emulateur CPU --> IAT --> OS Virtualizer --> Resultat virtuel --> Emulateur CPU --> etc...

Le fait, que j'ai construit ma propre implémentation I/O en Read-Only, je suis maintenant devant 2 choix difficiles à prendre à ce stade :

• Ou bien, passer par une IAT SHADOW TABLE, c'est à dire une table calquée de la table IAT originale, avec seule différence : l'identifiant FirstThunk contient une addresse mémoire convertible par le module OS Virtualizer vers une addresse mémoire d'une fonction d'émulation interne qui mimique le fonctionnement de la fonction OS originale.
  

1. Avantage : Le principe Read-Only est maintenu ( Aucune modification du fichier traité ).
2. Inconvénient : Allocation / Déallocation répétitive d'e plusieurs blocs de mémoire et travail supplémentaire pour la gestion d'accès à ces blocs ==> Dégradation de la vitesse générale de scanning et utilisation supplémentaire des ressources système :(
   

• Ou bien, obligation d'utiliser un autre modèle d'implémentation I/O moins rapide et non anti-stealth comme celui déjà implémenté depuis l'année dernière. Bref, obligation de construire un autre modèle dans ce cas !
  

1. Avantage : Possibilité de patcher 'FirstThunk' de chaque IMPORT DESCRIPTOR pendant la phase d'initialization de l'émulateur et l'abandon du overhead du IAT SHADOW TABLE.
2. Inconvénient : Le temps supplémentaire qu'il va falloir perdre afin d'implémenter un autre gestionnaire I/O aussi performant que celui que j'ai déjà implémenté :(
   

En fait, c'est ça mon problème, ce qui me fais perdre tant de temps : est le fait que je commence à coder avant que je commencer à raisonner. Résultats ? je passe trop de temps à coder vers une direction, puis à un moment donnée, en implémentant une autre fonctionnalité ou une autre technologie, je passe encore trop de temps à annuler l'ancienne méthode et ainsi va la vie dans ma tête de fou !! Construire, détruire ce que j'ai construis, puis construire ce j'ai détruis et en avant...

Mecca Antivirus Engine

Mecca ? pourquoi ce nom ?

En fait, c'est une longue histoire.. De retour en Tunisie, après mes études mises entre parenthèse en Russie, je me suis concentré sur l'apprentissage du cracking. Au tout début, c'était un sujet qui me paraissait trop compliqué et réservé pour les génies etc.. En téléchargeant quelques tutoriaux à l'époque depuis internet, je me suis mis à plein coeur dans une longue phase d'apprentissage, je me suis perdu dans le language assembleur de softice qui était si compliqué pour un simple littéraire comme moi. EAX ? EDX ? MOV, PUSH ?? Après une rude année d'auto-apprentissage, j'ai eu la chance de pouvoir tester mon niveau à l'échelle mondial en rejoignant quelques groupes de cracking internationaux et de renom ( je ne peux pas citer des noms ). Le fait que je sois membre de ces groupes, j'avais l'obligation d'apprendre à programmer en assembleur, pour pouvoir partager les patches et les keygens que je faisais. Cette ancienne expérience, ma vraiment permis d'appréhender les rouages des astuces de protections anti-piratage et m'a permis d'avoir une vision claire du langage machine dans son état brut, j'ai appris avec le temps et avec l'expérience à comprendre le mode de fonctionnement des logiciels à leur état brut, sans code source et avec tous les méchanismes de protections mis en oeuvre afin de contrer le 'Reverse Engineering'.

En 2004 j'ai commencé à m'intéresser un tout petit peu au développement des solutions de sécurité, j'ai étudié très vaguement quelques applications anti-spywares, anti-trojans.. j'ai dans un 1er temps, réussi à décrypter le mode de fonctionnement de leurs bases de données de signatures, leur algorithmes de détection etc.. J'ai pensé dans un 1er temps à développer une application Anti-spyware dans un temps éclair, et avec seul avantage de pouvoir inclure et utiliser les modèles de détection des logiciels que j'ai déjà étudié. Avec le temps, j'ai pu tirer quelques conclusions, qui sont peut être encore valides même à l'instant présent et qui est : Les logiciels, soit disant de renom, que j'ai pu mettre à nu, sont très mal construits, ce n'est pas vraiment très sérieux comme travail, rechercher des noms de fichiers, des noms d'entrées dans la base de registre Windows, n'est pas vraiment sorcier comme mode de fonctionnement; j'ai même anticipé l'idée en 2004, que les firmes Antivirus, vont se mettre dans la sauce sachant que les logiciels anti-spywares attirent beaucoup de consommateurs et que les technologies déjà implémentées dans les antivirus de l'époque, ne prenaient pas en comptes ce genre de menace en compte. D'où l'idée de développer mon propre Anti-spyware est née, et avec le temps, elle a évolué sans même voir le jour, pour finalement aboutir à un projet colossale d'un logiciel antivirus : 100% tunisien, 100% musulman, %100 arabe hehe...

Sachant que j'étais très en retard par rapport à la technologie antivirale, j'ai commencé par installer les toutes 1ères version de Kaspersky Antivirus et de BitDefender ainsi que plusieurs autres... Pour comprendre un produit, toute une technologie, il faut commencer toujours par les 1ères étapes,n'est-ce pas ? Donc, tout en analyseant Kaspersky - j'ai pris note du nom de leur 'Prague Loader', qui est l'engin principal de chargement / gestion des modules de détection etc.. Qu'est ce que 'Prague' veut bien dire ? C'est peut être un endroit plein d'anciens souvenirs pour les anciens communistes russes, mais du moins, pas pour moi ni pour les miens ( Dire que, Kaspersky, le Monsieur, est un ex-membre de l'ancien KGB hehe... ). L'endroit le plus sacré au monde pour moi est sans doute 'Mecca' et c'est en Arabie Saoudite et non pas en république tchèque hehe.. D'où le choix d'utiliser donc, le nom de 'Mecca' pour le Kernel de mon propre logiciel antivirus. Je vais faire tout mon possible pour hisser le nom de 'Mecca' dans le monde réservé des produits anti-virus; J'espère atteindre le sommet de la chose avec l'aide de dieu.

To be continued...

Salam People !

Au nom de dieu, le tout puissant, je commence, tard ce soir à blogger... En toute sincèrité, veuillez savoir que je ne porte aucun intérêt au blogging comme phénomène en soit. Sincèrement, mon réel but est de pouvoir promouvoir une technologie que suis entrain de mettre au point, faire partager un peu d'expérience et de savoir faire que mon dieu m'a aidé à acquérir pendant près de 4 années d'expérience intense en informatique, plus précisèment, dans la sécurité informatique et tout ce qui suit...

Je dédie ce blog à mon dieu et son prophète, à moi-même, à ma famille, à mon pays, à ma nation et à tous ceux qui me connaissent et qui m'aiment sincèrement.