Analyse

Modérateur : Génération IX

Avatar de l’utilisateur
BahaBulle
Bub'n'Bob Pawa!
Messages : 6393
Inscription : 06 août 2002, 09:34
Localisation : Sur une bulle
Contact :

Analyse

Message non lupar BahaBulle » 28 avr. 2014, 22:34


Avatar de l’utilisateur
BahaBulle
Bub'n'Bob Pawa!
Messages : 6393
Inscription : 06 août 2002, 09:34
Localisation : Sur une bulle
Contact :

Re: Analyse

Message non lupar BahaBulle » 02 mai 2014, 15:56

B.DAT

Fichier MAP


Voilà à quoi ressemble le début du fichier :
Image

Ce fichier est une archive car on remarque un index en début de fichier.
Pour être plus précis, on voit une suite de valeur 32 bits qui s'incrémente : 0x58 -> 0x38D4 -> 0x8098...
Ces valeurs correspondent aux adresses de chaque fichiers contenus dans l'archive.

Et si on regarde en 0x58, on voit des données qui "cassent" la suite.
De plus, je sais qu'il s'agit du format des données compressés dans les TalesOf.
Comment ? Ben j'ai eu accès aux sources des outils d'Orphis qu'il a fait au début de ce projet mais nous y reviendrons plus tard.

Notre index comprend donc les octets en rouge :
Image

Problème, la dernière valeur de l'index est 0x015E70 alors que notre fichier fait une taille de 0x418800 octets.
Cela voudrait dire que le dernier fichier est très gros. Possible mais douteux. Allons voir en 0x015E70 et descendons un peu plus bas.

Bizarre, une suite de 00 vers 0x016420 et on repart sur des données en 0x016800. Ces 00 font penser à du padding.
Cela voudrait dire que notre index ne couvre pas la totalité du fichier.
Et en 0x016800, on repart sur un nouvel index.

Ok, notre fichier est bien une archive mais on n'a pas l'index qui va avec.
Cherchons ailleurs. On commence par la fin du fichier parce que ça arrive qu'il y soit mais il n'y a rien de bien utile.

Vu qu'il n'y a pas d'autre fichier avec un nom similaire à B.DAT, on va chercher dans l'exécutable, le fichier SLUS_006.26.

Qu'est-ce qu'on cherche ?
Un index indiquant l'adresse de nos fichiers. On en a déjà 2, un en 0x00 et un en 0x016800.
Cherchons donc cette suite de valeurs en 32 bits et little endian : 00 00 00 00 00 68 01 00.

Cool, une occurrence en 0x0F3C00. Regardons de plus près :
Image

En rouge, notre suite de valeur. Regardons la suite.
On a une nouvelle fois 0x016800. Etrange, continuons.
0xA000
0x020800, tiens si on additionne les 2 valeurs précédentes (0x016800 + 0xA000), ça donne cette valeur (0x020800).
Allons voir à cette dernière valeur dans le fichier B.DAT.
Au-dessus, on a une suite de 00, le padding puis un nouvel index.

On peut faire quelque tests de plus avec les valeurs suivantes mais c'est sûrement notre index et il est composé de l'adresse du fichier et de sa taille.
On descend pour essayer de trouver la dernière valeur. Je trouve 0x40F800 avec une taille de 0x9000.
Et si on additionne les deux, ça nous donne 0x418800 qui est la taille de notre fichier B.DAT. Parfait.

Ca nous donne un index de 2712octets qu'on divise par le nombre d'octets par fichiers (8) et ça nous donne 339 fichiers contenus dans l'archive B.DAT.

Bien, codons un peu (en lua) pour découper proprement notre archive.

Code : Tout sélectionner

loadmodule "luahandle"
loadmodule "lualibs"
loadmodule "luacd"

------------------------------------------------------------------------------------------------------------------------

DIR_OUT   = "ToD/DUMP/DAT/B.DAT/" -- !! NE PAS OUBLIER DE CREER L'ARBORESCENCE !!
ISO_PATH  = "ToD.bin"
FILE_NAME = "/DAT/B.DAT"
SLUS_NAME = "/SLUS_006.26"
INDEX_ADR = 0xF3C00
INDEX_NB  = 339

------------------------------------------------------------------------------------------------------------------------
-- OUVERTURE DE L'ISO

