Bonjour,  
 
Ma question concerne sur les moyens pour implementer une limite de temps sur un programme dévelloppé en JAVA.  
 
De fait ca revient a un shareware de fonctionnalité totale mais limité dans le temps. Par contre je ne vois pas trop comment implementer quelquechose de solide et de secure en effet il s'agit d'un logiciel d'entreprise, donc il faut que se soit quelquechose de pro et non pas une simple bidouille.  
 
J'espere que l'un d'entre vous pourras m'éclairer mais surtout me conseiller sur quel moyen choisir.  
 
Merci  
 
PS: je dois aussi faire la meme chose pour une appli en C/C++ donc si dans la foulé vous avez des infos la dessus.

pour la limitation je sais pas trop, mais de toutes facons, il va falloir utiliser un obfuscateur (obfsucator) pour brouiller le code (sinon ca va etre trop facile a craquer), pour ca tu peux faire une recherche sur le forum, le sujet a deja ete aborde plusieurs fois

Merci Bobuse,
 
oui l'obfuscateur j'y avais pensé pas de probleme la dessus.
 
Mais c'est le bordel de temps limité c plus galere  

 
Voir les packages de Java Cryptography Extension java.sun.com/products/jce, sauf si tu as jdk > 1.4.x, ou c'est deja integré
 
Dans ton cas, la limitation peut se faire avec une clef (voir KeyGeneration)
Une classe A avec parametres d'entrée (dates de debut/fin, utilisateur...etc ), combinée avec JCE pour calculer une clef d'activation a la volée.
 
- Tu fournis un fichier "toto.key" au client
- Ce fichier contient les parametres identifiant le client, la date de debut, de fin d'utilisation, les fonctionnalités accessibles... Tout ca est bien sur encryptés (tu peux utiliser un RessourceBundle par ex encrypté via JCE)
- Ce fichier est lu par ton appli au demarrage via une classe spécialisée qui va decrypter le fichier (voir JCE), extraire les infos et les passer a une classe de traitement des acces
- La classe de traitement peut renvoyer un code de validation d'acces, une exception... Ce que tu veux

senternal, elle est bonne ton idée mais tu dis que dans le fichier toto.key il y a une date de fin ?
Donc je suis obligé de spécifier cette date a chaque fois que je distribue l'appli ?

 
Apparement, cette solution nécessite que chaque distribution ai une clé spécifique. ça n'a rien de choquant qu'un produit nécessite un clef d'activation spécifique. Et comme ça, tu peux utiliser le même système pour le débloquage de ton appli, en fournissant un clé de validation permanante.

 
Tu n'es pas obligé de spécifier une date de fin... C'est un exemple...  
 
Tu peux tout aussi bien ne pas mettre de date debut/fin et mettre uniquement une durée d'utilisation (30 par exemple pour 30 jours). Ensuite, dans ton code, tu peux aller lire cette durée dans la clef et vérifier que la date du jour - date d'install < durée d'utilisation. Je ne peux pas te donner une soluce clef en main... Un peu de reflexion !!  

 
Il cherche peut être à empêcher une utilisation de + de 30 jours, même si l'utilisateur modifie la date de son PC.

 
Auquel cas, sous Windows, il lui faut modifier les fichiers System (comme le bon vieux System.dat, base de registres ?? et encore...) et dans ce cas, tu oublies sous Linux/Unix... A ma connaissance (limitée peut-etre), il n'existe pas de systeme simple sans intervention sur les parametres de l'OS evitant a l'utilisateur de changer la date et de desinstaller/reinstaller l'appli... Y'a bien les dongles mais ca repondra pas forcement a son besoin...

tu peux bidouiller directement tes fichier class pendant l'execution, le bytecode n'est pas tres complique, ca doit pouvoir se faire non?
 
  enfin j'en sais rien, je propose juste hein c'est peut etre une idee stupide, mais il faut que tu stocke ca quelque part, et tu peux pas le faire dans un fichier texte, et si tu veux rester independant de l'OS tu peux pas utiliser autre chose non plus (genre base de registre sous windows etc..)

toutes facons, en decompilant c'est trop simple a déplomber pour etre efficace (enfin je suppose, j'ai jamais vraiment essayé)

ben si tu obfusque bien, il doit y avoir moyen de proteger un peu mieux, meme si ca reste crackable...

ben meme en obfuscant, il reste forcément les noms de classes et méthodes de l'api... donc on retrouve la vérif des clef assez facilement avec ca.
 
bref, a mon avis c'est pas une bonne idée...

 
Via JNI, et du C ansi pour la vérif de la clé, on peut s'en sortir pas trop mal niveau sécurité j'pense.

   
j'ai jamais utilisé jni, mais a mon avis coté java on voit l'appel, suffit soit de remplacer le bout de C, soit de squeezer l'appel. y'a pas de solution fiable dans ce genre de trucs

