[Tuto] Sécurité TOTALE d'un script

[Iste]

Salutations,

Si vous êtes arrivé sur ce sujet, c'est que soit :
1- Quelqu'un vous y a envoyé
2- Vous l'avez vu et ouvert pour apprendre
3- Vous l'avez vu et ouvert, par curiosité.

Si vous faites partie des cas 1 ou 2, ce sujet est pour vous. Dans le cas contraire, vous pouvez passer votre chemin ou bien rester en tant que spectateur (je ne suis pas contre votre avis )

Commençons !

Salutations, à toi qui viens chercher la réponse a l'éternel question (de débutant) de la sécurisation d'un script. Je me permet de te tutoyer, car je me place en tant que grand frère spirituel du jeune développeur, cherchant à répondre aux questions que tu te pose.
Ces questions sont sûrement au nombre de deux (sur ce sujet du moins)
-Comment puis-je éviter qu'on me vole le code source de mes scripts ?
-Comment puis-je stocker mes mots de passe dans mes scripts et de manière sécurisée ?

Je vais commencer par répondre à la première question.

Comment rendre un script inviolable ?

Pour éviter qu'un vil petit développeur ne vous vole le code source de votre script, il existe une solution très simple : ne pas le diffuser. Je parle du script compilé hein, pas des sources bien sûr . Par contre, si vous le garder pour vous, le jour ou un autre développeur le re-créera dans son coin et le diffusera en son nom, il sera trop tard pour vous en approprier les mérites. (Oui, car je sais, qu'en tant que programmeur débutant on cherche la reconnaissance des plus expérimentés)

Et c'est pour cela que tu dois me crier devant ton écran : "Mais je veux le partager mon script moi ! mais sans qu'on puisse me voler le code ..."
Et dans ce cas, je te répond : "C'est impossible mon petit, c'est impossible..."
En effet, réfléchi un peu, dans le cadre d'AutoIt déjà !
C'est un langage interprété.
Ce qui veux dire un code source et un interpréteur séparé (c'est comme cela qu'est compilé un script AutoIt). Quoi que tu fasse à ton script (obfuscator, mégacryptator etc.) il faudra le passer à l'interpréteur de manière lisible. Du coup, à un moment ou à un autre, le code sera là, et "volable".
Mais même, sans parler d'AutoIt. Disons un langage compilé tel que le C. Bah le code compilé, il est lisible par la machine ok ? Et elle le comprend très bien. La machine, elle est pas magique. Si elle peut lire le code, un humain le peut aussi puisque c'est l'humain qui a créé la machine. Peut être pas directement, mais après un petit passage dans un dé-compilateur il n'y a plus de soucis.

En clair, il n'y a que trois solutions qui s'offrent à toi, petit dev.
1 - Tu ne diffuse pas ton programme.
2 - Tu compile le programme dans un langage machine illisible pour les machines.
3 - Tu le diffuse, en sachant que si quelqu'un veux le voler, il le fera.

N'oublie pas par contre que les ambitions et les compétences des voleurs sont à la hauteur de la qualité du logiciel. Un logiciel de retouche d'image professionnel à licence coûteuse, attirera plus l'attention que ton petit auto-clikeur.exe fait en AutoIt.

