Version imprimable
Dans mon cas je cherche aussi à sécurisé ma connexion à mon serveur. j'ai pour le moment mit le code en dur pour tester.
Vous parliez de web services, dans mon cas je ne pourrai pas héberger un web service car mon serveur est sous linux (à moins qu on puisse le faire et que je ne le sache pas)
Alors j'aimerai savoir quels sont les moyens pour sécurisé sa connexion à son serveur?
Cordialement
Avec un système de sessions :)
Après identification du mdp, la bdd(ou autre) renvoie une clé de session temporaire à l'application qui utilise cette dernière pour se connecter au serveur.
Hashtable en anglais mais Table de hachage en français! (wikipedia confirme) Donc haché et pas hashé! Même s'il est vrai on est loi de la boucherie. Oui c'est hors-sujet mais il fallait que je le dise! :)Citation:
Envoyé par Louis-Guillaume Morand
Bonjour je viens de lire vos posts, comme tout le monde je suis d'accord avec les uns et pas d'accord avec les autres...
Je bosse depuis des mois sur un projet dont la commercialisation débutera la semaine prochaine inchallah... J'ai mis un système d'activation par fichier de licence ainsi qu'une clé pour décrypter le fichier de licence qui contient des ressources nécessaire pour les fonctionnalités avancé du logiciel...
Quand j'ai découvert Reflector! C'était le cauchemard! N'importe qui peut exporter le code source de mon programme, enlever le code de sécurité, régénérer et mettre disponible pour tout le monde!...
En fait y a pas une protection à 100% mais juste le temps de commercialiser le produit càd gagner du temps le temps de vendre quelques licences.
J'ai utilisé Eazfuscator.NET (gratuit) pour obfusquer l'exécutable, ayant une expérience du monde du cracking, je suis satisfait du résultat à 50% car même si j'ai développé en C++ je ne serai satisfait qu'à 75%. J'ai vérifié le code source exporté par Reflector après obscursissement par Eazfuscator.NET, les chaines de caractères sont cryptés, il me faudra des heures et des heures pour corriger les noms des classes et membres en enlevant les caractères superflus non acceptés par le compilateur, analyser le code et donner des noms ayant un sens aux différents classes, membres et variables, etc.
PS: Pour ne pas avoir des réponses hors-sujet, je tiens à signaler que j'ai fait une auto-formation du cracking A TITRE ÉDUCATIF pas plus!
pour nous l'obfuscation n'est pas une solution, vu qu'en cas d'exception, on enregistre la pile d'appel et on reflectionne sur la classe qu'a planté, ca serait plus très drole pour relire les fichier de log :D
Tu peux STP donner plus d'explication?
merci :)
on met des try catch partout (sub function property)
donc pas de fenetre "l'appli plante, continuer ou quitter ?"
et dans chaque catch, on appelle une sub avec en paramètre ex, this, et tous les parametres de la sub (ou fct ...) (dans les membres partagés on envoie que ex vu que this n'est pas dispo)
cette sub de tracage d'erreur, on créé un fichier avec toutes les infos (aussi possible par mail ou dans base de données)
deja avec ex on a .stacktrace (pile d'appel jusqu'à l'erreur)
on connait aussi le type d'erreur et le message qui va avec
et au passage
- on récupère la pile d'appel totale (cheminement depuis le début de l'action)
- on fait de la reflection sur tous les objets passés pour connaitre la valeur des variables et propriétés, qu'elles soient publiques ou privées, donc sur this et tous les autres paramètres du membre qui plante
et sur chaque valeur de membre on reflectionne à nouveau etc...
c'est très pratique pour débugger une appli
on a des controles complexes donc ca permet de retrouver par exemple une requete qui a planté, l'état d'une connexion etc....
et donc pour en revenir à l'obfuscation il me semble que ca change les noms de tous les membres
et donc savoir que aajehzakj a appelé jfrekfkle avec la variable gftncpa en paramètre
c'est quand meme moins pratique que de savoir que AfficheValeur a appelé FormateValeur avec en paramètre TexboxInfo3
et si les .pdb sont présents ca affiche même les numéro de ligne dans la pile d'appel
Merci pour les infos sperot51 :)
Oui je suis tout à fait d'accord avec toi, mais, mon objectif d'utilisation de l'obfuscation c'est de gagner du temps avant que quelqu'un ne trouve la faille et me coupe les vivres :D
Je sais pas si Reflector est le top des désassembleur mais l'obfuscation l'empêche d'analyser mon code source et le déplacement instantané vers la définition d'une classe par simple clique, etc.
Ce qui me préoccupe c'est pas qu'on crack mon prog mais qu'on obtient une version quasiment identique au projet avec tous les codes source et les ressources... Je sais que n'importe quel programmeur peut reproduire mon programme mais c'est comme ça! Au moins il doit fournir l'effort pour le reproduire et non pas <<comme on dit chez nous>> fournit sur une assiette d'or!
Merci :)