Aller au contenu


Fall.Exe


  • Veuillez vous connecter pour répondre
109 réponses à ce sujet

#101 Daneel53

Daneel53

Posté 01 mars 2017 - 02:02

27 février

OK, merci beaucoup pour ces précisions.

J'ai finalement passé deux heures cette nuit à commencer à poser tout ça sur le papier, j'ai un peu avancé. Je lis consciencieusement tes écrits et j'ai juste besoin de les assimiler pour les faire miens. Normalement dans une semaine j'aurais compris la mécanique du truc dans laquelle tu sembles nager comme un poisson dans l'eau. Ensuite il faudra dérouler pour identifier tous les pointeurs et la position de ce qu'il faut changer dans la Fixup Table.

A la fin je devrais obtenir un grand tableau qui donne, pour chaque ressource 1, l'emplacement du pointeur correspondant dans le Fixup Table. Et là on pourra enfin déplacer des ressources pour donner de l'air aux chaines qui n'en ont pas comme Neuf, Hache ou Ebonite. :)

Edit du 28 février

J'ai beaucoup avancé aujourd'hui !

J'ai enfin compris le principe du truc, j'ai installé Python 2.7.13, j'ai vu comment modifier de façon élémentaire ton script pour faire sortir les couples Src Off/Target d'autres pages que la 350, notamment la 346 qui m'a permis de modifier la Fixup Table pour taper un octet plus loin et faire afficher "uir" au lieu de "Cuir". :yahoo:

Alors il reste un gros travail à faire qui est celui qui consiste à trouver les emplacements des pointeurs de chaque ressource 1 et leur entrée dans la fixup table. J'ai quelques pistes mais je dois poursuivre ma réflexion. IDA Pro 6.95 Demo, que j'ai essayé cet après-midi, est une version limitée qui ne permet pas d'analyser les fichiers DOS, IDA 5.0 Free n'affiche pas le segment 3, donc IDA c'est mort pour moi, sauf à trouver une version pirate dans un coin. Or toutes les adresses virtuelles qui nous intéressent sont des adresses visibles seulement dans le segment 3 via IDA. Pour ne pas en arriver à pirater, j'ai remarqué qu'il y a un décalage constant entre les adresses virtuelles de IDA que je trouve dans les explications et celles données par le debugger de DosBox. Alors je passe par celui-là et je translate : c'est moins facile, mais on a quelques résultats.

Il faut que j'arrive à faire un dump texte des ressources 1, puis de toute la zone virtuelle des pointeurs vers les ressources 1, et chaque pointeur contenant l'adresse d'une ressource, on pourra faire le lien entre un pointeur et la Ressource vers laquelle il pointe. Une fois les pointeurs connus, on sait trouver leur entrée dans la Fixup Table. Mais a priori je ne sais pas quelle est la situation et l'étendue de la ou des zones de pointeurs, et surtout il me faut un dump avec les adresses virtuelles en segment 3 puisque ce sont celles-ci qui sont directement liées au contenu de la Fixup Table. Sans IDA, faire ce dump est un vrai problème... J'en ai un par DosBox, mais les adresses sont translatées et l'ASCII n'est pas traduit en bout de ligne.

A suivre...

Modifié par Daneel53, 01 mars 2017 - 02:04.


#102 Elenwel

Elenwel

    Granny Smith Wiwi


Posté 01 mars 2017 - 07:17

Tu peux aussi prendre le problème à l'envers, chercher dans les fixups les entrées dont taget correspond à la chaine que tu cherches. Pour la chaine cuir tu devrais avoir deux fixup records, un par pointeur. Du coup tu n'aurais pas à chercher les pointeurs, juste les fixups.

Voir le messageD.A.D., le 29 avril 2013 - 21:21, dit :

Un avertissement d'Elenwel, c'est un avertissement qui en vaut deux : si tu n'en tiens pas compte, c'est toujours pour TA pomme, et en général, il ne fait pas de quartier. Mieux vaut éviter les pépins, ça empêche d'y laisser sa peau.

#103 Daneel53

Daneel53

Posté 01 mars 2017 - 09:43

