AutoIt Français

Bonjour,

je pense que le titre n'est pas clair, c'est pourquoi je vais un peu plus m'étendre ici.
Je tiens à dire que ma question adressée aux gros développeurs où des personnes qui ont une bonne approche d'OllyDBG et donc de L'ASM.

OllyDBG, pour ceux qui ne connaissent pas est un désassembleur. C'est un programme qui va s'occuper de faire le processus inverse de la compilation d'un code. Ce logiciel vous propose d'ouvrir un fichier exe afin de le désassembler, on peut ainsi voir une multitude de commandes et cela, en assembleur.

L'assembleur étant un langage de bas niveau, il est donc dur à comprendre et est connu en général par les gros développeurs et les plus expérimentés.

Je m'étais renseigné à ce niveau là, et j'ai plus en conclure que JAMAIS ce programme pouvait restituer un code source de A à Z. (code source de plus haut niveau comme le C, C++, C# ou java et autres)

Je suis ami avec quelqu'un qui développe tout comme moi en AutoIt, et après m'être lancé sur un gros projet et après une bonne phase de développement, je lui ait donné mon exécutable, mais malgré le fait qu'il soit un bon ami, je ne lui ait pas passé mon code source même si il le demandait, car c'est un projet qui était (et qui demeure) pas terminé, et que je voulais le garder pour moi pour le moment. Je lui en parle maintenant un peu tout le temps quand on bavarde sur l'AutoIt, il est donc au courant de quelques problèmes que je rencontre pendant la phase de développement, il sait donc que l'algo principal est assez long et les petits bugs détectés, mais c'est tout.
Pas plus tard qu'aujourd'hui, il me dit qu'il a un bon moyen pour réduire mon algo et me montre un exemple. Étonné, je peux remarquer une suite d'instructions EXACTEMENT la MÊME que dans mon code source. Dans ces instructions, une condition qui traite près de 60 variables, toutes ces variables avec le nom exact et le processus de vérification dans l'ordre exact aussi.

Je lui ai finalement demandé, comment ça se faisait. Il m'a dit qu'avec OllyDBG il pouvait retrouver les noms de variables. Sachant que mon script fait un peu plus de mille lignes, et qu'il y a au moins une centaine de variables déclarées. (A noter qu'il a le même age que moi, c'est à dire 16 ans)

Ma question étant la suivante : peut-on restituer une suite d'instructions de l'ASM à l'AutoIt en ayant au final, la même chose que dans le code source initiale au mot près ?

J'l'ai peut être envoyé chier sur le coup, mais ce projet c'est quand même plus d'un mois que je bosse dessus sans relâche, et le voir s'en voler ça fait mal. Surtout que c'était un bon ami.

Merci aux personnes qui me répondront !

Hummm, tu pose des questions sur la décompilation de scripts AutoIt, alors n'oublie pas que c'est illégal

==> http://www.autoitscript.fr/forum/viewto ... f=3&t=1192

Et si je ne me trompe pas, un exe AutoIt n'est pas vraiment compilé, c'est juste un logiciel qui exécute un script inclus à ce programme. Donc, pas traduit en assembleur.
Mais, je n'en dirais pas plus sur les moyens de décompilations

Mince, pas vu désolé alors.

Mais je ne demande rien à propos du sujet, je donne seulement quelques infos sur le logiciel pour cibler le problème.

Le code source AutoIt est (je pense) traduit en C (ou autre) et ensuite compilé du C (ou autre) en .exe.

Ma seule question est : est-il possible de restituer une partie de code source, aussi précise à partir de l'ASM ? Je répète, je ne veux pas avoir "comment restituer un code AutoIt à partir d'un .exe avec OllyDBG", mais seulement si c'est possible.

Merci !

TT22 a écrit :un exe AutoIt n'est pas vraiment compilé, c'est juste un logiciel qui exécute un script inclus à ce programme.

Donc, ça veut dire que ton programme AutoIt compilé, c'est ton code source mis dans l'archive (le .exe) et exécuté par un code binaire qui fonctionne de la même façon que AutoIt.exe.
Et ce code binaire, est dans le fichier "C:\Program Files (x86)\AutoIt3\Aut2Exe\AutoItSC.bin".
Donc, si tu décompile l'ASM, tu vas tout simplement obtenir le code qui se trouve dans le fichier donné si-dessus

Et le compilateur Aut2Exe ne fait que créer un .exe à partir de ce fichier et y archiver ton fichier source AutoIt.

Et la preuve, voici le code ASM du fichier binaire, qui sera le même que celui d'un exe AutoIt : PS : Je sais pas si c'est très légal, mais bon

Et donc d'après toi, il aurait très bien pu extraire mon code source ?

J'ai bien essayé de le faire sur mon propre programme, et j'ai trouvé comme toi, un bazar incompréhensible en assembleur. Normalement un .exe c'est un exécutable qui est censé être lu par le PC et donc, du binaire ! Mon code n'est pas censé être là dedans(code source = mot pour mot ce que j'ai écris avec AutoIt). La seule exception que je connais au niveau des .exe c'est avec les langages .NET, où le .exe n'est pas réellement du binaire, il est donc lu dans une machine qui elle va se charger de le compiler pour être compatible avec la plate forme actuelle. Or, pour AutoIt, nous sommes pas obligés d'avoir AutoIt d'installé, il s'agit donc de vrai binaire.

C'est peut être un peu confus, c'est pourquoi plusieurs avis sur la chose, de développeurs assez costauds ne seraient pas de refus.

En ce qui concerne le sujet, je doute que ce soit illégal, le lien du post à Tlem dit que le désassemblage est interdit et qu'on ne doit pas mettre d'infos personnelles dans nos codes sources. Ensuite, je m'interroge sur ce qui est possible ou pas, pas sur comment l'effectuer.

Néanmoins, merci pour tes réponses !

EDIT : TT22, regarde. Dans le lien de ton premier post, on peut voir ça :

Tlem a écrit :Certes les variables n'ont plus leur nom d'origine, mais le code reste compréhensible et reproductible.

On m'a donc bien volé le code source, non ?!

blacksoul305 a écrit :Et donc d'après toi, il aurait très bien pu extraire mon code source ?

Non, mais tu lis ce que j'écrit ?
Si on décompile l'ASM d'un exe AutoIt, on obtient le code source de interpréteur qui va lire ton code source (inclus dans l'archive .exe) et faire le même chose que AutoIt.exe.
En fait, quand on dit que AutoIt n'est pas nécessaire sur un ordinateur pour lancer un exe, c'est à moitié vrai, car en fait, le logiciel compilé en AutoIt c'est interpréteur plus le code AutoIt à interpréter.

Donc, je pense que ton "ami" a utilisé un autre programme pour avoir ton code source
Mais, chuuuuut....on a pas le droit de dire son nom

Tout ce que je remarque c'est que :

1) c'est du vol
2) et le code source, comme tu es entrain de le démontrer, n'est pas visible directement (tel qu'il est écrit dans scite) à part si on utilise un programme spécial.