local ret, iso_in = pcall(cdabstract, ISO_PATH)
if not ret then return false, string.format('Impossible d\'ouvrir le fichier %s (%s)', ISO_PATH, iso_in) end

local cdutil  = cdutils(iso_in)
cdutil.iso_in = iso_in

-- On vérifie qu'on a bien le bon iso (on ne sait jamais :p)
local slusdirent = cdutil:findpath(SLUS_NAME .. ";1")
if not slusdirent then return false, "This isn't a Tales of Destiny US CD" end

-- Une petite protection pour éviter que les variables se perdent :p
gc_protect = { cdutil = cdutil, }

------------------------------------------------------------------------------------------------------------------------
-- OUVERTURE DE L'EXECUTABLE

local fullfilename = SLUS_NAME .. ";1"
local direntry = cdutil:findpath(fullfilename)
local slus = cdutil:cdfile(direntry)

-- RECUPERATION DE L'INDEX

slus:seek(INDEX_ADR)

local index = {}
for i = 1, INDEX_NB do
   table.insert(index, { pos = slus:readU32(), size = slus:readU32() })
end

-- Plus besoin de l'exécutable
slus:destroy()

------------------------------------------------------------------------------------------------------------------------
-- OUVERTURE DU FICHIER

fullfilename = FILE_NAME .. ";1"
direntry = cdutil:findpath(fullfilename)
local bdat = cdutil:cdfile(direntry)

for num, entry in ipairs(index) do
   print("Dump du fichier " .. num)

   bdat:seek(entry.pos)

   local file_out = Output(string.format('%s%04d.bin', DIR_OUT, num))
   file_out:copyfrom(bdat, entry.size)

   file_out:destroy()
end

bdat:destroy()

------------------------------------------------------------------------------------------------------------------------

Et exécutons le tout avec lua-interface :

Code : Tout sélectionner

lua-interface-light.exe TalesofDestiny.lua



Prenons maintenant le premier fichier extrait vu qu'on l'a déjà analysé au début.
On sait donc qu'il s'agit d'une archive (et oui encore :-P).

On va donc commencer par modifier notre bout de code pour qu'il gère directement le dump des fichiers de cette archive.

Code : Tout sélectionner

loadmodule "luahandle"
loadmodule "lualibs"
loadmodule "luacd"

------------------------------------------------------------------------------------------------------------------------

DIR_OUT   = "ToD/DUMP/DAT/B.DAT/" -- !! NE PAS OUBLIER DE CREER L'ARBORESCENCE !!
ISO_PATH  = "ToD.bin"
FILE_NAME = "/DAT/B.DAT"
SLUS_NAME = "/SLUS_006.26"
INDEX_ADR = 0xF3C00
INDEX_NB  = 339

------------------------------------------------------------------------------------------------------------------------
-- OUVERTURE DE L'ISO

local ret, iso_in = pcall(cdabstract, ISO_PATH)
if not ret then return false, string.format('Impossible d\'ouvrir le fichier %s (%s)', ISO_PATH, iso_in) end

local cdutil  = cdutils(iso_in)
cdutil.iso_in = iso_in

-- On vérifie qu'on a bien le bon iso (on ne sait jamais :-P)
local slusdirent = cdutil:findpath(SLUS_NAME .. ";1")
if not slusdirent then return false, "This isn't a Tales of Destiny US CD" end

-- Une petite protection pour éviter que les variables se perdent :-P
gc_protect = { cdutil = cdutil, }

------------------------------------------------------------------------------------------------------------------------
-- OUVERTURE DE L'EXECUTABLE

local fullfilename = SLUS_NAME .. ";1"
local direntry = cdutil:findpath(fullfilename)
local slus = cdutil:cdfile(direntry)

-- RECUPERATION DE L'INDEX

slus:seek(INDEX_ADR)

local index = {}
for i = 1, INDEX_NB do
   table.insert(index, { pos = slus:readU32(), size = slus:readU32() })
end

-- Plus besoin de l'exécutable
slus:destroy()

------------------------------------------------------------------------------------------------------------------------
-- OUVERTURE DU FICHIER

fullfilename = FILE_NAME .. ";1"
direntry = cdutil:findpath(fullfilename)
local bdat = cdutil:cdfile(direntry)

