Salut a vous!
J'aimerais pouvoir creer un system pour securiser une application
Java.
Exemple: si un utilisateur n'a pas une cle, alors meme s'il installe
l'application, il l'utilisera en partie voir meme ne pas pouvoir l'utiliser
Merci d'avance!
Version imprimable
Salut a vous!
J'aimerais pouvoir creer un system pour securiser une application
Java.
Exemple: si un utilisateur n'a pas une cle, alors meme s'il installe
l'application, il l'utilisera en partie voir meme ne pas pouvoir l'utiliser
Merci d'avance!
regarde du cote de l'ecriture lecture du registre de windows. Tu cree une cle dans le registre avec une date. tu teste cette (existance et valeur) pour determiner l'utilisation
La date ? C'est quoi le rapport avec une clé d'activation ? A priori la seule chose à stocker, c'est si oui ou non une clé valide a été fournie...
Mais j'imagine que la question est plutôt, existe-t-il des outils qui gèrent tout cela pour nous ? Auquel cas, je n'en sais rien et de toute façon, ce ne serait pas une bonne idée.
La force d'une protection de ce genre réside dans le fait que personne d'autre n'utilise la même, et donc que savoir la pirater a peu d'intérêt. Si une protection est utilisée par tout le monde, alors tout le monde sait aussi comment la désactiver. Logique.
la date etait un exemple de controle.Citation:
Envoyé par thelvin
Salut fmvgld, je vais essayer de suivre ta piste, cependant as-tu de bon tutoriaux dessus? Si oui je les lirais volontiers.
Salut thelvin, ma question n'est pas de savoir s'il existe des outils pour gérer les clés d'activation, mais comment les gérer dans ma propre application java.
L'idée de base c'est la suivante, a supposer que tes utilisateurs ne feront pas trop d'effort pour craquer
Ton application dispose d'une clé publique incorporée à l'application
La licence consiste en un fichier signé avec la clé privée, fichier contenant les dates de validité de la clé, le propriétaire etc
Ton application vérifie la signature en utilisant sa clé publique. Si pas valide => pas d'activation
Elle lit le contenu du fichier. Si date de début / fin n'incluent pas la date du jour =>pas d'activation
Ceci permet de vérifier que la clé d'activation, c'est bien toi qui l'a créée chez toi. Bien sur de ton coté, quand quelqu'un paie pour le logiciel tu dois créer un fichier, le signer, l'envoyer à l'utilisateur
Si tes utilisateurs commencent à bidouiller il faut alors trouver des parades pour:
empêcher le partage de clé d'activation (exemple inclure un identifiant utilisateur dans la clé)
protéger la clé publique, ca évite de la remplacer par une autre dont on connait la clé privée et donc de pouvoir créer des clés comme toi
empêcher un cracker de retirer le code de vérification (multiplier les endroit et les manière dont tu vérifie, obfusquer le code, ça ralentit mais ne rends pas impossible)
eventuellement valider en ligne régulièrement les clés, télécahrger la clé publique depuis un serveur sécuriser.
Etc, l'imagination est reine.
Après suivant l'infrastructure que tu vise, d'autres solution plus spécifique sont envisageable. Par exemple sur Android tu peux déléguer au playstore.
En Java, tout "vicieux" un tant soit peu patient et qui a accès au jar, fera "sauter" n'importe quelle protection implémentée dans l'application elle-même avec AspectJ, même avec de l'obfuscation et appel de code natif et callback d'un serveur distant…Citation:
Envoyé par tchize_
Dans l'absolu, protéger du code dont le binaire est dans un format connu et disponible sur la machine de l'utilisateur est voué à l'échec, les méthodes ci-dessus permettent juste de décourager le bricoleur qui s'y attaquerait pour le plaisir ou de retarder l'échéance en fonction des compétences du pirate.
C'est valable pour tout système de protection, on peut toujours allers plus où moins loin dans la complexité de la solution, à un moment où un autre, ça cassera pourvu que quelqu'un y mette les moyens. C'est valable pour les jar mais aussi les exe ou tout autre application locale.Citation:
Envoyé par JeitEmgie
c'est bien ce que veut dire "dont le binaire est dans un format connu et disponible sur la machine de l'utilisateur"Citation:
Envoyé par tchize_
Cette méthode semble être bonne pour un début .j'essaie d'exploiter l'API java.Security a cet effet.Citation:
Envoyé par tchize_
pour moi (moins expérimenté que vous je suppose)il ya pas mal de travail a faire.
Très intéressantes tes informations JeitEmgie . Si "protéger du code dont le binaire est dans un format connu et disponible sur la machine de l'utilisateur est voué à l'échec",Citation:
Envoyé par JeitEmgie
pourrais- tu suggérer un moyen de sécurité plus fiable?
"dans l'absolu… c'est voué à l'échec…" : ce qui veut simplement dire qu'iil y aura toujours au moins un comique qui aura la patience d'aller jusqu'au bout si la "récompense" en vaut la peine…Citation:
Envoyé par Ng.K.plus
Mais en pratique, protéger par différentes techniques c'est comme cumuler des filtres : chacun va décourager un pourcentage de tentatives d'un certain type, mais vous coûtera en temps de développement, test et maintenance, et vous n'arriverez jamais à une protection sûre à 100%.
Toute la question est donc : quel prix êtes-vous prêt à investir ? que ce soit en temps, en achat d'outils, … ?
Ou autrement posée, la question pourrait être : quel % de la valeur du produit ?
A mettre en perspective avec le type de piratage que vous craigniez par rapport au type de produit : vous développez un logiciel à 20K € pour un marché de niche ou un jeu à 0.99$ ?
Sans oublier vos contraintes propres par rapport au marché visé : pouvez-vous exiger une connection Internet du client pour l'utilisation du produit ou pas ?
Sans oublier que les protections faites "maison" par quelqu'un peu au fait de la mentalité des hackers ont toutes les chances d'être très vite contournées : l'imagination du pirate motivé est sans limite…
et surtout il ne suit pas du tout le même schéma logique de raisonnement qu'un développeur : il ne cherche pas à construire quelque chose mais simplement à enlever un obstacle…
le développeur a tendance à s'imaginer qu'un pirate va essayer de déverrouiller le coffre en s'attaquant à la belle serrure qu'il vient d'inventer,
alors que la première chose que le pirate va examiner si c'est le dos du dit coffre n'est pas en carton pâte et ne préoccupera de la serrure que s'il ne trouve pas d'autre moyen…
n'oubliez jamais le meilleur exemple de pirate : Alexandre le Grand face au nœud gordien…
le pirate ne résout pas un problème : il s'en débarrasse.
Cela dit aux techniques évoquées par tchize_ plus haut, vous pouvez ajouter
- de protéger le code de protection lui-même en ne le laissant pas sous une forme lisible, donc en Java cela signifie de développer votre (vos) propre(s) class loader(s) qui chargera(ont) du code encrypté…
- de ne pas communiquer par appel de méthodes mais par des techniques de type JMS (queue d'events avec producteurs/consommateurs…) et gestion d'une machine d'états
(et j'imagine que vous vous dites que cela paraît déjà beaucoup moins drôle à mettre en œuvre…)