Tutoriaux : Future Crew Unreal Reverse Engeniring - Part 1

Intro

La démo "Unreal" de Future Crew (http://www.pouet.net/prod.php?which=1274) est l'une des premières demos sur PC qui à eut (à l'époque) un effet "Woooowwww" massif.

Cette démo et surtout la seconde a permis a ce groupe de devenir légendaire... Pour le 20eme anniversaire de "Second Reality" en 2013 (la séquelle d'unreal) le lead coder a libéré sur github le code de cette légende (https://github.com/mtuomi/SecondReality), et ce dernier est abondamment commenté depuis (http://fabiensanglard.net/second_reality/index.php par exemple).

En farfouillant le net, je me suis rendu compte qu'il n'existait rien sur leur "premiere" démo... Je me suis donc attaqué à ce monument de la scene...

La démo arrive sur un seul .exe de 2.400.825 bytes et etait distribuée dans un fichier zip de 1.337.312 bytes (https://files.scene.org/view/demos/groups/future_crew/demos/unreal11.zip), cela peut faire sourire aujourd'hui, mais à l'époque, c'était beaucoup, elle etait diffusée via des modem qui downloadaient à +/- 2 KB/s (oui 2 kilobytes par secondes) ce qui fait qu'il fallait près de 11 minutes pour télécharger cette démo (vous pouvez comparer votre vitesse de download avec le lien sur scene.org.

ce fichier .exe contient a démo, la musique ET les assets graphique.

Deep dive dans le fichier

En regardant le code de second reality et en lisant l'excélente review de fabien, je me suis dit que unreal devait avoir la même structure. j'ai donc jeté un oeil sur l'exe via un petit utilitaire 'unp.exe' (http://unp.bencastricum.nl/) juste pour voir... et bingo... le fichier executable n'est pas de 2 mb, mais plutot de 25kb il s'agit donc bien d'un loader, voir même d'un DIS (Demo Interrupt Server), comme dans le cas de Second Reality.

Dans Second Reality, les parties et assets ne sont décrit que dans une série d'offset hardcodé dans le loader (c'est ce que nous apprends le code source du loader de second reality) et actuellement, il m'est impossible d'obtenir les sources de "unreal.exe", donc en désepoir de cause, je jette un petit coup d'oeil sur le fichier en mode hexa; nous savons déjà que les 26315 (+le header DOS de 32 bytes) premiers octets contiennent le loader et sans doute également le DIS et sont donc sans intéret... les données (musiques, graphiques, etc) commencent après l'offset 26315+32, soit 26347, ou 0x66EB en hexa cette valeur va réapparaitre comme par miracle plus tard.

Tout en parcourant le fichier, j'ai vu des chaines de caractère, notament "Scream Tracker V3.0... (offset 0x1430), en parcourant tout le fichier, je suis arrivé à la fin du fichier,et une série de "noms" de fichiers sont apparus, j'en ai compté 97 en tout. On remarque ci-dessous que le fichier contient également des sous executables (sans doute les sous-parties de la démo).

Il y a aussi une pattern très claire 16 octets pour le nom de fichier, et de 2 mots de 32 bits, soit un "bloc" de 24 octets au total que l'on peut décrire comme ceci:

typedef struct
{
  char          fname[16];
  unsigned long offset;
  unsigned long size;
} FileDef;

Toutefois, il y a un dernier "unsigned long" à la fin (0x00249911) qui est assez finalement assez simple à déduire; il s'agit d'un pointeur d'offset sur le début de la table de fichier:

Sauf que à l'offset pointé, il y a 3 unsigned long:

  • 0x00C82FC0 (13119424) aucune idée de ce que cela représente, un header ? un checksum ???
  • 0x00000061 (97) : le nombre d'entrée dans le répertoire
  • 0x000066EB (26347) : la fin taille total du loader (code + header DOS)

Sur base de ce que l'on vient de découvir, il est donc assez facile de lire le répertoire, et d'en extraire les parties.

#include <stdio.h>
#include <conio.h>
#include <malloc.h>
#include <string.h>
#include <dir.h>
 
typedef struct 
{
   char           fname[16];
   unsigned long  offset;
   unsigned long  size; 
} FC_FILE_ENTRY;
 
 
FILE          *fc_blob;
 
FC_FILE_ENTRY *fc_directory;
unsigned long fc_directory_size;

void main()
{
  unsigned long fsize=0, dirstart=0;
  unsigned long header[3],i;
    
  fc_blob = fopen(file,"rb");                 // open file
  if (!fc_blob)
  {
    puts("\nFile not found\n");
    exit(1);
  }
  fseek(fc_blob,0,SEEK_END);
  fsize = ftell(fc_blob);                     // get file size   
  fseek(fc_blob,fsize-4,SEEK_SET);            // read directory pointer
  fread(&dirstart,4,1,fc_blob);
   
  fseek(fc_blob,dirstart,SEEK_SET);           // read directory header (header, entry count, loader )
  fread(&header,4,3,fc_blob);
   
  fc_directory_size = header[1];
  fc_directory = malloc(sizeof(FC_FILE_ENTRY)*fc_directory_size);
  fread(fc_directory,sizeof(FC_FILE_ENTRY),fc_directory_size,fc_blob);
   
  fclose(fc_blob);
   
  for(i=0;i<fc_directory_size; i++)
  {
        printf("%16s  %08lX %08lX\n",fc_directory[i].fname,fc_directory[i].offset,fc_directory[i].size);
  }
}

Ce code devrait nous permettre de "voir" le répertoire dans la démo...

L'extraction des fichiers ne devrait poser AUCUN problème à ce niveau, il suffit de créer un fichier avec le nom fname, de se déplacé à l'offset spécifié dans le fichier source, et de copier size octets dans ce ficihier.

Prochaine étape, l'analyse des assets...

[TBC]

Références:

downloadable: