On s'éloigne de la programmation C mais je voudrais apporter quelques infos supplémentaires.
Je pense que la meilleure protection (ce qui ne veut pas dire qu'elle soit parfaite) est de proposer une version de démonstration non complète comme pour les jeux video. Si ce n'est pas possible, il faut effectivement se pencher vers un autre type de protection. Dans ce cas, il faut prendre en compte 2 points fondamentaux : l'algorithme et son implémentation.
Pour le premier, et si l'on suit l'idée donnée par Emmanuel, il faut :
- Trouver un moyen sûr de connaitre la date actuelle (ex : fichiers systèmes, serveur NTP, etc.).
- Cacher la date d'installation (ex : cryptage RC4, AES, RSA, etc. avec test d'intégrité (SHA-xxx)).
Mais tout ça ne vaut rien si dans ton code, tu as :
Code :
- if (DiffDate() > NOMBRE_MAX_DE_JOURS)
- {
- Quit();
- }
|
Car autant la comparaison que la constante peuvent être modifiées facilement.
Il faut donc camoufler ce test dans ton code, par exemple : le diviser en plusieurs parties éparpillées au milieu des routines d'initialisation, utiliser plusieurs variables et points de contrôle, crypter le code principal du programme et le décrypter au fur et à mesure que les tests se font. Tu peux aussi "crypter" les valeurs, par exemple : l'année 2006 est supérieure à l'année 2005 mais 2006 * 2 > 2005*2 aussi et en mettant des centaines d'opérations comme ça éparpillées dans toutes les routines d'initialisation, en utilisant de nombreuses variables, tu peux facilement perdre un attaquant. Je dirai que c'est la partie artistique de la programmation, cela demande de faire preuve d'imagination.
Il y a également tout un tas de techniques anti-debug pour empêcher ralentir l'analyse du programme...
En fait, c'est un ensemble de techniques mises bout à bout qui peuvent donner une protection "fiable".
Il reste les protections commerciales, mais je te le déconseille car aucune protection n'est inviolable et l'investissement n'en vaut pas la peine. Mais ce n'est que mon avis.