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