extraction de texte dans overlay Megaman Zero Collection NDS

recherche explication ou exemple

Une question en rapport avec le ROMHacking ?
Dans cette section nous tenterons de vous conseiller ou de partager nos connaissances, bien entendu dans la limite de nos compétences et de notre disponibilité.

Re: extraction de texte dans overlay

Message non lupar BahaBulle » Jeudi 10 Janvier 2013 à 20:50:43

jerome674 a écrit:j'ai extrait certains overlay sans aucune modification, le 129, le 139 et le 140.

Ca veut dire quoi "extrait" ? Extrait de la rom ?

jerome674 a écrit:j'ai modifié le fichier y9.bin en conséquence afin de préciser que les fichiers étaient bien décompressé.

Modifié en conséquence de quoi ?

jerome674 a écrit:129 decimal->81 hexa
139 decimal->8B hexa
140 decimal->8C hexa

Pourquoi cette conversion ?


La seule explication logique que je vois c'est que tu as décompressé ces 3 overlays et que tu as indiqué dans le fichier y9.bin qu'ils n'étaient pas compressés.
Dans ce cas, quelles valeurs as-tu modifié et par quoi ?

Je n'ai pas le temps de télécharger, dépacker et regarder tes fichiers.
Avatar de l’utilisateur
BahaBulle
 
Messages: 280
Enregistré le: Lundi 20 Décembre 2010 à 18:18:17
Genre: Homme

Re: extraction de texte dans overlay

Message non lupar jerome674 » Vendredi 11 Janvier 2013 à 1:50:27

BahaBulle a écrit:
jerome674 a écrit:j'ai extrait certains overlay sans aucune modification, le 129, le 139 et le 140.

Ca veut dire quoi "extrait" ? Extrait de la rom ?

->j'ai extrait le contenu de la rom et decompressé ces overlays avec l'outils de Loki et DSDecmp pour les overlays

Les modi faite sur le fichier y9.bin :

jerome674 a écrit:129 decimal->81 hexa