Super l'ami !

EDIT : J'ai oublié de te remercier, merci !

Et tu as vu le code décompilé ?
Et si oui, tu peux nous en montrer un petit bout ?
On pourra peut-être te dire d'où il vient

Oui, je fais ça de suite :

TT22 a écrit :Et tu as vu le code décompilé ?

Je parlais de celui en AutoIt, parceque celui que tu nous montre, il est le même pour tous les programmes AutoIt

TT22 a écrit :

TT22 a écrit :Et tu as vu le code décompilé ?

Je parlais de celui en AutoIt, parceque celui que tu nous montre, il est le même pour tous les programmes AutoIt

Pas bien compris ce que tu voulais dire

Edit : Je continue à faire mes recherches de mon côté, et apparemment il est largement possible de faire passer un .exe compilé en AutoIt à un fichier source .au3...

En clair, programmer en AutoIt n'est pas une superbe idée si jamais on voulait vivre de nos programmes, c'est ça ?

EDIT2 : Je te remercie quand même de m'avoir aidé à trouver la réponse, je te laisse tranquille. Je pense qu'il va falloir que j'envisage de partir sur un langage de programmation "basique", peut être le C#, car si je me casse le dos à faire un projet d'un mois ou +, alors que quelqu'un vient, prends ton .exe, se fait ton code source, je vais finir par faire un meurtre.

Merci encore de m'avoir aidé !

C'est vrai pour tous les langages de programmation, désolé de fissurer ton nuage !

jchd a écrit :C'est vrai pour tous les langages de programmation, désolé de fissurer ton nuage !

Oui ça je savais, mais là ça a l'air tout de même plus facile de générer un .au3 à partir d'un .exe. Sinon, les programmes ne seraient plus rentable j'imagine.

blacksoul305 a écrit :Pas bien compris ce que tu voulais dire

Ben, le script AutoIt que ton ami a obtenu, si tu l'as, montre-en nous un petit bout (10~20 lignes) pour qu'on voit d'où il viens.

blacksoul305 a écrit :apparemment il est largement possible de faire passer un .exe compilé en AutoIt à un fichier source .au3...

C'est pas une grande nouvelle, d'ailleurs, avant la version 3.2.5.1, le décompilateur Exe2Aut.exe était même fournis avec AutoIt

blacksoul305 a écrit :En clair, programmer en AutoIt n'est pas une superbe idée si jamais on voulait vivre de nos programmes, c'est ça ?

Nan, pour la simple raison qu'il n'est pas fait pour ça.
Si tu veux vraiment en vivre, passe au C/C++, ASM, ...

blacksoul305 a écrit :En clair, programmer en AutoIt n'est pas une superbe idée si jamais on voulait vivre de nos programmes, c'est ça ?
Nan, pour la simple raison qu'il n'est pas fait pour ça.
Si tu veux vraiment en vivre, passe au C/C++, ASM, ...

J'me vois bien programmer des logiciels du genre : Photoshop, RealPlayer, Adobe After Effects en assembleur haha !

