Suivez-nous sur X
|
|
|
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
|
|
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
|
|
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
|
|
A propos d'Obligement
|
|
David Brunet
|
|
|
|
Programmation : Assembleur - Un traqueur de virus
(Article écrit par Frédéric Mazué et extrait d'Amiga News Tech - juin 1991)
|
|
En cette période printanière, les virus, anciens ou nouveaux, reviennent faire des dégâts. Je
sais bien que les chasseurs de virus courent les rues du domaine public, mais quand je songe
au nombre de disquettes infectées que les lecteurs m'envoient, je me dis qu'il y a encore des
choses à faire.
Voyez la situation en face : beaucoup d'utilitaires, comme VirusX pour ne citer que le plus
célèbre, signalent la présence d'un bloc d'amorce suspect. Mais s'agit-il d'un bloc d'amorce
nécessaire au démarrage d'un jeu ou d'une démo, ou bien encore d'un nouveau virus ?
Angoissante question, je me remercie, une fois de plus, de l'avoir posée.
Le problème
Il s'agit cette fois de vérifier si un programme d'amorce ou un programme normal a
l'intention de faire joujou avec les vecteurs de réinitialisation (Reset) de votre Amiga
chéri. Ceci posé, comment faire ? Cela ne peut pas se faire facilement en regardant ce
genre de programmes "à l'oeil nu", car il sont en principe codés-de diverses manières,
de façon à déjouer les regards indiscrets.
La solution
Elle consiste en un programme dont la tâche sera de charger et lancer un programme ou
un bloc d'amorce suspect puis à vérifier l'état des vecteurs Reset chaque fois
qu'une instruction du suspect sera exécuté. Pour parvenir à ce résultat, nous utiliserons
une particularité des microprocesseurs de la génération 68000 : le mode Trace.
Petit rappel
Les microprocesseurs de la génération 68000 fonctionnent suivant deux modes : le mode
utilisateur et le mode superviseur, chaque mode utilisant sa propre pile. Le mode
utilisateur est le mode normalement actif lorsqu'un programme est exécuté. Le mode
utilisateur n'a "pas le droit" d'utiliser la gamme complète du jeu d'instructions.
Les instructions interdites sont appelées instructions privilégiées.
D'autre part, en mode utilisateur, le programmeur n'a le droit d'accéder qu'au poids faible
du registre d'état SR. Cette partie poids faible est nommée sous-registre ou registre CCR
et contient les drapeaux arithmétiques : Zero, Carry, etc.
Le mode superviseur est en principe réservé au système d'exploitation de l'ordinateur. Lorsque
le microprocesseur fonctionne sur ce mode, il est possible d'utiliser le jeu d'instruction au
complet. De même, il est possible d'accéder à la totalité du registre SR, dont le poids fort
contient des drapeaux représentant l'état du microprocesseur.
Que se passe-t-il si...
Que se passe-t-il si l'on essaie d'utiliser une instruction privilégiée depuis le mode
utilisateur ? Eh bien dans ce cas, le microprocesseur considère qu'il s'agit d'une faute
du programme, se met de lui-même en mode superviseur, puis saute dans le vecteur de bas
de mémoire correspondant à la situation. Dans ces vecteurs de bas de mémoire, sont
installés les convertisseurs de Trap d'Exec, qui débouchent finalement sur le Gourou
si la tâche coupable d'avoir utilisée une instruction privilégiée n'a pas auparavant signalé
la présence d'un convertisseur de Trap qui lui est propre. C'est ce procédé que nous
avons utilisé dans le Gourou Interceptor.
Le bit Trace
Dans le registre SR existe un bit appelé T. Ce bit est normalement à 0. S'il est à 1,
chaque fois que depuis le mode utilisateur, le microprocesseur exécute une instruction,
il passe en mode superviseur puis saute dans le vecteur d'exception d'adresse $24.
Voilà donc une excellente possibilité de contrôler pas à pas si un programme va attaquer
la réinitialisation.
Activation de la Trace
Ça c'est facile. Exec nous offre la possibilité de passer sans se fatiguer en mode superviseur
grâce à la routine SuperState, dont le principe de fonctionnement est de déclencher une
exception, de la récupérer à peu près comme expliqué plus haut, puis de revenir au programme.
Bref, nous voilà maintenant en mode superviseur. Nous avons accès au registre SR dans sa
totalité et c'est un jeu d'enfant que d'activer la trace en plaçant le bit T puis de revenir
en mode utilisateur à l'aide de la routine UserState, qui fait exactement l'inverse de la
précédente.
Mais attention : nous ne pouvons nous limiter à cela car maintenant, le microprocesseur va
sauter dans le vecteur d'adresse $24 dès la première instruction exécutée, et nous aurions
droit à un Gourou n°9.
Peut-on intercepter ce Gourou comme nous l'avions déjà fait en installant un convertisseur
de Trap sur notre tâche ? Hélas non, car dans ce cas, et c'est le seul, Exec ne regarde pas
si nous avons installé un convertisseur de Trap, mais envoie systématiquement le Gourou.
Il est donc malheureusement nécessaire de modifier nous-mêmes le vecteur de saut, en le
détournant sur notre routine de test. C'est bien sûr dans cette routine que nous allons
vérifier si les vecteur Reset sont attaqués. Il est regrettable d'être obligé de procéder
ainsi, car toutes les tâches sont de ce fait en mode Trace, ce qui ralentit considérablement
la machine et limite l'utilisation de notre programme à un test pur et non à un emploi
permanent.
Le programme
C'est maintenant tout simple. Il peut être appelé depuis le CLI ou le Workbench.
Premier cas
Appel depuis le Workbench ou depuis le CLI sans paramètres. Dans ce cas, il
est fait appel au trackdisk.device pour charger les secteurs d'amorce en df0:. On
vérifie que la disquette est bien auto-amorçable, on installe la routine de traçage comme
expliqué plus haut puis on saute dans le programme d'amorce (boot). Si cette amorce
contient un virus, une alerte vous en informera immédiatement.
Vous aurez le choix de continuer
ou de tuer le virus de façon certaine, mais attention : en mémoire seulement. Il ne faut donc
pas redémarrer la disquette infectée. Vous devrez la nettoyer avec un utilitaire quelconque,
ou tout simplement la commande "Install" du CLI (il faut également que je vous prévienne que
si c'est l'amorce d'une démo que vous testez, il est probable que vous aurez la visite du
Gourou. Mais dans tous les cas, s'il s'agit d'un virus, vous serez prévenu avant).
Deuxième cas
Vous lancez le programme depuis le CLI en donnant comme paramètre un nom de fichier. Si
ce fichier existe, et s'il est exécutable, on le charge en tant que segment puis l'on saute
dans le programme. En cas de virus coquille, l'alerte apparaît.
Un essai
Le petit programme virus n'en n'est bien sûr pas un, mais se contente de mettre une
valeur dans un vecteur Reset. Vous pourrez vérifier ainsi sans risque que tout fonctionne bien,
en tapant depuis le CLI.
Notre programme est capable de tester tous les programmes "normaux" mais ne peut pas fonctionner
avec les commandes du répertoire C: de la disquette Workbench, ceci à cause de la conception
même de ces programmes. Mais si vous êtes un fidèle lecteur, vous disposez déjà du programme
Sentinelle, qui, lui, convient très bien. En fait,
le programme de ce mois est surtout intéressant pour tester les blocs d'amorce.
La routine Reset
Toujours si vous êtes un fidèle lecteur, vous verrez que la routine Reset du programme est
très différente de celle recommandée dans l'article
Faisons une réinitialisation avec le sourire.
Pourquoi ? Simplement parce que l'ancienne routine n'était valable que pour un Amiga avec
microprocesseur 68000. La routine de ce mois convient à tout Amiga. Elle est directement
issue de la dernière révision des Amiga ROM Kernel Manuals.
Enfin une dernière chose : si vous avez installé le RAD: ne craignez rien, le Traqueur le
reconnaît et le réinstalle dès qu'il rend la main (NDLR : ce qui n'était pas le cas de la
Sentinelle, la honte soit sur Frédéric jusqu'à la 13e génération !).
|