for num, entry in ipairs(index) do
   print("Dump du fichier " .. num)

   bdat:seek(entry.pos)

   local buf = Buffer(true)
   buf:copyfrom(bdat, entry.size)

   local file_out = Output(string.format('%s%04d.bin', DIR_OUT, num))
   file_out:copyfrom(buf, entry.size)
   file_out:destroy()   
   buf:seek(0)   

   local nb = buf:readU32() / 4
   buf:seek(0)

   local index2 = {}
   for i = 1, nb do
      index2[i] = buf:readU32()
   end

   for i = 1, nb do
      local path = string.format('%s%04d/', DIR_OUT, num)
      mkdir(path)

      local size
      if i == nb then
         size = entry.size - index2[i]
      else
         size = index2[i+1] - index2[i]
      end

      local file_out = Output(string.format('%s%04d.bin', path, i))
      file_out:copyfrom(buf, size)
      file_out:destroy()     
   end

   buf:destroy()
end

bdat:destroy()

------------------------------------------------------------------------------------------------------------------------

On se retrouve maintenant avec 339 répertoires contenant les fichiers de chaque archive précédemment extraites. Youpi :)

On va continuer avec le premier fichier du premier répertoire (ToD\DUMP\DAT\B.DAT\0001\0001.bin si vous avez gardé la même arborescence que moi)

Comme dit plus haut, ce fichier est compressé :
Image

En rouge, nous avons l'index du fichier qui nous indique le type de compression, la taille des données compressées et la taille des données décompressées.

Code : Tout sélectionner

1 octet  : Mode de compression (00 = non compressé, 01 = compression LZ, 03 = compression LZ + RLE)
4 octets : Tailles des données compressées
4 octets : Taille des données décompressées

Ce qui fait que ces données sont compressées en mode 0x03, qu'elles font 0x3873 octets compressées et 0x8220 octets non compressées.

Je vais légèrement expliquer comment fonctionne cette compression.
Pour information, cette compression utilise un buffer de 0x1000 octets (pré-initialisé) pour stoquer les données décompressées.

Nous avons 1 octet (que je vais appelé header) qui va nous indiquer quels octets sont décompressés et quels sont ceux indiquant une compression.
Notre premier header est en bleu (B5) qu'il faut regarder en binaire pour bien comprendre. En vert, il s'agit de tous les octets lus par rapport au header B5.
La lecture des bits se fait de droite à gauche.

Pour chaque bit à 1, on va lire un octet non compressé.
Pour chaque bit à 0, on va lire 2 octets qui vont nous indiquer quels octets existants nous allons copier et combien.

Notre header vaut B5 ou 1011 0101 en binaire : le premier bit indique un octet décompressé, donc nous prenons le premier octet qui vient après le B5 : le 10 dans la partie verte et nous l'écrivons dans notre sortie.
Nous avons ensuite un 0, nous allons donc lire les 2 octets qui suivent : EC et F0

Ces 2 octets fonctionne de la façon suivante :

Code : Tout sélectionner

JJJJJJJJ JJJJLLLL

Les 4 bits L indiquent le nombre d'octets à écrire (il faut ajouter 3) : ici ça donne 0 + 3 = 3
Les 12 bits J indiquent la position dans le buffer pour aller chercher les octets à copier : les 4 bits J du 2ème octet sont à placer avant le premier octet, ce qui donne FEC.
Il faut donc lire 3 octets en 0xFEC dans le buffer et les écrire dans notre sortie.

Nous allons passer au 7ème bit pour montrer la compression RLE.
Les 2 octets lus sont 00 et 1F.
Si L vaut 18, cela indique une compression RLE et non LZ, du coup L n'est plus utilisé pour le nombre d'octets et le schéma est le suivant :

Code : Tout sélectionner

VVVVVVVV TTTTLLLL

Si T vaut 1 ou plus, il devient L et on y ajoute 3. V est l'octet à répéter.
Si T vaut 0, le schéma devient le suivant :

Code : Tout sélectionner

LLLLLLLL 00000000 VVVVVVVV

On ajoute 0x13 à L et V est un nouvel octet lu dans la partie verte et indique l'octet à répéter.

(en espérant avoir été clair :-P)

Voilà le traitement complet pour le premier header :

Code : Tout sélectionner

