AutoIt Français

Bonjour à tous,

Dans le cadre d'un projet qui communiquera avec une base de donnée où les données seront lié à un site internet également, je dois mettre à disposition un logiciel pour les utilisateurs qui aura pour but d'authentifier le logiciel à une licence mais aussi effectuer une liaison avec la machine. De ce côté pas de soucis.

Cependant, étant donné que les petits malins existent partout et que le programme n'échappera pas à une décompilation je voulais connaitre plusieurs choses :

1 - Comment brouiller les pistes ?
2 - Obfusquer le code est efficace ? Si oui, un lien qui me montre comment faire ?
3 - Comment cacher mes informations de connexion à la base de donnée ?

Exemple :

Dans mon script j'ai :

$server = localhost
$usr = root
$mdp = root
$port = 3306

Comment faire en sorte que si l'exécutable est décompiler on ne voie pas sa ? Soit le mettre ailleurs mais faire en sorte que c'est moins accessible ?

Je suis ouvert à tous vos conseils et réflexion.
Je sait que c'est un sujet sensible et complexe en autoit mais c'est important dans le cadre de mon projet.

Cordialement

Bien le bonjour,

désolé mais un programme sans faille n'est qu'illusions. Je vais me permettre de citer un message de jchd qui illustre assez bien la chose :

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).

Moralité, tu pourras toujours concevoir un moyen de sécurité poussé pour le verrouiller, il existera toujours quelqu'un d'assez curieux pour essayer de forcer la serrure et ouvrir le coffre. Ainsi je doute qu'il existe un moyen efficace de protéger ton code de qui que ce soit, y compris ton accès à la BDD.

Cela dit, je ne saurai que trop te conseiller ce que l'on fait pour le développement web, c'est à dire créer un utilisateur dans la base de données et lui attribuer que certains droits. Ainsi, si un méchant pirate venait à s'emparer des identifiants à la BDD, il n'aurait qu'un compte à accès restreint.

En effet, tout est question de proportion. Tant que le vol de ton secret rapportera plus qu'il ne coûtera, on le volera. En plus certains font ça pour la gloire, ce qui est plus délicat à valoriser.

Eventuellement je n'avez pas penser à ça.
Pour ce qui est de la BDD je sait pas si je peux crée un utilisateur supplémentaire sur mon hébergement je regarderais.
Dans le cas du programme il faudra juste un utilisateur avec la possibilité de lire la BDD.

Oui je sait très bien qu'il y aura toujours un malin pour tout casser mais c'est pour sa que je voulais juste brouiller les pistes. Rentre un peu plus difficile l'accès.

la solution est "Private exe Protector"

... oui et le crack est disponible quelques jours après la sortie de chaque nouvelle version. A $475 + $60 c'est chérot.

Le truc qu'il faut comprendre c'est que c'est un problème qui a réellement aucune solution, tout le monde le sait. Microsoft, Blu-Ray, DVD et les studios de développement vidéo-ludique en premier.

A quoi ça sert de rendre le code plus difficile à cracker pour un débutant, s'il peut-être cracké par quelqu'un de légèrement plus doué qu'un novice ? A partir du moment où c'est fait, c'est fait. Je dis pas que c'est inutile mais presque.

