Obligement - L'Amiga au maximum

Vendredi 29 mars 2024 - 00:12  

Translate

En De Nl Nl
Es Pt It Nl


Rubriques

Actualité (récente)
Actualité (archive)
Comparatifs
Dossiers
Entrevues
Matériel (tests)
Matériel (bidouilles)
Points de vue
En pratique
Programmation
Reportages
Quizz
Tests de jeux
Tests de logiciels
Tests de compilations
Trucs et astuces
Articles divers

Articles in english


Réseaux sociaux

Suivez-nous sur X




Liste des jeux Amiga

0, A, B, C, D, E, F,
G, H, I, J, K, L, M,
N, O, P, Q, R, S, T,
U, V, W, X, Y, Z,
ALL


Trucs et astuces

0, A, B, C, D, E, F,
G, H, I, J, K, L, M,
N, O, P, Q, R, S, T,
U, V, W, X, Y, Z


Glossaire

0, A, B, C, D, E, F,
G, H, I, J, K, L, M,
N, O, P, Q, R, S, T,
U, V, W, X, Y, Z


Galeries

Menu des galeries

BD d'Amiga Spécial
Caricatures Dudai
Caricatures Jet d'ail
Diagrammes de Jay Miner
Images insolites
Fin de jeux (de A à E)
Fin de Jeux (de F à O)
Fin de jeux (de P à Z)
Galerie de Mike Dafunk
Logos d'Obligement
Pubs pour matériels
Systèmes d'exploitation
Trombinoscope Alchimie 7
Vidéos


Téléchargement

Documents
Jeux
Logiciels
Magazines
Divers


Liens

Associations
Jeux
Logiciels
Matériel
Magazines et médias
Pages personnelles
Réparateurs
Revendeurs
Scène démo
Sites de téléchargement
Divers


Partenaires

Annuaire Amiga

Amedia Computer

Relec


A Propos

A propos d'Obligement

A Propos


Contact

David Brunet

Courriel

 


