aide pour casser la protection d'Armaeth version 1 (1991)

**stephh** · 21 août 2013, 00h57

Avec la rentrée qui se profile, pas sûr de pouvoir jeter un oeil avant la mi-septembre, mais j'ai néanmoins quelques questions :

Envoyé par farvardin Voir le message

Il semble également protégé par une protection physique, car le jeu demande à avoir la première disquette de jeu insérée dans le lecteur avant de démarrer. Lorsque je lance ARMAETH.BAT dans dosbox, ça m'indique : "Insérez la disquette clé puis tapez le nom du lecteur (A,B,...)". Seulement si je me contente de copier les fichiers du disque 1 dans un lecteur virtuel A, ça ne fonctionne pas, probablement parce que cette protection n'est pas dans les fichiers, mais dans la disquette.

Il se fait peut-être tard, mais je ne trouve pas ton fichier ARMAETH.BAT

Sur quelle disque (dans quel répertoire) est-il sensé être ?

L'installation officielle, qui demande de changer les 3 disquettes dans le lecteur A ou B, semble difficile à réaliser depuis l'installeur, dans dosbox (impossible de changer de disque). Mais ça semble bêtement copier tous les fichiers dans le même répertoire du disque dur.
- Le fichier Armaeth.bat appelle EGA.exe, sans doute pour initialiser la vidéo, puis GST000.exe. La protection semble être à partir de ce fichier.

Je n'ai pas encore testé la chose, mais y a-t-il une commande pour lancer l'installation ou est-ce que lancer le programme INSTALL.EXE suffit ?

A noter que la disquette RAW ne semble pas être une disquette d'origine, puisqu'on constate qu'elle a dû être formatée par PCTools (ça encore, pourquoi pas), mais surtout on y trouve des fichiers de PCTools (effacés ou pas, je n'ai pas complètement vérifié) ...

Steph

**farvardin** · 21 août 2013, 08h02

Envoyé par stephh Voir le message

Il se fait peut-être tard, mais je ne trouve pas ton fichier ARMAETH.BAT

Sur quelle disque (dans quel répertoire) est-il sensé être ?

ah oui effectivement... possible que le fichier ARMAETH.BAT soit généré lors de l'installation. En tout cas les fichiers qui ont été ajoutés sur le disque dur suite à l'installation de la première disquette (à part le batch) étaient les mêmes que ceux déjà présent sur le disque 1. Comme il n'est pas possible avec dosbox de changer de disquette (seulement valable pour les cdrom), je n'ai pas pu installer le reste via l'installateur, mais j'en ai conclu, peut-être à tort, que le reste de l'installation se faisait en copiant le reste des fichiers des disquettes 2 et 3 dans le dossier ARMAETH.

En tout cas lors du démarrage du jeu, ça demande bien une disquette dans le lecteur A ou B, donc je pense que le problème vient d'une protection plutôt que de fichiers mal installés. En tout cas on retrouve le contenu du fichier batch dans les fichiers ins360 et ins720, ce qui fait penser que le sous-dossier armaeth + le batch sont générés lors de l'installation.

Voici une nouvelle archive avec le début de l'installation : http://jolishare.com/FruO9EB4wF (lien corrigé)

À tout hasard, voici le contenu d'ARMAETH.BAT :

Code:

echo off
C:
cd \ARMAETH
ega
gst000
if not errorlevel 1 dm1 dm1

Envoyé par stephh Voir le message

Je n'ai pas encore testé la chose, mais y a-t-il une commande pour lancer l'installation ou est-ce que lancer le programme INSTALL.EXE suffit ?

si on tape juste install.exe, ça dit qu'il faut taper install.exe 360 ou install.exe 720, sans doute en référence à la capacité du lecteur du PC.

Envoyé par stephh Voir le message

A noter que la disquette RAW ne semble pas être une disquette d'origine, puisqu'on constate qu'elle a dû être formatée par PCTools (ça encore, pourquoi pas), mais surtout on y trouve des fichiers de PCTools (effacés ou pas, je n'ai pas complètement vérifié) ...

Possible. C'est le logiciel http://www.pamarsystems.com/raw qui a été utilisé pour faire l'image de la disquette 1. Si je monte cette image dans dosbox avec cette commande :

Code:

