Patch pour pouvoir lancer Lomax sans être en mode 8 ou 16 bits

Réduire
X
 
  • Heure
  • Afficher
Tout nettoyer
nouveaux messages
  • LunaVorax
    Militian


    • février 2007
    • 124

    #1

    Patch pour pouvoir lancer Lomax sans être en mode 8 ou 16 bits

    Bonjour,

    J'ai voulu jouer à Lomax mais le jeu affiche le message d'erreur suivant.

    Lomax will only run on 8 and 16 bit deep desktops.
    J'ai voulu voir si ça n'était pas juste l'affaire d'une petite instruction à patched, et c'est effectivement le cas.
    J'ai utilisé la version de Lomax fournie par Abandonware-France, les hashs de l'exécutable sont les suivant :

    Code:
    LOMAX.EXE md5: 9a057d3cf9f8deac1949fb6ac477379b
    LOMAX.EXE sha256: 04cc4dfd260037bab2765c649060ad2e091135e326e1668790a55ed4d649f130
    Vous devez rechercher la chaine hexadécimale suivante « 83 FD 08 74 1E 83 FD 10 74 19 » et la remplacer par « 83 FD 08 74 1E 83 FD 10 EB 19 »

    Une fois le correctif appliqué, vous devriez avoir les hashs suivants :

    Code:
    LOMAX_fix.EXE md5: 83a7d4413ce950e9b5e96025bf1313c0
    LOMAX_fix.EXE sha256: cd21e6c830059b74345b0b421f8cdb2db8b36173d4fb8b5bf77da4adf469d019
    À vous de me dire si le jeu fonctionne chez vous, des bugs graphiques peuvent appraitre.

    Pour ceux qui veulent comprendre à quoi cela correspond, il s'agit de la suite d'instructions qui comparent le mode de couleurs de l'écran avec 8 puis avec 16.

    Code:
    83FD 08    CMP EBP,8               ; L'écran est-il en 8 bits ?
    74 1E      JE SHORT LOMAX,004079BF ; Si oui, on passe à l'éxécution du jeu, sinon…
    83FD 10    CMP EBP,10              ; …est-ce que l'écran est en 16 bits ?
    74 19      JE SHORT LOMAX,004079BF ; Si oui, on passe à l'exécution du jeu, sinon on affiche un message d'erreur et on termine l'exécution.
    Le patch produit le comportement suivant :

    Code:
    83FD 08    CMP EBP,8
    74 1E      JE SHORT LOMAX,004079BF
    83FD 10    CMP EBP,10
    [COLOR="#FF0000"]EB[/COLOR] 19      [COLOR="#FF0000"]JMP[/COLOR] SHORT LOMAX,004079BF ; On exécute le jeu quoiqu'il arrive.
  • DragonsLover
    General


    • octobre 2004
    • 1724

    #2
    Intéressant, merci pour le patch.

    J'ai toujours voulu arriver à faire ce genre de choses dans des vieux jeux afin de les corriger comme tu le fais. Comment est-ce que tu t'y prends et est-ce bien compliqué ?
    J'adore les dragons! Ils sont le centre de ma vie! Je ne les oublierai jamais...

    Cliquez ici pour visiter mes dragons et les aider à grandir. Ils vous en seraient très reconnaissant!

    Commentaire

    • The Uploader
      MechWarrior


      • février 2010
      • 7353

      #3
      Salut

      J'aime beaucoup ce genre de modifs. J'essaie de m'y mettre mais ce n'est pas facile.

      J'aimerais beaucoup savoir comment tu mets en relation tel valeur héxa avec telle instruction ?
      Et comment tu modifies où "arrivent" les sauts d'instructions ?

      J'ai pu par le passé modifier des jeux pour qu'ils n'utilisent pas leur CD (Dune 2000) ou utilisent l'accélération graphique quoi qu'il arrive (Metal Gear Solid), mais c'était toujours en comparant un exécutable modifié anglais et une version non-modifiée anglaise pour répercuter les modifs sur un exécutable français (vive l'utilitaire VBinDiff !).

      Récemment j'ai voulu éviter au jeu pour Windows 9X O.D.T. (version PC) d'utiliser son CD, mais j'ai eu beaucoup de mal à insérer des "90" au bon endroit pour se faire. À vrai dire, je n'y suis pas arrivé, mais j'aimerais acquérir les compétences pour le faire.

      j'ai trouvé un NO-CD mais sous forme de patch à exécuter sous DOS (ou dans DOSBox) pour la version espagnol sur PC, mais je n'avais pas l'exécutable de la version espagnol pour comparer. Du coup, j'étais "sans béquilles", et c'était dur. :/

      Déjà, déboguer pas à pas le jeu avec Visual Studio m'a bien aidé pour savoir plus où moins où se faisait l'appel de la vérif CD. Le problème, c'est de décoder ce que je lis sans les sources. Et savoir mettre autre chose que "90". Et savoir intervenir au bon endroit.

      Au plaisir de te lire.
      Dernière modification par The Uploader, 28 octobre 2016, 10h24.
      RUNEXITW : pour quand RUNEXIT quitte le jeu trop tôt |
      Pack émulation PCem + Windows 95 | Pack émulation PCem + Windows 98SE | Pack émulation DOSBox + Win 3.11 | Pack PCem + Win 3.11 | Ma collection de wrappers (pas à jour)

      Commentaire

      • Groovykid
        Banned

        • août 2001
        • 11165

        #4
        je me souviens ya 30 ans avoir cherché sur Atari ST en hexa les verbes anglais utilisé dans King Quest 1, mais sans vraiment comprendre le reste comme ici lunavorax qui explique le JE en JMP qui permet de faire fonctionner lomax quelque soit la résolution !

        Ya t'il d'autres manoeuvre pour comprendre une partie du code source a partir d'un affichage en hexa ?

        Commentaire

        • LunaVorax
          Militian


          • février 2007
          • 124

          #5
          Salut à tous,

          Je ne pensais pas que mon patch déclencherais autant d'interrogations. Je vais tenter de vous donner les clés pour comprendre comment j'ai fait

          Avant toutes choses, non, je n'ai pas lu l'hexa directement, j'ai passé le programme dans un désassembleur/débogueur qui m'a permis de comprendre ce qui se passait.

          Ensuite, il faut que vous gardiez bien en tête que j'ai eu deux coups de chance
          1/ C'est un jeu pour Windows 32bits, et non un jeu Windows 16bits ou un jeu MS-DOS. Cela veux dire que je peux lancer le jeu dans un débogueur (j'ai utilisé OllyDbg v1.10) pour voir le code assembleur correspondant et l'exécuter pas à pas.
          2/ Il n'y a qu'une seule instruction à changer. C'est vraiment une chance et je ne le savais pas avant de me lancer dans cette affaire. J'aurais peut-êre eu avoir affaire à une procédure beaucoup plus complexe.

          Comment faire ?

          Récupérez d'abord la version 1.10 de OllyDbg, vous pouvez la télécharger à l'adresse suivante :
          http://ollydbg.de/odbg110.zip

          Interface de OllyDbg

          Lorsque vous lancez OllyDbg pour la première fois, cela devrait ressembler à la capture d'écran suivante. N'hésitez pas à maximiser la fenêre CPU.

          Ouvrez l'exécutable LOMAX.EXE avec OllyDbg, votre interface devrait ressembler à ceci :

          Cliquez sur l'image pour la voir en taille réelle 

