Planet X3 est disponible sous 3 “distributions”:

• Digital
• Boxed floppy 3“1/4 (720Ko)
• Boxed floppy 5”1/2 (350Ko)

Dans cette analyse, nous allons nous concentrer sur la version 3“1/4 de Aout 2020, version qui offre le choix dans plusieurs carte video (CGA, EGA, VGA).

Il existe une version plus récente (Avril 2021), mais quand j'ai commencé l'étude, je n'avais pas cette mise à jour (officiel mais pas disponible sur le site de the8bitguy).

Comme a mon habitude, je commence par analyser les “features” du programmes (mode graphiques, cartes son, etc…), les fichiers; leur types et tailles (si pertinent).

Trois “tileset” existent, et en plusieurs version suivant la carte graphique choisie

Planet X3 (dans sa version digitale/720Ko) contient 5 fichiers executables sont tous des fichiers de type “COM”.

La version 360Ko n'inclue QUE la version CGA.

Les fichiers binaires ”.com“ sont des fichiers executable destinés a être charger tel que en mémoire, ce mécanisme est hérité de CP/M, à la glorieuse époque des machines 8bits.

Ces fichiers ne contiennent aucun header, aucune Metadata, aucune instruction de chargement complexe; c'est simplement un bichier binaire pouvant meme être mis en ROM, il faut toutefois noter que sur PC, un fichier ”.com“ peut faire des appels à l'OS et donc ne pas fonctionner sans DOS préalablement chargé en mémoire, ce qui n'est pas le cas d'un fichier ”.com“ CP/M.

À l'époque des premier processeurs de la série x86 d'Intel, dont l'espace d'adressage était découpé en «segments» de maximum 64KB, les fichiers «.com» étaient des programmes de suffisamment petite taille pour tenir entièrement sur un seul segment; cette particularité de taille leur permettait de ne nécessiter aucune relocation pour leur chargement en mémoire.

Ces executables sont sensé n'occuper qu'un seul segment de mémoire (64Ko), même s'ils peuvent accéder à l'ensemble de la mémoire du PC (ne fusse que pour accéder à la carte graphique).

Les fichiers «.com» sont simplement chargés (par l'OS) à l'adresse 100h d'un segment quelconque, (après 100h/256 octets d'informations sur l'environnement). Une convention veut que les données soient placées au début du fichier, juste après une instruction de saut vers le code exécutable.

Un rapide coup d'oeil (en hexa) sur les fichiers ”.com“ nous permet de rapidement voir plusieurs anomalies sur ces fichiers.

Là où le tout petit “PX3.COM”:

Ce programme contient des parties ASCII parfaitement lisibles et cohérentes: on peut parfaitement lire ici ”px3_vga.com“, ”px3_cga.com“, ce qui confirme d'ailleurs le status de “loader” (mais uniquement pour choisir entre CGA et VGA) de ce programme, mais aussi qu'il n'est ni compressé, ni encrypté et qu'il peut donc être analyser tel quel.

Dans les “gros” fichiers .com, les parties “ASCII” ne semble très peu lisibles, même si l'on peut deviner du texte.

Il est beaucoup plus difficile de lire quelque chose dans ce début de programme, on devine des mots. En analysant le premier block “lisible”

"Choos", 0xdb,0xff, "e Video Mo",0x05
"1-CGA 320x",0x02,0xfb,0xf7

Ce type d'encodage est typique d'une compression relativement légère type RLE (une encryption n'aurait laissé aucun texte lisible).

Un autre indice est en fait les 4 lettres localisées à offset 0x24 : “UPX!”, il s'agit de la signature d'Ultimate Packer for eXecutables. il n'y a donc aucune raison d'analyser les fichiers avant de les décompresser via l'outil Ad-Hoc.

Ce fait a d'ailleurs été confirmé dans le “README.TXT” :

Cette phrase sous-entends que les modifications (et donc l'analyse) est permise, il n'y a donc pas de raison de ne pas le faire…

Après décompression (quand nécessaire) voici ce que donne le listing de ces fichiers: