Certains logiciels anti-virus surveillent les interruptions et bloquent les actions douteuses, telles que les tentatives d'écriture sur les fichiers COM et EXE. Si un de ces programmes est en mémoire, vous devriez le décharger le plus vite possible, avant que votre disque ne soit infecté à votre insu. En effet, un tel produit interdit donc toute écriture sur les exécutables, cependant ces dernières sont parfois nécessaires. Pour plus de convivialité, ces logiciels disposent parfois d'une option permettant à l'utilisateur de désactiver facilement l'alarme. Quelques virus tels que Eight Tunes, se servent de cette possibilité, reconnaissent le logiciel anti-virus et désactivent d'eux-mêmes l'alarme.

Une autre méthode consiste à ne pas infecter les logiciels anti-virus. En effet, ces derniers effectuent généralement un contrôle sur leur propre code avant même de s'exécuter et signalent toute modification. Le virus évite donc d'infecter tout fichier dont le nom contient les lettres 'SC', 'SCAN' ou même 'TEST'. A moins d'une contre-indication spécifique, il peut parfois être intéressant de renommer votre contrôleur.

Les virus essayant de tricher sur la taille réelle des fichiers laissent parfois paraître une différence entre la taille spécifiée dans l'entrée de répertoire et le nombre d'éléments dans le chaînage de la FAT. La commande CHKDSK signale ces contradictions et nous remarquons que CHKDSK est souvent utilisé dès que l'on soupçonne la présence d'un problème. Pour éviter cette détection, il existe au moins un virus qui contrôle le nom des commandes exécutées et désactive la dissimulation de la taille des fichiers pour CHKDSK.

Un virus furtif avancé tente de dissimuler sa présence aux logiciels anti-virus. Le meilleur exemple de virus furtif avancé est Frodo, également connu sous les noms de 4096, 4K et IDF. La manière d'agir de Frodo est souvent mal comprise. Nous avons vu des rapports expliquant qu'il désinfectait le fichier lors des demandes de lecture, ce qui est plutôt une curieuse façon de décrire son activité réelle. En fait, il piège l'interruption 21h, et entre en action dès qu'une opération est effectuée sur un fichier. Lorsqu'un programme utilise les appels DOS pour lire, écrire ou chercher un fichier, Frodo recherche quelles auraient été les informations s'il n'avait pas infecté le fichier. Il les retourne ensuite au DOS qui les passe au programme appelant. Par conséquent, lorsque Frodo est en mémoire, même une comparaison bit à bit entre un fichier infecté et sa copie saine ne révélera aucune différence. Frodo marque les fichiers infectés en ajoutant 100 ans à la date du fichier ce qui est totalement invisible. Il est par conséquent très difficile à détecter et à éliminer totalement.

Il utilise également une très bonne technique pour se cacher en mémoire. La plupart des programmes résidents capturent une interruption en modifiant une entrée dans la table des vecteurs d'interruption. Beaucoup considèrent que c'est le seul moyen utilisé par les résidents. Mais Frodo néglige cette méthode pour tromper les programmes qui surveillent les modifications dans la table des vecteurs d'interruption. A la place, il change les 5 premiers octets du gestionnaire d'interruption en implémentant un saut vers son propre code. Après l'exécution du code Frodo, le noyau DOS original est remis en place et exécuté.

Number of the Beast (ainsi appelé à cause des '666' contenus dans son code) fait exactement 512 octets et c'est également un virus furtif avancé. Cependant, il se dissimule en manipulant la table des fichiers système dans le DOS. Les 512 octets du fichier sont extrêmement bien codés - aussi précis qu'une montre suisse - bien qu'il vienne peut-être de Bulgarie. Lors de toute tentative de lecture des 512 premiers octets d'un fichier infecté alors que le virus est en mémoire, il va chercher les octets originaux qu'il a placé à la fin du fichier et les présente à la place. Comme précédemment, les comparaisons DOS ou les checksummers sont totalement dupés.

Lui aussi dissimule très bien sa présence en mémoire. Il prend très exactement 512 octets du premier tampon DOS et trompe le DOS en lui présentant le second tampon comme étant le premier. Ainsi, la plupart des programmes affichant le contenu de la mémoire ne reconnaissent pas ce trou ou l'identifie comme étant une partie du DOS.

Parmi les virus de secteur d'amorce, Joshi et EDV sont des virus furtifs avancés. A partir du moment où ils sont en mémoire, ils redirigent toutes les tentatives de lecture du secteur où ils se trouvent vers l'endroit où ils ont placé le secteur original.