header : B5 (1011 0101)
  1 - Ecrit : 10
  2 - LZ    : F0EC
      nb    : 03
      Pos   : 0FEC
      Ecrit : 00 00 00
  3 - Ecrit : 08
  4 - LZ    : F0EC
      nb    : 03
      Pos   : 0FEC
      Ecrit : 00 00 00
  5 - Ecrit : 0C
  6 - Ecrit : 02
  7 - RLE   : 1F00
      nb    : 04
      Ecrit : 00 00 00 00
  8 - Ecrit : E0

Ensuite, on repart sur un nouvel header et ainsi de suite.

Une fois décompressé, le fichier ressemble à ça :
Image

Pas très parlant comme ça :D

Mais si on sait que quand un fichier commence par la valeur 10 (en rouge) et que l'octet en 0x04 vaut 08 ou 09 (en bleu), il y a de grandes chance qu'il s'agisse d'un fichier de graphisme au format TIM.

Prenons un outil qui permet de convertir les fichier TIM en BMP/PNG/JPG... et TADAAAAAA :
Image

Continuons dans ce même répertoire avec le fichier 0022 puisqu'il s'agit d'une nouvelle archive.
Une archive dans une archive... On pourrait appeler ça une poupée russe :D

Il va falloir grandement modifier les outils afin de gérer cette possibilité surtout qu'on ne peut pas savoir quel sous-fichier est une archive.

J'ai donc créé une fonction récursive, c'est à dire qu'elle peut s'appeler elle-même. Cette fonction va traiter n'importe quelle archive du moment qu'elle utilise le même format.
Et pour chaque sous-fichier d'une archive, je regarde s'il est compressé, s'il s'agit d'un fichier TIM ou s'il s'agit d'une nouvelle archive et je traite en fonction. Dans ce dernier cas, j'appelle ma fonction avec le sous-fichier et ainsi de suite.

Voici la fonction (en espérant ne pas avoir fait d'erreur même si elle fonctionne :-P).
Je ne met pas le reste ici parce que j'ai complètement changé mon script de départ mais l'outil complet est quand même dispo ;)

Code : Tout sélectionner

function dumpArchive(buf_pack, pathname)

   local nb = buf_pack:readU32() / 4
   buf_pack:seek(0)

   local list = {}
   for i = 1, nb do
      list[i] = buf_pack:readU32()
   end

   local bufsize = buf_pack:getsize()
   for i = 1, nb do
      local name = string.format('%04d', i)
      local dirname = pathname .. "/" .. name

      local size
      if i == nb then
         size = bufsize - list[i]
      else
         size = list[i+1] - list[i]
      end

      buf_pack:seek(list[i])

      local obj = {
         source  = buf_pack,
         origin  = list[i],
         size    = size,
         do_seek = function (self)
            self.source:seek(self.offset + self.origin)
         end,
         do_read = function (self, count, userdata)
            return self.source:read(count, userdata)
         end,
      }

      local buf = luahandle(obj)

      local file_comp, ext = isCompressed(buf)
      if file_comp then
         ToFile(buf, string.format('%s.%02X', dirname, ext))
         buf:seek(0)

         local buf_decomp = decompFile(buf)

         buf:destroy()
         buf = ToBuffer(buf_decomp)

         buf_decomp:destroy()
      end

      if isArchive(buf) then
         ToFile(buf, string.format('%s.bin', dirname))
         buf:seek(0)

         CreateDirectories(dirname .. "/")
         dumpArchive(buf, dirname)

      elseif isTim(buf) then
         ToFile(buf, string.format('%s.tim', dirname))
      else
         ToFile(buf, string.format('%s.bin', dirname))
      end

      buf:destroy()
   end

end

Avatar de l’utilisateur
BahaBulle
Bub'n'Bob Pawa!
Messages : 6393
Inscription : 06 août 2002, 09:34
Localisation : Sur une bulle
Contact :

Re: Analyse

Message non lupar BahaBulle » 06 mai 2014, 22:20

BVB.D

Fichier MAP



Il s'agit d'une archive mais qui a un fonctionnement légèrement différent.
Déjà, c'est une seule archive, il n'y a pas d'index dans l'exécutable comme pour le fichier précédent.
Comment je le sais ? Je l'ai déduit en prenant la dernière valeur de l'index et en regardant la taille totale de l'archive. Les valeurs se rapprochent, il y a donc peu de chance que nous ayons affaire à plusieurs archives dans ce fichier.

Et l'autre différence, la voici :
Image

