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 - fonctionnement d'une tâche (exemple du virus DiskDoctors)
(Article écrit par Xavier Leclercq et extrait d'A-News (Amiga News) - juin 1990)
|
|
Tâche
C'est quoi monsieur une tâche (task) ? Eh bien, je pourrais vous répondre du task au task un processus possédant son
propre environnement (registres, pile, mémoire) en cohabitation avec d'autres processus. Pour plus de détails
théoriques, jetez un oeil sur notre article "Voyage au centre de
la ROM".
Évidemment, comprendre la théorie reste un plaisir intellectuel à quoi l'apport de la pratique en donne toute sa saveur.
Tout est pratique du multitâche sur Amiga à commencer par les fenêtres du CLI. C'est justement ce multitâche
qui permet au virus DiskDoctor (alias (c)Rack Right) de prendre toute sa force virulente. C'est, en effet, le premier
virus à créer sa propre tâche appelée "clipboard.device" pour lui permettre d'ignorer les antidotes classiques qui
l'éjecteraient hors de la mémoire.
Les propos de Steve Tibbet (auteur de VirusX) concernant DiskDoctor portent lourd à sa réputation :
"très compliqué à comprendre !" Ce qui nous intéresse est la partie "tâche" du virus. Je vais vous en
expliquer le fonctionnement et il ne vous restera plus aucun obstacle pour programmer vos propres tâches.
Un mot d'abord sur le virus
DiskDoctor ne fonctionne que sous les ROM 1.2. Malgré cela, je trouve que dans l'ensemble,
le virus a été bien programmé (malheureusement). Il prendra de plus en plus de mémoire à chaque
réinitialisation et finira par "planter" la machine.
De plus, le formatage de la piste 40 est effectué après un certain nombre de redémarrages.
La cohabitation de tâches
Ce qui retiendra ici notre attention est, comme je l'ai déjà expliqué, la manière qu'il
utilisera pour résister au maximum à l'antivirus : il se fixera à une tâche
appelée "clipboard.device". Le type "device" est donc ici un faux device. Toute structure
"Task" possède à la base une structure "Node" (un noeud). Ce noeud peut avoir de nombreux
types différents : NT_TASK (01), NT_DEVICE(03), NT_RESOURCE (08), etc.
Mais évidemment pour une tâche, ce type est 01 = NT_TASK. Le type est déterminé au décalage
8 de la structure "Node". Suit la priorité (décalage 9) et le pointeur sur le nom du "Node"
(décalage 10 = ln_Name).
Le "Node", c'est un cordon entre toutes les tâches du système, tous les devices, etc.
Lorsque plusieurs "Nodes" sont reliés ensemble, on parle de "Liste". L'Amiga possède quelques fonctions
de bibliothèques pour les gérer : Insert, Remove, AddHead, RemHead, Addtail, RemTail, Enqueure, FindName...
Ce n'est pas pour rien qu'il y au moins 256 ko de ROM !
Les "Nodes" sont utilisés énormément par l'Amiga : device, tâche, gestion mémoire. Une liste est
une série de structures "Node" reliées entre elles par un pointeur qui pointe sur le suivant et un
autre sur le précédent (décalage 0 et 4). Chaque liste possède également une première structure
ln_Head. C'est cette première structure dont je vous parle actuellement et qui est utilisée lors
de l'ajout d'une tâche au système avec l'instruction "AddTask".
La "priorité" est un nombre dont la valeur peut s'étaler de -128 à +127 (les priorités système s'étalent
de -20 à +20). Lorsque l'Amiga passe d'une tâche à l'autre, l'environnement est sauvé (comme pour une
interruption) et le "Program Counter" saute à une nouvelle tâche de priorité plus grande. En fait,
la priorité détermine directement le temps processeur qui sera alloué à la tâche ("task-scheduling").
Lorsqu'une tâche est en fonctionnement, elle est en mode "running" (2) et si elle désire un pointeur
de la tâche en cours, c'est évidemment son propre pointeur qui lui est transmis. Une fois exécutée,
elle attend de nouveau son tour dans une liste. Elle se trouve alors en mode "waiting" (4) et c'est
le chef que l'on appelle le "Scheduler" qui lui redonnera vie en fonction des priorités affectées.
Si vous voulez la retirer des listes du "Scheduler", c'est-à-dire l'enlever définitivement, il
vous faut utiliser l'instruction "RemTask". La structure "Task" sera commutée en mode (6) "removed".
A la suite de la structure "Node" se trouve la structure "Task" proprement dite. La structure est bien
expliquée dans l'ouvrage "La Bible de l'Amiga". J'ajouterai que l'ouvrage que je possède donne
un mauvais détail des registres utilisés par "AddTask", c'est en fait Addtask (Task (a1), Initia1PC (a2),
FinalPC (a3))...
Un mot sur le programme qui nous servira d'illustration
Cette partie est (à quelques octets de différences) la routine utilisée par le virus DiskDoctors.
Le programme commence par réserver la mémoire qui contiendra le code de la tâche (StartTask...)
et l'espace réservé à son environnement (pile). Après avoir recopié les routines, il sautera (JMP)
au point d'entrée de la routine qui ajoute une tâche au système (AddTask).
"FinalPC", argument transmis à la fonction "AddTask", se trouve à zéro lorsque vous décidez de sortir de
la tâche en utilisant une routine dont la ROM a le secret... La mémoire qui est réservée par le SP,
la limite inférieure et supérieure de la pile sont respectivement tc_SPReg, tc_SpLower et Tc_SpUpper.
Si vous insérerez une disquette dans n'importe quel lecteur, la piste 0 est lue et le bit 4 de $bfe001
est retiré, ce qui éteindra la LED au traitement suivant. Donc cette tâche commute l'état de la LED
(on/off) à chaque insertion d'une disquette dans n'importe quel lecteur.
Pour enlever la tâche,
il suffit de cliquer sur le bouton gauche de la souris. La tâche passe en mode (6) "removed". Les
modes sont lus en tapant "q a1" au Seka (15e octet = Tc_State). Attention "A-News.device" n'est pas
un "device" mais bien une tâche. Pour changer le nom, il suffit de faire pointer "ln_Name"
sur un autre message.
Le multitâche est enlevé avec la fonction "Forbid()" de exec.library et remise en marche avec "Permit()".
Vous pouvez donc monopoliser le temps système en interdisant l'accès des autres tâches
au processeur dans vos intros ou programmes utilisant beaucoup de temps à ce processeur.
|