Tu as parfaitement raison, Elenwel.

Cette réflexion s'était poursuivie dans mon cerveau durant la nuit et je me suis levé ce matin avec l'idée que peut-être je devrais partir de la FixupTable pour trouver les pointeurs puisque de toute façon je ne sais pas a priori où ils se trouvent.
J'ai donc dans la tête l'écriture d'un script ou d'un programme qui afficherait tous les couples  SrcOff/Target en ajoutant le calcul de l'adresse virtuelle complète du pointeur depuis NumPage et Target avec des équations que j'ai tirées de tes indications :
pMot.PAddr = (0x1000 x NumPage) + pMot.SrcOff + 0x56B10  et
pMot.VAddr = pMot.PAddr - 0x34B10

Je pense que ça doit être plus rapide en partant de ton script, il faut juste connaitre le premier et le dernier couple (et leurs pages respectives) à balayer, mais la réponse se trouve peut-être dans ton message précédent que je n'ai pas encore analysé. Ma journée fut chargée, on verra ça demain... :)

Question annexe : comment savais-tu qu'il y a deux pointeurs vers Cuir ? Je ne l'ai découvert hier après-midi que tout à fait par hasard en cherchant dans Fall.exe à l'éditeur hexa les octets 0x1E5F contenus dans la Fixup Table et j'ai vu qu'il y en avait deux : celui que je connaissais et un autre. En remontant depuis la Fixup Table je l'ai situé dans le monde virtuel, je l'ai pisté dans DosBox via les adresses translatées et j'ai vu qu'il pointait exactement au même endroit que le premier. Je ne sais pas depuis quel endroit du jeu il est utilisé, pas dans l'inventaire puisque que c'est là qu'on a trouvé le premier, et peut-être n'est-il pas utilisé du tout. Mais il faudra par principe le modifier aussi. J'ai vu dans la foulée que Cuir n'est pas le seul dans ce cas, il y aura donc pour certains mots non pas un mais deux octets ou plus à modifier dans la Fixup Table.

Modifié par Daneel53, 01 mars 2017 - 23:05.


#104 Elenwel

Elenwel

    Granny Smith Wiwi


Posté 02 mars 2017 - 07:36

IDA permet de lister les cross-références (référence vers une adresse ou pour les fonctions, graphes d'appel vers et depuis cette fonction). La deuxième occurrence d'un pointeur vers cuir semble être utiliser dans un message d'erreur.

Voir le messageD.A.D., le 29 avril 2013 - 21:21, dit :

Un avertissement d'Elenwel, c'est un avertissement qui en vaut deux : si tu n'en tiens pas compte, c'est toujours pour TA pomme, et en général, il ne fait pas de quartier. Mieux vaut éviter les pépins, ça empêche d'y laisser sa peau.

#105 Daneel53

Daneel53

Posté 02 mars 2017 - 09:46

OK, merci. C'est donc grâce aux références croisées d'IDA que tu avais vu qu'il y a deux pointeurs vers Cuir.

J'ai désormais une opération en trois étapes devant moi.

La première : lister tous les fixups présents dans la table, donner leur adresse physique dans Fall.exe (octet à modifier) et les adresses des pointeurs qu'ils dirigent.
La deuxième : relier les pointeurs aux chaines ciblées, celles qu'on veut déplacer.
Troisième, étape de regroupement : constituer un tableau complet qui relie les chaines et leur adresse à l'adresse du fixup à modifier dans Fall.exe.

Après ça, on pourra enfin déplacer des chaines et garder la mémoire de ce qu'on a fait.

Y a plus qu'à ! :)

Edit de 18:40

Après moult réflexions cet après-midi, j'ai compris que finalement on se fout totalement de l'emplacement des pointeurs. En effet, puisque toutes les ressources 1 se trouvent dans le segment 3, en partant des fixups on arrive à cette équation d'une simplicité biblique qui relie un fixup à l'adresse physique dans Fall.exe de la chaine pointée :

Ressource1.PAddr = Fixup.Target + 0x1A4B10 , 1A4B10 étant tout à la fois le début du segment 3 et le début des ressources 1 dans Fall.exe.

J'ai eu envie de me dire : tout ça pour en arriver là ! Mais sans tes explications et ton script, Elenwel, je n'aurais jamais pu en arriver là.

Il n'y a donc en fait que deux étapes :
1 - Lister le contenu de tous les fixups qui pointent vers une chaine en segment 3 et donner pour chacun l'adresse du Target et l'adresse de la ressource 1 visée. Pour cela j'utiliserai une version modifiée de ton script Python. Il me reste juste à identifier l'adresse du dernier fixup pour avoir une liste complète mais ça ne devrai pas être trop compliqué.
2 - Lier ça avec la liste des ressources 1 et leurs adresses, liste simple que je pourrai faire générer grâce à une petite modification de DFEXEEDT.

On obtiendra ainsi un tableau qui permettra de connaitre, pour chaque ressource 1, l'adresse et le contenu des Targets des fixups correspondants. Si on a besoin de déplacer un mot, il suffira de modifier le Target correspondant dans les fixups qui y font référence.

Je le répète, y a plus qu'à, mais on n'a jamais été aussi près de la fin de ce calvaire ! :)