Après si tu y tiens vraiment, regarde dans des ouvrages de sécurité informatique, dans des articles ou encore des tutoriels sur Internet. Seulement tu sais, pour ton programme, les moyens sont divers, désassemblage, injections, MITM... ça va être compliqué de parer toutes ces éventualités. Tu peux chiffrer le contenu de tes variables, tes communications client/serveur (peut-on chiffrer les chiffrer avec les fonctions SQLite ?) et te renseigner sur l'obfuscation ,même si tu peux déjà l'activer dans les options de compilation (et ça n'empêche pas les gens d'extraire le code AutoIt d'un exécutable).

Et si jamais tu venais à trouver LA solution, dépose un brevet et écris un article surtout héhé ! Bon courage !

Passe par des programmes intermédiaires : Tes propres programmes intermédiaires si tu veux brouiller les pistes d'un programme donné.

Merci à tous pour vos pistes.
Après je ne cherche pas la protection parfaite, je cherche juste à décourager les plus tétû.

Je vais effectuer quelques recherches tranquillement.
Je laisse ouvert le sujet pour ceux qui ont d'autres idées et qui sait sa peut servir aux autres.

Après je ne cherche pas la protection parfaite

Ca vaut mieux car elle n'existe pas.

je cherche juste à décourager les plus têtus

C'est justement ça qui pose problème.

Je vais effectuer quelques recherches tranquillement.

Tu peux rechercher ce que tu veux mais tu as déjà la réponse à portée de neurones, si tu veux bien te pencher sur le problème.

Tu cherches à empêcher l'accès à un secret (identifiants d'accès à ta BdD, le code de ton script ou quelque autre donnée), secret que tu places dans ton programme. Puisqu'il faut bien que ton programme soit exécutable au moment où il est actif, ton secret se trouve à un moment en clair, donc accessible à un intrus. Tu peux imaginer mettre 173 couches de chiffrement pour y accéder mais, sauf si tu fais appel à une clé extérieure au programme (saisie par l'usager, fournie par une carte à puce à authentification, dérivée d'une mesure biométrique ou autre), ton programme devra stocker en son sein les différentes clés de déchiffrement, ce qui les rend inutiles.

Par analogie, je suppose que tu fermes la porte de ton logis à clé quand tu t'absentes. Disons que ta maison est inviolable sans cette clé, si et seulement si tu la gardes sur toi. Si tu laisses ta clé sur la serrure extérieure, accrochée à un clou à côté de la sonnette, "planquée" dans le pot de fleurs de gauche, sous le paillasson ou n'importe où à côté de la maison et qu'on peut remarquer que pour rentrer tu n'utilises pas une clé que tu portes sur toi, alors toute personne peut plus ou moins facilement s'introduire chez toi. Laisser la clé à un voisin ne te met pas plus à l'abri : il suffit d'un brin d'ingénierie sociale pour aller voir le voisin en ton absence, prétendre que tu as eu un grave accident et qu'on doit apporter tes anciens dossiers médicaux à l'hôpital, tout en empêchant le voisin d'appeler au téléphone pour vérifier si l'histoire tient debout (brouillage, fils coupés, pression psychologique, ...). L'intrus est rentré sans effraction, tu as perdu. Sinon, on attend que le voisin s'absente et on récupère la clé qu'il garde dans l'arbre creux.

Si ton programme n'a pas un besoin vital d'un élément extérieur (la clé) fourni par un moyen non réplicable, alors il n'y a pas de protection possible.

Dit ainsi, c'est brutal et un poil trop binaire : possible ou impossible. En pratique, la frontière est plus floue. La véritable problématique est double.
Pour l'attaquant : la protection d'un secret ou d'un bien doit demander à un attaquant "plus" (d'argent, de ressources humaines ou matérielles, de temps, d'énergie, peu importe la mesure) que ne lui apporte le connaissance de ce secret ou le vol de ce bien.
Pour le possesseur du secret ou du bien : la conception et la mise en oeuvre de la protection ne doivent pas demander "plus" que le préjudice induit par le vol de ce bien ou la divulgation de ce secret.

Toute la difficulté repose dans l'évaluation correcte de ces "plus", qui ne sont pas toujours des valeurs aisément chiffrables. Par exemple la fierté qu'un hacker tire de la pénétration gratuite d'un réseau dit "sécurisé", juste pour le plaisir, ça se chiffre comment ? Quelle "valeur" attacher à une menace vandale (e.g. vandalisation d'un site web), terroriste ou même simplement nuisible (e.g. affaire Sony) ?

Ne pas oublier non plus que l'évaluation globale ainsi réalisée doit être régulièrement remise en cause du fait des évolutions technologiques et éventuellement sociales qui ne manquent pas de changer la donne.

communications client/serveur (peut-on chiffrer les chiffrer avec les fonctions SQLite ?)

SQLite n'a pas une architecture client/serveur !

jchd a écrit :SQLite n'a pas une architecture client/serveur !

Au temps pour moi, étant sur un projet de développement web pour les cours, j'ai tendance à oublier les différents programmes qui relient les requêtes lancées depuis le navigateur à la BDD. La question n'avait pas franchement lieu d'être haha !

Je vous confirme, que le logiciel Private exe Protector protégera vos codes AutoIt contre tout intrus.