En vert, on a le nombre de fichiers dans l'archive et en rouge, l'index de leur position.

Etant donné que le reste est identique, on peut utiliser la même fonction, autant ne pas s'embêter, on verra plus tard s'il faudra les séparer.
Il suffit de paramétrer la lecture du nombre de sous-fichiers, genre :

Code : Tout sélectionner

   if mode == 1 then
      nb = buf_pack:readU32() / 4
      buf_pack:seek(0)
   elseif mode == 2 then
      nb = buf_pack:readU32()
   end

Le mode 1, est pour le fichier B.DAT et le mode 2 pour le fichier BVB.D.

Difficile d'analyser chaque sous-fichier pour savoir de quoi il s'agit mais ça ne devrait pas être très important étant donné que les images sont au format TIM et qu'il ne s'agit pas de textes.

Avatar de l’utilisateur
BahaBulle
Bub'n'Bob Pawa!
Messages : 6393
Inscription : 06 août 2002, 09:34
Localisation : Sur une bulle
Contact :

Re: Analyse

Message non lupar BahaBulle » 08 mai 2014, 22:14

DBG.D / INI.D

Fichier MAP / Fichier MAP


Ces deux fichiers sont simplement compressés.

Une fois décompressés, ils contiennent des infos comme les noms des personnages principaux :

Image

Etant donné qu'on n'a pas l'intention de les traduire, pas la peine de s'attarder ici.

Avatar de l’utilisateur
BahaBulle
Bub'n'Bob Pawa!
Messages : 6393
Inscription : 06 août 2002, 09:34
Localisation : Sur une bulle
Contact :

Re: Analyse

Message non lupar BahaBulle » 08 mai 2014, 22:17

E.DAT

Fichier MAP


Ce fichier ressemble au fichier B.DAT car son index se trouve dans l'exécutable en 0xF3508.

En revanche, les sous-archives fonctionnent sur le même mode que le fichier BVB.D.

Bref, rien de bien particulier vu qu'on peut gérer ce fichier avec les mêmes fonctions déjà créées.

Avatar de l’utilisateur
BahaBulle
Bub'n'Bob Pawa!
Messages : 6393
Inscription : 06 août 2002, 09:34
Localisation : Sur une bulle
Contact :

Re: Analyse

Message non lupar BahaBulle » 08 mai 2014, 22:46

KAISEN.BIN / TKM.BIN


Là, ça commence à se compliquer.

Ce fichier est en 2 parties minimum.

La première partie contient des textes :
Image

La deuxième partie est une archive dont l'index est en 0xBBC8.
Image

En vert, le nombre de fichiers.
En rouge, l'adresse de chaque fichier.
En bleu, la taille de chaque fichier.

Le reste entre les textes et l'archive ne me parle pas plus que ça.

Le problème est multiple.
Je n'ai pas trouvé l'index du fichier complet permettant de le découper convenablement.
Je n'ai pas trouvé les pointeurs pour les textes afin de pouvoir les agrandir.

D'après mes recherches, il s'agirait de textes provenant d'un mini-jeu qui se situerait dans le Château Terazzi, après avoir battu un certain Tiberius.

Si jamais quelqu'un a une save à ce moment du jeu, ce serait sympa de me la faire parvenir. Je pourrais plus facilement regarder comment fonctionne ce fichier.
On peut trouver des infos ICI au niveau de Naval Battle.

En attendant, je vais passer au fichier suivant.

-------------------------------------------------------------------------------

Je met le fichier TKM.BIN dans le même sac car ils se ressemblent et j'ai les mêmes problèmes :p

Des textes au début.
Image

En revanche, je n'ai pas trouvé d'index pour une potentielle archive dedans mais je sais qu'il y a au moins 6 fichiers compressés à partir de l'adresse 0x55DC.

Avatar de l’utilisateur
BahaBulle
Bub'n'Bob Pawa!
Messages : 6393
Inscription : 06 août 2002, 09:34
Localisation : Sur une bulle
Contact :

Re: Analyse

Message non lupar BahaBulle » 11 mai 2014, 15:42

S.DAT

Fichier MAP


Une archive toute simple dont l'index se trouve dans l'exécutable en 0xF3638 :

Image

En rouge, l'adresse de chaque fichier et en bleu leur taille.

Avatar de l’utilisateur
BahaBulle
Bub'n'Bob Pawa!
Messages : 6393
Inscription : 06 août 2002, 09:34
Localisation : Sur une bulle
Contact :