Voila pour la première question. Bon je ne m'attarderai pas sur les demi-solutions visant à se protéger des kikoolol-voleurs-de-scripts, car je pense que la meilleur protection est l'open source. (bah oui, une foi qu'on a publié le code, c'est dur de passer après et de prétendre l'avoir fait soit-même)
Je vais donc répondre maintenant à la seconde question. Même si assez proche de la première techniquement, je sais que la problématique peut sembler tout autre.

Comment stocker un mot de passe sans qu'un utilisateur puisse le retrouver ?

Et bien encore une fois, petit dev, je vais te décevoir, car c'est impossible. Même si tu crypte le mot de passe, il faudra la clef de décryptage. Et même si tout le cheminement est très complexe, il suffit au vilain petit voleur d'attendre le mot de passe à la sortie. Car encore une foi, le résultat final devra être lisible.

Prenons un exemple :
Je veux créer un launcher pour un petit MMORP. A un moment ou à un autre, je devrais demander à mon script de taper le mot de passe dans le jeux. Mais que ce passe t-il si je crée une fenêtre identique à celle du jeu dans une de mes applications, et que je demande au launcher de me logger ? Bah il n'y verra que du feu et me donnera sans broncher le mot de passe. Quelque soit le niveau de vérification de la fenêtre, on peut en faire une identique (Après on peut chercher encore plus loin, mais une fois de plus on peut camoufler notre voleur de mot de passe)
Sans cela, un simple petit keyloggeur écoutant les frappes envoyées pourra également récupérer ces informations.

Aussi, même si le mot de passe était crypté en 512 bits et stocké sur un serveur distant, la démarche pour le récupérer est simple : il suffit de le demander.

Peut être as-tu entendu parler de MD5 et aimerais me dire que je n'ai qu'à hacher mes mot de passe ?
Après tout, on ne peut pas dé-hacher une donnée, ca parait donc sympa.
Oui et après ? Sais-tu vraiment ce que signifie "hacher un mot de passe" ?
Le hachage ne sert qu'à vérifier qu'un mot de passe récupéré de l'extérieur correspond a un mot de passe dont le script se "souvient".
Si on ne peut pas récupérer le mot de passe, c'est inutile dans le cadre d'un stockage.
En clair, aucun rapport avec la problématique actuelle, et surtout, aucune utilité.

Au mieux, on peut stocker les mots de passe dans le script de façon crypté, et demander à l'utilisateur la clef de décryptage. Mais si il n'y a pas un nombre suffisant de mot de passe, c'est pas vraiment utile.

Voici pour la seconde question. Encore une foi une réponse sûrement décevante. Si elles ne te satisfont pas, je suis hélas désolé de t'apprendre que ce n'est pas négociable. Et même si un petit kikoo-dev vient te dire qu'il y a une solution, soit il ment, soit il se trompe. Si c'était si simple, on n'aurai pas à chercher de solution, et Adobe ne verrait pas ses logiciels installés sur autant d'ordinateur.

Une dernière chose. Après lecture de ce sujet, tu dois sûrement me détester et te demander comment je peux me permette de te prendre d'aussi haut, te traitant comme un vulgaire "noob du dev".
C'est très simple. Je suis moi même un "noob du dev", tout jeune, lancé dans la programmation sérieuse. Cela fait pourtant maintenant plusieurs années que je code activement. Aussi je me suis posé ces questions, et ai trouvé ces réponses que je te donne regroupées aujourd'hui. Si tu ne comprend pas, et pense toujours que je suis pas sympa avec toi, sache que je te parle comme je parlerai au moi du passé (il n'y a pas si longtemps)


PS pour les cas n°3 qui auraient tout lu jusqu'ici :
Qu'en pensez vous ? J'attend de vous des réponses constructives bien sur, pas des "c'est trop taupe !" ou des "méga coule !", voir des "nul a chier..."....
Aussi, merci de ne pas écrire en réponse des solutions miracle pour contredire ce que je viens d'écrire. Je n'hésiterai pas à abuser de mon statut de modérateur pour garder ce sujet aussi clair que possible pour les novices cherchant de réelles réponses.
Par contre, si vous avez des petits trucs et astuces, comme le fait de stocker que les mot de passe cryptés et demander la clé a l'utilisateur tel que je l'ai décris plus haut, ou bien des obfuscator etc ... Ils seront les bien venu.

[ayuckers]

Hello, Moi je fait parti du cas 3
cela fait maintenant une semaine que je me creuse les méninges sur la partie Cryptage.
moi ce qui m’intéresse c'est plus particulièrement la 2éme partie a un petit détail près :
-Comment puis-je stocker mes mots de passe dans un fichier texte ?


sachant déjà tout ce que tu a dis plus Haut je cherche juste une idée pour rendre moins accessible le décryptage d'un mot de passe. Même si je sais pertinemment qu'il existera toujours une solution plus ou moins complexe pour le retrouvé. Je me suis donc mis a l’élaboration d'une recette

je suis partie du principe que si je laisse a l'utilisateur saisir son mot de passe il vas toujours aller au plus simple.
j'ais donc décidé de crée moi même la clé de cryptage de manière automatique.
elle ce compose de quelques éléments : tel que certaine information du profil utilisateur mais aussi des informations spécifique a la machine ainsi que quelques informations réseau.
comme cela le mot de passe sera unique pour 1 utilisateur et 1 Ordinateur Précis.

A oui j'ai oublier de préciser que le système de protection des ordi est de très haut niveau. je ne développerait pas cette partie. c'est comme sa.

Pour en revenir a mon idée un peu plus haut je travaille a une nouvelle version qui choisirais les élément de ma recette de manière Aléatoire.
Comme cela la clé de cryptage ne serais jamais la même. et pour poussé le bouchon encore plus loin ré-encodé le mot de passe avec ma clé de cryptage aléatoire a chaque utilisation du scripte.

[Iste]

Je rajoute un mot sur le Hashage, suite a ce topic : http://autoitscript.fr/forum/viewtopic.php?f=3&t=7208

On ne peut effectivement pas déhacher une donné, mais ce qu'il faut savoir :

1- Quand on stock une information hashée, c'est pour procéder de la sorte, quand un utilisateur prétend avoir la même donnée que nous, on la hash, on compare les deux hash, si ils sont identique, on en conclu que les données sont identique. Du coup, si on a le hash, et qu'on le "déhash", il suffit de prendre le premier résultat et de l'envoyer au service. Ce sera rehashé et on en conclura que c'est la même donnée.
2- Quand on déhashe une donnée, on a un nombre infini de possibilités, c'est vrai, mais seul une petite partie de ces données sont valables ! Dans le cadre d'un mot de passe, on ne gardera que les chaines de caractères définies par la regexp du site qui le demande. Et sur celle là une ou deux devraient sortir du lot.
3- De toute façon, c'est bien bô tout ca, mais on ne déhash jamais pour de vrai. C'est beaucoup trop long. Le plus simple reste de hasher un dico et de se faire une base de données. Et face a ca, tout les types de hash sont égaux. La seule solution et de pourrir les dictionnaire en modifiant légèrement notre hashage en ajoutant une donnée aléatoire. Faisant cela, même le bon vieux MD5 est fiable.

Conclusion : Seul moyen de stocker un mot de passe sans qu'on puisse le retrouver est de le hasher. Et pour éviter de se faire déhasher par dico, il ne faut pas utiliser le hash populaire du moment, mais une variation d'un hash fiable.

[zeshrek]

Conclusion : Seul moyen de stocker un mot de passe sans qu'on puisse le retrouver est de le hasher. Et pour éviter de se faire déhasher par dico, il ne faut pas utiliser le hash populaire du moment, mais une variation d'un hash fiable.

Oui.... mais non
Car en faisant ainsi on décalle le problème. Ce que le pirate devra retrouver sera donc le hash du mot de passe et non le mot de passe lui même.
Or le hash étant "simplement" une pesée d'octets, (notons les guillemets a 'simplement' parceque ce n'est pas tout a fait aussi simple) on se retrouve avec le fait que plusieurs intrants peuvent donner le même hash.
Il suffit donc au pirate de retrouver n'importe lequel des intrants donnant le même hash que le véritable mot de passe pour passer la barrière de sécurité.
Ainsi une attaque par brute-force qui rentrera tous les mots de passe possible aura beaucoup plus de chance de trouver un mot de passe qui fonctionne que si il devait trouver le véritable mot de passe.
Imaginons que nous ayons un hash qui correspond a 10 intrants, soit le véritable mot de passe et 9 autres dont le hasard a fait qu'ils donnent le même hash. Dans une attaque en brute force, statistiquement le pirate aura 10 fois plus de chances de tomber sur un intrant donnant le bon hash que si il devait retrouver le véritable mot de passe.
Contre toute logique utilser le hash peut DIMINUER la sécurité.

Dans tous les cas il vaut mieux donc se souvenir que Autoit n'est pas sécurisé, et qu'il n'est pas du tout fait pour interragir avec des applications suécurisées. Il est trop simple de le décompiler de modifier le script pour intercepter hash et mot de passe, ou faire une backdoor.

[Iste]

Heu oui mais c'est un peu hors sujet là.
Je par du principe que le mec a déjà le code source
Donc en utilisant un hash varié, meme avec le mot de passe hashé et la méthode de hash, il ne pourra rien faire d'autre que du brutforce pour retrouver le mot de passe d'origine.

Le but est juste de "stocker" un mot de passer sans le dévoiler.

[Tlem]

J'ai déjà signalé quelque part sur le forum, la sortie d'un utilitaire qui me semble pas mal : AutoIt3Camo

Je ne l'ai pas encore testé, mais d'après les quelques messages du forum Anglais, il permettrait d'avoir une forme de sécurité plus importante que ce que nous avons déjà vu (maintenant, ce n'est surement pas du 100%). ^^

