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.