imgmount A /tmp/armaeth/DISQ1.IMG -t floppy

, je lis sans problème le contenu de l'image (même contenu que le dossier DISK1)

bon courage

**stephh** · 21 août 2013, 09h09

Comme je ne peux pour l'instant rien faire, peut-être peux-tu tester certaines petites choses pour moi et répondre à de nouvelles questions :

1. As-tu essayé de lancer le fichier ARMAETH.BAT "à la main" ? A savoir, lancer chaque commande séparément pour savoir quand la disquette est demandée. Ainsi, ce sera déjà plus facile de savoir dans quel programme la protection disque semble être.

2. Quand les codes (ceux du fichier PDF) sont-ils demandés dans le jeu ? Dès le début, après un certain temps de jeu ou arrivé à un certain endroit ?

D'avance merci pour les infos, c'est toujours du temps de gagné pour se consacrer à autre chose ...

Steph

**farvardin** · 21 août 2013, 09h52

1/ Oui, j'ai lancé chaque commande séparément, et ça semble être à partir de GST000.EXE que ça demande la disquette pour la protection. Mais ce fichier lance ensuite GST001.EXE, et si GST001.EXE n'est pas présent, ça provoque une erreur et n'affiche pas le passage avec la demande de disquette. Néanmoins, je n'ai pas trouvé avec le désassembleur IDA de référence à un changement de disquette dans le fichier GST001.EXE alors qu'il y en a plusieurs dans GST000.EXE. En ayant modifié le binaire de GST000.EXE pour modifier certains sauts visibles dans le désassemblage, ça m'a marqué la même erreur (sortie puis genre "erreur sys") que quand GST001.EXE n'est pas présent dans le dossier (alors qu'il l'était à ce moment).

J'en conclus que GST000.EXE c'est pour la demande du changement de disquette, et GST001.EXE c'est la protection en elle-même avec comparaison etc.

La précédente archive n'était pas bonne, elle contenait le binaire modifié par mes soins, voici l'archive corrigée :
http://jolishare.com/FruO9EB4wF

2/ Au niveau de la protection par code, elle n'arrive que plus tard, probablement au début du jeu, et pour le moment il n'est pas possible de la voir tant que la première protection physique ne sera pas court-circuitée. N'ayant jamais joué au jeu moi-même, je ne pourrais pas dire exactement quand c'est demandé.

**ergonomy_joe** · 22 août 2013, 03h23

Je n'ai pas pu m'empecher de jeter un oeil moi aussi