[TT22]

Moi je fais parti le la 2ème catégorie :
Je voulais apprendre à sécuriser mes scripts et j'ai appris que ce n'étais pas possible
Mais bon, je suis finalement assez content car comme ça, je n'ai pas de manip supplémentaires à faire pour les sécurisés (je suis en vacance après tout )
En tout cas, je voulais dire que ce tuto est très intéressant.

[rabbit14000]

Bonjour/Bonsoir

je voudrais rendre mon scripte sécurisé de façon à rendre la lecture et la modification quasiment impossible, où au moins très difficile et prise de tête pour celui qui n'as pas les sources, et donc lâcherait l'affaire car c'est trop de travail pour ci peux.

Pourquoi ? : Je voudrais rendre mon scripte d'une part payant (qui est en faite le même programme que sa version gratuite met en amélioré), et comme il est impossible de le rendre indé-compilable, je voudrais que le "pirate" est un mal de crane pendant une semaine si il essaye de tout remettre en ordre (car je pence que c'est ce que obfuscator fait).

je voix après compilation avec "AutoIt3Wrapper.exe" (click droit compil avec option), un fichier " 'mon_au3'_Obfuscated.au3 " , quand j'ai ouvert ce fichier, je n'y comprenais rien du-tout. Après quelque recherche sur obfuscated, je tombe sur "obfuscator", et je ne trouve pas beaucoup d'information sur lui, a-part qu'il cripte le fichier "mon_au3.au3" pour en créer un autre de facon crypté. Alors je comprend donc pourquoi je n'ai rien compris quand je l'avais ouvert.