en 0x01020 :
original :
81 00 00 00 00 a1 15 02 80 50 00 00 00 00 00 00
b8 ba 15 02 bc ba 15 02 81 00 00 00 [color=#0080FF]00 23 00 01

après modif :
81 00 00 00 00 a1 15 02 80 50 00 00 00 00 00 00
b8 ba 15 02 bc ba 15 02 81 00 00 00 80 50 00 00

-> j'ai modifié la taille dans les derniers octets afin de que la rom comprenne qu'il s'agit de fichier non compressé (80 50 00 00).


139 decimal->8B hexa

original :
8b 00 00 00 00 a1 15 02 80 21 00 00 00 00 00 00
28 a9 15 02 2c a9 15 02 8b 00 00 00 4c 10 00 01

après modif :
8b 00 00 00 00 a1 15 02 80 21 00 00 00 00 00 00
28 a9 15 02 2c a9 15 02 8b 00 00 00 80 21 00 00


140 decimal->OC hexa
original :
8c 00 00 00 00 a1 15 02 00 32 00 00 20 00 00 00
f0 b2 15 02 f4 b2 15 02 8c 00 00 00 68 1c 00 01

après modif :
8c 00 00 00 00 a1 15 02 00 32 00 00 20 00 00 00
f0 b2 15 02 f4 b2 15 02 8c 00 00 00 00 32 00 00

J'ai bien evidement replacé les fichiers décompresssé lz dans la rom avec la bonne extension et vérifier les tailles à chaque fin de ces fichiers.

Puis j'ai refait la rom et là pas j'ai mes bugs donc sans aucune modification d'overlay.

faut-il d'autres détails ?
jerome674
 
Messages: 98
Âge: 36
Enregistré le: Mercredi 8 Juin 2011 à 22:53:05
Localisation: Tours
Genre: Homme

Re: extraction de texte dans overlay Megaman Zero Collection

Message non lupar BahaBulle » Vendredi 11 Janvier 2013 à 16:31:18

Est-ce que tu as comparé la RAM à un même moment sur les 2 roms (la bonne et la buggée) ?
Avatar de l’utilisateur
BahaBulle
 
Messages: 280
Enregistré le: Lundi 20 Décembre 2010 à 18:18:17
Genre: Homme

Re: extraction de texte dans overlay Megaman Zero Collection

Message non lupar jerome674 » Vendredi 11 Janvier 2013 à 17:49:34

j'ai en effet fait un dump de la ram au même moment sur les 2 roms, phase de dialogue identique.

par contre le décors bougent énormément, de grosses animations et quand de compare à l'éditeur hexa, il y a d'énormes différences dans le contenu, je ne sais donc pas si ca vient de l'annimation ou s'il manque quelque chose pour le coup...
Dump fait avec DesMUME..

Je ne sais comment avancer plus précisement...
jerome674
 
Messages: 98
Âge: 36
Enregistré le: Mercredi 8 Juin 2011 à 22:53:05
Localisation: Tours
Genre: Homme

Re: extraction de texte dans overlay Megaman Zero Collection

Message non lupar Lyan53 » Mardi 15 Janvier 2013 à 17:09:16

Okay,

Bon après avoir z'yeuté, je pense avoir une idée d'ou vient ton probleme

la plupart des overlays que tu cites et qui plantent ne sont que partiellement compressés

Je pense que ton souci vient de là tout simplement, il faudrait que tu tentes de les recompresser mais partiellement comme ils le sont à la base

j'avais moi même fait des tests sur ce type d'overlay et ils sopnt très susceptibles, j'avais réussi à les faire fonctionner qu'en les recompressant partiellement comme ils le sont à l'origine

je pense donc que c'est la piste à suivre


Prenons deux overlay en exemple, 1 completement compressé (le 134) et un qui ne l'est que partiellement (le 129)


....................................................................................................................................


Tout d'abord le "134" qui est un fichier overlay compressé conventionnel (on dira ^^) :
Image

On trouve le header de compression à la fin de l'overlay donc qd ce dernier l'est, il est important de noter que ce header ne contient que des données sur la compression et rien d'autre, toutes les données qui concernent le fichier sont stockées dans le y9.bin

En orange : c'est du padding pur la mise en forme du fichier (il peut y avoir 0 à 3 octets)
En rouge : c'est la taille des données compressées dans l'overlay (vu qu'il l'est entièrement, dans ce cas "conventionnel", c'est la taille de l'overlay compressé également)
En vert : c'est la taille du header de compression (bien entendu padding inclus)
En bleu : c'est la différence en octet qu'il y a entre les données compressées de l'overlay, et les mêmes données decompressées

pour determiner si l'overlay est entierement compressé ou non, suffit de regarder sa taille compressée, soit 0x26F0 dans ce cas-ci, et la taille complete du fichier (que l'on peut determiner grâce à l'offset encadré en rose sur le screen) qui est lui même de 0x26F0

on a donc un overlay entierement compressé

On peut même faire le calcul de la taille de l'overlay décompressé en additionnant la taille des données compressées (encadré rouge) + la différence entre les données compressées et décompressées (encadré bleu) soit : 0x26F0 + 0x2610 = 0x4D00


Une fois notre overlay 134 décompressé il fait bien cette taille ;)

Image
On le voit également dans le y9.bin :
En rouge : Taille de l'overlay decompressé
En bleu : taille de l'overlay compressé
En rose et en vert : nombre de l'entrée dans le y9.bin ainsi que le numéro de l'overlay (ces valeurs correspondent toujours donc à savoir laquelle des 2 est quoi exactement ^^)
En orange : l'octet de compression*

* Voici la correspondance pour cet octet :
Code: Tout sélectionner
0x00 : Non compressé, non signé
0x01 : Compressé, non signé
0x02 : Non compressé, signé
0x03 : Compressé et signé.


....................................................................................................................................


Et maintenant l'overlay "129" qui lui n'est que partiellement compressé
Image

dans le header donc, même légende que tout à l'heure
pas de orange : pas de padding dans ce cas-ci
rouge : taille des données compressées dans l'overlay (à noter que pour cette valeur, le header de compression est inclus)
vert : taille du header de compression (+ 0 de padding dans ce cas)
bleu : difference de taille entre les données compressées et les mêmes données non compressées