Nom : 		2016-10-28-122225_2560x1440_scrot.png 
Affichages :	1 
Taille :		29,5 Ko 
ID : 			715934

          À cet instant précis, OllyDbg a lancé LOMAX.EXE mais a stoppé l'exécution au tout début. Cela va vous permettre d'exécuter LOMAX.EXE instuction par instruction.

          Nous allons d'abord nous concentrer sur les deux boutons « Step into (F7) » et « Step over (F8) ».

          Cliquez sur l'image pour la voir en taille réelle 

Nom : 		buttons.gif 
Affichages :	1 
Taille :		30,0 Ko 
ID : 			715935

          Si vous appuyez sur l'un des deux (pour l'exemple, on cliquera sur « Step over (F8) » vous allez voir la ligne grise se déplacer vers le bas.

          Cliquez sur l'image pour la voir en taille réelle 

Nom : 		stepover.gif 
Affichages :	1 
Taille :		33,3 Ko 
ID : 			715936

          Cela signifie que l'instruction « MOV EAX,DWORD PTR FS:[0] » a été exécutée, et que la prochaine instruction à éxécuter sera « PUSH EBP ». Donc, si vous recliquez sur le bouton, vous exécuterez l'instruction « PUSH EBP » et la bande grise passera à « MOV EBP,ESP ».

          Si vous cliquez successivement sur « Step over (F8) » vous allez voir les valeurs dans les différentes fenêtres changer, jusqu'à que le programme se mette à planter. Mais cela risque de prendre un certain temps avant d'arriver manuellement au message d'erreur. Par exemple, si vous cliquez plusieurs fois sur « Step over (F8) » vous devriez arriver dans une boucle qui se situe entre 0043AE34 et 0043AE50. Le programme fait un calcul, tombe sur l'instruction « JNZ SHORT LOMAX.0043AE34 » (qui signifie « Jump if not zero », cela veux dire que le programme saute à l'adresse 0043AE34 si le calcul qui a été effectué précédement ne donne pas zéro. Ici, l'instruction qui précède est « CMP BYTE PTR DS:[ESI].22 » qui compare une valeur avec une autre et qui retourne zéro si les deux valeurs sont égales.) et saute à l'adresse 0043AE34.

          Comme nous ne savons pas quand cette boucle va s'arrêter et que nous voulons passer au travers, nous allons utiliser un breakpoint.

          Les breakpoints.

          Un breakpoint est un « point d'arrêt » qui permet de dire au débogueur à quel moment on souhaites mettre l'exécution du programme en pause. C'est à dire que nous allons mettre un point d'arrêt après la boucle, que nous allons demander au débogueur d'exécuter le programme normalement, et de s'arréter au moment ou le programme voudra exécuter l'instruction sur laquelle nous avons mis un breakpoint.

          Pour cela, il suffit de faire un clic droit sur l'instruction sur laquelle on désire mettre un breakpoint, et choisir dans le menu déroulant « Breakpoint → Toggle (F2) ». Pour supprimer un breakpoint, faites exactement la même chose.

          Cliquez sur l'image pour la voir en taille réelle 

