retrouver les .vi d'un .exe

[vince.th]

Bonjour, 

J'aurais voulu savoir s'il était possible de récupérer, à partir d'un .exe labview, les .vi avec lequel il a était fait.

Si oui quelle manip faut-il faire ?

Merci d'avance,

V.T  

[Michael.C]

Bonjour,

Il existe des outils de sorcellerie qui permette de le faire en naviguant dans des zones du web non recommandable.

Toutefois, je te déconseille cette solution, l'exécutable étant un langage compilé, il n'a plus par définition toutes les informations "graphiques" composant les diagrammes de tes VIs, et dans une bonne partie des cas, n'a pas non plus l'information des phases avant de sous-vi qui ne sont pas exploitées.

Au mieux, avec ce genre d'outils, tu auras une "philosphie" du programme, mais en aucun cas quelque chose de viable pour générer un correctif ou une évolution, je te conseillerais vivmeent d'user plutôt ton temps à trouver les sources réelles du programmes.

Bon courage.

[Bilsix]

Salut vince.th,

C'est une question qui revient régulièrement. Mais je ne pense pas qu'un décompilateur LabVIEW soit à l'ordre du jour, malheureusement... A voir peut-être pour les executables créé à partir de très anciennes versions de LabVIEW, mais même ça, je n'en suis pas sur.

Un employé NI saura surement mieux te renseigner que moi, mais je doute très fort que cela soit possible...

[ouadji]

Je confirme totalement les dires de Michael et Bilsix.

" Il existe des outils de sorcellerie qui permette de le faire "

oui, peut-être pensons-nous au(x) même(s)... les "vrais" outils (de pro) dans ce domaine se comptent sur une demi main.

Encore faut-il savoir s'en servir.  Il s'agit plutôt de boîtes à outils, complexes ... il n'existe aucun soft qui fait ça "tout seul".

C'est du Reverse Engineering, c'est très spécifique, très pointu, et ça prend un temps fou.

Désassembler ... ce n'est rien du tout ça ... ensuite il faut tracer, interpréter, des centaines (milliers?) de lignes d'assembleur

Le tout mélangé avec des appels aux fonctions de l'OS, un travail de titan.

Et à moins que tu ne sois un génie de l'assembleur, des structures internes des exe, des dll et j'en passe ... tes chances d'arriver à quoi que ce soit sont (très) minces.

Au mieux, tu retrouveras un algorithme (là, tu es déjà un génie) ... quant à retrouver les VIs à l'origine du code compilé .... jamais, tu oublies !!!

[vince.th]

Bonjour, 

Merci pour vos réponses! 

En faite, je souhaite communiquer via RS232 avec un appareil (pompe de refroidissement) via un protocole VISA SERIAL classqiue. Mais ce dernier me retourne toujours une erreur de timeout à la lecture de données. 

J'ai essayer plusieurs variantes de programmes pour palier à cette erreur ... rien à faire.

Et en farfouillant sur le net, j'ai trouver un .exe qui a été fait pour commander la machine via Labview. C'était surtout pour voir le protocole de communication utilisé dans ce .exe.

Mais si cela relève d'un travail acharné de décompiler un .exe, cela n'en vaut peut-être pas la peine...  

Merci en tout cas!  

[Michael.C]

Bonjour,

Fourni ton VI de communication, tes soucis de timeout sont surement du à une mauvaise gestion du retour de trame. Comment arrête tu la lecture de tes données ?

--> Caractère de terminaison ?

--> Nombre de bit ?

Quand on a un nombre d'octets variables dans une communication série, il y a 2 possibilités pour considérer que la trame de retour est complète :

Soit on arrête la lecture quand on reçoit un caractère de terminaison donnée (exemple 0xA LF), pour cela il faut activer ce fonctionnement dans la configuration de ton thread VISA (je te laisse regarder dans les noeuds de propriétés et dans les exemples de labview).

Soit on arrête la lecture sur un nombre d'octets. Dans ce cas là, pour éviter d'avoir un timeout si on demande plus d'octets que le système ne renvoit, il te suffit de mettre une structure séquence, et de suivre la séquence suivante :

1- Envoi de la requete au produit

2- Attente x ms (dépend de la réactivité de ton équipement)

3- Noeud de propriété "Nbre de bytes sur le thread VISA"

4- Lecture VISA en cablant le nombre de byte au noeud de propriété.

Cdt,

Michael

[vince.th]

Bonjour Michael, 

Voici mon programme de communication test: http://prntscr.com/atoa6k

J'utilise la lecture sur un nombre d'octets mais quelque soit la commande que j'envois, le nombre d'octets retournés pour la lecture est de 0 ... 

V.T

[Michael.C]

Augmente la valeur de timeout de ton thread VISA.

Mettre 2 seconde est purement irréaliste.

Une valeur standard sera plus de l'ordre de 10 seconde mini.

[vince.th]

même erreur pour 10 sec ou plus 

[Michael.C]

As tu déjà réussi à communiquer avec ton programme ?

Que dis la documentation  concernant le paramétrage de la liaison série pour ton équipement ? Ta configuration me semble légère au vue de ton VI.

Vérifie bien les caractères de terminaison pour l'envoi des commandes ? Protocole XON/XOFF, parité, ....