Edit de 01:20

Pour l'instant ton script modifié sort une longue liste comme ça (là c'est pour Cuir) :
Fixup Address : 51943
Src off : 0FD2
Target 3:1E5F
Adresse Mot : 001A696F

Ça sent bon, hein ? Sauf que je dois mettre l'adresse du Target et pas celle du début du fixup... et ajouter le Mot en question qui se trouve à l'adresse indiquée. :)

J'essaie de pousser ton script jusqu'à la lecture de la chaine ressource. J'ai cherché mais pas trouvé un moyen simple de lire dans le fichier une chaine de taille inconnue à priori. Une instruction comme Mot = struct.unpack('s', file.read()) exige que Mot ait la taille exacte de la chaine à lire, inconnue a priori. Tu saurais comment faire, pour lire Cuir par exemple, si tu connais son adresse (0x001A696F) dans le fichier mais pas sa longueur ? Au pire j'ajouterai une fonction FileReadSTRING qui lira les caractères un par un jusqu'au premier 00, mais il serait étonnant qu'il n'y ait pas déjà une instruction Python toute faite pour ça...

Édit du 05 mars

Cette histoire de lecture de string C m'a bien fait chier, je me suis tapé des tonnes d'erreurs de type jusqu'à ce que je finisse par trouver sur Internet du code qui fonctionne. Maintenant ça y est, j'ai une fonction FileReadSTRING qui sait ramener la chaine vers laquelle pointe le fixup. M'enfin, deux jours de perdus à cause de ces typages Python non explicites et brumeux ! :twisted2:

Maintenant je me heurte à ce que tu avais évoqué, à savoir le décodage plutôt complexe des fixups dont il existe plusieurs types dans la table. Tant qu'on est dans le format que tu as décodé, c'est à dire des trucs de sept octets qui commencent par 07 00 et qui pointent vers le segment 03, ça va à peu près, au moins on reste synchronisés. Par contre il y a dans le tas des fixups de neuf octets, et ceux-là il faut réussir à les détecter sinon le décodage finit par un plantage lamentable quand on se retrouve par exemple à aller chercher la chaine à une adresse supérieure à la fin de fichier parce que le fixup est mal décodé. Les fixups commençant par 07 00 ne sont pas non plus tous identiques car là je viens d'y trouver des targets qui pointent derrière le paquet de ressources 1 et semblent plutôt se diriger sur une indirection vers les ressources 2.

Bref, il me faut maintenant traiter les différentes formes de fixup pour rester synchronisé dans la table et réussir à trouver tous les fixups vers les ressources 1... et seulement ceux-là.

Quand j'aurai bien compris comment lire tous les fixups, mon but ultime sera finalement d'intégrer tout ça à DFEXEEDT de façon à ce que ce programme puisse aussi permettre le déplacement latéral des chaines de ressources 1 et non seulement leur remplacement au même endroit. Ceci afin de permettre une meilleure traduction en français sans avoir à faire tout le job à la main sous éditeur hexa, mais aussi permettre de faire la même chose aux traducteurs dans les autres langues qui ont exactement le même problème : un programme qui fait tout sera toujours mieux qu'un très long discours explicatif.

