Discussion :

[Happy]

Bonjour,

J'essaye de trouver un example de création de keygen,
ceci pour proteger mon application par example..
Mais je ne trouve nullpart de l'aide pour ce genre d'algo'
Je programme en C++ sous Code::Blocks.

Merci d'avance pour un lien ou un petit example

[PRomu@ld]

En fait, tu as plusieurs solutions :

Soit tu donnes une seule et unique clé pour ton programme, si l'utilisateur à la clée, c'est bon . Dans ce cas, tu peux soit mettre la clée en clair dans ton programme (if strcmp( cle, "la clée") == 0 ...) soit tu passes par un cryptage de ta clée dans ton programme (par une fonction simple style md5 ...).

Soit tu as une liste limité de clée et là c'est un peu comme au dessus, tu as une liste de clée et tu les testes une à une .

Sinon, si tu veux tu as des méthodes mathématiques. En fait tu décide que ta clée obéit à certaines règles (un nombre divisible par 50 et pas par 3, ...). Ton programme saurat identifier les clés facilement et tu peux en générer autant que tu veux.

PS : je ne suis absolument pas un expert dans le sujet mais je pense que c'est comme celà que l'on fait.

[Jean-Marc.Bourguet]

Tu pars de quelque chose qui identifie uniquement l'ordinateur. Par exemple l'adresse MAC de son interface réseau.

Pour générer la clé, tu "signes" l'élément identifiant l'ordinateur avec un algo de cryptage à clé publique.

Le programme vérifie au démarrage que la signature correspond à l'élément identifiant.

[@drien]

Un problème : il sera toujours possible de changer le code de test en dur pour qu'il soit toujours vrai... d'après moi il sera impossible de complètement verrouiller un exécutable.

Peut-être en le cryptant totalement et en créant un launcher qui irait chercher la clée sur le net? je ne sais pas, je cherche

[PRomu@ld]

En fait rien est infaillible (regarde RSA par exemple), même pas les protections matérielles (style dongle), il faut évaluer le rapport difficulté de cassage et facilité d'utilisation.

Il faudrait savoir ce que le principal interressé veut exactement.

[Jean-Marc.Bourguet]

Un problème : il sera toujours possible de changer le code de test en dur pour qu'il soit toujours vrai... d'après moi il sera impossible de complètement verrouiller un exécutable.

Face à quelqu'un qui y mets réellement les moyens, non. Mais il est possible de compliquer les choses. En vérifiant plusieurs fois la clé (et pas avec une seule fonction), en répartissant les tests, en encryptant une partie du code et en encryptant dans la clé ce qui permet de désencrypter le code... Tout ce qui est purement logiciel est craquable.

La chose la plus sure est d'avoir un dongle capable d'exécuter du code et d'y mettre une partie critique de son application.

[benratti]

Dans ce cas, tu peux soit mettre la clée en clair dans ton programme (if strcmp( cle, "la clée") == 0 ...)

A eviter absolument... une simple decompilation ou une execution a l'aide d'un debuggeur te permet de trouver simplement ta clef.

Peut-être en le cryptant totalement et en créant un launcher qui irait chercher la clée sur le net?

C'est une mauvaise solution... a un moment donnee, le code sera en clair dans la memoire pour qu'il puisse etr executer. C'est juste une perte de performance de ton programme mais pas une augmentation de la difficulter a cracker ton logiciel. et de tout facon, un autre probleme sera amener par cette solution : ou cacher la clef de dechiffrement de la partie chiffrée de ton programme ? c'est en sorte un retour a la case depart.

Bref, je n'ai pas apporte de solution mais ta problematique est la meme que celle qui sont rencontré en obfuscation ( obscursissement en bon francais ), normal, tes motivations sont une des motivations a faire de l'obscurssissement de code. Sur ce sujet particulier, la recherche n'est pas tres avancé pour le moment, donc pas vraiment de solution pour faire l'obscussissement vraiment efficace ( enfin, rien de prouvé )...

[Happy]

Ouip,
Merci beucoup pour vos reponses!
Des qu'il y a une clé c'est ok,
de toute facon je me vois pas faire un prog'
que tout le monde cherchera a le craquer,
mais juste le securiser un peu.

[Matthieu Brucher]

N'oublie pas que les protections ne feront qu'embêter les acheteurs potentiels, les crackeurs casseront la clé tôt ou tard si le logiciel est un tout petit peu intéressant.
Nombreuses sont les protections qui limitent l'utilisateur, mais pas le pirate. Dans la série des dongles à problèmes, je note les iLoks, les Syncrosoft de Cubase SX3, ... dans la série des codes, Native Instrument est assez chiant - on a le mot-clé généré, il faut aller sur le site, le débloquer, rentrer le nouveau numéro dans l'interface -, Adobe, ...