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 ??

[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)

[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é ?

[Deamon77]

quel est le principe de ces algorithmes?

le but est de protéger un logiciel, le client achète le produit et pourras installer le produit sur le nombre de machine qu'il le souhaite.
J'aimerais dans la mesure du possible faire un système que le client ne puisse pas comprendre afin de sécuriser un maximum cette clé.

je ne suis pas sur d'être très clair

[jean.2edi]

... un système que le client ne puisse pas comprendre afin de sécuriser un maximum cette clé.

Si tu fournis un programme Java, ton client peut toujours le décompiler et regarder comment il fonctionne. Si tu veux empêcher cela, ou plus exactement le rendre difficile, il faut que tu regardes les discussions au sujet de l'obfuscation...

Si ta clé marche (est valide) sur toutes machines, ton client pourra la donner à un autre... ou alors il faut que tu fournisses quelque chose de spécifique à chaque client qui sert au calcul de la validité de ta clé (un identifiant, un nom, un numéro de client...). Est-ce que tu fournis le programme au client spécifiquement, ou est-ce qu'il le télécharge ? Est-ce que tu peux enregistrer quelque chose dans le programme avant qu'il le télécharge ?

Pour la clé et l'algorithme, il y a en fait 2 familles : les symétriques et les assymétriques.

Assymétriques : à partir d'une information A (sous forme d'un nombre, de caractères, d'une suite de caractères avec des "-"...) tu calcules une information B et tu vérifies que l'information B que tu obtiens est celle que tu dois obtenir.
L'assymétrie signifie qu'il est très difficile de retrouver l'information A à partir de la B. Dans ton cas, sans pouvoir pré calculer A et B et noter B dans le programme de ton client, sans passer par un serveur, ce n'est pas très simple... Je ne vois pas de solution de chiffrement simple mais il faudrait réfléchir à la question...

Symétriques : la différence est qu'à partir de B on peut retrouver A, ce qui te permet d'avoir une seule information B pour tous tes clients et de générer autant de clés A que tu veux...

Algorithme :

• Tu peux décider que les clés sont sous la forme XXXX-XXXX-XXXX-XXXX : 16 caractères alphanumériques (mais attention zéros et O) avec 36 possibilités chacun : en théorie 7,9x10^24 ! C'est ton A.
• Tu calcules un nombre à partir de A, par exemple en remplaçant chaque caractère par son indice de 0 à 35, en multipliant chaque indice par sa position (1x pour le premier, 2X pour le deuxième...) et en faisant la somme.
  Si ta clé est AEBX-..., le résultat est 1x0 (A=0, B=1, C=2...) + 2x5 + 3x2...
• Tu dois obtenir un nombre entre 0 et 1x35+2x35+...16x35 = 4760 (si je ne me suis pas trompé).
• Tu décides que pour que ta clé soit valide, il faut que B soit égal à 1000 !!!
• Reste à générer des clés qui te donnent bien 1000, ce qui est le plus difficile. Le plus simple est de générer une clé au hasard, et de changer un caractère jusqu'à ce que ton information vaille 1000. Tu as une chance sur 4760 et ça doit aller vite avec un bon ordi. Je vais essayer de te coder ça...

Voilà, je n'ai pas le temps de réfléchir plus mais si j'ai des idées ou si tu as des questions...

[Invité]

Salut,
Je me permets une petite rectification sur ce que vient de dire jean.2edi :
Asymétrie signifie que la clef pour crypter est différente de celle pour décrypter, et symétrie, que une seule clef permet de faire les deux opérations. Il ne faut pas confondre avec les fonctions à sens unique (fonctions de hachage...). Donc avec un algorithme asymétrique, tu peux bien évidemment retrouver l'information de départ aussi, cf RSA le plus connu des algo asymétriques
Comme je l'ai dit plus haut il y a quelques temps : qu'est-ce qui importe ? que le client ne comprenne pas ce que dit la clef ? ou on se moque qu'il le comprenne, juste qu'il ne puisse pas la falsifier. Dans le deuxième cas, une signature par un procédé asymétrique est envisageable...
Tu signes le contenu avec ta clef privée, que tu es le seul à connaitre et tu mets la clef publique dans le programme pour vérifier cette signature et donc l'intégrité et la validité de ta licence...
Si tu distribues ton logiciel au cas par cas, genre pour des servers, à ip fixe, tu peux inclure l'IP dans ta licence, et dans ton programme tu vérifies que l'ip de l'ordi est celle de la licence, comme ta licence est signée, on ne peut pas changer l'ip sans casser la vérification de signature (ou alors si tu y arrives en un temps normal, bravo tu es riches et célébre, et tu mets tous le monde dans un beau bazard...).
Bref tout dépend de ce que tu veux de ta licence

[jean.2edi]

Bon, 5 minutes de test et de réflexion = modification !
Mon algo n'est pas terrible parce que la distribution des clés n'est pas uniforme : on va avoir un hash (info B) en moyenne vers 2000, très peu de petits nombres (vers 0) et de grands (vers 4700) ce qui est normal !
Il faut appliquer un modulo, ce qui donne moins de possibilités de clé et de hash mais de meilleurs résultats.
Voilà un petit test, avec un modulo de 997 et une valeur voulue ) 500 :

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
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
 
package cle;
 
import java.util.Random;
 
public class KeyGen {
 
	private static String CARS = "ABCDEFGHIJKLMNOPQRSTUVWXYZ0123456789";
	private static int TAILLE_CLE = 16;
	private static int MODULO = 997;
	private static int VOULU = 500;
 
	public static void main(String[] args) {
		new KeyGen().gen(1000);
	}
 