Maintenant regardons la taille complete de ce fichier (via l'offset encadré en rose), on voit que ce dernier fait 0x2300 octets
regardons maintenant la taille des données compressées (en rouge), nous avons : 0x22C1 octets seulement

Dans ce cas-là, ça signifie tout simplement que notre overlay n'est que partiellement compressé

Il y a donc une partie du fichier qui ne l'est pas ;)
Calculons le nombre d'octets en question : 0x2300 - 0x22C1 = 0x3F

Les 0x3F premiers octets de cet overlay sont donc "non compressés", il ne faut donc pas y toucher
Image
Encadré en rouge : octets non compressés (0x3F voir offset en rose)
Surligné en bleu : les données compressées
Entouré en bleu (bas droite) : taille des données surlignées en bleu (donc celles compressées puisque c'est surligné jusqu'à la fin du fichier dans ce cas-ci)

On peut donc determiner la taille de l'overlay 129 decompressé :

"Tailles des données compressées (encadrées en rouge dans le header) => 0x22C1" + "taille de la diff entre les données compressées et non compressées (encadrées en bleu dans le header) => 0x2D80" + "taille des octets non compressés au debut du fichier => 0x3F" = "taille du fichier decompressé => 0x5080"

Verifions ça dans le y9.bin :
Image
Meme legende que plus haut :
En rouge : Taille de l'overlay decompressé
En bleu : taille de l'overlay compressé
En rose et en vert : nombre de l'entrée dans le y9.bin ainsi que le numéro de l'overlay (ces valeurs correspondent toujours donc à savoir laquelle des 2 est quoi exactement ^^)
En orange : l'octet de compression

Les données correspondent bien ;)

....................................................................................................................................



Maintenant que tu as une explication du principe, il va donc falloir mettre tout ça en pratique sur tes fichiers lorsque tu viendras à les recompresser

Tout d'abord, verifie si ton fichier est compressé partiellement ou non qd tu trifouilles tes overlays

Dans l'absolu bien que pour certains on peut aisement by-passer la compression, un travail bien propre voudrait qu'on recompresse les fichiers modifiés de préférence (en tout cas moi je le fais sur mes projets :) )

dans le cas ou ton fichier est partiellement compressé donc, lors de l'extraction ce n'est aps un probleme, en revanche, en recompression il faut bien prendre soin de retirer la partie qui ne doit pas etre compressé du fichier avant de le recompresser

Par la suite il faudra donc coller la partie compressée après la partie qui doit resté en clair, puis adapter juste deux choses dans le header de compression, c'est tres important.

Il s'agit du padding de mise en forme.

Comme les données checkées sur NDS suivent la regle des 32 bits (4 octets) il faut que le header de compression qui fait 8 octets en tout soit placé sur un offset se terminant par 0x.0, 0x.4, 0x.8 ou 0x.C
C'est pour cette raison qu'on utilise les 0xFF de padding avant ce dernier (de 0 à 3)

Comme ton fichier compressé est ajouté apres des données non compressées, topn header ne sera peut etre aps correctement en place, et donc faudra t'assurer qu'il est bien mis en forme en ajoutant ou retirant du padding si necessaire, en ajustant la taille des données compressées (puisque le header y est inclu ainsui que le padding) et egalement la taille du header

Derniere chose, ton fichier overlays 132 est en theorie que partiellement compressé, c'est étonnant qu'il fonctionne en l'etat donc, le mieux serait de le recompresser partiellement comme il l'est à la base pour eviter tout probleme