EDV utilise une astuce supplémentaire. Si vous essayez de lire l'endroit où il a placé le secteur original, au cylindre 39, tête 1, secteur 8, le virus retourne une erreur de secteur défectueux. Ainsi, vous ne serez pas mis en alerte par la découverte d'un secteur d'amorce à un endroit aussi inhabituel. Le virus détecte la présence de mémoire supérieure et, si possible, se charge dans cette partie pour échapper aux logiciels affichant le contenu de la mémoire.

Joshi résiste à un démarrage à chaud (CTRL-ALT-SUPR). La plupart des utilisateurs pensent que ces touches déclenchent un redémarrage, alors qu'elles peuvent être modifiées en remplaçant l'interruption 9. Parfois, Joshi a ainsi survécu à des opérations de nettoyage effectuées par des personnes qui estimaient suffisant de réamorcer à chaud et d'exécuter un formatage bas niveau du disque dur.

Le détecteur est le pire ennemi des virus car c'est le seul outil couramment utilisé par un grand nombre d'utilisateur. Les auteurs de virus ont donc développé différentes méthodes pour dissimuler leur présence, ou au moins compliquer la tâche des détecteurs.

Le premier virus à agir en ce sens est peut-être Cascade. La majorité du virus est encryptée à l'aide de deux clés variables. La seule partie du virus qui reste constante est le décrypteur/chargeur constitué de deux douzaines d'octets qui permettent de décrypter le virus et de l'exécuter. Ce qui ne laisse au concepteur de détecteurs que 24 octets pour définir une chaîne de recherche. La plus évidente est: '141$Flu'. C'est celle que la plupart des premiers détecteurs ont choisi, mais ils n'ont pas réussi à l'encrypter. Par conséquent les détecteurs trouvaient cette séquence et donnaient des fausses alarmes. Pour éviter ce problème, pratiquement tous les détecteurs encryptent aujourd'hui leurs chaînes de recherche. Il en existe cependant toujours quelques uns qui ne le font pas ou qui n'effacent pas la mémoire après leur exécution, ce qui conduit inévitablement à des fausses alarmes. Le fait de ne disposer que de deux douzaines d'octets pour détecter Cascade aggrave ce problème.

L'escalade commence lorsque les auteurs de virus placent quelques octets variables dans le décrypteur/chargeur. Ces octets n'ont aucune action significative et peuvent donc contenir n'importe quelle instruction valide. Le détecteur doit, par conséquent, ajouter des caractères génériques dans ses chaînes de recherche, ce qui, tout en n'étant pas insurmontable, complique quelque peu le programme. Phoenix, Evil, Proud et Virus101 utilisent cette technique.

Pour rendre la détection encore plus difficile, les auteurs de virus font varier automatiquement le nombre de ces instructions non-significatives. Pour cela, ils utilisent un générateur de nombres aléatoires pour choisir l'instruction et le nombre d'itérations utilisées. C'est à ce moment que nous commençons à parler de générateur de code dans le corps du virus, destinés à créer différents décrypteurs/chargeurs de façon aléatoire. Le virus Simulate utilise cette technique. Ce qui signifie que nous devons créer un détecteur pouvant accepter un caractère générique d'une longueur variable, bien que limitée. Mais quelles sont les limites? Il est absolument nécessaire de les connaître car si nous avons, par exemple, six chaînes de recherche de trois octets à trouver dans un fichier de 64Ko, le risque de provoquer une fausse alarme est plus grand que si la zone de recherche est limitée à 100 octets. Mais il est impossible de se faire une opinion tant que le virus n'a pas été désassemblé et analysé.

Les auteurs de virus ont ensuite réalisé que dans beaucoup de cas, l'ordre des instructions n'a aucune incidence sur le résultat obtenu. Par exemple, si vous chargez le registre AX puis le registre CX, vous arrivez au même résultat qu'en chargeant les registres CX puis AX. Les auteurs de virus ont donc écrit un générateur de code créant une séquence d'instructions aléatoire. Mettez-vous à la place des développeurs d'anti-virus, il ne vous reste plus que deux solutions. Soit vous fournissez au détecteur toutes les séquences de recherches possibles, soit vous trouvez un moyen de dire au détecteur que dans une certaine limite, l'ordre des instructions n'a aucune importance. Dans ce cas encore, il est nécessaire de désassembler et d'analyser les virus pour déterminer quelles sont les limites du générateur de code. Une fois encore, le moteur de recherche de l'anti-virus devient plus complexe.

Remettez-vous maintenant à la place de l'auteur de virus qui découvre que plusieurs séquences de code complètement différentes peuvent avoir exactement le même but. Par exemple, pour copier le registre CS dans le registre DS:

Push CS

Pop DS

ou

Mov AX, CS

Mov DS, AX