Nom : 		breakpoint.gif 
Affichages :	1 
Taille :		74,4 Ko 
ID : 			715937

          Une fois le breakpoint posé, vous pouvez continuer l'exécution du programme en cliquant sur « Debug → Run (F9) ».

          Continuez l'exécution du programme avec « Step over (F8) » et vous tomberez très vite sur le message d'erreur à l'adresse 0043AE99.

          L'instuction CALL.

          C'est là que les choses sérieuses commencent. Nous pouvons voir que notre logiciel plante lors de l'exécution de l'instruction « CALL LOMAX.0044CED7 » située à l'adresse 0043AE99. Cela signifie que quelque chose se passe dans cette instruction qui génère notre message d'erreur. L'insctruction CALL signifie appel, elle permet d'exécuter un morceau de code situé ailleurs dans le programme.

          C'est ici que nous allons utiliser le bouton « Step into (F7) » pour rentrer à l'intérieur de l'instruction CALL pour voir ce qu'il s'y passe.

          Procédure.

          Maintenant que nous avons déclenché notre message d'erreur, nous devons le relancer, mettre les breakpoints où nous voulons et rentrer dans les instructions qui nous posent problème.
          Voici la procédure que vous aurez à faire régulièrement.

          1/ Relancer le programme en cliquant sur « Debug → Restart (Ctrl+F2) ». Cliquez sur Yes si vous avez un message « Process still active ».
          2/ Allez directement à l'adresse incriminée en faisant un clic droit sur le code assembleur (n'importe où) et en cliquant sur « Go to → Expression (Ctrl+G) ». Et rentrez-y l'adresse de l'insctruction qui vous a posé problème, ici 0043AE99.
          3/ Placez un breakpoint sur l'instruction « CALL LOMAX.0044CED7 ».

          Cliquez maintenant sur « Debug → Run (F9) » et le programme s'arrêtera avant d'exécuter l'instruction.

          Step into.

          Nous allons maintenant rentrer dans l'instruction CALL pour voir ce qui s'y passe. Pour cela, cliquez sur le bouton « Step into (F7) ». Le curseur du débogueur se trouve maintenant à l'adresse 0044CED7.

          Et maintenant ?

          Maintenant, le travail va être essentiellement le même. Il va être question de dégrossir le code responsable du message d'erreur. C'est à dire qu'il faut exécuter le programme avec la commande « Step over (F8) » et faire attention à tout les CALL exécutés, pour voir lequel provoque un message d'erreur ou un arrêt du programme.

          Ainsi, très vite, vous allez voir que le CALL situé à l'adresse 0044CEE7 provoque lui aussi un message d'erreur.
          Il faut donc mettre un breakpoint dessus, relancer le programme et faire « Step into (F7) ». Et ainsi de suite.

          La solution.

          Au bout d'un moment, vous devriez tomber sur le dernier CALL qui pose problème. « CALL LOMAX.00407930 » situé à l'adresse 0040346D. Si vous vous rentrez dans ce CALL vous devriez voir quelque chose qui vous mettra la puce à l'oreille.

          Cliquez sur l'image pour la voir en taille réelle 