Vous le constatez, on n'est pas rendus, mais ça avance ! :)

Modifié par Daneel53, 05 mars 2017 - 14:05.


#106 Daneel53

Daneel53

Posté 06 mars 2017 - 22:30

Salut !

Je vais vous livrer ce soir le premier résultat tangible de mes travaux, qui n'ont pu arriver à ce stade que grâce à l'aide immense d'Elenwel qui m'a donné toutes les explications et le script Python qui allait avec comme en attestent les échanges ci-dessus. C'est en modifiant son script que j'ai fini par générer le ficher ci-dessous dont voici un très court extrait :

Target Address :  51933, Value : 1E6D, Resource Address : 001A697D
Resource : Plate
Target Address :  5193A, Value : 1E67, Resource Address : 001A6977
Resource : Chain
Target Address :  51941, Value : 1E5F, Resource Address : 001A696F
Resource : Cuir
[...]
Target Address :  51A98, Value : 1E59, Resource Address : 001A6969
Resource : Eboni

Ce fichier, brut de fonderie, contient 1951 références aux ressources 1 et indique :
- Target Address : Adresse dans Fall.exe des deux octets Target qui vont générer les pointeurs vers la ressource au lancement du programme Fall.exe.
- Value : Valeur actuelle du Target.
- Ressource Address : Adresse dans Fall.exe de la ressource concernée.
- Ressource : La ressource en question.

Si on veut déplacer une ressource dans Fall.exe avec un éditeur héxa, la procédure est simple :
- On la cherche dans ce tableau.
- On ouvre Fall.exe à l’éditeur héxa et on se rend à la Target Address.
- On modifie la valeur de ce Target de la valeur souhaitée.
- Puis on va à l'emplacement de la ressource et on la déplace en conformité avec la modif de Target qu'on vient de faire.

Par exemple, si on veut déplacer Cuir de deux octets vers la droite pour laisser de la place à Eboni qui se trouve juste devant dans la liste des ressources de Fall.exe, on se rend à l'adresse 0x51941 et on modifie 1E5F en 1E61. Puis on va à l'adresse 001A696F et on déplace les quatre octets de Cuir de deux octets vers la droite (il y a la place puisque 3 0x00 derrière Cuir). Pour finir le truc, on complète le mot Eboni qui est juste devant pour que ça devienne Ebonite (là inutile de s'occuper du target puisqu'on ne déplace pas le début de Ebonite). Et c'est fini !

Alors ce tableau est incomplet puisque je n'ai sorti pour l'instant que 1951 ressources 1 sur les 2540 identifiées.  La raison principale est qu'il y a deux formats de Fixup Records dans la table, ceux qui commencent par 0700 et qui font sept octets de long, et ceux qui commencent par 0710 et qui font neuf octets. Je n'ai pas encore réussi à décoder les 0710, les ressources 1 manquantes s'y trouvent certainement. En attendant d'y arriver, je préfère poster dès ce soir ce premier résultat : on n'est jamais à l'abri d'un accident et maintenant que ce résultat existe il serait vraiment dommage de ne pas le rendre public, même imparfait.

Mon travail continue, mais cette première étape nous aurait fait sauter de joie si on avait su la sortir il y a quatre ans. La porte de l'amélioration des textes français contenus dans le fichier Fall.exe est aujourd'hui grande ouverte, il n'y a plus qu'à ! :yahoo:

Édit du 7 mars

Aujourd'hui j'ai fait deux choses.
1 - Essayer de décoder les fixups en 0710, mais je ne suis arrivé à rien. Au bout de deux heures de recherche j'ai laissé tomber, je ne dois pas prendre le problème par le bon bout. Si le target y est sur quatre octets au lieu de deux (d'où les deux octets supplémentaires des fixup records 0710 vs les 0700), je n'ai pas trouvé à quoi additionner les targets pour arriver à une adresse valide dans les ressources 1... en admettant que ça y mène.
2 - J'ai codé le décryptage des fixups records dans DFEXEEDT et j'ai fait la jointure avec la liste des 2540 res1. On dispose donc désormais d'une liste ordonnée des res1 où figurent les adresses des targets et leurs valeurs pour les 1951 res1 identifiées. Celles dont le fixup record est encore inconnu se reconnaissent au champ Target addr qui reste à 0x00000000.