	private void gen(int i) {
		// Clé de départ
		Random random = new Random();
		StringBuilder sb = new StringBuilder();
		for (int j = 0; j < TAILLE_CLE; j++) {
			sb.append(CARS.charAt(random.nextInt(TAILLE_CLE)));
		}
		// boucle de recherche
		do {
			int hash = hash(sb.toString());
			System.out.println(sb + " :" + hash);
			if(hash == VOULU) {
				break;
			}
			sb.setCharAt(random.nextInt(TAILLE_CLE), CARS.charAt(random.nextInt(CARS.length())));
		} while(true);
	}
 
	/**
         * Calcule le hash de la clé, avec modulo
         * @param key
         * @return
         */
	private int hash(String key) {
		if(key == null || key.length() != TAILLE_CLE) {
			throw new IllegalArgumentException("Clé invalide: " + key);
		}
		key = key.toUpperCase();
		int n = 0;
		for (int i = 0; i < key.length(); i++) {
			char car = key.charAt(i);
			int index = CARS.indexOf(car);
			if(index == -1) {
				throw new IllegalArgumentException("Caractère de la clé invalide: " + car);
			}
			n += (i + 1) * index;
		}
		return n % MODULO;
	}
 
}

C'est assez rapide pour générer une clé...

[jean.2edi]

Merci George pur les précisions. Je parle de symétrique au lieu de bijective et je fournis un exemple sans trouver la fonction inverse !
La sécurité de mon code repose sur 2 choses : le client ne sait pas qu'il doit trouver 500 et il ne sait pas comment trouver 500 ! C'est faible...

[Invité]

Merci George pur les précisions. Je parle de symétrique au lieu de bijective et je fournis un exemple sans trouver la fonction inverse !
La sécurité de mon code repose sur 2 choses : le client ne sait pas qu'il doit trouver 500 et il ne sait pas comment trouver 500 ! C'est faible...

De rien
On a aussi l'habitude d ire qu'un algorithme de cryptage (ou assimilé) reposant sur le secret de l'algorithme en soi, n'est pas sur.
Je pense personnellement que le contenu d'une licence peut être connu de tous (sauf si des informations de la licences doivent rester secrètes, mais bon une date de validité, le nombre de postes autorisés, etc etc... ca n'a rien de secret), l'important étant que personne ne puisse générer une fausse licence, et parfois qu'on ne puisse pas donner la licence à un autre, d'où mon idée de signature électronique.

Pour ce qui est de ton algo, je pense qu'une erreur s'est glissée à cette ligne

Code :

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

1
2
 
sb.append(CARS.charAt(random.nextInt(TAILLE_CLE)));

car je ne vois pas pourquoi limiter le choix des caractéres à la taille de ta clef, je pense que tu voulais plutôt écrire ca :

Code :

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

1
2
 
sb.append(CARS.charAt(random.nextInt(CARS.length)));

Ensuite je ferais attention si je me lance dans la création d'une telle fonction car la sécurité est un domaine complexe et si le logiciel en vaut la peine des gens vont s'attaquer et assez rapidement trouver (surtout en Java comme tu as dit où une décompilation te donne facielement l'algo de hachage et le résultat à trouver...)

[jean.2edi]

Décidément, tu fais bien de me relire !
Ta correction est bonne, il faut bien sûr choisir parmi tous les caractères...

Pour l'algo, je suis d'accord : ce n'est qu'un bricolage qui ne trompera qu'un client qui ne cherche pas à casser la clé. Si on cherche à vendre le logiciel et à l'installer de manière industrielle, la seule solution est la cryptographie avec des algorithmes éprouvés. Mais sans connexion à un serveur qui garde la partie privée, comment faire ?
De plus, quelque soit la méthode, le client pourra toujours décompiler la partie qui décide si la clé est valide sans comprendre le calcul de cette validité ou supprimer cette partie. La protection passe alors par l'obfuscation...

Ensuite, on voit -- je ne citerai pas -- des programmes vendus (ou téléchargés) pour lesquels la clé est juste vérifiée localement. Si un utilisateur donne sa clé à un autre, elle est valide...

[Invité]

Justement l'intérêt des clefs publiques. Ces clefs sont faites pour être connue de toutes, et une signature est le fait que tu "cryptes" ton message avec ta clef privée connue de toi seul. Donc toi seul peux produire le résultat = licence.
Par contre tout un chacun peut vérifier (offline avec la clef publique écrite dans le programme), et vérifier que le résultat du texte "décrypté" est bien le résultat en clair. Tu donnes donc deux info : le texte clair normal du contenu de ta clef, et la signature.
Il existe d'autres côtés pervers ceci dit, quelqu'un pourrait modifier la clef publique dans le programme et comme ca générer ses propres licences, tu peux empêcher ca en isgnant ton appli, mais pourquoi ne pas resigner l'appli modifiée, bref tout est toujours possible mais à quel prix ensuite ? Ceci dit si tu obfusque ton code, ca commence à devenir duraille tout ca un code obfusqué et signé empêche déjà quelques personnes de faire des modifications, mais pas toutes

[Jimalexp]

Salut,

L'obfuscation devrais freiner un peu ceux qui auraient le savoir-faire pour contourner votre système. On peut déjà obfusquer le nom des attributs mais aussi transformer le code de sorte qu'il rende difficile le processus inverse (une méthode consiste à faire des JMP au dessus de lignes de code qui n'ont aucun effet).

Il faut savoir qu'il est également possible de faire du bytehacking sur une .class. Par exemple, une personne qui connais les bytecodes pourrait transformer un if( a == b ) en if( a != b) ou même changer le nom d'une méthode.

L'idéal c'est de restreindre au minimum le processus d'authentification dans l'application finale. Si vous avez la possibilité de générer une clé d'activation ou d'authentifier à distance, faites le. N'hésitez pas non plus à utiliser la réflection.