DCMOTO - Emulateur universel Thomson 8 bits : Forum - Programmation

Auteur

Message

Daniel
Visiteur

Date : 15/05/2005 à 09h40

C'est la suite de la discussion commencée ici
Pour comprendre, il faut connaître les principes de bases du fonctionnement du MO5 (voir Assembleur et Périphériques à la page Documentation du site dcmoto) et la structure des fichiers sur cassette MO5 (voir section FAQ du forum de dcmoto).

Première partie : le programme "LOADEUR"

Dans toute protection de cassette, le premier programme doit pouvoir être lu par les routines standard du moniteur. C'est le cas pour Vampire, encore que ce programme ait quelques particularités que l'on peut noter :

- le nom de fichier : 0C 4C 4F 41 44 45 55 52 20 20 21 .LOADEUR !
Comme il n'y a pas de caractère interdit dans les noms de fichier Thomson, on peut mettre des séquences de caractères interprétées par le moniteur lors de l'affichage. Ici c'est le caractère 0C, qui provoque l'effacement de l'écran.

- la taille du bloc 00 : &H2B
Normalement le bloc 00 a une taille de 16 octets. Ici, il y a 27 octets supplémentaires. C'est un "Cheval de Troie" permettant d'introduire un petit programme en mémoire sans se faire remarquer. Nous verrons plus loin le contenu de ces 27 octets.

Le bloc 01 contient deux segments 00 :

- Premier segment 00 : 00 03 20 00 7E 22 A8
C'est le programme principal. Il contient 3 octets chargés en &H2000. Remarquons que c'est l'adresse des vecteurs réservés du Basic. En se chargeant, ce programme les détruit, ce qui rend ensuite le Basic inutilisable (pour les petits malins qui voudraient lire le programme avec des PEEK).
Listing du programme principal : 2000 7E22A8 JMP $22A8

- Deuxième segment 00 : 00 01 21 99 01
C'est l'auto-run. En mettant le bit 0 de l'octet &H2199 à 1, le Basic fait un EXEC automatique après le LOADM. Si on a tapé la commande LOADM, elle est interprétée comme LOADM"",,R. Il n'y a aucun moyen de charger le programme sans qu'il démarre, donc on ne peut pas le lister car il va s'auto-détruire.

Le bloc FF est totalement standard : 2000 est l'adresse d'exécution.

Examinons maintenant le "Cheval de Troie". Il suffit d'utiliser le debugger de dcmoto, avec un point d'arrêt en &H2000. En &H22A0 on trouve une zone de travail du Basic, qui contient le bloc FF venant d'être lu : 00 00 20 00. Et après, on retrouve les fameux octets du bloc 00, qui n'ont pas été écrasés car tous les segments suivants étaient plus courts. C'est le programme exécuté par le JMP $22A8 du programme principal.

22A8 318DFFFF LEAY $22AB,PCR
22AC 8601...... LDA #$01
22AE 3F22....... SWI #$22
22B0 8E0064... LDX #$0064
22B3 3F20....... SWI #$20
22B5 301F....... LEAX -$01,X
22B7 26FA....... BNE $22B3
22B9 39.......... RTS

Je vous laisse le méditer jusqu'au prochain épisode...

Daniel

en haut - en bas

Daniel
Visiteur

Date : 29/05/2005 à 21h31

Rappel : Le fichier .wav de la cassette originale est à la page Programmes du site dcmoto.

Deuxième partie : le chargement du chargeur

En étudiant le programme en &H22A8 vous dites : trop facile, il lance le moteur du magnétophone par SWI #$22, puis il y a une boucle de lecture de 100 secteurs par SWI #20, et enfin retour au programme appelant par RTS.
Eh bien non ! Vous êtes tombés dans le piège. Observez l'adresse du buffer de lecture dans Y : &H22AB. Le programme s'auto-écrase avant la fin de la première boucle, il ne la termine donc jamais. Ce programme est un leurre, qui dissimule le véritable programme de chargement stocké dans le bloc FF suivant. Vous croyez qu'un bloc FF indique la fin d'un fichier ? Vous allez être surpris, ici il contient un programme ! Ce programme se charge en &H22AB. Après chargement, le compteur ordinal du 6809 est en &H22B5, qui contient :

22B5 BD237D JSR $237D

Et en &H237D, il y a 01 = instruction invalide ? Ou tout au moins inconnue dans la documentation Motorola. Nous dirons : pas officielle et pas documentée. En réalité, elle a une longueur de deux octets, un temps d'exécution de 3 microsecondes, et ne fait rien. C'est l'équivalent d'un BRN. Le programmeur 6809 n'est pas sensé la connaître, mais William Hennebois était plus malin. Il en a truffé son programme pour le rendre incompréhensible.

237D 018C
237F 308DFF35 LEAX $22B8,PCR
2383 018C
2385 3410....... PSHS X
2387 018E
2389 BF239B... STX $239B
238C 018E
238E 308900C5 LEAX $00C5,X
2392 018E
2394 018C
2396 6382....... COM ,-X
2398 018E
239A 8C2300... CMPX #$2300
239D 26F5....... BNE $2394
239F 018E
23A1 39........... RTS

Faites abstraction des instructions invalides. Vous voyez que ce programme s'auto-modifie (c'est un piège supplémentaire).
En 239A, le CMPX #$2300 est remplacé par CMPX #$22B8. Cette routine fait donc un COM sur les octets &H22B8 à &H237C, puis retourne au programme appelant. Le programme en &H22B8-237C était donc crypté. Au retour du JSR $237D il est décrypté et s'exécute.
A noter qu'un cryptage par COM est loin d'être inviolable, mais il est bien suffisant puisque personne d'autre (à ma connaissance) n'a réussi à déprotéger Vampire sur cassette MO5.

A suivre : l'analyse du chargeur, les temporisations, la taille des blocs, les segments spéciaux, etc...

Daniel

en haut - en bas

jasz Visiteur	Date : 29/05/2005 à 23h01 La technique du cryptage existait aussi sur thomson
en haut - en bas

Orion_ Visiteur	Date : 29/05/2005 à 23h34 comment c'est trop fort ces protections :D mais a quoi ça servait réellement ? puisque une simple copie de la casette avec un magnétophone/mini chaine suffisait non ?
en haut - en bas

jasz Visiteur	Date : 29/05/2005 à 23h53 Ben, c'est pas pour protéger des copies mais pour protéger les codes
en haut - en bas