Si on regarde cette liste on voit que les res1 où le target est non identifié sont globalement des ressources dont on se fout, à savoir des noms de fichier ou des messages d'erreur utilisés par les devs pour le debug du jeu. En attendant mieux si on y arrive un jour, on peut considérer que cette nouvelle liste est suffisante pour faire toutes les modifs que l'on désire dans Fall.exe.

Je dépose ci-dessous la nouvelle liste qui annule et remplace celle d'hier soir.

Édit du 08 mars

J'ai continué mes modifications de DFEXEEDT. Les infos relatives aux fixup records sont maintenant affichées pour la ressource 1 courante, ça permet de ne pas être obligé de se reporter au fichier Fall.txt généré.
J'ai également enclenché le codage du déplacement d'une ressource à une autre adresse, ça devrait être terminé dans deux ou trois jours au plus tard. A partir de là, les déplacements de ressources 1 dans Fall.exe pourront être faites par m'importe qui sans comprendre la technique sous-jacente. La seule chose sera quand même de bien voir où on veut déplacer une ressource sans foutre le bordel, mais ça, aucun processus automatique ne le permettra, il faudra toujours avoir un œil sur l'ensemble pour voir les déplacements possibles.

A suivre...

Fichier(s) joint(s)


Modifié par Daneel53, 08 mars 2017 - 21:30.


#107 Daneel53

Daneel53

Posté 12 mars 2017 - 18:43

Salut,

Nouvelles rapides.

Je n'y ai pas travaillé ces jours ci, sauf cet après-midi où je me suis aperçu que certaines ressources peuvent avoir jusqu'à 13 fixups records (treize !) qui pointent dessus. En fait elles sont quarante à avoir au moins trois références. Le code va donc être un peu moins simple que ce que je pensais, et notamment sa vérification. Enfin, rien d'insurmontable, il faudra juste être rigoureux, ce que doit être de toute façon tout bon développeur de soft ! :)
Et accessoirement le fichier ci-dessus est incomplet puisque je n'y liste pas la totalité des fixups qui pointent vers une ressource ! Ma sortie texte devra être complétée.

Édit du 14 mars

Première étape franchie : DFEXEEDT sait désormais déplacer une ressource de quelques octets vers la droite quand il y a de la place (c'est à dire plusieurs 00 derrière la chaine utile) et mettre à jour tous les fixups en conséquence. J'ai donc pu réaliser avec ce programme ce qui me tenait à cœur depuis si longtemps : déplacer Cuir pour permettre l'écriture de Ebonite à la place de Eboni. C'est quand même plus pratique et rapide que de faire ça à la main dans un éditeur héxa. :yahoo:

Prochaine étape : implémenter le décalage vers la gauche pour profiter des 00 surnuméraires de la ressource précédente. :)

Modifié par Daneel53, 15 mars 2017 - 00:53.


#108 Daneel53

Daneel53

Posté 16 mars 2017 - 10:32

Bonjour,

Voilà, le décalage à gauche est lui aussi implémenté. Ce qui fait que maintenant il suffit de jouer au taquin pour déplacer des ressources afin de libérer de la place pour celles qui en manquent. Hier soir je me suis pris au jeu et en quelques minutes j'avais déplacé une vingtaine de ressources pour en agrandir cinq ou six, mettre Neuf à la place de Neu par exemple, ce qui affiche désormais "Etat : Neuf" dans l'inventaire au lieu de "Etat : Neu", c'est quand même plus chouette, non ?

Je vais pour l'instant laisser DFEXEEDT dans l'état où il se trouve, les éditions à suivre de Fall.exe me donneront sans doute l'idée de petites modifs supplémentaires, on verra. La dernière version (2.2.0) se trouve sur mon site, comme d'hab.