Dossier : Le virus SHV (Saddam Hussein Virus)
(Article écrit par Xavier Leclercq et extrait d'Amiga News - juin 1991)


SHV : le virus le plus virulent sur Amiga

Bref historique

Le tout premier virus sur Amiga, le SCA, avait engendré de très nombreuses émules : copies à peu près conformes où seul le texte trahissant la nature peu recommandable "du fléau mutant" changeait à l'écran. La technique de reproduction étant alors la première du genre (reproduction uniquement de démarrage à démarrage), il est donc logique qu'elle ait été copiée ; en effet, elle était révolutionnaire même si en fait elle était très simple... et pas très dangereuse car la reproduction n'était alors possible qu'à la réinitialisation.

Quant à la deuxième technique de reproduction (déviant un vecteur appelé DoIo qui intercepte chaque ordre de lecture/écriture utilisé par le trackdisk.device pilotant les unités de disquettes) elle est "historiquement" revendiquée par un Allemand qui, à l'époque des faits, avait 16 ans lorsqu'il "inventa" cette programmation sur son virus en éprouvette : le DASA. C'était en 1988.

Certains ignorent peut-être de quoi je parle, j'ouvre donc d'abord une parenthèse avant d'avancer dans mon propos.

Comme je vous l'ai dit, selon des articles dans la presse allemande, cette jeune personne a décidé un jour de programmer un virus capable non seulement de se reproduire à chaque réinitialisation mais aussi à la moindre introduction d'une disquette dans un lecteur. Mais, comme je vais vous le rappeler plus loin, il fallait obligatoirement démarrer la disquette (lancer la disquette à partir du lecteur interne).

Une victime de ce virus DASA a décidé, en décembre 1988, de tout faire pour découvrir l'auteur du fléau qui lui avait endommagé de très nombreuses disquettes. Ce monsieur décide alors de passer une annonce dans un journal informatique pour inciter à la délation : une récompense de 1000 DM (plus de 3000 FF) sera attribuée à toute personne voulant dénoncer, avec preuves, l'auteur du virus. Au mois de novembre, il avait entre-temps porté plainte "contre X" en s'adressant à un avocat. Un peu plus tard un gamin d'une dizaine d'années lui téléphone et dénonce le jeune X. La personne qui a porté plainte se fait alors passer pour un journaliste et contacte le présumé auteur du DASA pour une entrevue. D'après lui, durant la conversation, X reconnaît les faits en précisant qu'il ne regrette rien, qu'il voulait que son virus puisse causer des dommages, etc. (il a même avoué avoir programmé plusieurs virus : le DASA et pour les autres la question reste ouverte).

En juin 1990, la plainte civile contre X se prépare. Les dommages causés par le DASA sont estimés à 170 000 DM ! Je ne sais pas la suite mais sans doute que l'affaire est toujours en cours... Je ferme la parenthèse.

Le Saddam est le deuxième d'une nouvelle génération

Bref, même si le DASA et ses émules étaient très contagieux, ils ne pouvaient être actifs en mémoire qu'en démarrant sur la disquette. Après cette génération, il y a eu les virus Links (IRQ_Team), les chevaux de Troie, les bombes logiques et des virus d'amorce de plus en plus virulents (série des Lamer Exterminators).

Enfin, il y a quelques mois, je vous annonçais un premier spécimen d'une nouvelle génération complètement révolutionnaire. C'était en effet la découverte (ce fut un choc) du virus Return Of Lamer Exterminator (ROLE). Ce virus était, en outre, le premier à s'introduire en mémoire sans besoin de démarrer la disquette ! Il suffit d'introduire une disquette vérolée dans n'importe quel lecteur pour que le fléau s'infiltre automatiquement dans votre système !

Concrètement, pour les septiques :

1. Formater une disquette.
2. Créer un répertoire "1" sur cette disquette.
3. Copier un disk-validator dans ce "1".
4. Éditer le disk-validator (par exemple en utilisant un éditeur hexadécimal de fichier) et modifier à partir du décalage 36 (=$24) les octets qui deviennent ainsi : $33fc 0f00 00df f180 60f6 (commande "e" du C-Mon).
5. Sauver le résultat dans l:disk-validator de cette disquette.
6. Éditer la piste 40 de cette disquette et modifier à partir du décalage 312 (=$138) la suite d'octets $ffff ffff (= -1 valid bitmap) en $0000 0000 (= invalid bitmap). Calculer la nouvelle somme de contrôle (commande "k" du C-Mon). Sauver le résultat piste 40.
7. Protéger la disquette contre l'écriture, la retirer et l'insérer dans un lecteur (n'importe lequel).

A ce moment précis, le faux disk-validator que nous avions bricolé sera chargé et l'écran clignotera rapidement en rouge... (pour sortir, il faut réinitialiser).

Comme le SCA où le DASA, il était à prévoir que le ROLE (Return Of Lamer Exterminator) crée à nouveau ses propres émules. Je peux donc vous annoncer la découverte d'un deuxième type de virus de cette génération qui est baptisé : le virus Saddam Hussein.

Ce SHV est plus virulent que le ROLE. Après l'avoir désassemblé, je peux déjà vous dire que son auteur n'est sans doute pas le même que le ROLE mais à étudier ses méthodes de programmation.

Un curieux "port"

Tout d'abord, tout comme le ROLE, il s'inscrit dans les 1848 octets du disk-validator. Avant de vous exposer "son petit manège" en mémoire, je vais vous parler en deux mots d'un fait très, très curieux. Il s'agit d'un test qu'effectue le SHV avant de s'installer dans le vecteur ColdCapture qui permet au virus de rester présent en mémoire après une réinitialisation. Le virus teste en effet si le "port" (moyen de communication sur Amiga entre différentes tâches) du nom de "mycon.write" est présent avant de prendre le contrôle de ce vecteur. Si "mycon.write" est détecté, alors le virus ne résistera pas à la réinitialisation.

Mais lorsque pour la première fois le SHV infecte la mémoire, c'est-à-dire si vous avez introduit une disquette vérolée dans un lecteur, il ne crée pas de "port" de ce nom. Donc c'est que l'auteur du SHV pensait sans doute que dans certains cas son virus pouvait rencontrer un port "mycon.write" émanent d'un autre programme d'un nom inconnu... C'est en effet une manière de "protéger" l'utilisateur de ce programme contre une reproduction du virus...

Reproduction à chaque insertion

Le grand changement est que, non seulement le fait d'introduire une disquette vérolée infectera automatiquement la mémoire, mais aussi la moindre insertion d'un disquette, au départ saine mais déprotégée en écriture, provoquera son infection !

Le virus Saddam Hussein est donc le virus le plus virulent jamais inventé sur Amiga. Encore heureux qu'il ne s'attaque pas au disque dur !

Le cycle du SHV

1. Insertion d'une disquette vérolée dans n'importe quel lecteur suivant le même procédé que le ROLE (l'Emflag, c'est-à-dire le décalage 312 qui détermine la validité du bitmap, a la valeur "False", ce qui force le chargement du disk-validator (et donc du virus) de la disquette insérée. Pour plus de détails allez (re)lire ce qui a été dit sur le ROLE (je ne reprends donc pas les parties communes aux deux virus).

2. Si "mycon.write" n'est pas présent en mémoire, déviation du ColdCapture.

3. En attendant la réinitialisation, le RasterBeam (rafraîchissement vertical, alias "vertical blanking") est dévié et vérifie que BeginIO() et ColdCapture sont bien déviés par le virus. Après un certain temps (l'intervalle entre deux interrupts étant de 1/50s) déclenchement d'un gourou où est affiché "Saddam Virus" tout en faisant jouer des sons pas très mélodieux aux têtes de lecture en les baladant d'un bout à l'autre de la disquette très rapidement.

4. En cas de lecture d'un bloc de données (T.DATA type) le virus Saddam Hassein peut le détruire comme bon lui semble : il écrira "Irak" dans le bloc à la manière des Lamer Exterminators. En cas de lecture du bloc d'amorce, il rendra un "bloc d'amorce codé" peut-être pour faire croire à celui qui le traque qu'il se cache dans le bloc d'amorce... (il change également l'Emflag mais cette routine est identique au ROLE).

5. Non seulement le SHV est le plus virulent des virus mais aussi le plus résistant car à la réinitialisation, il ne pratique pas comme les autres virus. La routine du ColdCapture dévie CoolCapture (déjà assez rare car les virus un peu compliqués utilisent le KickTagPtr). La routine CoolCapture dévie InitResident(). Et c'est là l'astuce suprême qui lui permet de résister à pratiquement n'importe quoi : les antivirus classiques sont appelés par InitResident et c'est alors qu'ils testent si un virus est présent en mémoire ! La plupart ne trouveront alors rien sans deviner qu'il ont été installés par le virus lui-même ! En fait, le SHV attend tranquillement la fin de l'installation de tous les programmes résidents. Pour ce faire, il testera le dernier de ce type : le BootStrap qui démarre le processus de démarrage de la disquette.

Saddam Hussein Virus

C'est tellement génial (enfin c'est une manière de parler) qu'il est très difficile de se débarrasser du SHV sans éteindre la machine ! Même une réinitialisation longue classique sera sans effet. Il faut modifier légèrement la manière de procéder (évidemment je parle de la réinitialisation).

6. La phase de reproduction se fait, quant à elle, à chaque insertion où démarrage d'une disquette en utilisant le CloseTrack(). A l'insertion d'une disquette, le SHV vérifie chaque lecteur de DF0: à DF3: (mais pas les disques durs). Et s'il trouve une disquette qui pour son malheur est déprotégée, il se reproduira dessus (DFx:l/disk-validator) en créant (comme le ROLE) le répertoire ":l" si nécessaire. Le SHV avant reproduction vérifie son éventuelle présence dans le :l/disk-validator. Il ne se reproduit donc pas deux fois consécutives sur une disquette infectée. Le SHV utilise "la bibliothèque interne du DOS" pour se reproduire le plus rapidement possible en essayant d'être le plus discret possible.

La bibliothèque DOS interne

En fait (et vous n'obtiendrez plus ces informations dans la Bible De L'Amiga), au lancement de chaque commande CLI/Shell, vous trouvez dans le registre A2 un pointeur de cette bibliothèque DOS interne. Toutes les fonctions utilisées par le SHV pour lire/écrire sur la disquette résultent des appels de cette bibliothèque interne. C'est aussi de cette manière que vos commandes CLI/Shell utilisent les fonctions du DOS. Voici comment le SHV crée le répertoire ":l" à partir de ces fonctions internes :

Saddam Hussein Virus

Tous ces décalages ne sont pas repris par Commodore et ne se retrouvent nulle part. En désassemblant le SHV (idem pour le ROLE), il m'a fallut retrouver les fonctions qui correspondent. Simulation de Wait 5 :

Saddam Hussein Virus

Oubliez cette façon de programmer mais sachez qu'elle existe...

Protection ?

Comment se protéger du SHV ? En attendant les antivirus adéquats, si vous êtes la malheureuse victime du SHV, pour l'enlever de la disquette, il vous faut dans l'ordre :
  • Restaurer le RasterBeam() et le beginIo().
  • Changer le "False" de l'Emflag de la racine en "True".
  • Recalculer la somme de contrôle de la racine et la sauver.
  • Remplacer le disk-validator vérolé par un sain.
Conclusion

Je redoute un troisième virus de ce type qui aurait la possibilité de s'attaquer au disk-validator du disque dur (et c'est malheureusement réalisable assez facilement !). Si cela se produit, il me semble alors pratiquement impossible de se protéger contre par exemple le formatage du disque dur dès l'insertion d'une disquette vérolée dans n'importe quel lecteur !

Espérons que nous n'en arriverons jamais là ! Et peut-être que le plus dramatique est encore à venir ! Mais avec des "si" on pourrait reconstruire le monde...


[Retour en haut] / [Retour aux articles]