Protection des jeux Thomson

[Daniel]

Vingt ans après, on peut estimer que parler de la protection des jeux Thomson n'est plus du piratage, mais de l'histoire

Pour ma part je connais pratiquement tout des protections de cassettes MO5, depuis la simplissime protection des programmes Basic (j'ai écrit un décrypteur) jusqu'à la génialissime protection de 3DFight (je l'ai adapté pour DCMO5). Par contre, je ne connais rien de la protection des disquettes TO, car j'ai eu mon premier TO8D il y a 4 jours, autant dire que je suis un débutant absolu. Voilà...

Pour lancer la discussion, qui peut dire comment Infogrames protège ses disquettes, par exemple le pack "Les Athlètes 1" ?

Daniel

[coimbrap]

Moi non, mais j'aimerai bien en savoir plus :
où peut on se procurer ton décrypteur ?
y a t-il un site où sont présentées en détail ces protections que l'on puisse analyser la structure et même l'esprit ?

[Daniel]

où peut on se procurer ton décrypteur ?

http://dcmo5.free.fr/uti/dcprobas.exe
Il lit en entrée un fichier binaire contenant un pogramme Basic Thomson (TO ou MO, Basic 1 ou 128 ou 256). Le format est celui des fichiers sur disquette. Pour une cassette MO5-MO6, il faut d'abord la transformer en fichier disquette avec dck72dsk.exe téléchargeable à http://dcmo5.free.fr . Pour une cassette TO7-TO8-TO9 il y aura bientôt un programme identique sur le site de mon nouvel émulateur DCTO7.
Si le programme Basic est protégé, dcprobas le déprotège. S'il n'est pas protégé, il le protège. Mais dcprobas n'est pas le seul moyen : il est plus simple de charger le programme dans DCMO5, et dans le menu "Mise au point" décocher la case "protection".

y a t-il un site où sont présentées en détail ces protections que l'on puisse analyser la structure et même l'esprit ?

Eh non, malheureusement C'était considéré à tort comme du piratage, alors que c'est un très bon jeu d'aventure

Daniel

[Daniel]

y a t-il un site où sont présentées en détail ces protections que l'on puisse analyser la structure et même l'esprit ?

On va dire que ce site est My Silicium , mais ils risquent des ennuis avec la police

Pour commencer le plus simple : mettre une checksum non standard, et modifier l'algorithme de contrôle pour qu'il l'accepte.
Il faut connaitre la structure des fichiers cassette (voir les FAQ de http://dcmo5.free.fr ). Le dernier octet de chaque bloc est la checksum, calculée par une formule simple : la somme modulo 256 des octets utiles du bloc (y compris la checksum) doit être nulle.
Le principe est de recopier dans le programme la routine système de lecture d'un bloc, et de changer les 2 ou 3 instructions de contrôle de la checksum. Par exemple on dit qu'elle doit être la somme modulo 256 des octets précédents. Pour charger le programme on appelle cette routine modifiée au lieu d'appeler la routine officielle.
Tous les autres programmes de chargement ou de copie utilisant les routines de lecture standard trouvent la checksum mauvaise et s'arrêtent avec la fameuse erreur 53 (erreur de lecture).

Mais finalement c'est peut-être pas très astucieux d'expliquer tout ça. C'est plutot en trouvant soi-même qu'on se fait plaisir. Faut-il continuer

Daniel

[coimbrap]

Oui, parce que perso, le temps que je consacre à nos vieilles babasses est dédié aux Amstrad. Je ne trouverai donc jamais ce genre de trucs sur MO ou TO

[Daniel]

Oui...

Alors une petite anecdote sur la protection infogrames :

Après la création des sites DCMO5 et DCMO6, j'ai eu quelques contacts avec des auteurs de programmes. Parmi eux les bons : Pascal Bacoux, Pascal Pellier, Gérard Banel, et les meilleurs (opinion personnelle) : Didier et Olivier Guillion, William Hennebois.

Dès la sortie de DCMO6, ce dernier a voulu exécuter Prohibition (son chef-d'oeuvre) avec l'émulateur. Il a donc essayé de détourner la protection (géniale) qu'il a lui-même inventée, probablement en 1985. Mais il avait oublié un de ses pièges, et n'a pas réussi. Ne sachant pas comment faire, il m'a demandé de le convertir. Vous imaginez ma jubilation, juste récompense des heures passées sur Sorcery, Vampire, Sortilèges, Saphir et les autres, à l'époque du MO5, quand on n'avait pratiquement aucun outil, qu'il fallait tout programmer soi-même, et que le moindre jeu mettait plus de dix minutes à se charger !

Daniel

[Daniel]

Protection des programmes Basic

Les programmes Basic ont l'avantage d'être faciles à écrire et l'inconvénient d'être lents.
Mais quand la vitesse d'exécution n'est pas recherchée, ce n'est pas une honte d'écrire quelques lignes de Basic, et de très bons programmeurs l'ont fait. Pour vous en convaincre, regardez le concours de deuligne à http://dcmo5.free.fr
Pour protéger un programme Basic, on utilise souvent la technique suivante :
En mémoire, les lignes du programme sont chaînées : chaque ligne est précédée d'un pointeur contenant l'adresse du début de la ligne suivante. La longueur d'une ligne n'est limitée que par la taille mémoire disponible.
Par contre, l'éditeur Basic ne peut pas traiter les lignes de plus de 255 octets. S'il en trouve une, il n'affiche que les 255 premiers, et si on cherche à la modifier il la tronque à 255. L'astuce consiste à écrire tout son programme dans une seule ligne, qui aura la longueur du programme, par exemple 25000 octets. Si on le liste, on ne voit que les 255 premiers, et si on le modifie on perd les 24745 suivants.

Daniel

PS: Arrêtez-moi si ce monologue vous fatigue . Et répondez s.v.p. à la question du premier post, sinon je vais avoir le plaisir de chercher moi-même la réponse

[yvesffr]

PS: Arrêtez-moi si ce monologue vous fatigue

Salut,

non non au contraire, moi je trouve ca super interessant,
ne connaissant rien aux Thomsons ca me permet de me "cultiver"
sur le sujet !

Yves

[destroyedlolo]

L'astuce consiste à écrire tout son programme dans une seule ligne, qui aura la longueur du programme, par exemple 25000 octets. Si on le liste, on ne voit que les 255 premiers, et si on le modifie on perd les 24745 suivants.

Heu ... mais ca empeche les GOTO/GOSUB et autres joyeusetes non ?

Tien, d'ailleur j'imagine que ca fonctionnerait aussi sur des pocket Sharp, mais restera quant meme une limite a 255 caracteres (il n'y a pas de pointeur sur la ligne suivante mais un octet qui contient la taille de la ligne). L'editeur ne gere que 80 caracteres.

[Daniel]

Heu ... mais ca empeche les GOTO/GOSUB et autres joyeusetes non ?

Oui, c'est juste, ça rend l'exercice très très difficile. Mais avec des FOR...NEXT on arrive presque à faire de la programmation structurée. Par exemple on fait une boucle FORI=0TO1STEP0, et quand on veut en sortir on fait I=1. Evidemment ce n'est pas très pratique. Le pire, c'est pour les IF. Le MO5 ne connait pas l'instruction ENDIF, c'est la fin de la ligne qui en tient lieu. Donc avec une seule ligne dans le programme on galère pas mal (heureusement il y a le ELSE). On peut aussi faire des variantes : par exemple 5 lignes d'environ 5000 octets au lieu d'une de 25000, et ça t'ouvre les possibilités de GOTO et de GOSUB. Quand tu vois qu'on peut écrire Pictor en "deuligne" (cf mon site), on doit pouvoir faire un éducatif de français en 5. Mais je te l'accorde, c'est du sport de haut niveau.

Daniel

[Daniel]

Les codes opération invalides.

Les instructions du 6809 sont codées sur un octet, ou sur deux octets avec un pré-octet 10 ou 11 (hexa). Au total 768 possibilités.
La bible du programmeur 6809 est le "MC6809-MC6809E Microprocessor Programming Manual" (voir http://dcmo5.free.fr/onlinedoc ). Il décrit environ 300 instructions. Les 470 codes restants sont qualifiés de "code opération invalide". Si le programmeur étourdi en glisse un dans son programme, il a de fortes chances de se planter. Mais ces codes opérations ne sont pas si invalides qu'on le dit. Ils font tous quelquechose, au minimum ils incrémentent le compteur ordinal d'une ou plusieurs unités. D'après mes tests, chaque code opération invalide fait une opération valide. Le problème, c'est que même les bons programmeurs ne savent pas quoi. Certains codes invalides sont décrits (voir le très bon site d'Arto Salmi sur le 6809), mais il en reste des centaines qu'aucun désassembleur ne connait (sauf une version très personnelle du mien ). D'où l'idée des programmeurs de protections : utiliser des codes opération invalides dans leur programme, pour que personne (sauf les initiés) ne puisse le comprendre.

Daniel

[Daniel]

non non au contraire, moi je trouve ca super interessant

Alors je continue, mais comme le sujet est inépuisable on risque d'avoir un fil un peu long...

Quand on écrit un programme de protection, on cherche souvent à le cacher : s'il n'est pas visible, il sera beaucoup plus difficile à comprendre. Une bonne cachette dans le MO5 est la mémoire video (idem pour les autres Thomson, mais sur les TO l'adresse est différente). Elle est composée de deux banques de 8 Ko se partageant les adresses 0000-1FFF. La première banque est utilisée pour stocker les couleurs, la deuxième pour les "formes" (dans le language de Thomson la "forme" définit si un pixel a la couleur d'écriture ou la couleur de fond). Mais les couleurs, comme les formes, n'occupent que 8000 octets. Il reste donc 8K - 8000 = 192 octets inutilisés dans chaque banque, soit au total 384 octets. De quoi loger un joli petit programme. Il faut toutefois se méfier de la sélection de la banque video, qui peut intempestivement commuter d'une banque à l'autre au gré du bit 0 du registre A7C0. Mais le programmeur Thomson connait bien ce mécanisme, et s'en accommode sans problème !

Daniel

[rene]

vazy mon gars, le piratage, il n'y a que ca de vrai.
Et c'est mieux que les concours de poeme ou les bordées d'insultes.

[Daniel]

vazy mon gars, le piratage, il n'y a que ca de vrai.
Et c'est mieux que les concours de poeme ou les bordées d'insultes.

Ou les préservatifs pour clavier
Si le prez me pousse au vice, il ira rejoindre les pirates en prison, et nous lui apporterons des oranges. Alors je continue...

Encore plus subtil :

Quand la couleur d'écriture et la couleur de fond sont identiques, on ne voit pas ce qui est écrit à l'écran (dans la mémoire "forme"). On n'y voit que du bleu (ou du noir, du jaune, du vert etc.). On peut donc en profiter pour mettre ce que l'on veut dans cette banque video, et pourquoi pas un programme de protection. Et là, plus de limite à 384 octets, on dispose d'un espace confortable de 8 Ko. Bien évidemment ce programme ne peut rien afficher, sinon il s'auto-détruit. Mais il peut sans problème lire la cassette, charger des modules en RAM, les crypter, les décrypter, bref faire tout ce qu'il veut sans crainte d'être découvert. Pour finir il lance un effacement d'écran et il n'y a plus aucune trace.

Daniel

[smague]

Par contre, je ne connais rien de la protection des disquettes TO

c est bien dommage car c est ce qui interesse les thomsonistes si j en croit les discussions entendues au Forum 2003.