Re: Analyse

Message non lupar BahaBulle » 11 mai 2014, 15:55

TALE.VB


Je n'ai rien trouvé de spécial dans ce fichier à part que le premier octet de chaque "ligne" semble servir à quelque chose.

C'est peut-être une espèce de script.

Image

Avatar de l’utilisateur
BahaBulle
Bub'n'Bob Pawa!
Messages : 6393
Inscription : 06 août 2002, 09:34
Localisation : Sur une bulle
Contact :

Re: Analyse

Message non lupar BahaBulle » 12 mai 2014, 22:32

M.DAT / M.B

Fichier MAP


Le M.DAT est un bon gros fichier de 130 Mo. Rien que ça me fait penser à une archive.

En regardant de plus près, je confirme qu'il s'agit d'une archive, il y a un index au tout début.
Cependant, cet index est petit et ne couvre pas l'intégralité du fichier.

L'index du fichier est donc ailleurs. Je pourrais chercher dans l'exécutable comme pour d'autres fichiers déjà vu mais un autre fichier m'intrigue car il porte le même nom : M.B
Après une petite étude, il s'agit bien de l'index de notre fichier M.DAT.

Le format de cet index est :
  • 4 octets : adresse du fichier
  • 4 octets : taille du fichier
Image

Et en rouge, on a les pointeurs qui vont avec ;)
Bien évidemment, on a une belle poupée russe avec des archives dans des archives, des fichiers compressés, encore des archives...
ET des textes, youpi :D

Image

Et en rouge, on a les pointeurs qui vont avec ;)

Une autre chose qu'Orphis avait remarqué dans les fichiers des textes, c'est qu'on a leur adresse au tout début en 0x04. Il faut multiplier par 2 la valeur 16 bits, et ça donne l'adresse de la table de pointeurs.
Image

Une fois tout désarchivé, on peut remarquer que les fichiers de texte se trouvent dans le premier fichier de la dernière sous-archive. Que lorsqu'il n'y a pas de textes, la valeur en 0x04 semble indiquer la fin du fichier ou presque.
Et enfin qu'il y a des fichiers de textes qui sont totalement identiques.

Avatar de l’utilisateur
BahaBulle
Bub'n'Bob Pawa!
Messages : 6393
Inscription : 06 août 2002, 09:34
Localisation : Sur une bulle
Contact :

Re: Analyse

Message non lupar BahaBulle » 19 mai 2014, 21:38

BF.D

Fichier MAP


Fichier compressé en mode 03 avec un joli fichier TIM :

Image

Avatar de l’utilisateur
BahaBulle
Bub'n'Bob Pawa!
Messages : 6393
Inscription : 06 août 2002, 09:34
Localisation : Sur une bulle
Contact :

Re: Analyse

Message non lupar BahaBulle » 19 mai 2014, 21:51

FACE.D

Fichier MAP


Une nouvelle archive avec des sous-fichiers compressés.

Image

4 octets : Nombre de sous-fichiers
4 octets * x fichiers : Adresse des sous-fichiers

Pour au final, se retrouver avec 10 fichiers TIM :

:
Image Image Image Image Image Image Image Image Image Image

Avatar de l’utilisateur
BahaBulle
Bub'n'Bob Pawa!
Messages : 6393
Inscription : 06 août 2002, 09:34
Localisation : Sur une bulle
Contact :

Re: Analyse

Message non lupar BahaBulle » 19 mai 2014, 22:00

FACE2.D

Fichier MAP


Même chose que le fichier FACE.D, une archive archive avec des sous-fichiers compressés et des TIM au final.

Image

4 octets : Nombre de sous-fichiers
4 octets * x fichiers : Adresse des sous-fichiers

:
Image Image Image Image Image Image Image Image Image Image

Avatar de l’utilisateur
BahaBulle
Bub'n'Bob Pawa!
Messages : 6393
Inscription : 06 août 2002, 09:34
Localisation : Sur une bulle
Contact :

Re: Analyse

Message non lupar BahaBulle » 19 mai 2014, 22:19

MC.D

Fichier MAP


Même chose que les fichiers FACE.D et FACE2.D, sauf que c'est l'archive complète qui est compressée et pas les sous-fichiers.

Image

