[R] Exécuter des fonctions à partir d'une chaine.

[orax]

Avec XXXX[supprimé] ça n'a rien de sorcier.

[jchd]

ses personnes qui décompilerais mon .exe n'auront quand même pas les 100% du programme

Bien sûr que si.

[jguinch]

@orax : This software is in direct violation of the AutoIt license agreement. Donc pas de lien vers ce truc
http://www.autoitscript.fr/wiki/FAQ_Decompilation

[orax]

@jguinch Ah autant pour moi ! J'avais cru qu'il s'agissait du même décompilateur qu'il y avait avant dans le dossier "Extras".

Si je compile mon script, et que les données sont compilé dedans, oui il peut toujours le décompilé, et donc retrouver le mot de passe et l'accès vers ma BDD MSSQL :s

Et en plus si le script doit se connecter sur un serveur distant, il ne faudra pas que le mot de passe soit véhiculé en "clair" (sans chiffrement) sur le réseau. Sinon quoi, il sera facile de le récupérer.

[mica2727]

Et vous avez déjà essayé de unpacked un .exe AutoIt packed avec MEW ?

C'est quand même un gros problème qu'il n'existe pas un programme sécurisé. Enfin je suis aussi d'accord que si un programme ne peut pas être lue il ne sert à rien, c'est pour ça que peut importe la complexité il sera toujours décompilable, mais bon.

