Inscrivez-vous gratuitement
pour pouvoir participer, suivre les réponses en temps réel, voter pour les messages, poser vos propres questions et recevoir la newsletter
trouver une chaine de caractères dans un programme compilé
Bonjour,
J'ai un programme(exe) qui affiche à certain moments un message "Erreur. En attente(...)"
Je voudrais trouver dans le code compilé ou se trouve ce message et éventuellement le modifier.
Est ce possible ? Et si oui quelqu'un sait il comment faire ?
Merci.
Bonjour,
si la chaîne est codée en ASCII simple, c'est assez facile avec un éditeur hexadécimal
Merci Forthman pour ton aide :-)
En fait ma demande n'est pas très bien formulée.
Pour trouver le message en ASCI pas de prblm.
J'ai pris Hex Edit, j'ai fait un find et j'ai trouvé.
Maintenant ce que je voudrais faire c'est modifier le code (pas le message) pour que ce message ne s'affiche plus.
Pour ça j'ai besoin de trouver d'ou est "apellé" le message d'erreur.
Le programme a vraiment une structure bizarre il est composé de plusieurs fichiers aux noms étranges.
Par exemple celui ou j'ai trouvé ma chaine ASCII c'est 66666666.003 et il semble que ce fichier contienne tous les messages d'erreur du programme (uniquement ça).
Donc je me dis que dans un autre fichier (celui ou l'erreur est traitée) il doit y avoir un "appel" du message dans le fichier 66666666.003 mais vu que je ne sais pas comment se fait cet appel je ne sais pas quoi chercher.
Aurais tu un conseil ?
pour quel os est écrit ce programme ?
fonctionnement en mode console ou en fenêtres ?
Alors si j'ose dire Hales c'est là qu'est l'os !
Ce programme ne tourne pas sur un OS mais sur un hardware bien spécifique sans OS (http://www.lightronic.de/Produkte/Controller/hydra.htm)
J'ai réussi à trouver dans le code le message d'erreur et à le changer en un autre message.
Mon but n’est évidemment pas de faire apparaitre un message d’erreur fantaisiste mais de supprimer le bloquage du à l’erreur...
Je me dis que pour ça il « suffirait » que je remonte « le courant ».
Ce message d’erreur est bien « appelé » par le programme quand je mets une valeur DMX supérieure à 2.
Si je trouve de ou dans le code il est appelé je pourrais peut être identifier le « bout de programme » qui gère l’erreur et le jumpé pour qu’il ne traite plus cette erreur et me laisse mettre n’importe qu’elle valeur.
Qu’en pense tu ?
Mon souci maintenant c’est comment je pourrais « voir » la structure et trouver d’où est appelé le message ?
Aurais tu une idée ?
Ce genre d'appareil, quand il renvoit une erreur c'est pas pour rien normalement.
T'es sûr que c'est un bridage logiciel ?
Bonjour,
Ça, c'est assez courant en informatique, même sur PC, pour gérer l'internationalisation (i18n). Ça permet de réécrire facilement les messages dans toutes les langues et d'utiliser ensuite celle de l'utilisateur sans avoir à recompiler tout le programme.Envoyé par Yepazix
Parlons franchement : essaies-tu de contourner la limitation d'un logiciel dont tu n'aurais pas la licence ?
Dans le principe oui mais dans tous les cas, il va te falloir désassembler ton code et, pour cela, avoir les bons outils. Même une fois cela effectué, remonter le code va s'avérer fastidieux, surtout sans la documentation de ton matériel. Si ton programme est compilé en langage machine, tu obtiendras du code assembleur adapté à ta cible mais tu ne retrouveras jamais le code source original depuis lequel il a été produit. En premier lieu, donc, il te faudra effectivement cerner la structure de tes exécutables et déterminer sur quel micro-processeur ils tournent.Je me dis que pour ça il « suffirait » que je remonte « le courant ». Ce message d’erreur est bien « appelé » par le programme quand je mets une valeur DMX supérieure à 2. Si je trouve de ou dans le code il est appelé je pourrais peut être identifier le « bout de programme » qui gère l’erreur et le jumpé pour qu’il ne traite plus cette erreur et me laisse mettre n’importe qu’elle valeur. Qu’en pense tu ?
Ensuite, il va falloir vérifier si tes exécutables ne sont pas en fait compilés dans un langage de plus haut niveau destiné à être interprétés par une machine virtuelle installée sur ta machine. Enfin, faire disparaître le message d'erreur en lui-même ne règlera pas forcément la source du problème : ce n'est pas parce que le message d'erreur aura disparu en lui-même que tu pourras accéder à l'étape suivante.
Ben pour parler franchement... pas du tout les logiciels sont dans toutes leurs versions téléchargeables gratuitement sur le net.Parlons franchement : essaies-tu de contourner la limitation d'un logiciel dont tu n'aurais pas la licence ?
Mon erreur est d'avoir bricolé mon hardware et du coup d'avoir fait en sorte que celui ci ne soit compatible qu'a 80 % avec les logiciels existant, le Hardware étant devennu une sorte d'hubride entre deux version --> il me faudrait une sorte d'hybride entre deux versions de soft.
Bon vu ce que vous me racontez je crois que je vais essayer de trouver les pièces (malheureusement le produit est discontinued) pour changer ce qui est incompatible dans mon hardware et ainsi je pourrai réinstaller le soft "normal".
Merci quand même.
Il est normal que l'on te pose la question (la plupart des désassemblages aujourd'hui le sont pour cette raison), et la modération a posteriori des forums nous oblige — légalement — à faire ce genre de vérification.
Du coup, peut-on avoir un lien vers les exécutables en question ? Si on a une vue sur la manière dont ils sont construits, on sera peut-être plus à même de t'aider.
Ça, c'est une info capitale que l'on n'avait pas au début. Peux-tu nous en dire plus également ?Mon erreur est d'avoir bricolé mon hardware et du coup d'avoir fait en sorte que celui ci ne soit compatible qu'a 80 % avec les logiciels existant, le Hardware étant devennu une sorte d'hubride entre deux version --> il me faudrait une sorte d'hybride entre deux versions de soft.
Le projet peut être passionnant en soi, mais il n'en restera pas moins très difficile. Il s'agit d'un authentique reverse engineering, bien qu'il existe probablement des forums consacrés à ta machine et qui doivent déjà receler les infos dont tu as besoin.
Cependant, et pour le coup, trouver l'endroit où ton message est appelé est effectivement un bon moyen de faire l'association entre ton matériel et la façon dont il est piloté logiciellement (notamment au niveau des ports d'entrée-sortie).
Bon alors je me lance dans des grandes explications détaillées.
AU départ il existe six versions de l'appareil dont on parle.
Spirit, Sky et Space en version normale ou tour on peut les voir ici http://www.lightronic.de/Produkte/Controller/hydra.htm.
C'est six appareils sont exactement identiques au niveau du hardware.
Même carte mère, mère CPU, même RAM,...
Les seules différences sont l'écran LCD intégré et les sorties DMX (RS485).
Spirit : Petit écran LCD et 1 sortie DMX.
Sky : Petit écran LCD et 2 sorties DMX.
Space Grand écran LCD et 4 sorties DMX.
Quand j'ai du remplacer mon écran j'avais "de stock" un petit écran que j'ai donc mis à la place de mon grand écran.
J'ai donc un modèle qui possède 4 sorties DMX mais un petit écran.
Ce n'est donc plus vraiment une Space mais un peu plus qu'une Sky tout de même.
De la j'ai deux choix, soit je fais tourner le programme de la Space et dans ce cas je peux exploiter mes 4 sorties DMX mais mon écran est illsible.
Soit je fais tourner le programme de la Sky, dans ce cas pas de problème d'écran mais je ne sais plus exploiter que deux sorties DMX au lieu de 4.
Les trois versions du programme sont disponible sur Internet ici :
http://www.lt-light.com/en/discontinued/hydra-spirit/
http://www.lt-light.com/en/discontinued/hydra-sky/
http://www.lt-light.com/en/discontinued/hydra-space/
Vous verrez qu'il y a chaque fois deux liens : Software et Simulator.
Software est la version qu'il faut charger dans l'appareil.
Simulator est une version qui peut tourner sur le PC comme simulateur (limité a 5 minutes d'uttilisation effective, après les sorties se désactives et donc sans grand intéret.
Le produit étant discontinued et très ancien je n'ai pas réussi a contacter des gens pouvant me renseigner sur le logiciel ou les sources (surtout que la société est un peu cahotique). Le gars que j'ai eu, un ancien du service technique a juste pu me dire que toutes les versions logicielles sont à la base identiques à l'exception de la gestion de l'écran. Il m'a dit que même en ce qui concerne la limitationde l'adressage DMX c'est juste une petite routine avec une limitation de la valeur.
Si vous voulez voir comment se manifeste le problème le mieux c'est d'éxécuter sur votre ordi le simulateur, comme il reproduit la même chose que sur l'appareil vous verrez.
Pour ça :
Téléchargez l'émulateur SKY.
Ouvrez le dossier et cliquez sur Wolehydrasky.exe
Vous allez voir une représentation de l'appareil s'ouvrir sur votre écran.
Double cliquez sur le bouton CHANNEL (au dessus du 7 du pavé numérique).
Vous voyez sur l'autre fenêtre (qui représente l'écran VGA externe de l'appareil) que les chose ont changées.
Il y a une collone à droite avec des numéros 1,2,3,4,5,6,7,8,... et en regard de ces numéro des adresses DMX. Vous remarquez au millieu au dessus qu'il est mentionné Dmx 1,1 - 512,4. Pourtant si vous tentez d'introduire une valeur supérieure à 512,2 (1,3 par exemple) ca ne marche pas.
Pour essayer cliquez sur le chiffre en regard du 1 et essayez d'introduire 1,3.
Vous aurez le message "Erreur. En attente gradateur/numéro de ligne ###.# / .#".
Si maintenant vous téléchargez le simulateur de la Space vous verrez que si vous faites exactement la même chose ça marche parfaitement.
Voila je crois que maintenant vous savez tout.
Le but pour moi est de pouvoir introduire dans la version sky une valeur DMX ,3 ou ,4 et même plus haute si possible car je pense même à rajouter des cartes DMX pour porter le nombre de sorties à 6 ou 8.
Ceci étant dit ça me semble mal barré mais bon si quelqu'un a un trait de génie :-)...
Il ne faut pas hésiter à se lancer d'emblée dans ce genre de laïus (quitte à ajouter un synopsis en tête de post) car tu n'es pas limité par le temps de parole. À l'inverse, les gens fréquentent beaucoup de forums différents et ne sont pas dans la tête des gens qui demandent de l'aide et il faut souvent partir à la pêche aux informations. Les problèmes détaillés et exposés clairement deviennent alors très appréciés.
Quelle version du logiciel utilises-tu ?
La bonne nouvelle est qu'effectivement, il s'agit bien de fichiers *.exe au format MS-DOS pour i386. Un file sous Linux nous donne le résultat suivant :
Code Shell : Sélectionner tout - Visualiser dans une fenêtre à part
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
Ta machine est donc un mini-PC sous MS-DOS et pilotant du matériel propriétaire. Il est donc extrêmement facile de désassembler les exécutables en eux-mêmes et si c'est le remplacement de l'écran qui provoque la panne, ton idée de rechercher la chaîne pour trouver la cause du blocage redevient la bonne !
Par contre, le problème de l'absence de documentation persiste et la cause fondamentale peut se trouver enfouie plus profondément qu'on le croit. As-tu une idée de ce qu'est le « gradateur » en question ? Si c'est un dimmer pour la luminosité de l'écran, pas de problème. Si c'est un équipement de scène piloté par la console (intégré à elle ou pas), c'est plus ennuyeux parce que ça signifie qu'il est possible que le logiciel se servent des équipements qu'il peut détecter, comme ton écran, pour déterminer sur quelle machine il tourne et que cela l'induise à faire une fausse hypothèse et à attendre des équipements inexistants.
EDIT - je n'avais pas lu ceci :
De la j'ai deux choix, soit je fais tourner le programme de la Space et dans ce cas je peux exploiter mes 4 sorties DMX mais mon écran est illsible.
Soit je fais tourner le programme de la Sky, dans ce cas pas de problème d'écran mais je ne sais plus exploiter que deux sorties DMX au lieu de 4.
Il n'y a donc pas de détection matérielle. Tout est directement inclus dans le programme adapté au modèle que tu utilises et su tu dis que tu as réussi à installer l'un et l'autre (quitte à avoir un écran illisible), ça veut dire qu'il n'y a même pas de contrôle à l'installation.
Trouver la chaîne risque de ne pas t'être d'un grand secours dans un premier temps. Le fait de pouvoir utiliser 4 sorties DMX au lieu de 2 ne doit pas être lié simplement à un compteur quelque part mais également à leurs ports d'entrée-sorties qui doivent être fixes, d'une part, et à la gestion par le logiciel des données envoyées par ces ports (plusieurs files à maintenir, à surveiller, et à faire cohabiter avec le reste des effets).
Par contre, il y a des chances pour que le programme soit suffisamment modulaire pour que l'on puisse extraire l'affichage de l'un pour l'inclure dans l'autre. C'est de la chirurgie informatique mais c'est faisable.
EDIT 2 : Qu'entends-tu exactement par « écran illisible » ? Est-ce que l'affichage est complètement brouillé ou bien les informations s'affichent-elles correctement à l'écran mais que le reste est invisible parce que sous la limite basse de l'afficheur ?
petite idée en passant : désassembler les 2 programmes ( 2 et 4 sorties)
et les comparer, avec un peu de chance la solution pourrait sauter aux yeux
edit: comme l'a dit Obsidian, ça commence à devenir intéressant
Hello et merci de l'intéret que vous portez à mon problème.
En effet on peut charger n'importe quelle version sur n'importe quel hardware.Il n'y a donc pas de détection matérielle.
et la solution pourrait d'ailleurs venir de là et être plus simple que prévue car en fait les hardwares sont aussi strictement identiques.
La version 2 sorties DMX possèdes en fait les 4 sorties exactement comme la version 4 sorties car ces sorties peuvent être "physiques" ou "virtuelles".
Je l'explique, dans mon domaine on uttilise depuis longtemps un protocle apellé DMX512 (512 cannaux par sortie) donc quand on vouloat plus de 512 cannaux il fallait multiplier les sorties et donc le nombre de câble (PFFFF).
Il y a quelques années un nouveau standard est apparu: ARTNET !
On à l'art dans mon domaine de renommer les chose car le ARTNET c'est en fait du "bête" Ethernet !, dans cet Ethernet on fait "passer" un certain nombre (8 je crois), de DMX à la fin du ARTNET on peut avoir différentes machines qui ont un connecteur ARTNET mais "répondent à une adresse DMX.
Pour bien comprendre il faut savoir que ces différentes machines ne font que recevoir un info et n'envoient jamais des infos.
Un gradateur reçois du hardware qui nous occupe une valeure de 0 à 255 sur un canal DMX.
Prenons un exemple, si le gradateur est assigné avec l'adresse 1 sur l'univers DMX2 (adresse 1,2 ou 513) et que sur le hardware je tappe CHANNEL 1 @ 50, la lampe branchée sur le gradateur s'alumera à 50 %.
Bien sur je simplifie, nous avons maintenant des projecteurs comme ceci http://www.soundlightup.com/flash-an...clay-paky.html qui permettent des chose bien plus complexes. Une adresse DMX peut alors correspondre à la puissance de la lampe mais aussi à l'amplitude d'un mouvement, la densité d'une couleur,...
Bref ce qui est important à retenir c'est que le Hardware envoit une info vers un appareil sous forme d'une valeur de 0 à 255 dans un canal de 1 à 512 et un univers de 1 à ... .
L'appareil reçoit cette info et agit en conséquence mais sans jamais "répondre" au hardware.
Ce qu'il faut savoir aussi c'est que tous les modèles de Harware n'ont pas le même nombre de sorties DMX physiques mais ils ont tous une sortie ARTNET.
Donc virtuellement sur tous les hardwares il y a un nombre illimité d'univers DMX.
Maintenant pour en revenir à mon problème.
Quand je charge le programme de la space, l'écran est partiellement brouillé, ce qui est en clair est désorganiser et c'est normal puisque l'écran de la space est grand (+/- 10 cm de haut) et que j'ai mis un écran de Sky à la place (+/- 5 cm de haut).
Quand je charge le programme de la Sky l'écran s'affiche bien mais je n'ai plus que 2 sorties DMX exploitables (physiques ou ARTNET).
Je pense qu'il faut laisser tomber l'idée de modifier la partie "écran" du programme car elle va être complexe et fort "imbriquée" dans le programme.
Par contre selon les infos que j'ai eues il serait très facile de modifier le "verrou" qui limite l'asignation DMX.
Comme je le disais dans mon précédant message c'est uniquement quand on veut assigner un canal DMX que se manifeste le problème.
C'est au momment de ce que nous appelons le patch.
Patcher signifie dire au Hardware quel canal DMX correspond à quel canal du Harware.
Imaginons qu'on a trois "spots", un rouge, un vert, un bleu.
Ils sont sur des gradateurs différents et ayant les adresses DMX 5,1 - 8,1 et 63,1.
On souhaite que ces projecteurs s'alument toujours en même temps, pour cela on va "patecher" les trois gradateurs de ces trois projecteurs sur le même canal de la console.
Pour cela on va dans le patch : CHANNEL CHANNEL.
On va sur la première ligne à droite on se place dans la collone du centre en dessous de Edit+ et dans la collone DMX on va tapper l'un en dessous de l'autre 5,1 - 8,1 et 63,1.
Ensuite on sort en faisant plusieurs fois EXIT.
Maintenant si on tappe CHANNEL 1 @ 50, nos trois projecteurs s'alumeront ensemble a 50 %.
Maintenant imaginons que notre troisième projecteur n'est pas sur un gradateur ayant l'adresse 63,1 mais sur un gradateur ayant l'adresse 58,3.
Ca ne marcherait pas !
On retourne dans le patch : CHANNEL CHANNEL.
On va sur la première ligne à droite on se place dans la collone du centre en dessous de Edit+ et dans la collone DMX on va tapper l'un en dessous de l'autre 5,1 - 8,1 et 58,3.
Et la on a le message d'erreur : "Erreur. En attente gradateur/numéro de ligne ###.# / .#".
Et bien sur en même temps que ce message la valeure 58,3 est rejetée.
De ce que j'ai comme info ce rejet et ce message d'erreur sont le résultat d'une petite routine de contrôle qui est identique sur toutes les versions du logiciel à l'exception de la valeur de rejet (1, 2 ou 4).
Ce qu'il faudrait trouver c'est juste ou est cette routine et soit la supprimer, soit mettre un valeur très haute genre 9.
J'ai déjà essayé comme le suggère Forthman de comparer les différentes versions du logiciel mais sans succès. Je n'ai peut être pas non plus les bons outils....
Voila j'espère qu'avec ça vous visualisez mieux le problème et que vous pourrez m'aider.
A bientôt...
Hello,
Merci pour ces infos.
J'entends bien et c'est bien à cela que je pense aussi. Malheureusement, il est probable, même si pas entièrement certain, que le logiciel fasse plus que simplement contrôler la validité des numéros de DMX au moment de la saisie. Il suffit qu'il utilise un tableau par canal (pour chacun de ses 512 slots) pour que ce tableau ait lui aussi besoin d'être étendu si tu passes de deux à quatre canaux. Et ce, tout au long du logiciel.
Il est probable également qu'il n'y ait besoin que de changer une seul ligne… au niveau du programme source ! Par exemple si celle-ci contient l'équivalent d'une macro #define en C indiquant tout au long du programme de combien de canaux on dispose. Dans ce cas, il faudrait le recompiler et les modifs risquent d'être importantes.
Cela dit, comme le dit Forthman, il peut être intéressant de comparer bit à bit les deux versions du logiciel pour vérifier si elles ne seraient pas identiques à quelques octets près, ce qui aurait tendance à aller vers ton souhait.
Quoi qu'il en soit, il est essentiel que l'on sache quelle version du logiciel tu utilises pour l'explorer. Apparemment, la dernière en date, tant pour Sky que Space, est la v3.34 du 16 octobre 2012.
Par contre, côté difficultés : comme tu l'as remarqué, les chaînes de caractères sont déportées dans un fichier dédié. Il va donc être très difficile de retrouver à quel endroit elles sont gérées dans l'exécutable. Ensuite, j'ai commencé à désassembler cet exécutable : 320.000 lignes de code assembleur. Il y en aurait pour plusieurs années de travail à temps plein si on voulait les commenter toutes.
De ce que j'ai eu comme info de l'ancien servive technique il y a juste une vérification de la valeur au moment de l'introduction de la valeur dans le patch et ensuite plus aucune vérification.
La version que j'uttilise est bien la dernière.
J'ai essayé de comparer les programmes mais il ne fauit pas oublier qu'il y a aussi des différences au niveau de l'écran --> On aura malheureusement pas seulement une différence au niveau de la valeur à modifier et je ne sais vraiment pas comment différencier les deux.
Ce que je me disais c'est que j'ai repéré dans un des fichiers le texte du message d'erreur :
Comme tu le vois je me suis même amusé àle modifié et maintenant à la place du message d'erreur ça affiche "tu es vraiment trop con".
Pour que le programme puisse afficher ce message il faut bien qu'il soit "appelé" de quelque part n'est ce pas trouvable ?
Si oui on aura déjà une idée de la zone qui est à modifier non ?
Bon évidemment dit comme ça :-)
Encore une question, tu as maintenant de l'assembleur, n'est il pas possible de le convertir en un language plus clair ?
Même si cette convertion est aproximative et contient des erreurs elle pourrait nous aider à trouver le morceau qu'on cherche non ?
Peux tu me dire ce que tu uttilise comme outils par exemple pour convertir en assembleur ?
Merci encore :-)
Je viens de regarder rapidement les 2 fichiers archive space et sky 3.34
je n'ai pas d'outil là de suite pour comparer 2 fichiers octet par octet, mais
j'ai remarqué que dans les 2 zips tous les fichiers sont identiques en taille
sauf 55555555.777
En les ouvrant avec un éditeur hexa, j'ai vu la signature "MZ" en début du fichier. ce sont donc des fichiers EXE renommés
Il faut donc sûrement fouiller là dedans
Si. C'est généralement comme cela qu'on fait pour isoler rapidement une zone à partir d'un code objet dont on ne sait rien (et aussi souvent pour contourner les protections qui nous gènent). On part d'un message, on le localise dans le code objet, on en détermine l'offset, on recherche cette valeur ailleurs dans le code et on examine le code désassemblé autour des zones que l'on a trouvé pour vérifier si elles sont bel et bien en train de référencer ce message. Puis de là, on remonte la pile des appels et on commence à mettre en place un début de structure.
Malheureusement, dans le cas présent, les messages en question sont tous rassemblés dans un fichier distinct. Ce fichier est lui-même identifié non pas par un nom ordinaire mais par une suite de chiffres, ce qui tend à laisser penser qu'il doit être autogénéré à partir d'un algorithme quelque part, et qu'on ne pourra pas non plus retrouver facilement ce nom de fichier au sein du code objet principal.
Les messages doivent donc être affichés à l'écran en appelant une routine quelque part et en passant un numéro déterminé à la compilation. Il n'y a donc rien qui nous permettent d'emblée et facilement de retrouver à quel endroit tel ou tel message est généré.
Réponse courte : non.Encore une question, tu as maintenant de l'assembleur, n'est il pas possible de le convertir en un language plus clair ?
Les compilations ne sont pas des bijections, et heureusement parce qu'elles n'auraient alors plus beaucoup d'intérêt.
On peut — parfois — trouver quelques indices qui nous permettent de deviner dans quel langage le programme a été écrit (par exemple à la manière de gérer la pile), quand ce n'est pas directement en assembleur, ce qui se faisait somme toutes encore beaucoup du temps du DOS.
En fait, je le fais depuis Linux mais j'utilise nasm et ndisasm après avoir extrait le code lui-même du fichier entier. Il y a beaucoup d'utilitaires sur la toile permettant de manipuler directement les *.exe mais j'ai la flemme de les rechercher et de les installer.Peux tu me dire ce que tu uttilise comme outils par exemple pour convertir en assembleur ?
Pas tous, il y a aussi 44444444.560. Malheureusement, 55555555.777 est le plus gros de tous les fichiers et est justement celui qui nous intéresse (le logiciel en lui-même).je n'ai pas d'outil là de suite pour comparer 2 fichiers octet par octet, mais j'ai remarqué que dans les 2 zips tous les fichiers sont identiques en taille
sauf 55555555.777. En les ouvrant avec un éditeur hexa, j'ai vu la signature "MZ" en début du fichier. ce sont donc des fichiers EXE renommés
Il faut donc sûrement fouiller là dedans
Un truc que l'on peut faire, en revanche, c'est vérifier si l'image du soft téléchargé se retrouve bien telle quelle à l'intérieur de l'exécutable de l'émulateur puis lancer l'affaire sous wine (déjà fait), et provoquer un core dump pour avoir une vraie image de la mémoire en situation. De là, on pourrait retrouver les références aux chaînes, trouver un bout de code qui le fasse, et retrouver sa trame au sein du code objet original.
Autre truc que je viens d'essayer et qui donne de bons résultats : je n'ai pas de bindiff à ma disposition mais un dump hexadécimal des fichiers objets avec un octet par ligne permet de les comparer facilement avec le diff habituel et là, surprise : la majorité des différences font entre 1 et 10 octets de long maximum, et la différence contiguë la plus large est un seul bloc de 217 octets seulement :
Code Shell : Sélectionner tout - Visualiser dans une fenêtre à part
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
… par contre, il y a en tout 121868 différences entre le 55555555.777 de Sky et celui de Space. On ne va donc pas tous se les taper à la main, donc.
Même si je n'ai pas tout compris je l'avoue, à la lecture de ton message il me vient une idée !
Tu as comparé Sky et Space et si j'ai bien compris tu as trouvé un nombre relativement grand de différences.
C'est assez normal puisqu'entre Sky et Space il y a des différences pour les sorties DMX et pour l'écran.
Si tu faisais la même comparaison entre Spirit et Sky, tu devrais avoir bien moins de différences puisque dans ce cas la seule différence c'est le nombre de sorties DMX.
Et finalement si tu regardes les résultats obtenus sur les trois fichiers seule la zone qui est différente sur les 3 fichiers devrait être celle qui nous intéresse non ?
De là il y aurait peut être moyen de faire quelque chose ?
Salut,
Je ne comprend pas trop de quoi vous parler pour l'instant, mais ça a finit par m'intriguer alors j'ai téléchargé la version Sky et je l'ai passé sous Imm debugger.
Il y a un truc qui m'interpelle cash, je vois qu'il y a un import de socket et bind ??
C'est normal pour ce genre de logiciel ?
edit: d'ailleurs je viens de lancer le logiciel sans faire exprès en appuyant sur f9 alors qu'il était déjà sur le point d'entré. Il a démarré, mais il a complétement fait planter mon winxp (sous vbox). Lenteur extrême, impossible de faire quoi que ce soit, j'ai été obligé de forcer l'arrêt du systême.
Tu as téléchargé quoi ? Le logiciel lui-même ou l'émulateur (qui l'embarque) ?
Ça marche bien avec wine sous Linux. Par contre, je suis obligé d'effacer les sous-répertoires qu'il a créé pour le lancer une deuxième fois…edit: d'ailleurs je viens de lancer le logiciel sans faire exprès en appuyant sur f9 alors qu'il était déjà sur le point d'entré. Il a démarré, mais il a complétement fait planter mon winxp (sous vbox). Lenteur extrême, impossible de faire quoi que ce soit, j'ai été obligé de forcer l'arrêt du systême.
Vous avez un bloqueur de publicités installé.
Le Club Developpez.com n'affiche que des publicités IT, discrètes et non intrusives.
Afin que nous puissions continuer à vous fournir gratuitement du contenu de qualité, merci de nous soutenir en désactivant votre bloqueur de publicités sur Developpez.com.
Répondre avec citation
Partager