119 réponses à ce sujet

[Nico coiN]

Oh si, que certains lisent ce que tu écris ! C'est juste que c'est très haut-perché pour moi. Ce que tu fais tient beaucoup du hacking et ça m'intéresse à titre personnel, mais je suis bien incapable de te faire des suggestions utiles ou te prêter assistance.

J'admire ce que tu fais et m'y intéresse mais j'ai juste... euh... ben... rien à dire.

Bon courage et bonne continuation.

[Daneel53]

Salut Nico,

Merci pour tes encouragements, j'en aurai besoin. Hier matin je me demandais si je n'allais pas laisser tomber, tellement j'étais perplexe. Je ne voyais pas par quel bout prendre le truc : je voyais des instructions assembleur mais je ne comprenais pas comment je pourrais exploiter ce que j'avais devant les yeux. Aujourd'hui ça va un peu mieux, même si les interrogations restent nombreuses. Je vais expliquer ici ce que je fais. Si je laisse tomber un jour prochain, d'autres arriveront peut-être à poursuivre.

Comme chacun ici le sait, le paquet qui nous pose problème dans Fall.exe est ce qui est appellé Text Resources #1 dans DFEXEEDT : un longue suite de 2540 chaines de texte de tailles variables séparées par un x00. Le problème de cette liste est que, pour traduire en français, on est obligé de respecter la longueur max des textes équivalents anglais car le programme s'en va lire sans coup férir à l'emplacement du début de chaque texte anglais, on ne peut pas ajouter une lettre en français et décaler bêtement ce qu'il y a derrière. Cela pose problème par exemple pour traduire Axe par Hache (manque 2 lettres) ou New par Nouveau (il en manque 4), d'où les nombreux mots restés en anglais ou les raccourcis foireux restant de ci de là dans le PFD : ils viennent tous de Fall.exe !

Je cible actuellement pour mes essais une zone très précise des ressources 1 de Fall.exe : celle qui va de Fer à Cuir. Pourquoi ? Deux raisons :
- Fer (620), Acier (621), Argent (622) et Cuir (628) sont des matériaux que l'on trouve dès le début du jeu dans des objets de son inventaire. Il suffit donc d'accéder à l'inventaire pour déclencher très facilement la lecture de ces textes par le programme : de bons candidats aux breakpoints comparatifs sans avoir à jouer entre chaque essai, un clic sur le bon objet suffit.
- Juste avant Cuir dans cette liste se trouve l'Ebonite (627). En anglais il y a dans le fichier Ebony0Leather0. En français Leather devient Cuir, on gagne deux lettres. Par contre Ebony devrait devenir Ebonite, mais il manque deux lettres. Vu l'impossibilité de changer les longueurs des textes, la version française dans le fichier du PFD est devenue Eboni0Cuir000. C'est quand même ballot : on a deux octets de libre derrière Cuir mais on ne peut mettre Ebonite0Cuir0 car, si le programme affiche alors très bien Ebonite en entier (lecture de la chaine jusqu'au premier 0), tapant toujours au même endroit absolu, il ignore le déplacement de Cuir et lit e0, le Plastron Cuir devient un Plastron e.

Tout l'enjeu de mes essais se résume simplement : comment faire comprendre au programme qu'il doit aller chercher le mot Cuir deux octets plus loin ? Plus généralement, que faut-il changer dans le binaire de Fall.exe pour décaler l'instruction de lecture de certains textes des ressources 1 ?

Fall.exe est un jeu DOS. Pour le lancer sous un Windows moderne il faut donc utiliser un simulateur de DOS, ce que fait très bien le programme Dosbox. Inconvénient ? On ne peut pas debugger directement le programme Fall.exe car il est lancé au sein de Dosbox. Vu de Windows, c'est Dosbox qui tourne, pas Fall.exe.

La semaine dernière j'ai découvert qu'il existe une version avec debugger intégré de Dosbox. La solution idéale ? Ca aurait pu, malheureusement il manque à ce debugger deux choses fondamentales : la recherche de l'emplacement d'une chaine de caractère en mémoire (où se trouve Cuir ?), et surtout la possibilité de mettre un point d'arrêt (breakpoint) en lecture. Comme tous ces textes ne sont accédés qu'en lecture, il est impossible avec ce debugger intégré de faire arrêter le programme quand il lit le mot Cuir.

Je suis donc passé à un debugger externe, j'ai choisi un peu par hasard Cheat Engine 6.6 (CE). Lui sait trouver une chaine en mémoire et mettre un point d'arrêt en lecture. Donc je lance CE, je lance Daggerfall (DF) via Dosbox comme d'habitude (mettre DF en fénêtré et non en plein écran pour pouvoir switcher avec Alt+Tab entre les fenêtres de CE et celle de DF) et je dis à Cheat Engine de pister le processus Dosbox.

Dans Daggerfall je lance le jeu, charge une sauvegarde et accède à l'écran d'inventaire. Puis je vais dans CE, je recherche en mémoire la chaine Cuir, je met un point d'arret en lecture sur la lettre C, je repasse dans DF, je clique sur un objet en cuir dans l'inventaire... et Cheat Engine stoppe le jeu sur l'instruction assembleur qui lit Cuir.

Constats :

Dans le fichier Fall.exe, les textes se trouvent aux adresses suivantes :
001A6936 : Fer (Iron)
001A693B : Acier (Steel) = 001A6936 + 5
001A6941 : Argent (Silver) = 001A6936 + x0B
...
001A686F : Cuir (Leather) = 001A6936 + x39