J'ai l'impression effectivement que pour passer la premiere protection, il faut se plonger dans GST0001.EXE.
On dirait un executable compile avec "Microsoft C" tout ce qu'il y a de plus classique, mais en partie crypte avec XOR.
Et il a un petit loader accole, lui aussi en parti XORe, et son decodeur redirige les interruptions 1 et 3 (trace et breakpoint, donc pas moyen d'utiliser debug) et utilise un checksum de son propre binaire pour la cle.
Du beau boulot.

Il faudrait le tracer dans un PC virtuel avec debugger integre. Quelqun'un sait si Dosbox a une telle fonction ?

**stephh** · 22 août 2013, 09h41

Envoyé par ergonomy_joe Voir le message

J'ai l'impression effectivement que pour passer la premiere protection, il faut se plonger dans GST0001.EXE.
On dirait un executable compile avec "Microsoft C" tout ce qu'il y a de plus classique, mais en partie crypte avec XOR.
Et il a un petit loader accole, lui aussi en parti XORe, et son decodeur redirige les interruptions 1 et 3 (trace et breakpoint, donc pas moyen d'utiliser debug) et utilise un checksum de son propre binaire pour la cle.
Du beau boulot.

Ca a l'air effectivement bien sympa

Ceci dit, je suis arrivé à avoir le fichier plus ou moins décrypté (en fait, j'ai sauvé la mémoire au moment de l'appel de la fonction 00h de l'interruption 13h), j'ai désassemblé tout ça "à la barbare", et j'ai déjà pu voir les choses suivantes :

. Il y a bien une lecture de secteurs (fonction 02h), mais je ne sais pas encore si ce qui est lu a un intérêt
. Il y a un test de type de disque dans le lecteur A (fonction 15h), mais visiblement juste pour savoir s'il y a une disquette dans le lecteur
. En plus du message "Insérez la disquette clé ...", il y a aussi un message "La clé ne correspond pas."

Prochaine étape, essayer d'avoir le deuxième message au lieu du premier.

Il faudrait le tracer dans un PC virtuel avec debugger integre. Quelqun'un sait si Dosbox a une telle fonction ?

Pas à ma connaissance

Steph

**farvardin** · 22 août 2013, 12h41

merci de votre intérêt pour ce jeu et son système de protection

Ça semble finalement plus complexe que je croyais. J'avais déjà réussi il y a quelques années à court-circuiter la protection d'un petit shareware windows (devenu freeware depuis) avec winice ou softice, c'était relativement aisé.

Il faudrait le tracer dans un PC virtuel avec debugger integre. Quelqun'un sait si Dosbox a une telle fonction ?

Dosbox permet cela, mais il faut une version compilée avec l'option de debogage, comme on voit ici :

et comme expliqué ici : http://www.vogons.org/viewtopic.php?t=7323

Je continue aussi à regarder de mon côté.

**ergonomy_joe** · 23 août 2013, 12h36

Envoyé par farvardin Voir le message

merci de votre intérêt pour ce jeu et son système de protection

Merci a toi, ca m'a l'air vraiment d'une rarete ce que tu nous a deniche. Tu en as d'autres des comme ca ?

Envoyé par farvardin Voir le message

Ça semble finalement plus complexe que je croyais. J'avais déjà réussi il y a quelques années à court-circuiter la protection d'un petit shareware windows (devenu freeware depuis) avec winice ou softice, c'était relativement aisé.

Cool; c'etait quoi comme jeu ?

Envoyé par farvardin Voir le message

Dosbox permet cela, mais il faut une version compilée avec l'option de debogage, comme on voit ici :

[ATTACH=CONFIG]31112[/ATTACH]

et comme expliqué ici : http://www.vogons.org/viewtopic.php?t=7323

Je continue aussi à regarder de mon côté.

He ben, il etait temps que je me mette au courant pour cette histoire

en tous cas merci, ca m'a bien aide.

Alors du coup j'ai pu deXORer le loader. On y trouve la chaine de caracteres: ** COPS' COPYLOCK II Bad Copy **
Ca a l'ai d'un truc bien professionnel.

Si j'arrivais a mettre la main sur la routine qui deXORe le reste de l'exe, on pourrait carrement se passer du loader...
Probleme, c'est assez dur a lire. Avec mon approche ca n'est pas pour demain quoi.

**stephh** · 23 août 2013, 16h45

Envoyé par ergonomy_joe Voir le message

Ca a l'ai d'un truc bien professionnel.

C'est clair que c'est du beau boulot !

Si j'arrivais a mettre la main sur la routine qui deXORe le reste de l'exe, on pourrait carrement se passer du loader...
Probleme, c'est assez dur a lire. Avec mon approche ca n'est pas pour demain quoi.

La routine qui déXORe est en fait appelée à plusieurs reprises par le programme; elle est en 0x11f8 demande comme paramètres les registres CH, DX et AX.

Comme j'ai "capturé" la mémoire au moment de l'initialisation du lecteur, je n'ai qu'une partie "en clair", mais on a déjà bien avancé. Je joins les 2 fichiers "bruts" (le dump du segment en cours et ce que ça donne sans réfléchir dans DEBUG) pour que tu puisses te faire une idée.

Le souci, c'est que si je court-circuite par quelque moyen que ce soit la lecture du secteur (qui ne semble rien avoir d'extraordinaire d'après le fichier RAW), je n'arrive pas à sortir du programme (de GST000.EXE en fait puisque mon loader ne fait que l'exécuter après avoir détourné des interruptions). Il doit donc probablement falloir tout exécuter en minimisant les modifs puis trouver la routine qui fait le checksum (toute piste est la bienvenue).

Autre problème rencontré, la fonction 15h de l'interruption 13h n'est pas émulé par DOSBox ! On a donc potentiellement une erreur dès le départ

De plus, il est fait un appel à l'interruption 25h dont je ne sais pas si elle est émulée et qui pourrait donc là encore provoquer quelque chose de pas prévu (même si ça semble ne forcer que la lecture des secteurs sur A).

Le week-end approche, ça risque d'être un peu compliqué pour moi, et lundi, c'est la reprise du boulot après 6 semaines d'absence => je risque d'être "bloqué" pendant quelques temps (même si ça ne m'empêchera pas de lire le forum et vos possibles avancées).

Steph

Fichiers attachés

A.ZIP (124,7 Ko, 82 affichages)

**ergonomy_joe** · 24 août 2013, 03h57

Envoyé par stephh Voir le message

La routine qui déXORe est en fait appelée à plusieurs reprises par le programme; elle est en 0x11f8 demande comme paramètres les registres CH, DX et AX.

Comme j'ai "capturé" la mémoire au moment de l'initialisation du lecteur, je n'ai qu'une partie "en clair", mais on a déjà bien avancé. Je joins les 2 fichiers "bruts" (le dump du segment en cours et ce que ça donne sans réfléchir dans DEBUG) pour que tu puisses te faire une idée.

Ca doit etre mes explications qui n'etaient pas tres claires, mais pour ce qui est du loader j'ai deja fait le deXORage; j'ai meme le code "en clair" jusqu'a l'offset 0x1eb1.

Pour la routine manquante, je parlais de l'executable original.
Si on regarde la structure de gst001.exe, on voit que la partie "loader" est precedee d'un autre programme qui est l'executable original.
C'est ce dernier qui est crypte (tous les offsets dont les 4 derniers bits sont 8 et 9).

Mon avis sur ce que fait le loader:
1- verifier par differents moyen la presence de la disquette originale dans le lecteur
2- si c'est le cas, decrypter l'executable original (peut-etre en utilisant des informations trouvees sur les secteurs "caches" de la disquette ... si c'est le cas, on va bien s'amuser pour la suite

)
3- appliquer les informations de relocations (on les trouve entre l'executable original et le loader)
4- positionner les registres important: CS:IP SS:SP
5- passer la main a l'executable original

pour les etapes 3, 4 et 5 on dirait que ca se passe vers l'offset 0x0eba du loader.

Par contre l'etape 2 je ne trouve pas encore, et c'est de cette routine dont je parlais dans mon post.

Et donc, si on arrive a decrypter l'executable original, on pourrait y accoler un nouveau header (on a deja les informations de relocations) et completement se debarasser du loader.

Envoyé par stephh Voir le message

Autre problème rencontré, la fonction 15h de l'interruption 13h n'est pas émulé par DOSBox ! On a donc potentiellement une erreur dès le départ

De plus, il est fait un appel à l'interruption 25h dont je ne sais pas si elle est émulée et qui pourrait donc là encore provoquer quelque chose de pas prévu (même si ça semble ne forcer que la lecture des secteurs sur A).

Ca doit etre a l'offset 0x1715 que tu fait reference; l'interruption 0x13 est redirigee vers l'offset 0x1780. Puis un appel a l'interruption 0x25 est fait, est enfin l'interrutpion 0x13 est restauree.
Cette routine ne fait que verifier le numero de drive envoye a l'interruption 0x13.
Peut-etre pour eviter des "subst" ou l'utilisation de lecteurs virtuels?

Envoyé par stephh Voir le message

Le week-end approche, ça risque d'être un peu compliqué pour moi, et lundi, c'est la reprise du boulot après 6 semaines d'absence => je risque d'être "bloqué" pendant quelques temps (même si ça ne m'empêchera pas de lire le forum et vos possibles avancées).

6 semaines ??? de vacances ?

**stephh** · 24 août 2013, 09h49

Envoyé par ergonomy_joe Voir le message

Ca doit etre mes explications qui n'etaient pas tres claires, mais pour ce qui est du loader j'ai deja fait le deXORage; j'ai meme le code "en clair" jusqu'a l'offset 0x1eb1.

Pour la routine manquante, je parlais de l'executable original.
Si on regarde la structure de gst001.exe, on voit que la partie "loader" est precedee d'un autre programme qui est l'executable original.
C'est ce dernier qui est crypte (tous les offsets dont les 4 derniers bits sont 8 et 9).

Clarifions effectivement les choses ... Le loader, c'est quel fichier pour toi ? GST000.EXE ou GST001.EXE ? Quant à ton programme/exécutable original, c'est quoi ?

Quoi qu'il en soit, si tu as déjà un fichier avec le code de GST001.EXE (voire GST000.EXE) "en clair", peux-tu l'attacher en pièce jointe à ce message ?

Mon avis sur ce que fait le loader:
1- verifier par differents moyen la presence de la disquette originale dans le lecteur
2- si c'est le cas, decrypter l'executable original (peut-etre en utilisant des informations trouvees sur les secteurs "caches" de la disquette ... si c'est le cas, on va bien s'amuser pour la suite

)
3- appliquer les informations de relocations (on les trouve entre l'executable original et le loader)
4- positionner les registres important: CS:IP SS:SP
5- passer la main a l'executable original

pour les etapes 3, 4 et 5 on dirait que ca se passe vers l'offset 0x0eba du loader.

Par contre l'etape 2 je ne trouve pas encore, et c'est de cette routine dont je parlais dans mon post.

Et donc, si on arrive a decrypter l'executable original, on pourrait y accoler un nouveau header (on a deja les informations de relocations) et completement se debarasser du loader.

Ce qu'il semble évident (pour moi), c'est que GST000.EXE appelle GST001 (qui vérifie la disquette originale) puis revient au DOS en ayant probablement laissé des trucs en résident (avec certaines interruptions détournées) pour que quand tu lances DM1.EXE, il n'y ait pas d'erreurs.

Ce que j'ai remarqué, c'est qu'il y a beaucoup d'adresses dans GST001.EXE qui contiennent 0x4e par défaut ou quand ça plante, et 0x59 quand l'opération s'est bien déroulée. Mais je n'ai pas encore vérifié si derrière elles étaient également testées par GST000.EXE ou DM1.EXE ...

Pour ce qui est de l'étape 2, je ne suis effectivement pas très rassuré : j'arrive effectivement sans problème à ne pas avoir le message demandant la disquette, mais JAMAIS celui me disant que la clé ne correspond pas. De plus, je ne reviens JAMAIS au DOS (je boucle quelque part sans savoir où)

Néanmoins, je n'ai pas l'impression qu'il y ait une lecture de secteurs "spéciaux" dans GST001.EXE => on doit pouvoir peut-être tricher en passant par le fichier RAW.

Ca doit etre a l'offset 0x1715 que tu fait reference; l'interruption 0x13 est redirigee vers l'offset 0x1780. Puis un appel a l'interruption 0x25 est fait, est enfin l'interrutpion 0x13 est restauree.
Cette routine ne fait que verifier le numero de drive envoye a l'interruption 0x13.
Peut-etre pour eviter des "subst" ou l'utilisation de lecteurs virtuels?

C'est bien celle-là : lecture directe avec numéro de disque (A = 0x00, B = 0x01, C = 0x02 ... Z = 0x19) par l'interruption 0x25 avec l'interruption 0x13 détournée qui récupère à quel lecteur ça correspond (0x00 à 0x03 pour les disquettes et 0x80+ pour les disques durs) et agit en conséquence (on force la lecture de la disquette si on se rend compte qu'on essaie de lire un disque dur). Sauf que je n'ai pas encore testé si cette fonction 0x25 est bien émulée par DOSBox pour m'assurer qu'elle va bien appeler l'interruption 0x13.

6 semaines ??? de vacances ?

Education Nationale = 50 jours de vacances (hors week-ends et jours fériés) par an + 5 jours potentiels de RTT

Et comme je n'en avais pas pris beaucoup cette année à cause des formations pour le concours, j'ai pu m'absenter aussi longtemps (comme chaque année) tout en ayant un reliquat qui va se rajouter à mes congés 2013-2014

Et je ne compte pas les heures supplémentaires (l'équivalent de 8 jours quand même) dont j'ai fait grâce à l'administration ...

Steph

**ergonomy_joe** · 25 août 2013, 03h30

Envoyé par stephh Voir le message

Clarifions effectivement les choses ... Le loader, c'est quel fichier pour toi ? GST000.EXE ou GST001.EXE ? Quant à ton programme/exécutable original, c'est quoi ?

Tous mes posts jusqu'a present ne concernent que GST001.EXE.
Et pour resumer, voila sa structure:
- header EXE
- code + donnes de l'executable original (crypte)
- infos de relocations de l'executable original (en clair il me semble)
- loader (verification disquette originale + decryptage de l'executable original)

Voila pourquoi je pense que si on arrive a decrypter l'executable original, on doit pouvoir se debarasser du loader completement.

Envoyé par stephh Voir le message

Quoi qu'il en soit, si tu as déjà un fichier avec le code de GST001.EXE (voire GST000.EXE) "en clair", peux-tu l'attacher en pièce jointe à ce message ?

En fait je n'ai pas le binaire, j'ai juste une version en assembleur "a ma sauce".
Je le retravaille un peu et je le poste, promis !

Envoyé par stephh Voir le message

Ce que j'ai remarqué, c'est qu'il y a beaucoup d'adresses dans GST001.EXE qui contiennent 0x4e par défaut ou quand ça plante, et 0x59 quand l'opération s'est bien déroulée. Mais je n'ai pas encore vérifié si derrière elles étaient également testées par GST000.EXE ou DM1.EXE ...

0x59 en ascii c'est 'Y' (pour Yes?) et 0x4e c'est 'N' (pour No?).

Envoyé par stephh Voir le message

Pour ce qui est de l'étape 2, je ne suis effectivement pas très rassuré : j'arrive effectivement sans problème à ne pas avoir le message demandant la disquette, mais JAMAIS celui me disant que la clé ne correspond pas. De plus, je ne reviens JAMAIS au DOS (je boucle quelque part sans savoir où)

Néanmoins, je n'ai pas l'impression qu'il y ait une lecture de secteurs "spéciaux" dans GST001.EXE => on doit pouvoir peut-être tricher en passant par le fichier RAW.

Le probleme c'est que beaucoup d'acces a la disquette se font directement par le controleur disque. Donc dans ces cas-la, rediriger l'interruption 13h ne peut pas nous aider.

Envoyé par stephh Voir le message

Education Nationale = 50 jours de vacances (hors week-ends et jours fériés) par an + 5 jours potentiels de RTT

Vive l'education nationale

**ergonomy_joe** · 25 août 2013, 10h33

Youhou, ca marche !

En tracant gst001.exe avec DosBox, et en re-positionnant le registre ip pour simuler le bon deroulement des operations, j'ai pu obtenir en memoire, une version deXORee de l'executable original.

Ensuite, j'ai:
-dumpe cette memoire dans un fichier.
-corriges les relocations dans le code (valeur par rapport au debut du fichier)
-inserer un header exe "fait main et fait maison"

... et roule ma poule.

En piece jointe voici le nouveau fichier gst001.exe;

GST001_20130825.zip

Pour tester le jeu, il suffit de le mettre dans le repertoire de la version installee du jeu (en ecrasant l'ancien donc), et ca devrait suffire.

En revanche, la protection "manuel" est toujours en place. Ca sera pour la suite.

et pour Stephh, ma version desassemblee du loader;
GST001(loader)_20130825.zip

***batjijo*** · 25 août 2013, 14h23

Envoyé par ergonomy_joe Voir le message

En tracant gst001.exe avec DosBox, et en re-positionnant le registre ip pour simuler le bon deroulement des operations, j'ai pu obtenir en memoire, une version deXORee de l'executable original.

Ensuite, j'ai:
-dumpe cette memoire dans un fichier.
-corriges les relocations dans le code (valeur par rapport au debut du fichier)
-inserer un header exe "fait main et fait maison"

... et roule ma poule.

En piece jointe voici le nouveau fichier gst001.exe;

[ATTACH]31116[/ATTACH]

Pour tester le jeu, il suffit de le mettre dans le repertoire de la version installee du jeu (en ecrasant l'ancien donc), et ca devrait suffire.

En revanche, la protection "manuel" est toujours en place. Ca sera pour la suite.

et pour Stephh, ma version desassemblee du loader;
[ATTACH]31117[/ATTACH]

Je viens de tester en mettant le code demandé, cela renvoie sur le fichier DM1 avec le message "Fichier non accessible", retour sous dos box avec le message "fichier non localisable ou illisible".....

aide pour casser la protection d'Armaeth version 1 (1991)

aide pour casser la protection d'Armaeth version 1 (1991)

Commentaire

Commentaire

Commentaire

Commentaire

Commentaire

Commentaire

Commentaire

Commentaire

Commentaire

Commentaire

Commentaire

Commentaire

Commentaire

Commentaire