En "jouent" avec les ligne,

Code : Tout sélectionner

#Region ;**** Directives created by AutoIt3Wrapper_GUI ****
#AutoIt3Wrapper_Icon=jessicaico.ico
#AutoIt3Wrapper_Outfile=trajet_creatorx86.exe
#AutoIt3Wrapper_Outfile_x64=trajet_creatorx64.exe
#AutoIt3Wrapper_Compression=1
#AutoIt3Wrapper_Compile_Both=y
#AutoIt3Wrapper_Res_requestedExecutionLevel=requireAdministrator
#AutoIt3Wrapper_Tidy_Stop_OnError=n
#AutoIt3Wrapper_Run_Obfuscator=y
#EndRegion ;**** Directives created by AutoIt3Wrapper_GUI ****
 

après compilation quand j'ouvre ce fichier " 'mon_au3'_Obfuscated.au3 " , il n'est plus crypté.

1 - J'aimerai savoir si le cryptage ce fait quand même ou pas. Si il ne ce fait pas, bah que ca re-fonctionne.
2 - jusqu'à quelle modification fait-il dans le scripte, que je comprenne si moi même connaissant et ayant les sources du scripte, si je pourrait mis retrouver.

Merci bien de votre future aide.
(si je doit poster un nouveau sujet, pas d'soucis je m’exécute)

[Tlem]

@rabbit14000
Il y a de nombreux sujets traitant de la protection d'un script et si je me souviens bien, nous avons déjà abordé le sujet de l'obfuscateur (utilisation).
Vous devriez faire quelques recherches sur le forum.

[rabbit14000]

j'ai pas essayé de recherche "obfuscateur" je vous dit ce qu'il en est prochainement...^^

EDIT: dans ce sujet "Re: [..] Protéger le code source des décompilateurs"
Ani me fait comprendre qu'il est entrain de décrypter justement un fichier crypté par obfuscator.
Et qu'il est facile de savoir tel ou tel partie de code peux être supprimé, et que toutes les variables peuvent être retrouvé sous leur nom d'origine. (j'ai cru lire plus haut que le code ne bougé pas de place, et gardé la même structure) je pence qu'avec la fonction "remplacer" les variable ce remette en place facilement.

Tiend donc on connait la même personne apparement, son nom ne commencerai par S lol
tbl est crée justement par obfuscateur. il est possible d'induire en erreur en y ajoutant du code bidon, dont le tbl qui se verra dans le dossier temporaire, ne correspondra pas au code original, mais bon, un oeil avisée décodera automatiquement le concept

le code je l'ai déjà décrypter, mais pas encore envoyé à S..., manque juste à décoder une petite partie pour récuperer les nom des variables et fonction d'origine.

l'obfuscateur transforme les noms de variables/fonctions
exemple = _string deviendrai A6451522.

voilà voilà, faite mes amiti!s à la personne qui vous a mit ce message

Sur le forum y a un ou deux post concernant la protection. une petite recherche

bonne continuation

donc j'ai les infos que je voulais savoir, mais est-ce trés long pour décrypter un scripte de 1500 lignes sans les inculdes ?
(si c'est long, plusieurs personne pourrait ce décourager avant de terminer, suivant l’importance du projet)

(ps: j'ai lancer obfuscator.exe dans "x:\xxx\AutoIt3\SciTE\Obfuscator" , j'ai choisie mon scripte a crypter, et je trouve null part le fichier qu'il a du créer)

[Tlem]

L'Obfuscateur est publique et commun à tous les scripts utilisant ce procédé. Celui qui veut faire une protection plus complexe, devra combiner ce mode plus d'autres.

Il me semble que le code de l'obfuscateur à été rendu publique sur certaines version. Vous pouvez alors tout simplement adapter l'obfuscateur à vos propres besoins.
Si vous le personnalisé avec votre propre 'code', alors il sera encore plus difficile de recréer la source.

On peut difficilement quantifier le temps que mettrait quelqu'un de très motivé pour arriver à recréer votre code, mais soyez sur d'une chose, plus votre programme sera intéressent et cher et plus il y aura de gens pour le pirater. ^^

Après, il y à différentes manières de protégé un code.
Soit vous ne voulez pas qu'il soit lu et là on en revient à la discussion ci-dessus, soit vous voulez le protéger en voulant prouver que vous en êtes l'auteur original et dans ce cas, le choix est beaucoup plus délicat, car si votre code n’a pas été diffusé ou déposé, rien ne prouvera jamais que vous en êtes l'auteur.

Si vous voulez vraiment en faire une propriété intellectuelle, vous devriez lire cet article.
Personnellement, je pense qu'il faut partir sur une de ces solutions :
- Dépôt du code source dans un organisme spécifique (principalement payant comme ici).
- Dépôt du code source sur une plateforme comme sourceforge ou similaire (gratuit mais code publique).
- Dépôt du code source dans un forum dédié comme ici par exemple (gratuit mais code publique).
- Une dernière méthode moins connue mais qui à déjà été utilisée par certains, c'est l'envoi par la poste d'une lettre ou colis scellé et non ouvert à vous même. Comme cela, en cas de procédure juridique cela peut être emmené comme preuve de propriété, mais attention, il y a des règles à respecter.

[scorp84]

Bonjour,

- Une dernière méthode moins connue mais qui à déjà été utilisée par certains, c'est l'envoi par la poste d'une lettre ou colis scellé et non ouvert à vous même. Comme cela, en cas de procédure juridique cela peut être emmené comme preuve de propriété, mais attention, il y a des règles à respecter.

Il existe une enveloppe dite "enveloppe Soleau" qui permet d'envoyer à l'INPI (procédure très simple) une enveloppe double avec dedans 2 exemplaires du code source par exemple.

Le coût est de 15 €.

Pour en savoir plus :
http://www.inpi.fr/fr/services-et-prest ... oleau.html

Amicalement.

BM

[Tlem]

Cela limite le dépôt à un code imprimé sur du papier.
Comme l'enveloppe ne peut contenir que 7 feuilles au format A4 et qu'il faut deux exemplaires identiques, cela fait 3,5 feuilles A4 pour imprimer le code. Il vaut mieux qu'il ne soit pas trop long, sinon, même en recto-verso avec une police de 8 pouces ça sera un peut juste. ^^

[mikell]

avec une police de 8 pouces ça sera un peut juste. ^^

Comme c'est vrai...