Teste ça et dis nous si ça corrige ton souci (mais je pense serieusement que c'est bien de là que vient ton plantage)
Image
Avatar de l’utilisateur
Lyan53
Administrateur du site
 
Messages: 864
Âge: 40
Enregistré le: Lundi 22 Novembre 2010 à 20:48:11
Genre: Homme

Re: extraction de texte dans overlay Megaman Zero Collection

Message non lupar jerome674 » Mercredi 16 Janvier 2013 à 13:01:32

hello !

bon avant tout merci pour ton explication tu en es écoeurant sur le fonctionnement...
je lis et relis ça depuis hier soir afin de bien tout assimiler et tes conclusions parraissent en effet être les bonnes sur les tailles.

j'ignorais que des overlays pouvaient être partiellement compressé, sacré bazar...
Par contre il est vrai que certains overlays m'avaient posé problème à la décompression et j'avais dû utiliser l'outils de loki pour certain et DSDecmp.exe pour la majorité.
L'outils de Loki fonctionne à tous les coups et DSDecmp.exe devait avoir des problèmes pour décompresser ces overlay semi compressé en fait...

Pour la partie soustraction :
"Il y a donc une partie du fichier qui ne l'est pas
Calculons le nombre d'octets en question : 0x2300 - 0x22C1 = 0x3F"
le nombre 45 localisé en 0x3F ne fait-il pas parti des données non compressées ?
les données compressées ne démarrent-elles pas de 0x40 à 0x2300 ->j'avoue avoir souvent du mal si on part ou pas de telle ou telle donnée.

Merci pour cette explication sur le padding car il est vrai que je ne voyais pas l'utilité au début.
Je modifierai cette overlay ce soir et donnerai le résultat mais ça me semble cohérent ça fait plaisir si c'est bien ça.

Si c'est bien ça, j'espère ne pas avoir trop d'overlay présentant ces problèmes car ca va être plus contraignant à modifier comme je ne suis pas développeur je fais tout à la main, rien d'automatisé :s ...
jerome674
 
Messages: 98
Âge: 36
Enregistré le: Mercredi 8 Juin 2011 à 22:53:05
Localisation: Tours
Genre: Homme

Re: extraction de texte dans overlay Megaman Zero Collection

Message non lupar Lyan53 » Mercredi 16 Janvier 2013 à 17:33:48

Bah je taffe à la main également, c'est sûr que ça demande de la patience m'enfin bon quand on ne peux pas faire autrement ^^

Sinon pour le 3F non ça s'arrete bien comme sur mon screenshot

J'inverse le bloc surligné sur le screenshot pour te montrer :
Image
En rouge => taille du bloc surligné sur fond bleu

N'oublie pas que le 1er offset (0x00) est inclu ;)

Le mieux c'est de directement vérifier avec l'éditeur hexa pour ne pas se planter (il en faut un qui donne la taille des blocs que l'on surligne, c'est nettement plus confortable pour travailler :) )
Image
Avatar de l’utilisateur
Lyan53
Administrateur du site
 
Messages: 864
Âge: 40
Enregistré le: Lundi 22 Novembre 2010 à 20:48:11
Genre: Homme

Re: extraction de texte dans overlay Megaman Zero Collection

Message non lupar jerome674 » Jeudi 17 Janvier 2013 à 1:16:44

bon voici ce que j'ai fait sur l'overlay_0129.bin (ne marche pas mais à quel niveau)... :

j'ai décompressé l'overlay :

remarque -> les données ne sont pas les memes jusqu'a 0x3f après décompression, je prends donc lesquelles quand je veux reconstruire mon overlay (compressée ou non compressée, j'ai pris les compressées )?

avant décompression :
70 b5 00 22 0c 48 0d 4b 11 1c 54 10 a6 00 d4 07
a5 0f 84 19 2c 19 52 1c e1 52 07 2a f5 db 08 4a
01 20 10 76 07 48 c1 67 91 76 11 71 06 4a e3 20
b7 21 0c f7 5f f8 70 bd 64 02 11 02 e8 d0 02

après décompression :
70 b5 00 22 0c 48 0d 4b 11 1c 54 10 a6 00 d4 07
a5 0f 84 19 2c 19 52 1c e1 52 07 2a f5 db 08 4a
01 20 10 76 07 48 c1 67 91 76 11 71 06 4a e3 20
b7 21 0c f7 5f f8 70 bd 64 02 02 e8 06 00 0e

Mon soucis est donc de savoir si je travaille bien sur les bonnes données au début...

-------------------------------------------------------------------------------------------------------------
j'ai fait mes modifs en fr en partant de l'octet 0x3f à la fin sur l'overlay décompressé.
je l'ai compressé lzss à part dans un nouveau fichier.

j'ai copié le tout à la suite de l'overlay de base après le 0x3f.
j'ai ajouté un FF pour le padding et du coup j'ai modifié l'entrée 08 en 09 pour le padding.
ayant rajouté 1 octet, j'ai ajouté sur le header de la compression :
-pour la taille des données compressée : +1 en big endian par rapport à ce qui était calculé par DSDecmp
-différence entre les données compressée et les données décompresssées : +1 en big endian par rapport à ce qui était calculé par DSDecmp