et en utilisant une connection a un serveur web que l'on controle? genre on demande une clef au serveur, on peut verifier si elle est valide ou non. Si valide, ok, sinon pas ok.chaque appli s'identifie de facon unique et hop... non ? (je propose toujours hein, je sais pas si c'est bon   )

c'est encore ce que je vois de mieux, mais même probleme : trop facile de décompiler et de virer la partie verification

suis d'accord avec lorill...
 
je pose ma petite contribution :  
j'ai utilisé Rational XDE et au lancement il se connecte à un serveur distant, contrôle les droits utilisateurs et télécharge un bout de code permettant de faire fonctionner l'appli... donc obligation de se connecter
 
ensuite, le tout est de savoir comment effacer ce bout de code lorsqu'on quitte l'appli..

Merci pour toutes vos contributions.
 
C'est vrai que c'est genant que l'utilisateur puisse "by-passer" la sécurité en modifiant la date du system.
 
Mais aller modifier les parametres de l OS ce n'est pas l'ideal.
 
On m a aussi donné l'idée d'une activation par internet (server web autorisant le lancement) c'est la solution la plus sure et efficace mais demande trop de contrainte.
 
Reste la solution de la clé crypté qui me semble la plus simple mais tout cela est "facilement" crackable. ou alors hardcoder la date limite dans le code.
 
Reste alors le probleme de l'obfuscation ! es ce fiable car les outils de reverse engeneering sont assez efficace maintenant.
 
Mais bon je ne me voile pas la face , le systeme de protection ne sera pas infaillible, je veux juste éviter qu un utilisateur (informaticien) avec des compétences moyennes ne puisse virer la sécurité en 10 min.

Je dis p-ê une connerie, mais pkoi pas une limitation au niveau du nb d'exécutions?
Ca évite les pbs de vérif de la date du système, déjà...

 
Oui j'y ai pensé mais il faut estimer ce nombre.
Et c moins contraignant de dire a un client :
"Vous avez 30 jours pour le tester"
 
que
 
"Vous pouvez lancer l'application x fois"
 
Dans mon cas je prefere une limite en jours.

 
De toute facon, n'importe laquelle des solutions ne sera pas fiable tant qu'on aura acces sans aucune restriction au ClassLoader et a la magie du ClassLoader.defineClass... C'est la le gros hic...
 
L'obfuscation par encryption de ton byte-code (fait peter le terme obscure...) ne change rien. Il te suffit simplement de modifier ton rt.jar par ta propre implementation d'un ClassLoader et le tour est "presque" joué, mais ca prend un peu de temps, ca depend de la valeur que tu peux mettre en face de ton outil...
 
Disons que Java n'est pas en soit un langage "secure" des lors qu'on a la main sur l'environnement d'execution. Cela dit, la solution que je t'ai proposée est en soit parfaitement viable. Quand à l'utilisation d'une connexion a un serveur http pour recuperer une clef ou du code a executer a la volée, si c'est ca que vous utilisez pour securiser votre appli...

d'un autre cote, si c'est une appli pro, les pro ils achetent, ils respectent les periodes d'essai et compagnie (suis-je trop naif ? )

demande aux mecs qui font intellij-idea
apres avoir joué pendant 3 mois avec des licenses d'essai, on a fini par acheter 6 licenses au taf...
de toutes façons, le temps que tu t'amuses a essayer de plomber le truc y'aura deja un crack ou un serial qui traine

1. Pour chaque nouveau client tu cree un nouveau compte (tu te debrouilles) sur ton systeme d'enregistrement
 
2. Tu donnes un ID au client et un mot de passe
 
3. Au 1er lancement l'ID et le mot de passe doivent etre fournis, tu stocke cette info ou tu veux cote client
 
4. 1ere connection, tu MAJ ta BDD client en donnant un timestamp pour cette premiere connection
 
5. A chaque connection, tu loades une classe distante (tu peux specifier une URL), dans l'url tu indiques l'ID et le mot de passe
 
6. Cote serveur tu verifies a la demande de la classe si le client a droit de lancer l'appli (temps depasse ou non)
 
7. La classe downloadee n'est jamais ecrite sur disque donc...
 
Plus precis que ca je ne peux pas...
 
 
7.  
 
Connection distante a un serveur

Et si la machine du client n'est pas connectée à Internet ? je sais que c'est pour une entreprise et qu'il y a peu de chances, mais n'ayant pas internet à disposition chez moi, je ne peux m'empecher de bondir à l'evocation de telles pratiques.

 
Relis le...
 

 
Si la machine n'est pas connectee... et bien il peut oublier