Mais oui, j'envisage de me tourner vers un autre langage.

Le truc, c'est qu'AutoIt permet de faire des choses plutôt pas mal, et cela en très peu de temps car les bases s'assimilent vite. Mais après il suffit de pratiquer, comme partout. Néanmoins, après avoir vécu ça, je me servirai d'AutoIt seulement dans quelques situations, mais plus de façon permanente. Par contre je passerai tout le temps et comme toujours sur le forum pour aider ceux qui en ont besoin, et pour bavarder pourquoi pas.

En tout cas ça fait plaisir de voir des membres aussi actifs.

Merci à toi de m'avoir éclairer sur mon problème, je dormirai un peu mieux ce soir je pense, mais ça fait toujours mal au bide.

Je n'ai pas eu le courage de lire tous ces messages mais sache que ton amis se la joue certainement et n'a pas utilisé OllyDBG puisqu'il existe des décompilateurs comme Exe2aut pour ne pas le citer...

blacksoul305 a écrit :En clair, programmer en AutoIt n'est pas une superbe idée si jamais on voulait vivre de nos programmes, c'est ça ?

C'est une autre question que tu soulèves, là
Pour du logiciel payant il s'agirait de rendre ton soft incrackable plutôt que de protéger le code-source (qui irait s'emmerder à pomper tout un code-source si c'est juste pour pouvoir avoir le soft gratis ?)
Et là, comme l'a déjà dit jchd dans plusieurs topics le langage utilisé n'a pas vraiment d'importance, ce qu'il faudrait c'est une sécurisation réellement fiable mais c'est pas gagné
Donc AMHA programme en autoit pour la facilité, et si tu dois te prendre la tête fais-le plutôt sur des mesures de protection, cryptage ou autres ^^
Si ton 'ami' a réussi à décompiler ton exe, c'est certainement pas grâce à Olly mais plutôt parce que tu avais fait une compilation normale, simple et 'brute' sans mesures de protection

lesolutionneur a écrit :Je n'ai pas eu le courage de lire tous ces messages mais sache que ton amis se la joue certainement et n'a pas utilisé OllyDBG puisqu'il existe des décompilateurs comme Exe2aut pour ne pas le citer...

Bah tu sais, lire c'est pas gênant (quand tu as du temps), et t'en apprends vachement plus. Surtout que c'est plutôt bien écrit, c'pas comme si c'était des messages écrits comme ça :

alr je cé pa dc jvé poséé une kestion?? eske cé possible.......

Oui, j'ai fais des recherches de mon côté menant à un décompilateur pour .EXE AutoIt, mais je voulais m'assurer si c'était possible qu'avec OllyDBG, retrouver un code source AutoIt tel qu'il écrit dans un fichier source.

EDIT : Désolé, pas vu ta réponse mikell, je devais être entrain d'écrire.

Déjà, merci de participer et donner ton point de vue. Personnellement, pensant que c'était mon ami et qu'il comprendrait, je lui ai passé mon exécutable pour une phase d'essaie. Il était fonctionnel mais pas fini, tout simplement. Je m'attendais pas à ce qu'il l'ouvre ou le décompile par lui même, juste pour avoir mon code source.

Mon .exe j'l'ai créé avec F7 et n'ai pas cherché à protéger quoi que ce soit pour la raison énoncée ci-dessus.

Aussi, je savais pas qu'il était possible de protéger le programme par le biais du code source, mais imaginons le truc. Je crypte chacune de mes variables, alors qu'il y'en a plus d'une centaine ?! Surtout qu'au bout d'un moment, pour que le prog les lise, il faut bien les décrypter, et on me mange mon code source easily (si j'ai bien compris).

En ce qui concerne les autres langages, je savais pas qu'il était possible de recréer un fichier source à partir d'un .EXE, je viens de le découvrir en ayant eu ce problème là.

quand tu as du temps

Justement...

En ce qui concerne les autres langages, je savais pas qu'il était possible de recréer un fichier source à partir d'un .EXE, je viens de le découvrir en ayant eu ce problème là.

héhé, c'est pas pour rien que des compresseurs/crypteurs sont souvent utilisés ! (upx, mozrar, pe...)

Mais le code C reste moins facile à lire que le code AutoIt.


Pour protéger ton exe, il y a autoit3cano mais le problème est qu'il est détecté par certains antivirus comme un "virus" (mais c'est un faux positif).

Pour du logiciel payant il s'agirait de rendre ton soft incrackable plutôt que de protéger le code-source

Je ne suis pas tout à fait d'accord:

Pour le cas des logiciels payants:

-connaitre le code source veut dire comment le logiciel procède à l'activation autrement dit comment le logiciel vérifie qu'il est acheté.
-si tu sais comment l'activation est faite et quelle valeur est attendue, alors tu peux facilement craquer le logiciel en simulant le retour avec le fichier host (pour ne citer que lui).

Se taper une récupération complète de code-source juste pour avoir accès à la partie sécurisation, c'est un peu comme démonter intégralement une bagnole pour trouver la roue de secours... il doit certainement exister des moyens plus simples