Nom : 		2016-10-28-130630_2560x1440_scrot.png 
Affichages :	1 
Taille :		56,0 Ko 
ID : 			715938

          Le message d'erreur « Lomax will only run on 8 and 16 bit deep desktops. » apparait ici à l'adresse 004079A8. Plus intéressant encore, celui ci est précédé du code suivant
          Code:
          CMP EBP,8
          JE SHORT LOMAX.004079BF
          CMP EBP,10
          JE SHORT LOMAX.004079BF
          Autrement dit
          Code:
          Comparer la valeur du registre EBP avec 0x8 (valeur décimale : 8)
          Jump if equal / Sauter à l'adresse 004079BF si EBP = 8
          Comparer la valeur du registre EBP avec 0x10 (valeur décimale : 16)
          Jump if equal / Sauter à l'adresse 004079BF si EBP = 16
          Si EBP n'est égal ni à 8 ni à 16, alors le code ne sautera pas à l'adresse 004079BF et exécutera les insctuctions suivantes :
          Code:
          PUSH EBX
          PUSH EBX
          PUSH LOMAX.00462BE0
          CALL LOMAX.0045503E
          XOR EAX,EAX
          POP EBP
          POP EDI
          POP ESI
          POP EBX
          ADD ESP,4F4
          RETN
          Autrement dit, afficher « Lomax will only run on 8 and 16 bit deep desktops. » et sortir de la fonction.

          Ainsi, la solution est facile. À l'adresse 004079A4, il faut remplacer l'instruction « JE SHORT LOMAX.004079BF », qui est un saut conditionnel (c'est à dire que le programme saute à une adresse différente à condition que le résultat de l'instruction précédente lui convienne), par un saut normal, donc par l'instruction « JMP SHORT LOMAX.004079BF ».

          Pour cela, double cliquez sur l'instruction, remplacez JE par JMP et validez en cliquant sur « Assemble ».

          Enregistrer son exécutable.

          Maintenant, pour sauvegarder vos modifications la procédure est la suivante :
          1/ Faites un clic droit sur le code en assembleur et choisissez « Copy to executable → All modifications ».
          2/ Une nouvelle fenêtre s'ouvre, fermez la, et OllyDbg vous demandera si vous souhaitez sauvegarder vos modifications.

          C'est terminé.

          J'espère que mes explications auront été claires. Si vous avez la moindre question ou le moindre soucis de compréhension, n'hésitez pas à m'en faire part. Je verais de mon mieux pour y répondre.

          Gardez aussi en tête que c'est une modification du jeu qui n'était pas prévue. Des bugs sont à prévoir. Par exemple, il y a des problèmes pour afficher les images transparentes, qui sont remplacées par des pixels noirs. Je ne sais pas encore si cela peut être corrigé, ni comment. Affaire à suivre donc

          Commentaire

          • The Uploader
            MechWarrior


            • février 2010
            • 7353

            #6
            Merci !

            Je n'utilisais pas la bonne manière de faire. Pouvoir remplacer des instructions x86 avec OllyDbg plutôt que d'être obligé de passer par l'hexa (car j'utilisais Visual Studio pour le déboguage, et HxD pour modifier l'exécutable) me rendra la tâche bien plus aisé (et rapide).
            Dernière modification par The Uploader, 28 octobre 2016, 14h07.
            RUNEXITW : pour quand RUNEXIT quitte le jeu trop tôt |
            Pack émulation PCem + Windows 95 | Pack émulation PCem + Windows 98SE | Pack émulation DOSBox + Win 3.11 | Pack PCem + Win 3.11 | Ma collection de wrappers (pas à jour)

            Commentaire

            • Warrens
              Champion


              • janvier 2003
              • 962

              #7
              Je me souviens d'un membre ('ergonomy_joe') qui nous faisait des tutos entiers sur des jeux modifiés en assembleur avec un désassembleur et un éditeur héxadécimal sur ce site même mais je ne me souviens plus dans quelle rubrique c'est.
              Je dis Joker ! Je peux donc rejouer...

              Commentaire

              Chargement...