Après avoir mis des points d'arrêt en lecture successivement sur Fer, Acier, Argent et Cuir, j'ai fini par remarquer que le registre EDI contenait successivement les valeurs 0027E646 (EDI1), 0027E64B (EDI2), 0027E651 (EDI3) et 0027E67F (EDI4). Que constate-t-on avec quelques petites soustractions ?
EDI2 = EDI1 + 5
EDI3 = EDI1 + x0B
EDI4 = EDI1 + x39
Autrement dit, les valeurs successives de EDI sont séparées des mêmes différences que les adresses des textes dans Fall.exe. De là à penser que ce registre est chargé, avant la lecture, d'une référence directe à l'emplacement mémoire des textes il n'y a qu'un pas. Intéressant, mais...

Dans Cheat Engine, les textes ont d'abord été trouvés aux adresses suivantes : 097D9666, 097D966B, 097D9671, 097D969F. A part le dernier chiffre, pas de rapport évident avec les adresses dans Fall.exe. Mais au cours de lancements successifs de Dosbox durant mes essais j'ai constaté que l'emplacement mémoire des chaines et du code exécuté n'était pas toujours le même. Sans doute un effet du chargement dynamique par pages dans le mode protégé de Windows car CE trouve les adresses absolues du process Dosbox dans la mémoire du PC et non pas des adresses dans Daggerfall proprement dit. La seule constante a finalement été les valeurs de EDI, toujours égales à 0027E67F quand je cherchais Cuir par exemple.

Pour essayer d'y voir plus clair j'ai laissé de côté CE et je suis revenu dans le debugger intégré de Dosbox qui présente l'avantage d'écrire les adresses du programme Fall.exe et non de Dosbox sous la forme [Segment]:[Adresse dans le segment] et non sous forme d'adresse absolue comme CE.
J'ai commencé par constater que le code est au segment 0838 et les data au segment 0828, ce qui est attesté par les registres CS = 0838 et DS = 0828.
Pris d'une intuition, j'ai regardé à l'adresse 0828:0027E67F et j'y ai trouvé... Cuir !

CQFD ! Le flag EDI contient bien, pour une chaine à lire, son adresse dans le segment Data indiqué par le registre DS !

Étape suivante : de où cette valeur sort-elle ? Comment le programme sait-il qu'il doit aller chercher Cuir en 0027E67F ? Ce n'est pas l'adresse directe dans Fall.exe (001A686F), la différence entre ces deux valeurs n'est pas a priori significative (000D7E10), Fall.exe ne contient pas la suite d'octets 27E67F ou 7FE627 donc cette valeur ne se trouve pas directement dans le programme.

Seule solution pour avancer : pouvoir mettre un breakpoint lors du remplissage de EDI par la valeur 0027E67F pour comprendre comment cette valeur est élaborée. Malheureusement il semble que la fonction Breakpoint sur valeur de registre n'existe pas dans Cheat Engine...

Je ne suis pas au bout de mes peines !

A suivre...

Modifié par Daneel53, 19 février 2017 - 09:06.

[Nico coiN]

C'est ironique par ce que là j'ai peut-être quelque chose à dire...

Daneel53, le 19 février 2017 - 08:58, dit :

Fall.exe ne contient pas la suite d'octets 27E67F ou 7FE627 donc cette valeur ne se trouve pas directement dans le programme.

L'adresse que tu cherches est 0027E67F. L'inversion des octets de poids fort et faible se fait-elle aussi sur 4 valeurs ? Je n'en suis pas sûr... Ce qui voudrait dire que la suite de valeurs que tu cherches serait en fait 27007FE6, non ?

Sinon, quand je m'amusais à tricher dans mes jeux j'utilisais TSearch. Pour résumer on comparait la mémoire à des états différents (genre le nombre de pièces d'or possédées par le joueur à chaque fois qu'il achetait un objet). On trouvait une valeur qui changeait en concordance, et à une adresse spécifique. Si on injectait une valeur comme xFF à cette adresse alors on se retrouvait en jeu avec 255 pièces d'or. Cette adresse était dynamique et changeait à chaque partie, voir plusieurs fois dans la même partie. Je devais donc relancer une comparaison de mémoire régulièrement pour retrouver la bonne adresse et me redonner des pièces d'or.

Ça marchait mais c'était répétitif et usant. TSearch permettait aussi de tracker le jeu d'instructions assembleur (une soustraction) qui allait enlever des pièces d'or à cette adresse dynamique. Il suffisait alors de faire une recherche hexa pour trouver ce jeu d'instruction directement dans l'exécutable du jeu (à condition qu'il ne soit pas crypté, packé ou compressé) et le modifier pour le remplacer par une addition (acheter un objet ajoutait alors son prix à ma bourse au lieu de le retirer) ou des NOP (l'objet devenait gratuit). Je modifiais donc l'exécutable (avec un simple éditeur hexa) et je pouvais jouer à mon jeu cheaté sans même avoir à relancer TSearch et me reprendre la tête à courir après une adresse mémoire qui changeait sans arrêt.

Tes explications montrent grosso modo qu'on appliquait la même procédure. Ce long monologue que je viens de faire ne sert pas à grand chose si ce n'est à te montrer que je comprends de quoi tu parles. Alors c'est très ancien pour moi (c'était il y a 8-9 ans), mais peut-être (je dis bien peut-être) que TSearch contient des outils plus malléables ou plus poussés pour faire ce que tu cherches.