Et vous savez comment décompiler un .exe compiler avec VC6 ? (je sais, c'est du hors sujet), avec PE Explorer, il récupère les données à l'intérieur, je vois les fonctions en claire, mais j'arrive pas à créer des .c et .h d'après ses données

[orax]

PE Explorer c'est plutôt un désassembleur à première vue. Il pourra générer de l'assembleur mais pas des fichiers .c.

[Sea]

Et vous avez déjà essayé de unpacked un .exe AutoIt packed avec MEW ?

C'est quand même un gros problème qu'il n'existe pas un programme sécurisé. Enfin je suis aussi d'accord que si un programme ne peut pas être lue il ne sert à rien, c'est pour ça que peut importe la complexité il sera toujours décompilable, mais bon.

Et vous savez comment décompiler un .exe compiler avec VC6 ? (je sais, c'est du hors sujet), avec PE Explorer, il récupère les données à l'intérieur, je vois les fonctions en claire, mais j'arrive pas à créer des .c et .h d'après ses données

Que du méli-mélo je te conseil de lire l'initiation au C de openclassroom(tu comprendras enfin comment un programme fonctionne et enfin pourquoi tout ce que tu mets sur l'ordinateur de ton client crypté en AES 1024+ RSA +LaCryptoDeLaMortKiTue sers à rien face a quelqu'un qui s'y connais...).Et tu comprendras la différence entre un langage scripté et un langage compilé... Cest vrai que tout les jeux développer par des entreprises qui possèdes des millions de dollars sont vraiment des noobs a ne pas arriver a proteger leur jeux... (ceci est un troll)

Bref vu que ton packer Mew, te rend (d'apres toi) ton truc illésible, je vais t'expliquer comment un packer fonctionne.
Il va crypter ton executable le foutre dans ces ressources, ensuite lorsque tu doubles click sur ton exe précédemment packé, celui-ci va lancer des fonctions de check sur l'environnement et lancer une fonction de decryptage qui va charger sois ton programme en mémoire sois créer un processus de programme (decrypter OFC). Donc la il te suffit de dump ce que ta en mémoire reconstruire l'IAT(Import Adress Table) et hop tu as ton .exe autoit unpacked. Tu as plus qu'a lire ton EOP et hop tu as ton script. Bref une autre idée de génie?

De plus on ne peux pas decompiler du C++ car c'est un langage compilé(c'est a dire traduit en code assembleur, que ton processeur va comprendre...) l'autoit, comme le java,le delphi, .net sont des langages qui ne sont pas compilé mais qui sont placé dans une portion de code, puis le reste du programme va traduire cette portion de code autoit,.net,java en assembleur qui lui va être compréhensible par le processeur.
Si tu veux debug télécharge Ollydbg, apprend l'assembleur et voila


Et pour finir je le redis le problème c'est de donner la réponse d'une énigme, a la personne a qui tu poses l'énigme.
Tu veux un truc sécure ne lui donne pas la réponse et arrange toi pour qu'il puisse en savoir le moins possible.
Donc si tu veux que tes fonction SQL sois safe, ne les executes pas par ton client directement ou alors rajotue un système de protection sur ton serveur pour checker toutes les requetes...

[jguinch]

@mica2727 : donc tu l'auras compris, il n'y a aucun moyen de protéger ton code contre les voleurs.
Il y a des tonnes de posts concernant cette problématique sur les différents forums, mais personne n'a de solution (forcément !)

Perso, pour planquer un mot de passe, j'ai déjà travaillé sur le scénario suivant (qui n'est pas plus sécurisé qu'un autre scénario) :
- le programme compilé va chercher le mot de passe dans une DLL externe en appelant une fonction, appelons-la _GetPassw()
- la DLL contient le mot de passe, sous forme de chaîne (encodée) découpée dans une variable de type Array (les Array sont à priori plus compliqués à bidouiller)
- la DLL contient le checksum MD5 du programme compilé, également sous forme de chaîne (encodée) découpée dans une variable de type Array.
- la fonction _GetPassw() va d'abord calculer et encoder le checksum MD5 l'exécutable (celui qui fait appel à la DLL), puis va vérifier s'il correspond à celui qui est renseigné dans la DLL. Si ce n'est pas le cas, la fonction renvoi une chaîne vide. Si le checksum MD5 est bon, le programme renvoi le mot de passe.

Mon idée est la suivante :
Si quelqu'un décompile le programme AutoIt et le recompile (en modifiant ou pas le code), le checksum MD5 aura changé, donc il ne pourra pas récupérer le mot de passe. Il faudra qu'il s'attaque à la DLL, ce qui risque d'être plus compliqué (je pense)

@Sea : que pense-tu de ce scénario ? Pense-tu qu'il est plus facile/difficile de s'attaquer à une DLL qu'à un script compilé ? Quel sera le moyen de récupérer le mot de passe ? Un dump de la mémoire le permettra t-il ? Un désasambleur ?

[mica2727]

En faite pour faire simple, vous me dites soit je protège mes données donc aucun mot de passe ni autre chose sensible dans autoit.

Sois je passe a un langage compilé (qui est pas décompilable, d'après ce que j'ai compris), comme le C++.
J'ai fais un peu de cours sur le C++ malgré ce que certain pense, mais ça reste du très compliqué face à AutoIt.

Je vais devoir me posé les bonnes questions alors.
Et personne pour récupérer les fonctions dans C++ V6 ?

Je l'ai vois déjà en claire avec PE Explorer, donc il y a moyen de les récupérés mais je ne trouve pas le logiciel adéquate.

[mica2727]

J'avais une autre question,
Est-ce que le Qt me permettrait de faire un jeu?
ça a l'air plus simple que C/C++ non?

Le Qt se rapproche un peu d'AutoIt, alors que le C/C++ c'est de la programmation, j'ai déjà essayé 4 fois à l'apprendre mais sans succès.

[TommyDDR]

Qt est un framework d'interface graphique pour C++, si vous l'utilisez, vous devrez coder en C++.

[mica2727]

Oui, mais je vais devoir m'y remettre pour une 5ème fois.

Parce que AutoIt est très bien pour des logiciels "privée" mais pour un logiciel à distribuer, ce n'est pas le mieux sécurisé pour ça, et d'ailleurs si j'ai bien compris AutoIt est quand même développeur dans une optique < Open Source > alors que C/C++ et Qt est fait pour une programmation un peu plus privatisé (selon moi).

Je pense pas me tromper de loin, pour mes logiciels avec la BDD qui reste sur mon pc il y a pas de soucis, mais quand ça touche à des choses plus privée je pense donc me tourner vers C++ une nouvelle fois.

Merci quand même de votre aide l'équipe AutoIt FR

[orax]

Mais même avec 'un langage comme le C++, il ne faut pas mettre des données sensibles dans un programme.

Vous ne pourrez pas protéger votre script à 100% et ce dans tous les langages. Pour garder votre mot de passe au chaud, je confirme qu'une solution serait de ne pas le donner au client et de passer par un serveur qui fera les requêtes pour le client.

Donc si tu veux que tes fonction SQL sois safe, ne les executes pas par ton client directement

Avec Qt il y aussi des "bindings" dans d'autres langages mais je suppose que le C++ est le plus approprié.

[mica2727]

Merci de votre aide, je pense que je vais faire ça.
Mais vu que c'est un jeu 3D c'est mieux C++ et Qt ou que C++ ? Qt c'est fait pour les interfaces non? alors que C++ c'est plutôt du langage pure, mais pour les interfaces c'est assez compliqué.

De plus il existe Qt Creator pour créer des interfaces à coder après avec C++ je crois.
Et oui Qt il lit le lua, j'ai vu sur ton lien orax.

Mais pour ce qui est du DDS ? et des fichiers INF, je ne sais pas.
Directx aussi d'ailleurs c'est plutôt du C++ ça.

[jguinch]

Tu as regardé du côté des autres langages ? PureBasic, FreeBasic...

[mica2727]

Merci, oui c'est vrai que les deux permettent de faire des jeux.

Mais ça va être plus compliquer d'ajouter des .INF, .DDS et .TGA, et sur leur liens, a moins que j'ai mal cherché, mais je pense pas qu'il puisse faire ce genre d'extension.

Alors que le C ou C++ lui malgré la difficulté élever d'apprentissage, il doit pouvoir le faire.
Mais si tu as d'autre idée de langage de programmation orienté jeu, ça me dérange pas.

FreeBasic : Vu les jeux je pense pas qu'il soit utile.
En revanche le premier il y a quand même pas mal de jeu, et en plus sans DLL supplémentaire, ça peut être bien d'un sens. Mais je ne pense pas qui prends le Lua en charge...

Et je ne sais pas vraiment ou chercher d'autre langage non plus.

[jguinch]

Sinon, Unity.
Mais là on commence à s'éloigner d'AutoIt...

[mica2727]

Je l'avais déjà vu Unity, mais je crois que c'est juste pour une plate forme web, ou aussi plate forme logiciel ?
Oui je sais qu'on s'égard d'AutoIt, mais vous êtes bon en conseil :p

C'est pas pour ça que j'utiliserais plus AutoIt, il est bien trop puissant pour l'abandonner comme ça.
Mais pour des jeux AutoIt n'est pas fait pour ça.

[orax]

Et je ne sais pas vraiment ou chercher d'autre langage non plus.

Sur un site/forum spécialisé ? http://jeux.developpez.com/ par exemple.

[TT22]

Pense-tu qu'il est plus facile/difficile de s'attaquer à une DLL qu'à un script compilé ? Quel sera le moyen de récupérer le mot de passe ? Un dump de la mémoire le permettra t-il ? Un désasambleur ?

Le moyen suivant devrait être assez simple sans même se préoccuper de la DLL :

si le script doit se connecter sur un serveur distant, il ne faudra pas que le mot de passe soit véhiculé en "clair" (sans chiffrement) sur le réseau. Sinon quoi, il sera facile de le récupérer

@mica2727 Pourquoi tu ne fais pas tout simplement un code côté serveur qui va lui-même gérer les requêtes SQL ?