4 octets : Nombre de sous-fichiers
4 octets * x fichiers : Adresse des sous-fichiers

Ce fichier contient également plusieurs fichiers TIM :

:
Image Image Image Image Image Image Image Image Image Image Image Image Image Image Image

Avatar de l’utilisateur
BahaBulle
Bub'n'Bob Pawa!
Messages : 6393
Inscription : 06 août 2002, 09:34
Localisation : Sur une bulle
Contact :

Re: Analyse

Message non lupar BahaBulle » 19 mai 2014, 22:22

RC.D

Fichier MAP


Un simple fichier TIM compressé :

Image

Avatar de l’utilisateur
BahaBulle
Bub'n'Bob Pawa!
Messages : 6393
Inscription : 06 août 2002, 09:34
Localisation : Sur une bulle
Contact :

Re: Analyse

Message non lupar BahaBulle » 19 mai 2014, 22:29

WM.D

Fichier MAP


Une nouvelle archive avec des sous-fichiers compressés.

Image

4 octets : Nombre de sous-fichiers
4 octets * x fichiers : Adresse des sous-fichiers

Pour au final, se retrouver avec 5 fichiers TIM (ben oui les deux dernières adresses sont identiques) :

:
Image Image Image Image Image

Avatar de l’utilisateur
BahaBulle
Bub'n'Bob Pawa!
Messages : 6393
Inscription : 06 août 2002, 09:34
Localisation : Sur une bulle
Contact :

Re: Analyse

Message non lupar BahaBulle » 03 juin 2014, 22:21

I.D

Fichier MAP


Encore une belle archive avec tout plein de fichiers compressés dedans.

Image

4 octets : Nombre de sous-fichiers
4 octets * x fichiers : Adresse des sous-fichiers

Une fois décompressés, on n'obtient que des fichiers TIM, dont voici quelques exemples :
:
Image Image Image Image Image Image Image Image Image

Avatar de l’utilisateur
BahaBulle
Bub'n'Bob Pawa!
Messages : 6393
Inscription : 06 août 2002, 09:34
Localisation : Sur une bulle
Contact :

Re: Analyse

Message non lupar BahaBulle » 05 août 2014, 19:25

J'ai ajouté un tableau lua donnant le mapping de chaque archive.

Le tableau indique si le sous-fichier est compressé, s'il s'agit d'une archive, d'un fichier TIM ou d'autre chose. Il indique également l'adresse dans l'archive et la taille de chaque sous-fichier.

ARC1 : indique que le fichier est une archive de type 1, c'est à dire que l'index commence directement par l'adresse de premier sous-fichier.
ARC2 : indique que le fichier est une archive de type 2, c'est à dire que l'index commence par le nombre de sous-fichiers.

Il faudrait que j'ajoute le type TXT pour les scripts mais je n'ai pas encore trouvé de moyen d'identifier à coup sûr un fichier contenant du texte de façon automatique.

hbx360
Nouveau Floodeur
Messages : 13
Inscription : 14 juil. 2012, 10:56

Re: Analyse

Message non lupar hbx360 » 10 mars 2015, 21:03

Salut, j'ai tous lu et je suis impressioné par tes connaissances je pense que tu as dû faire des études à l'université. Malheureusement pour moi je n'ai pas le niveau pour comprendre tous ça c'est assez compliqué mais super intéressant.

J'apprends à codé sur internet en langage C est-ce qu'il est possible de faire un programme en C pour pour découpé les archives au lieu de le faire en lua je dis ça car se serai un bonne exercice pour moi mais je pense qu'il y a des connaissances universitaire à avoir pour faire cela et notamment aussi pour la décompression un programme en C serai bien aussi.

Bonne continuation.

Salut.

Avatar de l’utilisateur
BahaBulle
Bub'n'Bob Pawa!
Messages : 6393
Inscription : 06 août 2002, 09:34
Localisation : Sur une bulle
Contact :

Re: Analyse

Message non lupar BahaBulle » 10 mars 2015, 21:15

Pas besoin d'avoir été à l'université. J'ai un BTS informatique de gestion et tout ce que je fais ici je ne l'ai pas appris à l'école ;)

Tu peux très bien faire les outils en C ou n'importe quel autre langage.

Avatar de l’utilisateur
StorMyu
Parce que "StorMyu avant"!
Messages : 1191
Inscription : 25 nov. 2009, 00:25