Ça va peut-être te faire hérisser le poil mais pourquoi ne pas essayer de taper au hasard ? Ta valeur EDI qui est une constante (si je t'ai bien compris), que se passe-t'il si tu la modifies (si tu l'incrémente de 1 par exemple ?)

J'espère ne pas avoir dit d'ânerie... Je doute de pouvoir t'aider plus, désolé.

[Daneel53]

Bonjour,

Non, tu ne dis pas d'âneries, tu t'interroges, comme moi...

Merci pour la suggestion sur l'ordre des octets dans l'adresse, je n'avais pas pensé à cette combinaison, mais elle ne donne rien non plus. Cela ne m'étonne pas, je pense qu'elle doit être le résultat d'une addition Base + Offset, la base pouvant être par exemple l'adresse du début du paquet de ressources 1 et l'Offset la position dans le paquet. Mais je pense qu'il y a plusieurs bases dépendant des diverses déclarations de tableaux dans le jeu. Ce n'est pas pour rien que l'on trouve d'abord main.c puis d'autres fichiers.c, on trouve là tous les noms des fichiers source ayant contribué à l'élaboration du programme Daggerfall. Donc autant de bases que de fichiers source serait probablement le minimum.

[Elenwel]

Pour tout ce qui est reverse, je te conseil très très fortement IDA, il existe une version démonstration qui te permettra au moins d'avoir une vue plus simple que via CheatEngine

Sinon, pour apporter ma pierre, je viens d'utiliser l'installeur disponible ici http://wiwiki.wiwila...ench_Daggerfall, je décompile le binaire FALL.EXE datant du 01/12/2012 (MD5 : 21DF3B5B4EE4bCFF6DDAD307A292D0F9). Sous IDA, les chaines dont tu parles (Fer, Acier, ...) sont en
ds03:00171E26.

Tu remarqueras que les chaines ne sont par référencées directement, mais via des tableaux (typiquement, tu as en dseg03:0017CF4A un tableau de type Fer/Acier/Argent/Elfiqu/Dwemer/...). Sauf mécanisme de contrôle d'intégrité il me semble plus adapté de modifier ce tableau pour pointer sur les chaines qui vont bien et ça résoudra ton problèmes de places

[Daneel53]

Ça s'agite ! C'est bien.

On est bien d'accord que les chaines sont probablement rangées en tableaux déclarés dans le code C de Daggerfall. Et quand on traduit c'est bien directement dans ces tableaux qu'on modifie, c'est ce que fait DFEXEEDT. Le problème est que l'adresse de départ de toutes les chaines est FIXE, il est impossible pour l'instant de changer l'adresse de la première lettre de ces chaines, on peut pas simplement décaler vers l'avant ou l'arrière un mot de ci de là pour pouvoir mettre une traduction française de meilleure qualité.

Il faut donc trouver dans le code de Fall.exe la façon dont ces adresses de début de chacune des chaines est élaboré pour pouvoir espérer, comme décrit dans l'exemple ci-dessus, décaler le mot Cuir de deux octets vers la droite pour dégager les deux octets manquants pour écrire Ebonite et non seulement Eboni comme aujourd'hui. Comme expliqué ci-dessus, si on remplace aujourd'hui à l'éditeur hexa Eboni0Cuir000 par Ebonite0Cuir0, Daggerfall affiche correctement Ebonite mais affiche e au lieu de Cuir, parce qu'il continue de pointer sur l'ancienne adresse du C, adresse où se trouve désormais le e final de Ebonite.

Si je dois quitter Cheat Engine, j'essaierai probablement OllyDBG et la version gratuite de IDA.

[Elenwel]

Je recommence, parce uqe je suis pas sur de comprendre le problème :

On a ça dan IDA, à gauche une vue disassembly avec les CString dont on discute, à droite la vue hexa de la zone.

 wiwi_asm1.PNG   13,58 Ko   17 téléchargement(s)

On a bien des chaines, Fer, argent, ELfiq, le traducteur n'ayant pas la place pour écrire le mot complet.

C'est CStrings ne sont pas référencée directement, tu peux le voir sur IDA en listant les cross-reference (touche X) sur l'offset qui t'intéresse. Par exemple l'adresse ds03:171E26 est référencée par au moins deux tableaux (en ds03 17CF4A et ds03:1809B6). L'équivalent en C serait un tableau de pointeur de char.

 wiwi_asm2.PNG   224,35 Ko   19 téléchargement(s)

Tableau terminé par un pointeur NULL d'ailleurs. Si on prend le tableau en 1809B6, il est lui même référencé dans une structure de type char**** et par une fonction (sub_55A5B)

 wiwi_asm3.PNG   16,48 Ko   19 téléchargement(s)

On a un appel de fonction qui pourrait être en C func("Matériau interdit", materials[matID])

Bref, tu peux tout à fait modifier les pointeurs contenus dans 1809B6 pour pointer ou tu le souhaite (dans le même segment).

[Daneel53]

OK...

Je vais télécharger tes images pour les regarder tranquillement et voir ce que je peux tirer de tout ça. Ce qui m'intéresse ce sont les tableaux d'offsets à droite de l'image 2, offsets qui ressemblent furieusement aux tableaux que nous avions essayé, sans succès, de modifier à la main il y a quatre ans.

Comment utilises-tu IDA ? Une décompilation de Fall.exe sans que le programme soit en cours d'exécution ?

Plus tard...

Je comprend de tes images que tu as trouvé l'adresse de Fer (171E26) stockée à l'adresse 1809B8, et ainsi de suite pour les suivants de la liste. Et je suis d'accord avec toi sur le fait que si je modifie lors de l'exécution le contenu de l'adresse 1809B8 le programme va chercher la chaine ailleurs.

Le problème est que si je cherche dans le fichier Fall.exe la suite d'octets 26 1E 17 00, elle ne s'y trouve pas ! Exactement comme j'ai cherché hier l'adresse 27E67F et ne l'ai pas trouvée. J'en déduis que ces valeurs d'offset sont fabriquées de façon dynamique au chargement du programme puisqu'elles ne se trouvent pas dans le fichier non lancé. Ceci expliquerait d'ailleurs pourquoi les suites d'offsets identifiées il y a quatre ans peuvent être mises à 00 dans Fall.exe avec un éditeur hexa sans que le programme ne moufte à l'exécution : ces zones d'offset doivent être écrasées au lancement avec les offsets réels une fois le chargement du programme terminé.

On en revient au point de départ : comment ces offsets sont-ils élaborés et que faut-il modifier dans Fall.exe AVANT LANCEMENT pour les faire pointer ailleurs ?

Suite...

J'en remet une couche sur cette histoire d'offsets dans Fall.exe. Dans ton image, si je calcule la différence entre 1809B8 qui contient l'adresse de Fer et l'adresse du mot Fer lui-même 171E26, on trouve EB90. Par curiosité j'ai ajouté EB90 à l'adresse du mot Fer dans le fichier Fall.exe 1A6936, ce qui m'amène à l'adresse 1B54C6. Et là je suis tombé exactement sur ce que j'avais identifié il y a quatre ans comme la possible zone de stockage des offsets de Fer et ses successeurs sur 8 mots jusqu'à Eboni : on trouve successivement les valeurs 1E26, 1E2B, 1E31, 1E38, 1E3E, 1E46, 1E4E et 1E59 dont les écarts sont exactement les tailles des sept premiers mots. Ça s'arrête là parce que Orque et Daedric ne sont pas situés derrière Eboni comme leurs adresses en 18E9D6 et 18E9DA en attestent (on passe de 171Exx à 1718xx).
Ce sont ces valeurs que j'ai mises à 00 il y a quatre ans sans que Daggerfall n'en soit le moins du monde perturbé. D'ailleurs j'ai refait un essai ce soir : j'ai modifié à l'éditeur hexa la première valeur en 1E27 pour pointer sur le e de Fer et non le F, mais une fois lancé Daggerfall continue d'afficher Fer et non er. Il se fout de nos modifs alors que cette adresse est bien un pointeur vers l'adresse du mot Fer, la preuve en a été apportée ce soir.

L'objectif serait donc désormais de comprendre comment ces pointeurs sont renseignés au lancement du programme. Il faudrait, pour reprendre ton exemple, mettre un breakpoint en écriture sur l'adresse 001809B6 pour voir quel code est exécuté pour y mettre 261E1700, emplacement du mot Fer.

20 février :

J'ai téléchargé IDA Free 5.0 mais il se suicide au lancement après deux messages d'erreur : d'abord une boite avec Failed to set data for " puis une deuxième avec EAccessViolation. Une idée, Elenwell ? A moins que tu n'utilises la version Pro 6.x payante...

J'ai ensuite essayé les programmes x64Dbg et OllyDbg, mais aucun d’entre eux ne semble capable de retrouver le mot Cuir dans le processus DosBox. En fait c'est tout le paquet de ressources qui est introuvable, comme si ces programmes débuggaient Dosbox lui-même mais pas le programme contenu en train de tourner.

Je crains d'être contraint de trouver une version illégale de IDA Pro pour avancer...

21 février :

Quand on est un peu bêta, il faut savoir le reconnaitre. En fait il faut lancer IDA Free 5.0 en mode Administrateur pour qu'il fonctionne ! Voilà, c'était tout con, j'aurais dû y penser; Et maintenant, à l'attaque !

Modifié par Daneel53, 21 février 2017 - 17:27.

[Nico coiN]

Une question bête : la table des strings est-elle chargée une seule et unique fois par l'exe ? J'ai très peu joué au jeu et n'ai pas l'intention de le réinstaller, mais si tu meurs et reviens au menu principal puis reprend une partie, la table est-elle rechargée ?

[Daneel53]

Je ne sais pas, faut voir...

Sinon j'ai essayé IDA mais je n'ai absolument pas réussi à reproduire les extraits que Ellewel a postés il y a deux jours, et notamment la vue numéro deux. Je ne comprend pas bien comment il fonctionne, c'est quand même TRÈS complexe, même pour un ancien ingénieur logiciel comme moi...

[Elenwel]

En même temps c'est un métier de faire du reverse Mais ça vaut le coup de s'accrocher, IDA est vraiment très utile pour ces problématiques.  La deuxième vue c'est ma configuration de travail, j'ai toujours une ou plusieurs vu hexa, dont une synchronisée avec le curseur de la vue disassembly.

Je sais pas si tu as vu mais tu peux positionner les différents onglets un peu comme tu veux. Ensuite, tu peux synchroniser la vue hexa avec la vue "IDA-view" en cliquant droit sur l'hexa/synch with/ce que tu veux. C'est plus pratique.

J'ai essayé de patcher la table qui devrait correspondre à la liste des classes lors de la création d'un perso et je tombe sur le même comportement que toi Daneel.... Il faut que je re-trouve de la doc sur les vieux formats pré-NT, pour y retrouver mes petits, c'est peut être tout connement une histoire de table de relocation : les offsets dans FALL.exe sont relatifs à la base du segment (0x1A4B10 dans FALL.EXE), il faut un mécanisme pour que le loader sache que 1EB6 doit être remplacé par @seg+1EB6 en mémoire.

[Daneel53]

Citation

En même temps c'est un métier de faire du reverse

Alors là, je n'ai aucun doute ! En tant que développeur j'ai passé de très nombreuses années en compagnie de debuggers divers et variés (et encore récemment avec ceux de Visual Studio et de C++Builder), mais c'était toujours avec le code source sous les yeux. Mais là...

Je vais le dire différemment.

Utiliser Cheat Engine me fut très facile : tu lances Daggerfall via Dosbox, tu lances CE et tu l'attaches à Dosbox, tu demandes à CE de chercher Cuir en mémoire, il te le trouve très rapidement, un clic droit, tu poses un breakpoint en lecture sur le C, tu continues Daggerfall et CE t'arrête à la première lecture de la chaine Cuir : easy !

Avec IDA... Quand tu t'attaches à Dosbox il s'arrête sur un segment NTdll dont on ne sait pas ce qu'il fout là. Tu lui demandes de trouver la chaine Cuir et il mouline pendant des heures sans obligatoirement la trouver : il faut penser à cocher la case "Trouver toutes les occurrences", sinon il ne trouve rien. Et même en allant dessus (comment, c'est franchement pas évident de trouver la commande pour afficher cette zone), il t'affiche juste les octets les uns en dessous des autres, mais absolument pas ce que je vois sur ta deuxième capture : une liste de chaines les unes en dessous des autres avec leurs adresses, et à droite une autre fenêtre (laquelle ?) avec les pointeurs qui y mènent.

Ce programme est totalement abscons. Je voudrais déjà savoir comment tu arrives aux deux fenêtres que je vois sur ta capture 2. Par exemple je vois des segments appelés dseg03, je n'ai absolument pas cette nomination là dans mes fenêtres, moi j'ai debug065:0939C69E pour le C. Comment arrives-tu à générer les schémas de ta capture 3 ?


On ne va peut-être pas gonfler ce forum avec la façon d'utiliser IDA. Si tu peux m'envoyer ta façon de faire afficher ce contenu de cette façon, fais-le par mail à rdaneel53@gmail.com.

Citation

il faut un mécanisme pour que le loader sache que 1EB6 doit être remplacé par @seg+1EB6 en mémoire.

On est bien d'accord ! Sauf que comme je l'ai indiqué Daggerfall se fout totalement qu'on change ou qu'on modifie les valeurs d'offsets mises aux adresses correspondant aux pointeurs qui contiendront les adresses des chaines. J'ai remarqué un autre truc cet après-midi (extrait de mes notes de débogage) :

En ce qui concerne les valeurs trouvées dans les pointeurs de Fall.exe, on peut constater que si la suite de pointeurs des huit matériaux (Fer à Ebony) se termine par x1E4E et x1E59, le contenu des pointeurs vers Cuir, pourtant situés ailleurs avec d’autres pointeurs bien différents au milieu, prend la suite : x1E5F, x1E67, x1E6D, etc. Il semble que le contenu de ces valeurs poursuit, lui, une suite d’adresses de mots (qui commence à 0000 ?) dans l’ordre du paquet de ressources. Une façon d’indiquer où se trouve la chaine dans le paquet vers laquelle pointe le pointeur présent à cet endroit ? Probablement un travail fait par le compilateur, mais qui rend encore plus déroutant le fait que la mise à zéro de ces pointeurs ne gêne en rien le bon déroulement de Daggerfall.

Si je comprend globalement la logique du truc, je continue de ne pas comprendre comment la mise à 00 de ces pointeurs dans Fall.exe ne perturbe aucunement le programme. Les pointeurs sont à 00, mais le programme est toujours capable au chargement de savoir où sont les chaines. Pourtant, je suis d'accord avec toi, le schéma offset basique dans le pointeur de Fall.exe + décalage constant selon le chargement en mémoire semble bien logique... Mais ça ne fonctionne pas comme ça.

Il nous faudrait un spécialiste des compilateurs, il nous expliquerait comment tout ça fonctionne, à la génération de l'exe puis au chargement du programme. Mais je n'ai pas ça dans mon entourage, et je doute qu'il y en ait un qui passe par ici...

Modifié par Daneel53, 21 février 2017 - 21:40.

[Elenwel]

Format des exécutables sous MS/DOS:

http://www.textfiles...RMATS/lxexe.txt

Regarde du côté des tables de fixup, ça correspond plus ou moins à la fonction qu'on cherche. Le format a l'air merdique, mais potentiellement les entrées de type FixupRecord lieraient un offset src à une destination. Si le format est franchement mal branlé, il se peut que le pointeur qui va être écrit (par le loader) dans les différents tableaux soit intégralement décrit dans la fixuptable. En gros, le loader s'en foutrait de ce qu'il y a dans les tableaux, il l'écraserait par le contenu de la fixuptable.

Pour bien faire il faudrait faire un petit python pour parser tout ça et avoir une vue globale.

Et pour IDA, ne l'utilise pas comme un debuggeur, mais ouvre FALL.EXE avec. Tu retrouveras les mêmes adresses et segments que moi pour le tuto je vais voir ça, ça risque de me prendre du temps.

[Daneel53]

Merci pour le "petit" txt sur la structure des EXE DOS... Je regarderai ça à tête reposée.

Pour le tutorial, j'ai juste besoin de comprendre comment tu fais apparaitre les deux fenêtres qui figurent sur ton image 2. Elles sont très pratiques pour trouver les pointeurs des différentes chaines.

J'avais essayé cet après-midi d'ouvrir directement Fall.exe... Mais a priori ça ne permet pas de faire apparaitre des pointeurs avec un contenu tel que 261E1700, contenu qui ne peut exister que quand fall.exe a été lancé. Ou alors je suis vraiment paumé ! Et de plus moi je n'obtiens que deux segments (le 003 est vide), le paquet de ressources n'est pas affiché du tout, il est introuvable, les noms de segments ne sont pas comme toi, chez moi ils s'appellent seg001 et seg002 et non dsegxxx. Bref, une vision très partielle du fichier Fall.exe et différente de la tienne.

Sur ce, j'ai un gros coup de barre, à demain !

Nota : Tu fais comment pour insérer des images dans ton texte ? Chez moi le clic sur le bouton Insérer une image conduit à une demande d'URL et non à télécharger un fichier depuis mon PC. Je ne sais donc pas comment faire afficher une capture d'écran, d'où mes explications parfois confuses là où une petite capture serait tellement plus explicite !

Modifié par Daneel53, 21 février 2017 - 23:04.

[Elenwel]

Pour les images, tu as un onglet "Gallerie d'image" en haut du forum sous la bannière. A partir de ce module tu peux créer de nouveaux albums, uploader des images que tu trouvera ensuite dans la catégorie "mes media" de l'éditeur de post.

[Daneel53]

Passer par la création d'un album pour pouvoir poster une simple image ! C'est bien compliqué les amis.

Enfin, merci pour l'info, j'essaierai ça dans la journée.

Édit de 20:40

En fait j'ai encore passé deux ou trois heures à tester IDA Free 5.0 cet après-midi mais je n’arrive pas à reproduire ce qui se trouve dans ton image 2. Comment arrives-tu à faire que IDA soit conscient que le contenu des adresses depuis 1809B6 sont des offsets vers les chaines qui commencent à Fer, chaines qu'il est capable d'indiquer ? Pour ma part je n'ai rien trouvé dans le programme qui permette de chercher un offset ou indiquer qu'une adresse en contient un.
Accessoirement, je te repose la question : quelle version de IDA utilises-tu ? Peut-être que la version 5.0 ne contient pas cette possibilité.
J'ai trouvé le PDF du bouquin de référence de IDA Pro, j'y trouverai peut-être des réponses mais il fait 600 pages...

Modifié par Daneel53, 22 février 2017 - 20:48.

[Elenwel]

Guide rapide des raccourcis IDA (je dois être sur la dernière version de mon côté, mais de mémoire ça ne devrait pas avoir beaucoup changé):
d : créer des données, cycle entre BYTE/WORD/DWORD
a : créer un CString à l'offset courant
o : créer un offset
Ctr+r : dialogue pour définir un offset plus complexe (offset depuis une base surtout)
c : déclare du code à l'offset courant, IDA va tenter de désassembler jusqu'à tomber sur des opcodes non-définis
p : déclare une fonction à l'offset courant
u : undefine supprime le typage courant
h : cycle entre hexa et décimal
x : cross référence permet de lister les référence vers un label
espace : vue graphe
maj+F12 : liste des string

Surtout tu as la liste de toutes les fonctions possibles dans Options/Shortcuts.

[Daneel53]

Merci beaucoup, je vais regarder ça ces prochains jours.

De mon côté j'ai commencé à essayer de piéger la mise à jour des pointeurs avec le debugger intégré de DosBox qui présente l'immense intérêt d'avoir un adressage fixe à chaque lancement (le pointeur est toujours à la même adresse), alors que via un debugger externe comme IDA les adresses changent à chaque lancement de Dosbox, ce qui rend impossible la pose d'un point d'arrêt sur la mise à jour du pointeur puisque tu ne connais pas son adresse a priori.

En clair, pour en revenir au mot Cuir par exemple :

• Dans le fichier Fall.exe, Cuir se trouve à l'adresse 001A696F.
  
• Son pointeur s'y trouve à l'adresse du mot + B173, soit en 001B1AE2, et contient l'offset 1E5F, soit 5F 1E 00 00.
  
• Dans Dosbox, Cuir se trouve à l'adresse 0828 :0027E67F.
  
• Son pointeur s'y trouve à l'adresse +B173, soit en 0828:002897F2 et contient l'offset 27E67F (7F E6 27 00) une fois le programme chargé, soit l'adresse directe de Cuir dans le même segment.

J'ai réussi à déterminer que dans un premier temps Fall.exe se charge comme il est en fichier, c'est à dire avec 1E5F dans le pointeur de Cuir en 0828:002897F2, puis son contenu est transformé en 27E67F. C'est cette transformation que j'essaie de comprendre, mais ce n'est pas facile.

Pour en revenir à IDA, je ne peux pas trapper cette transformation puisque je ne peux savoir a priori à quelle adresse se trouvera le pointeur (elles sont différentes à chaque lancement de DosBox) et quand j'arrive à prendre la main, la transformation a déjà eu lieu. Alors qu'avec DosBox, le lance DosBox seul à la main, je pose mon breakpoint en 0828:002897F2, à ce moment il n'y a encore rien à cette adresse donc elle est à 00, puis je lance Fall.exe dans DosBox et le point d'arrêt se déclenche quand le 00 se transforme en 5F (chargement initial). J'attends ensuite le 7F mais en fait ensuite ça boucle indéfiniment entre 5F et 00, ça ne passe à 7F que si je supprime le point d'arrêt, donc je ne suis pas plus avancé.

Il faudrait une fonction du style "arrêter quand telle adresse passe à 7F", mais cette fonction n'existe pas dans le debugger limité de DosBox. On se résume : IDA ne peut trapper le passage de 5F à 7F parce que l'adresse du pointeur est inconnue a priori, le debugger de DosBox connait l'adresse mais ne le fait pas parce que la fonction nécessaire n'existe pas et que tant qu'il y a un breakpoint actif il ne passe jamais à 7F (il semble boucler éternellement entre les modes réel et protégé à cause du BP, je donnerai des détails plus tard).

Modifié par Daneel53, 23 février 2017 - 21:48.

[Elenwel]

Comme je le pensais, ça doit bien venir de la fixup table. J'ai commencé un petit script pour parser le format LinearExe mais c'est loin d'être propre

Bref, si on reprend tout, on cherche à savoir ce qui se passe à l'adresse virtuelle 0x01809B6 (pointeur vers fer)

• pFer est compris dans le segment (Objet dans la spec LE) 03
  
  • VAddr : 0X170000
    
  • PAddr : 0x1A4B10
• l'adresse physique (dans le fichier) de pFer est VAddr-segment.VAddr + segment.PAddr : 0x1B54C6
  
• pFer est donc dans la page (PAddr - Header.DataBaseAddr)/Header.PageSize = (PAddr - 0x56b10)/0x1000 = 350
  
• on peut aussi dire que pFer est dans la 16ème page de seg03 (la page commençant à 0x180000)
  
• En parsant la fixup table pour obtenir l'offset dans la fixup record table des fixup pour la page 350 on a :

 wiwi_asm4.PNG   16,4 Ko   9 téléchargement(s)

Pour la première entrée :
l'adresse page+0xB1A est remplacé sur un DWORD par l’adresse virtuelle 03:2A78
en 0x180B1A on a bien un pointeur vers 0x172A78

Autre exemple, la liste des classes à la création d'un perso, on a Spellswor et battlemage.

• la chaine battlemage est en 0x1719A5 soit 03:19A5
  
• une recherche dans la fixup table de 03 A5 19 retourne l'adresse physique 0x51E60, qui donnerai un fixup du type DWORD 0x17CD02=>03:19A5
  
• en patchant 03 A5 19 par 03 9A 19 (adresse de la chaine Spellsword) on a en jeu :

 wiwi_asm5.png   19,52 Ko   6 téléchargement(s)

Bref, c'est la fixup table qu'il faut patcher !

[Daneel53]

Ouaouh ! Je découvre à l'instant ton message et si je tire de bonnes conclusions de la phrase de fin tu aurais réussi à comprendre ce sur quoi nous (enfin, surtout moi, en fait) avons séché lamentablement depuis des années  !

Je regarderai ça de près ces prochaines heures (jours...) et si par la suite "il n'y a plus qu'à" pour trafiquer Fall.exe, je m'en chargerai. C'est le fardeau que je me suis donné, je le trainerai jusqu'au bout !

Ceci dit, pour aller jusqu'au bout, je suppose qu'il faudra ton programme et une vision complète de la Fixup Table. Tu peux me le faire parvenir par mail pour je puisse l'utiliser ? Ou bien nous poursuivons cette discussion technique de façon plus fouillé par mail, comme tu le sens.
RDaneel53@gmail.com

17h50

Je pense qu'il va falloir que j'installe la dernière version de façon temporaire (temporaire vu le timeout de la version démo) car quand j'essaie de charger Fall.exe dans IDA Free en indiquant que c'est un programme DOS il met un message d'alerte pour indiquer qu'il y a des "extra data" et si on continue il charge deux segments mais le segment 3 est totalement vide ! Or  c'est là dedans que se trouvent nos chaines et nos pointeurs.
Ça sent le bug corrigé après la version 5.0...

Modifié par Daneel53, 24 février 2017 - 18:03.

[Elenwel]

Non, c'est juste qu'il te charge le stub DOS Normalement tu dois pouvoir charger FALL.EXE au format New Executable, ou Linear Executable.

Sinon, mon script, mais c'est franchement crade :

http://pastebin.com/X9aGxpL7

[Daneel53]

Écoute, je suis désolé de t'embêter avec ces problèmes techniques, mais je n'arrive à rien avec IDA Free. Voici ce qu'il se passe.

Je le lance, écran d'accueil :

IDA Free 01

Album: IDA Free 5.0

Envoyé  25 févr. 2017 - 17:36

Je choisis New, cet écran s'affiche :

IDA Free 02

Album: IDA Free 5.0

Envoyé  25 févr. 2017 - 17:37

Je passe sur l'onglet DOS et choisis la première possibilité :

IDA Free 03

Album: IDA Free 5.0

Envoyé  25 févr. 2017 - 17:37

Je demande l'analyse :

IDA Free 04

Album: IDA Free 5.0

Envoyé  25 févr. 2017 - 17:37

Suit un écran d'options où tous les paramètres sont cochés sauf un :

IDA Free 05

Album: IDA Free 5.0

Envoyé  25 févr. 2017 - 17:37

Je continue, arrive le message d'erreur :

IDA Free 06

Album: IDA Free 5.0

Envoyé  25 févr. 2017 - 17:37

Je poursuis, l'analyse se fait et tu peux constater le résultat, il n'y a rien dans le segment 3 :

IDA Free 08

Album: IDA Free 5.0

Envoyé  25 févr. 2017 - 17:37

Alors qu'est-ce que j'ai mal fait là dedans ?

Accessoirement j'ai suivi tes instructions pour insérer des images, j'ai (difficilement) créé un album, je sélectionne les images par Mes Medias et j'obtiens le résultat présent qui renvoie sur la galerie au lieu d'insérer les images directement comme toi, c'est nul et ça me gave !

Sinon merci pour le script. C'est du Python... Comme quoi l'informatique est vaste : je sais développer des programmes Windows en C++ et d'autres langages, je sais monter et installer un PC mais je ne sais pas gérer un site Web et je ne connais pas le Python.
Ceci dit, tous les langages récents sont un peu bâtis sur le même moule, donc je comprend globalement ce que fait ton script.
Il me reste, un, à réussir à obtenir ce fameux segment 3, deux, à finir de comprendre ce que tu as exposé ci-dessus et trois, à réussir à l'appliquer pour les autres mots. Mais sans le segment 3 sous les doigts pour jouer avec c'est un peu compliqué.

J'ai commencé à regarder comment exécuter ton script Python. Si j'ai bien compris ce que j'ai lu et la syntaxe de ton script, tu es bien en Python 2.x et non en version 3.x ? si oui j'installerai la dernière version 2, soit la 2.7.13 aujourd'hui, sinon ce sera la 3.6.0.

Merci pour ton soutien et à bientôt.

Modifié par Daneel53, 17 mars 2017 - 09:12.

[Elenwel]

Ah oui, c'est du python 2.7 Je n'aime pas m'emmerder avec le type byte, et puis c'est celui qui est de base avec IDA pro... Et pour IDA, il ne te charge que le stub DOS, peut être une limitation de ta version... Essaye avec une version plus récentes si tu veux. (tous les exécutables de type PE/LE/XE/NE..;, bref post DOS, contiennent un stub dos, en général un print de "This program cannot be run in dos mode", pour FALL.EXE y a un peu plus.).

En fait, je suis pas certain que tu es vraiment besoin de parser tout le format LE.
Tu as besoins de la table des objets/segments et des champs DataPageOff et PageSize du header pour convertir les adresses virtuelles en adresses physiques et pour avoir l'idx de page.
Et des champs FixupPageOff, FixupRecorsOff et PageCount pour reconstruire un table mappant les index de page à l'offest base, dans le fichier des fixups pour la page.

[Daneel53]

OK, j'essaierai la version démo de IDA Pro 6.95, histoire de vérifier qu'avec cette version ça va mieux. Mais il ne faudra faire vite vu que la version démo a un time out non précisé mais probablement d'une durée maximum de un mois. Après, retour à la version Free et ses limitations...

Citation

Tu as besoins de la table des objets/segments et des champs DataPageOff et PageSize du header pour convertir les adresses virtuelles en adresses physiques et pour avoir l'idx de page.
Et des champs FixupPageOff, FixupRecorsOff et PageCount pour reconstruire un table mappant les index de page à l'offset base, dans le fichier des fixups pour la page.

Tu sais que tu n'es pas loin du chinois pour moi, là.

Je voulais essayer d'assimiler tout ce que tu as écris en ce dimanche pluvieux mais ma femme a laissé la télé tourner tout l'après-midi et moi, s'il y a de la musique ou la télé, je ne peux pas me concentrer sur des concepts nouveaux et des calculs, j'ai besoin de calme. Alors ce sera pour plus tard cette semaine.
Il faut que je mette "en équations" les liens entre les adresses physiques des chaines et de leurs pointeurs, leurs adresse virtuelles une fois le programme chargé, et le contenu de la Fixup Table où doivent finalement être faites les modifications.
Pour l'instant la seule chose qui soit vraiment connue c'est l'adresse physique des 2400 chaines. Les 2400 adresses physiques des pointeurs ne sont pas identifiées, sauf pour les mots allant de Fer à Cuir (ou Battlemage) que nous avons spécifiquement pistés. J'aimerais trouver un moyen de passer automatiquement de l'un à l'autre via la Fixup Table, mais je doute que ce soit aussi simple. C'est ce que j’entends par "mettre en équations" les adresses physiques des chaines et leurs pointeurs.

En attendant j'ai quand même cet après-midi modifié DFEXEEDT pour lui faire sortir les adresses physiques des chaines de ressources 1, j'en avais assez de devoir utiliser un éditeur hexa pour les connaitre. Les adresses sont affichées à l'écran à côté de la taille de la chaine et j'ai aussi ajouté ces adresses dans la sortie Fall.txt, comme ça on a les 2400 adresses hexa en clair dans un fichier texte. A tout hasard, je poste le fichier texte ci-dessous.

Fichier(s) joint(s)

•  Fall-Fr 20170226.txt   170,83 Ko   0 téléchargement(s)

Modifié par Daneel53, 26 février 2017 - 23:17.

[Elenwel]

Tu as besoins des champs "Page Size" (LEHead + 0x28 : taille d'une page physique)  et "Module # of Pages" (LEHead+0x14 : nombre de pages de données contenues dans le fichier"), et du champ "DataPageOffset" (LEHead + 0x80 : l'adresse du début des pages de données dans le fichier).

Et de deux tables, appelées dans la spec Fixup Page Table et Fixup Record Table.


Tu as donc les adresses (dans le fichier):

• 0x3C : offest vers le headerLE => 0x6B90
  
• 0x6B90 :
  
  • +0x14 : Nobre de page : 16C
    
  • +0x28 : Taille d'une page 0x100 (implicitement << 4 : 0x1000)
    
  • +0x80 : @ des pages dans le fichiers : 0x56B10
• 0x6B90 toujours:
  
  • +0x40 : offset de Table des descripteurs d'objets/Segments : 0xC4 => @ = 0x6B90+0xC4
    
  • +0x44 : nombre de module : 3
    
  • +0x68 : offest de la fixup page table : 0x6C5 => @ = 0x6B90+0x6C5
    
  • +0x6C : offset de la fixup record table : 0xC79 => @ = 0x6B90+0xC79

Pour connaitre la liste des fixup records pour une page virtuelles donnée il faut :

• Calculer son adresse physique
  
• En déduire son index (la combientième page?)
  
• Récupérer l'offset dans la table des fixup records via la fixup page table, et l'offset du dernier record pour cette page :
  
  • @RecordsStart = FixupPageTable[PageIdx] + FixupRecordTableOffset
    
  • @RecordsEnd = FixupPageTable[PageIdx+1] + FixupRecordTableOffset

Et maintenant parser les records jusqu'à tomber sur le bon Le format est complexe, j'en ai parsé qu'une toute petite partie. En gros:

• Byte : Flag de type
  
• Byte : Flag
  
• si Type&0x20 : Byte Source
  
• Sinon : WORD Source
  
• Si flag&3==0:
  
  • Byte : target's segment
    
  • si Flags&0x10 : DWORD Target
    
  • Sinon :   WORD Target

Source est l'offset dans la page de l'adresse à modifier, target est l'offset, par rapport au segment, de la cible.