Dans un fichier tout simple, donc.
Eh bien, pour lire/écrire du binaire, c'est InputStream / OutputStream. Dans un fichier, plus précisément FileInputStream / FileOutputStream. S'il est sur le serveur, ce n'est pas un fichier local, donc ce ne sera pas avec les FileTruc. Tout dépendra du protocole utilisé pour dialoguer avec le serveur.
N'oubliez pas de consulter les FAQ Java et les cours et tutoriels Java
En supposant qu'il n'y aie qu'un seul code. On peux aller dans des chemins plus ou moins complexe:
avoir une partie de la clé décodée qui sert de base à certains des calculs que fait le serveur: du coup, il ne suffit pas de supprimer les check, il faut simuler tout le retour de décodage. Avoir le décodage non pas dans une méthode, mais via un ou plusieurs bout de code copié/collé partout dans le code. Du coup pour faire sauter le décodage faut aller trouver tous les endroit dans le code où t'as fait ce putain de copier/coller, probablement en le mélangeant avec du code buisness. Mais ce sera une chierie pour toi à maintenir.
Si le serveur a une connexion internet tu pourrais rajouter du code qui, occasionellement, se connecte à un serveur central puis te signaler qu'un serveur tourne avec ta clé.
Maintenant, bien qu'il ne faille pas donner la solution tout cuite aux pirate, si ton logiciel doit tourner dans une entreprise et qu'il sert à son buisness, l'entreprise n'ira pas courir le risque, en général, de reposer sur une application qui peut pêter demain à cause du crack. Le risque de piratage est plus faible. On trouve sans problème des cracks pour la pluspart des produits microsoft. Et pourtant, les entreprises achetent toujours autant de licence sharepoint ou sqlserver. Le jeu n'en vaut pas la chandelle. Pour économiser 50.000 euros de licence, risque de perdre des centaines de milliers d'euros en données perdues et jours de chomage le jour où ça pêtera....
Il suffit d'utiliser un outil comme JAD et de "décompiler" les classes.
Ensuite, tu n'as plus qu'à supprimer le bout de code qui fait le test de licence ou l'appelle et tu as "déplombé" l'application.
Bref, c'est très facile.
La solution d'un serveur est de loin la meilleure (typiquement une architecture client/serveur), le client étant fait pour afficher les résultats uniquement. L'inconvénient étant d'obliger le client d'avoir une connexion.
N'oubliez pas de consulter les FAQ Java et les cours et tutoriels Java
Disons que c'est un peu comme la guerre.
Il y a des armes de base: la copie pure et dure de ton programme pour pas payer
Il y a les gilets pare-balle: une licence et une simple vérification de sa date
Il y a les armes lourdes, contre lesquels le gilet ne sert à rien: supprimer le check (décompilation ou encore plus facile maintenant, utiliser l'aop pour faire de l'injection de methode), fabriquer une fausse licence
Il y a donc les véhicule blindés: verrouiller la licence avec une clé cryptographique et planquer le code, avec des obfuscateurs par exemple
Il y a les armes anti-tank: remplacer la clé cryptographique, décompiler le code en assembleur ou avec des noms de variables obscon et recompiler quand même
Il y a des contre mesures passives aux missiles anti tanks: Multiplier les nombre de vérifications dans le code, ne pas tout centraliser dans une classe, utiliser la sortie cryptographique dans des calculs du programmes, rajouter des tests supplémentaire pour s'assurer que les classes n'ont pas été modifiées, refuser aléatoirement les fausses clés pour ne pas pouvoir savoir si on a réussi du premier coup mais plutot avoir un truc qui crashe après 2 semaines, ...
Il y a les missiles anti tanks à double charge pour contrer les contre mesures: ...
Il y a les contre mesures actives: ....
....
C'est une escalade sans fin. Le tout est d'avoir une idée de
Toi tu es prêt à aller jusque où?
L'adversaire veux bien aller jusqu'où? On ne protège pas de la même manière le dernier photoshop piraté à des millions d'exemplaires qu'on ne protège la dernière version de github enterprise qui n'intéresse que quelques milliers de clients à travers le monde
Ce n'est pas parce que la protection absolue n'existe pas qu'il est inutile de mettre un minimum de protection. A toi de voir ce qui est faisable, d'utiliser ton imagination. Le b-a-ba je dirais, c'est au minimum:
De décoder la licence avec une clé publique pour vérifier son contenu
De garder bien au chaud chez toi la clé privée
D'éviter qu'il soit possible de facilement remplacer la clé publique dans ton programme
Ok merci pour vos reponses. Je représsisse mes attentes mon problèmes ce n'est pas que craigne que quelqu'un puyisse copier mon logiciel d'une entreprise AZ pour une entreprise B car les états portent le nom de l'entreprise de plus l'application ne sert à rien sans le serveur. Je veux bien continuer avec mon approche qui vas donc stocker le fichier de licence sur le serveur et également la clé pour décrypter. maintenant comment les lire et avec quel protocole et comment faire? voilà à peu près mes préaucupations.
La force d'un programmeur ne réside pas dans le fait qu'il écrive des codes puissants mais dans sa capacité à les maintenir!!!
Comment les lire: comme n'importe quel fichier
Comment la décrypter: Tu peux trouver pas mal de documentation sur ce forum à propos de la cryptographie assymétrique. Java possède tout ce qu'il faut, faut juste passer les bon paramètres.
ben une connexion internet entre l'application déployée chez le client et un serveur de licences central dans ta société.
La force d'un programmeur ne réside pas dans le fait qu'il écrive des codes puissants mais dans sa capacité à les maintenir!!!
Oui on a bien compris, tu ne part pas sur l'option d'un serveur décentraliser qui gère les licences et fait un travail utile. Je crois que c'est toi qui n'a pas bien compris. T'as pas besoin d'un serveur distant nécessairement pour vérifier la licence et gérer la clé cryptographique. L'option du serveur distant, c'était une solution qui permettait d'éviter le crack. J'ai bien compris, on ne part pas dans cette direction. Donc maintenant, qu'est-ce qui te coince?
Bon je m'explique un peut mieux je mets la clé sur un sereur distant pour ne pas l'aoir sur tous les postes clients idem pour la clé de décryptge. Ce que je nrrie pas à faire c'est le procédé pour lire un fichier sur une machine distante
La force d'un programmeur ne réside pas dans le fait qu'il écrive des codes puissants mais dans sa capacité à les maintenir!!!
N'oubliez pas de consulter les FAQ Java et les cours et tutoriels Java
Que la force de la puissance soit avec le courage de ta sagesse.
Non mais, prenons l'état des lieux et faisons avec.
Tu as des postes client, et ton application est une application desktop sur le poste client? Si oui tu met la licence sur le poste client (dans un dossier que tu choisi), tu inclue la clé publique à ton programme, tu fais tes checks dans le programme après avoir décodé la licence avec la clé publique. Pas besoin de serveur pour tout ça.
Il n'y a pas de magie : en dehors des problématiques de ton programme, le poste client doit pouvoir contacter le serveur.
Sont-ils connectés en réseaux ?
Si aucun programme serveur ne tourne sur la machine serveur, alors tu dois installer un programme serveur. Lequel ? A toi de choisir. Peut-être FTP par exemple ?
Ensuite ton programme doit être capable de faire une requête sur le programme serveur de la machine serveur. En Java, le protocole FTP est directement géré par l'API standard.
N'oubliez pas de consulter les FAQ Java et les cours et tutoriels Java
Que la force de la puissance soit avec le courage de ta sagesse.
La force d'un programmeur ne réside pas dans le fait qu'il écrive des codes puissants mais dans sa capacité à les maintenir!!!
Bon, va falloir clarifier franchement. Tu veux protéger quoi contre la copie?
L'application que tu déploie sur les postes clients?
Le serveur que tu installe chez le client?
Les deux?
Aussi, corrige cette lettre "v" qui ne marche plus sur ton clavier, tes messages sont très durs à lire
Vous avez un bloqueur de publicités installé.
Le Club Developpez.com n'affiche que des publicités IT, discrètes et non intrusives.
Afin que nous puissions continuer à vous fournir gratuitement du contenu de qualité, merci de nous soutenir en désactivant votre bloqueur de publicités sur Developpez.com.
Partager