En attendant il faut désormais s'attaquer au VRAI travail : déplacer les ressources pour permettre d'agrandir celles auxquelles il manque des lettres. Je vais me plonger là dedans pour traiter toutes les évidences, tout en notant pour info les ressources que j'aurai modifiées (pas celles simplement déplacées, ce serait trop lourd et il est possible qu'à la fin une majorité ait changé de place).

Allez, Fall.exe, à nous deux ! :)

Édit du 18 mars

Voici la version actuelle de DFEXEEDT avec laquelle je m'amuse comme un fou :

Image IPB

En modifiant la New Address, il est possible de faire glisser une ressource vers la droite ou la gauche avec mise à jour automatique des fixups records, libérant ainsi de la place pour d'autres qui en manquent en faisant un jeu de taquin.

Avant-hier soir j'ai fait une grosse session de travail de plusieurs heures et j'ai dû déplacer environ 400 ressources au total pour en agrandir 150 dont j'ai pu améliorer le texte français. Quand je vois le temps qu'il m'a fallu pour réaliser ça avec cet outil (parfois il faut déplacer dix chaines pour en agrandir une onzième de façon suffisante), je peux vous assurer que faire ça à la main avec un éditeur héxa aurait vite tourné au cauchemar ! En effet pour chaque déplacement il faut bouger la chaine, boucher le trou avec des 00, calculer la nouvelle Target Value puis se rendre à chaque Fixups records pour modifier les target values, le tout sans se tromper. Vous imaginez faire ça 400 fois à la main ?

Il doit y avoir environ 1500 chaines réellement utiles dans le jeu, donc il reste du pain sur la planche !

Édit du 21 mars

Comme supputé, j'ai un peu modifié l'outil DFEXEEDT (j'ai mis à jour l'image ci-dessus). Désormais on peut faire déplacer une ressource soit en donnant sa nouvelle adresse, soit en donnant un déplacement dans le champs Move. Quand on doit faire des déplacements en chaine, c'est beaucoup plus pratique : on met par exemple -2 dans Move, touche Enter et c'est fait ! Puis on sélectionne la ressource suivante, re-Enter dans Move et elle se déplace aussi de -2, etc.

En parallèle je poursuis les modifications des ressources 1 de Fall.exe. C'est très long et il y en a pour un gros paquet de jours.

Modifié par Daneel53, 31 mars 2017 - 18:10.


#109 Daneel53

Daneel53

Posté 31 mars 2017 - 18:10

Un ch'ti coucou en passant, histoire de signaler que mon travail sur Fall.exe continue, lentement mais sûrement.

J'y travaille peu parce que c'est rébarbatif mais pour l'instant j'ai dû en arranger environ 320. Je m'appuie sur la version anglaise que je consulte en parallèle et, en plus de supprimer les abréviations merdiques, j'en profite pour traduire ce qui ne l'avais pas été et dont je suppose que c'est utile : les nombreux commerçants et artisans par exemple (menuisiers, bijoutiers, joailliers, etc.).

Édit du 03 avril

Ça y est, j'ai tout passé en revue, j'ai même corrigé quelques ressources 2 dans la foulée. Cela fait au total un peu plus de 400 ressources 1 corrigées et agrandies et pour certaines qui ne l'avaient pas été, traduites de l'anglais. Ceci a nécessité un immense jeu de taquin : plus de 1200 ressources ont changé d'adresse !Tout n'est pas encore nickel chrome mais j'ai fait au mieux avec la place disponible.

Il faudrait maintenant faire un essai du Fall.exe nouveau pour vérifier qu'il ne génère pas de plantage. Si ça tente certains, je le dépose ci-dessous.

Fichier(s) joint(s)


Modifié par Daneel53, 03 avril 2017 - 23:55.


#110 Daneel53

Daneel53

Posté 26 juin 2017 - 15:56

Ce Fall.exe est désormais intégré au PFD 0.32.

Si vous avez des choses à en dire, n'hésitez pas ! :)




0 utilisateur(s) li(sen)t ce sujet

0 membre(s), 0 invité(s), 0 utilisateur(s) anonyme(s)