Discussion :

[Deamon77]

Bonjour,

Je cherche comment fabriquer un keygen me permettant d'avoir une clée d'activation avec un algorithme réversible mais je ne trouve pas d'exemple sur internet.
je n'ai pas trouvé mon bonheur avec la fonction rechercher sur le forum afin de voir la la réponse à ma question s'y trouvait.

quelqu'un aurait une idée ou autre?

Merci

[sovo]

Je crois que ton problème est beaucoup plus conceptuel.

En effet, ce que je trouve être ton problème c'est l'algorithme de génération de ta clé. Et une fois que c'est fait, tu pourras créer un logiciel (basé sur cet algorithme) pour générer ton logiciel.

NB: j'espere que le logiciel et la clé son créer et générer par toi.

[Deamon77]

oui mon problème est algorithmique, je ne vois pas du tout comment créer une clef sous la forme XXXX-XXXX-XXXX-XXXX
les tirets sont simples à rajouter mais se sont les X que je ne vois pas.
et pouvoir vérifier par l'algorithme inversé que ma clef est bonne

NB: le logiciel est crée par moi, et je souhaite créer un keygen pour envoyer une clef lors de l'achat du logiciel qui lui demandera la clef (d'où l'algo réversible)

[sovo]

tu dis que ta clé doit etre de la forme

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

XXXX-XXXX-XXXX-XXXX

, mais concretement, que represente ces X ?? JE veux dire comment tu fait pour avoir ces X ??

[Deamon77]

tu dis que ta clé doit être de la forme

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

XXXX-XXXX-XXXX-XXXX

, mais concrètement, que représente ces X ?? JE veux dire comment tu fait pour avoir ces X ??

X représente un caractère alphanumérique soit : 0-9 et a-z.

je m'excuse d'avoir mis autant de temps a répondre mais je n'ai pas eu le temps de revenir plus tot.

[jean.2edi]

A quoi sert ta clé ?
Il y a beaucoup de moyens de calculer une "validité" d'une clé plus ou moins longue, d'après sa forme (XXX-XXX etc...), une clé de Luhn, de la cryptographie plus ou moins compliquée, une combinaison de tout ça, etc... mais il y a d'autres questions ensuite :

• Est-ce que ta clé ne doit marcher que sur une machine ?
• Est-ce que tu veux empêcher l'utilisateur de comprendre comment marche ta clé ?

[f_aubertin]

Je ne suis pas du tout un expert en crypto, et ma solution n'est certainement pas élégante, mais elle devrait pouvoir marcher: tu peux créer une méthode de validation de clés se basant grosso modo sur le système utilisé pour les numéros de cartes VISA: tu appliques une transformation linéaire à chaque chiffre constituant ton nombre, tu fais une somme de tout cela et tu t'assures que le modulo par un nombre choisi soit bien 0.

Bien entendu, ceci est pour la validation, la question de la génération de la clé (qui est cruciale) reste entière. Et là, ça dépend du niveau de sécurité que tu veux. Mais si le logiciel s'adresse à des personnes ne connaissant rien en informatique, tu peux toujours générer des clés aléatoirement et les passer dans ton validateur, en prenant soin d'imprimer les clés correctes. Un example de code faisant cela:

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
 
private static long generateRandomKey() {
	return (long)(Math.random()*100000000.0);
}
 
private static boolean validateKey(long key) {
	long sum = 0;
	String keyStr = String.valueOf(key);
	for (char c : keyStr.toCharArray()) {
		byte element = Byte.parseByte(String.valueOf(c));
		sum += element+4;
	}
	return sum%15 == 0;
}
 
public static void main(String[] args) {
	long zeKey = generateRandomKey();
	while (!validateKey(zeKey)) {
		zeKey = generateRandomKey();
	}
	System.out.println(zeKey);
}

Bon maintenant, on est d'accord que si la clé doit être absolument infaillible, on est mal barré avec ce principe, car toute personne ouvrant ton fichier .class avec un soft de reverse-engineering peut avoir accès au validateur et écrire vite fait un programme qui génère des clés alétoires en imprimant les clés acceptées par ce validateur

[Invité]

Salut,
Une solution si le contenu de la clef n'est pas secret, mais doit juste ne pas pouvoir être changé par n'importe qui : Tu écris les données de ta clef, et tu signes ceci par un algorithme à clef publique (donc avec ta clef privée que tu es le seul à connaitre). Pour vérifier ta clef, tu vérifies que la signature donnée correspond bien à la clef entrée (ceci se fait par l'utilisation de la clef publique).
Bien sur ce principe rend difficile l'utlisation d'une clef au format XXXX-XXXX-XXXX-XXXX, mais se fait très bien avec un fichier clef, ce qui permet d'éviter en plus à l'utilisateur la perte de temps et source d'erreur de recopie de clef
Bon courage

[tchize_]

Bien sur ce principe rend difficile l'utlisation d'une clef au format XXXX-XXXX-XXXX-XXXX, mais se fait très bien avec un fichier clef, ce qui permet d'éviter en plus à l'utilisateur la perte de temps et source d'erreur de recopie de clef
Bon courage

Si les données sont assez courtes, un passage du flux binaire de la paire donnée-signature dans de l'encodage base64 te permet d'avoir un flxu de lettres Bien sur, si l'ensenble fait plus d'une 20aine de bytes, ca commencera a être dur pour tes utilisateurs à retapper

[Invité]

Si les données sont assez courtes, un passage du flux binaire de la paire donnée-signature dans de l'encodage base64 te permet d'avoir un flxu de lettres Bien sur, si l'ensenble fait plus d'une 20aine de bytes, ca commencera a être dur pour tes utilisateurs à retapper

Certes mais avec un principe de signature comme je l'ai dit on dépasse très vite la cingtaine d'octets Surtout si on utilise on container PKCS#7 (par exemple)