Re: Analyse

Message non lupar StorMyu » 10 mars 2015, 23:19

je plussoie, j'ai tout codé pour Tales of Rebirth moi-même et j'ai fais 0 études d'info !
Faut juste pas faire son Lyan et s'y mettre ! HEIN LYAN :-D

Avatar de l’utilisateur
rid
Dieu Suprême du flood
Messages : 1974
Inscription : 04 janv. 2005, 22:17
Contact :

Re: Analyse

Message non lupar rid » 11 mars 2015, 02:16

A une époque Lyan était relativement puissant quand même :p
C'est juste une période d'hibernation à échéance floue...

Avatar de l’utilisateur
pinktagada
Mauvaise ROMhackeuse débutarte
Messages : 2144
Inscription : 10 mars 2010, 10:39
Localisation : Midgard
Contact :

Re: Analyse

Message non lupar pinktagada » 11 mars 2015, 08:56

Faut voir Kipy, c'est un bon exemple, étudiant ingé du son, il a appris le flash, a fait des outils démentiels et il s'est réorienté en info et a fini ses études dedans, et il est encore plus roxxor :D
MAIS Y A PLUS DE PLACE A L'ÉCRAN! NON DE MERDE MÊME SI JE TE DONNE TOUS LA PLACE DU MONDE DANS LA ROM!! TU POURRAIS PAS EN FAIRE AFFICHÉ PLUS A L'ÉCRAN!!!
Un grand philosophe...

Image

hbx360
Nouveau Floodeur
Messages : 13
Inscription : 14 juil. 2012, 10:56

Re: Analyse

Message non lupar hbx360 » 12 mars 2015, 21:56

Les gars vous êtes quand même balèze chapeau bas je ne pourrais pas être à votre niveau à mon avis même avec toute la volonté du monde car si moi on m'explique pas, pas à pas j'arrive pas, souvent les tuto je ne les comprend pas, exemple sur le tri par tas j'ai passé des dizaines d'heures sur internet à lire tous les cours sur le tri par tas que se soit sur les cours universitaire, vidéo youtube site internet etc... les explication été souvent peu claire voire incompréhensible le peu de codes trouver sur le tri par tas était pas du tout claire, même ceux universitaire ; finalement j'ai trouver après 50 heures de recherche une petite animation sur wikipédia qui expliquait le tri par tas et la j'ai enfin réussis à comprendre après cela j'ai décider de faire une vidéo sur youtube du tri par tas qui explique le principe allez la voire vous verrez très rapidement que ma façon de l'expliquer est à la porté de n'importe quel personne même un enfant de 5 ans comprendrais tapez simplement tri par tas hbx360 vous verrez sa c'est de la pédagogie et je dis ça humblement.

Je dit tous ça pour dire qu'il est très rare d'avoir des cours simple claire précis et pas à pas pourtant cela permettrai au non initiè de pouvoir apprendre simplement et facilement sans perdre de temps les gens ne savent pas faire des cours pédagogique malheureusement.

Voilà.

En tout cas merci d'avoir pris le temps de répondre.

Avatar de l’utilisateur
pinktagada
Mauvaise ROMhackeuse débutarte
Messages : 2144
Inscription : 10 mars 2010, 10:39
Localisation : Midgard
Contact :

Re: Analyse

Message non lupar pinktagada » 13 mars 2015, 08:21

Tsais, mon faible niveau je l'ai acquis à grands coups de pompes dans le fion par Jes. Et les tutos de la TRAF. Surtout les tutos de la TRAF, mais aussi les posts fleuves de Lyan, à lire les sujets des uns et des autes, à essayer de comprendre. Et un jour je me suis lancée, j'ai fait un truc pourri mais un truc quand même. Je suis plutôt traductice, mais bon. ^ ^ Et pour ce qui est de programmer, c'est pas ma tasse de thé ;)
MAIS Y A PLUS DE PLACE A L'ÉCRAN! NON DE MERDE MÊME SI JE TE DONNE TOUS LA PLACE DU MONDE DANS LA ROM!! TU POURRAIS PAS EN FAIRE AFFICHÉ PLUS A L'ÉCRAN!!!
Un grand philosophe...

Image


Revenir vers « PSX-Tales of Destiny »

Qui est en ligne ?

Utilisateurs parcourant ce forum : Aucun utilisateur inscrit et 1 invité