Nous allons expliquer comment décrypter le fichier “ryzom_xxx.idx”. Ce fichier est le premier fichier télécharger par le client, il permet de mettre à jour le client. De plus, on retrouve la base de la communication réseau (enfin je pense) Par la suite, je vais considéré le fichier comme un document.

inlinetoc

Ce fichier a pour fonction de lister tous les fichiers contenu dans le patch ainsi que la catégorie pour ces fichiers.

Catégorie permette de désigné si le fichier est complet (ou incrémentale), caché, ….

Dans les fait, nous avons deux listes.

• Une liste définissant les fichiers (nom, taille, checksum, date de modification)
• Une liste catégorie qui définit le type de fichier (et la liste de fichier dans cette catégorie)

Le fichier est séparé en quatre zone.

Version : Définit la version du document

Taille totale : Taille du document (incluant tous les champs)

Chaque token a une taille de 16 bits. Un token permet de décrypter le contenu du document

Un token est séparé en deux groupes:

1. Token ID : Définit la fonction du token
2. Token Type : Définit le type de donnée

Cette structure flexible permet de définir la structure des données de manière non rigide. Un plus pour toute évolution, par contre moins simple à décrypter.

Ainsi pour notre fichier patch nous avons une liste de fichier et une catégorie.

pour chaque fichier:

Pour chaque categorie : (en fait il y en a qu'une)

Corresponde à l'ID (la fonction du token)

Ici on a un numéro, mais il fait référence à un mot de clef (position dans le tableau/liste de String)

Bref, sans le tableau de string, impossible de savoir la fonction du token !

Un token type est sur 16 bits, avec une possibilité qu'il soit étendu (donc 32 bits) (via l'option EXTEND_TOKEN)

Quand il est étendu, il doit avoir le même Token ID.

Sans interprétation :

En interprétant l'option “Extend”, si il est définit:

Chiffre sur 32bits Suivant les informations du token, il peux s'agit d'un nombre signé, non signé, 32 bits, 64 bits, …

Chaque chaîne de caractère sont séparé par '\0'. (à l'image d'un string en C/C++)

Après la lecture du fichier (toutes les données sont mise en mémoire/tampon)

1. On lit le premier token (on sépare token id et token type)
2. Puis suivant le type on lit le/les arguments (1, 2 voir 3 - mais jamais vu dans le patch)
3. Dans le cas d'une chaîne on récupère la valeur de l'argument (on garde que la partie basse) et on obtiens la position de la chaîne.
4. Et ensuite on analyse les données.

Attention, dans le cas de EXTEND_TYPE, il faudra lire le token suivant

Il envoie la commande load [bnp_patch.cpp # bool CProductDescriptionForClient::load]

Dans cette commande, on remarque que le type de donnée est CPersistentDataRecord, et il lance la fonction apply qui effectue l'analyze des données.

Dans la structure de la classe CPersistentDataRecord, on à la liste des classes possible. [bnp_patch.h # class CProductDescriptionForClient]

CBNPCategorySet _Categories; liste de catégorie

CBNPFileSet _Files; liste de fichier

Dans les fait, il va lire le premier token est recherche l'une des deux classes. Chacune de ces classes contients d'autre classes (et ainsi de suite).

(dans bdn_patch.h)

• CBNPCategorySet _Categories; liste de categorie
• CBNPFileSet _Files; liste de fichier

(dans bdn_patch.h)

• std::vector<CBNPCategory> _Category;

(dans bdn_patch.h)

• std::string _Name;
• bool _IsOptional;
• std::string _UnpackTo;
• bool _IsIncremental;
• std::string _CatRequired; Name of the category required
• bool _Hidden; If optional but not displayed
• std::vector<std::string> _Files;

(dans bdn_patch.h)

• std::vector<CBNPFile> _Files;

(dans bdn_patch.h)

• bool _IsIncremental;
• std::string _FileName;
• std::vector<CBNPFileVersion> _Versions;

(dans bdn_patch.h)

• uint32 _VersionNumber;
• uint32 _FileTime;
• uint32 _FileSize;
• uint32 _7ZFileSize;
• uint32 _PatchSize;
• std::vector<uint32> _HashKey;