Ai-je bien fait ?

dans le fichier y9.bin j'ai bien modifié

la taille décompressée :
taille compressée+difference taille entre données compressées et les meme données non compressées + 0x3f

la taille compressée :
juste édité le fichier à la toute fin et remplacé la valeur dans le ficheir y9.bin en mettant bien un 1 pour dire qu'il est compressé.

->coté calcul j'ai des doutes avec la "différence entre les données compressée et les données décompresssées" ->dernière partie du header d'un fichier compressé.

vois-tu des énormitées ou ca semble normal ? (je doute vu que ca ne tourne pas...)a
jerome674
 
Messages: 98
Âge: 36
Enregistré le: Mercredi 8 Juin 2011 à 22:53:05
Localisation: Tours
Genre: Homme

Re: extraction de texte dans overlay Megaman Zero Collection

Message non lupar Lyan53 » Jeudi 17 Janvier 2013 à 2:27:09

Les données correspondant au 0x3F sont strictement les mêmes sur le fichier décompressé comme le compressé, tout du moins sur les tests que j'ai effectué, il doit y avoir un souci au niveau de la décompression via les logiciels que tu utilises :/

Faudra sans doute le signaler à Lokichu ;)

Pour ma part j'ai extrait les fichiers overlay avec crystaltile, mais tu peux également voir ce que ça donne avec la compression BLZ de CUE > http://www.romhacking.net/utilities/826/


Par contre je ne comprends pas ton histoire de big endian car les datas sont stockées en little endian ;)
Bref attention à ne pas te planter :)



Concernant la reconstruction de l'overlay à compression partielle , il faut donc suivre cette ligne de conduite :

Note : en partant du principe que tu bosses sur des fichiers clean (donc bien décompressés sans erreur à la base)

1 - Restaurer les 0x3F tels quels dans un new fichier
2 - Faire une copie de ton fichier modifié et virer les 0x3F premiers octets sur ta copie (ceux qui ne doivent pas être compressés)
3 - Compresser tes nouvelles données modifiées
4 - Les coller dans ton nouveau fichier
5 - Ajuster proprement le padding de mise en forme et modifier la "taille du header + la taille des données compressées" en conséquence
6 - Voir la taille que ton overlay modifié décompressé fait (l'original, pas la copie)
7 - En partant de cette taille de base, soustraire les 0x3F dans un 1er temps, puis la taille des données compressées ensuite pour obtenir le différentiel de compression
8 - Ajuster les datas du différentiel en conséquence du résultat obtenu dans le header de ton overlay reconstruit


Et normalement c'est tout ;)
Image
Avatar de l’utilisateur
Lyan53
Administrateur du site
 
Messages: 864
Âge: 40
Enregistré le: Lundi 22 Novembre 2010 à 20:48:11
Genre: Homme

Re: extraction de texte dans overlay Megaman Zero Collection

Message non lupar jerome674 » Jeudi 17 Janvier 2013 à 12:36:42

En effet l'outil de Loki merde sur l'extraction, et Crystaltile2 passe bien sur la décompression... ->merci pour l'info

L'outils de CUE ne fait que de la compression ?
Si ca fait la décompression, quelle ligne de commande dois-je faire ?
la doc espagnole n'est pas évidente :oops: je vais continuer a compresser avec dsdcmp pour voir...

->me suis planté en effet c'est en little endian, je ne sais pas ce qu'il m'est passé par la tete...


points 1. à 4. ca va.

5. padding ok
modifier taille du header->ajuster suivant le padding ajouté ou non ?
modifier taille des données compressées->la taille change ou je garde les infos créées par la compression ?

6. pour connaitre la taille totale décompressée, c'est bien l'original -> sans le header ?
et avec les 0x3F du début a ajouter ?

7. a voir en pratique si je ne me perds pas dans toutes ces valeurs

8. oula, je teste et te redis ca :s

merci encore !
jerome674
 
Messages: 98
Âge: 36
Enregistré le: Mercredi 8 Juin 2011 à 22:53:05
Localisation: Tours
Genre: Homme

PrécédenteSuivante

Retourner vers Sur le ROMhacking

Qui est en ligne

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

x

#{title}

#{text}