AutoIt Français

jchd a écrit :Plus dur à craquer ... pour la petite soeur. C'est une expression consacrée, mais qui veut bien dire ce qu'il y a lieu d'en penser.

Si tu protèges un secret (ton code) par un module ultra-sophistiqué que tu mets disons 3 semaines à concevoir, coder, tester, deboguer (et 3 semaines ce n'est pas cher payé), il y a fort à parier que tu trouveras un bon nombre de gugusses capables de le déplomber en moins de temps que ça et ayant des ressources comparables aux tiennes.

Ton raisonnement est le suivant : j'enferme un joyau dans un coffre que seuls les voleurs rusés peuvent violer. Bilan de l'action : le joyau est volé. Pfft, parti, a pu le caillou.

Que ce soit par Pierre, Paul, Jacques ou les trois à la fois ou en séquence, cela ne change rien au désastre. Parce qu'une fois l'oiseau envolé, la vertu cardinale de la création logicielle fait qu'il peut se multiplier à l'infini à coût zéro, contrairement à un bien matériel. Ton code est un secret, alors s'il est divulgué, il n'est plus secret pour personne (potentiellement).

Je suis complètement passé à côté de votre message, j'viens de le remarquer maintenant. C'est vrai que dans tout les cas, ça donne le même résultat. Mais admettons que je fasse un programme que juge assez bon pour pouvoir le vendre à un prix correct, vu ma popularité, ce seront pas de grosses personnes qui vont s'y intéresser. Et donc si jamais j'ai travaillé comme vous venez de le dire, pendant trois semaines, cela aura un bon effet. Car ces personnes si elles ont l'attention de le cracker, elles vont essayer des tutos à droite à gauche, ça va rien donner. Plouf, elles vont laisser tomber.

Bon après, cette aura aura moyen de le donner à quelqu'un qui arrivera à le cracker et publiera un crack, ou va donner à quelqu'un d'autre et ainsi de suite.

Je suis d'accord pour dire que, on arrivera fatalement au même résultat, mais on a moins de chance de se faire cracker un logiciel si on a travaillé un temps soit peu sur sa protection, et si notre côte de popularité est faible.

C'est donc bien pour ça qu'on appelle ceci "la protection de la petite soeur", même si on en met une ... couche !

Ca n'a rien de ridicule ni de gênant, tant que personne ne se leurre sur la robustesse du verrou et qu'on est bien conscient qu'il sautera au premier coup d'une épaule un peu "carrée".

Ce sont des images mais elles transcrivent bien la réalité.

C'est toujours mieux d'imager ses propos faut dire ! Un jour, je parlais de "crackage" justement, et on m'a dit : "Quand tu souhaites cambrioler ton voisin, défonce pas la porte, passe par la fenêtre."

Bonjour,
Dans la page 2 de ce sujet, matwachich montrait avec virtuosité comment créer 1 DLL (avec des nombres entiers).
J'ai essayé avec des décimaux, mais je commets des erreurs, je ne comprends pas tout et cela ne fonctionne pas :
J'ai essayé cet appel à la DLL (dans le langage d'origine) et cela marche: Quand j'essaie de "transcrire" cela en Autoit (ce qui est le but), cela bloque : A votre avis, quelle est mon erreur ? D'avance, merci.

J'ai trouvé en relisant l'aide, il faut changer le 2ème argument :

$ret = DllCall("decimaux2.dll", "float:cdecl", "MaFonction", "float", 10.1, "float", 20.1)

Pourtant, dans son exemple, matwachich avait laissé "str" au lieu de mettre "int" (?).
(Je comprends maintenant correctement "DllCall"...)

Je sais pas si ce sujet est complêtement dead ou quoi cependant voici comment fonctionne l'autoit.


Un STUB codé en C qui contient TOUTE les fonctions basique d'autoit puis après lors de la compilation le compilateur viens coller le stub ainsi que votre source dans l'EOF(End Of File) du programme.

Comment notre exe fais le lien entre les fonctions et notre code? Tout simplement en rajoutant une petite routine qui va lire ligne par ligne le code situé dans l'EOF.

Donc deux solution pour protéger votre exe. Mais qui ne rendra en rien incrackable ! ça sera juste plus compliqué !
Bref 1ere solution qui va permettre de berner les tools déjà tout fais pour decompiler l'autoit. Inclure l'eof dans le programme (pour plus d'info s'informer sur le format PE d'un exe) puis de juste changer l'offset de lecture pour notre routine de lecture. Et à la limite rajouter un faux code dans notre EOF pour berné les decompilateurs ^^

2e solutions plus dur à mettre en place mais plus sur. crypter notre EOF avec un algo perso puis patcher la routine de lecture pour lui rajouter l'algo de decryptage.

Vous pouvez bien sur combiner les 2 solutions mais comme je le dis ça ne rendra pas votre programme incrackable juste plus chiant car le stub autoit à FORCEMENT besoin à un moment d'avoir notre source donc ce qui veut dire qu'il est forcement en mémoire quelque par à un moment !

C'est sûr (bonnes méthodes). Vos remarques sont très justes et nous montrent de nouvelles directions. Auriez-vous la possibilité de nous montrer 1 exemple de transformation de l'EOF ou encore des copies d'écran nous montrant où travailler (code hexadécimal) ?

[Mais ici, ce n'est pas le sujet (protection d'1 logiciel) qui m'intéressait, mais plutôt commencer à apprendre l'écriture de DLL.
Il y a une autre méthode pour l'écriture de DLL sur le site Anglais, mais que je trouve moins bonne que celle-ci (quoique les 2 méthodes peuvent être + ou - intéressantes, selon ce que l'on a besoin de faire.]

Malheureusement le fais de toucher à un exe est illegal si tout le code source ne nous appartient pas et interdit sur ce forum donc non je montrerais pas mais bon je pense qu'en recherchant sur google ça dois ce trouver ^^

Apprend les base du revesing et c'est tout

Je voulais juste parler d'1 logiciel que nous avons créé et que l'on veut protéger. Il ne s'agit nullement de s'attaquer à des logiciels...
Pour ce qui est de la protection, faut-il "décompiler" son propre logiciel, déplacer certains éléments , puis recompiler son propre logiciel ?
Le logiciel "Camo" agit-il comme vous l'avez dit ?

Oui, AutoIt3Cano est efficace.