Algorithmes / methodes de generation de licenses

> J'aimerais connaitre les differentes methodes utilisées pour la
generation de clé d'activation de logiciels. Ex : Generation d'une
license d'activation d'un logiciel on utilisant le nom du client ....

Ceci est en fait un problème de cryptage. Pour des licences à clef, il y
a trois solutions : soit la clef est produite par le cryptage du nom du
client, soit par le cryptage du nom et d'un identificateur propre à
l'ordinateur (BIOS, disque, Windows, etc.). Il y a aussi le cas où la
clef est produite par le cryptage d'un numéro de série du CD. Ca ne vaut
rien, tout le monde peut copier et transmettre le code qui va avec (qui
n'a pas fait ça au moins une fois dans sa vie ?).

Avantage du 1er cas : le client peut changer de PC sans avoir à demander
une nouvelle clef de licence.
Inconvénient du 1er cas : le client peut faire des installations
multiples sous son nom, y compris chez le voisin.

Avantage du 2nd cas : chaque installation nécessite une clef ; vous
pouvez donc contrôler de façon étroite.
Inconvénient du 2nd cas : vous allez recevoir beaucoup de demandes
(changement de PC, de disque, de Windows).

Je pense que le 1er cas est à privilégier pour des logiciels à grande
diffusion, et tant pis pour les quelques fuites de la part de clients
indélicats qui installent chez un lointain voisin. Le mieux est
d'afficher en gros le nom du client correspondant à la licence, ça
freine un peu les téméraires. Il va de soi que le nom doit être vérifié
et correspondre à la facture pour éviter les noms générique genre "X".

Pour ce qui est du cryptage, faites preuve d'imagination, et surtout
utilisez une information redondante avec des vérifications partielles et
aléatoires. Une simple comparaison de deux données est facile à craquer.
Une vérification aléatoire sur des données multiples, stockées à
différents endroits et cryptées différemment devient plus difficile à
faire sauter, à moins d'y passer beaucoup de temps pour faire tous les
cas possibles. Les vérifications elles-mêmes peuvent s'opérer en
plusieurs étapes disséminées dans le programme plutôt qu'un test unique
au lancement. Bref, plus c'est dilué (données et vérification), plus
c'est pénible à craquer. Ca vaut aussi pour les dongles.

Bon, je devrais pas donner tous mes trucs...

> utilisez une information redondante avec des vérifications
partielles et aléatoires. Une simple comparaison de deux données est
facile à craquer.

Bref, plus c'est dilué (données et vérification), plus c'est pénible
à craquer. Ca vaut aussi pour les dongles.

En ce qui me concerne je minimise toujours le temps passé sur les
protections vu qu'elles finiront toujours par sauter :
* pour les petits logiciels, ils sont peu populaires donc une
protection toute naine suffit.
* si le logiciel se met à avoir du succès, peu importe la protection
elle sera contournée.

Pour la petite histoire j'ai par le passé écrit un logiciel à numéro
de série. Il y avait deux routines de vérification différentes qui
étaient utilisées à différents endroits du code (inline) et en
fonction de la parité du mois. Un crack est sorti 1 an plus tard qui
ne faisait sauter la protection que les mois pairs. Deux mois plus
tard le crack complet est sorti.

La moralité de l'histoire c'est que la protection toute simple m'a
fait gagner un an. De passer du temps à la rendre plus robuste m'a
fait gagner 2 mois.

Aujourd'hui je mets en place des protections qui me prennent un temps
minimal de développement mais l'objectif est de prendre une méthode
simple et de la présenter de façon à ce que le compilateur génère un
code différent à chaque fois de façon à obliger le cracker à traiter
tous les cas en particulier. En gros j'écris plusieurs routines de
vérification différentes sous forme de macro en saucissonant chaque
bout en plusieurs morceaux puis j'en saupoudre le code.

La faiblesse de cette méthode ce sera toujours qu'en mettant une
trappe sur la lecture des zones mémoire qui contiennent le numéro de
série on trouve rapidement les routines de vérification. Mais comme
elles sont dans des contextes différents, le compilateur génère un
code relativement varié qui oblige le cracker à passer du temps sur
chacune d'elles.

Ça vaut ce que ça vaut. Pas grand chose.
Mes deux cents d'euro.

--
cns

> La moralité de l'histoire c'est que la protection toute simple m'a
fait gagner un an. De passer du temps à la rendre plus robuste m'a
fait gagner 2 mois.

Oui, mais si vous aviez utilisé une méthode à 50 facettes différentes ou
plus, utilisées de façon aléatoire avec des probabilités d'appel de plus
en plus faibles, vous auriez peut-être gagné quelques années. C'est
certes du temps passé, mais après on n'y revient plus. Personnellement,
je n'utilise pas la date/heure comme source d'aléa. Trop facile à
repérer. Et pas non plus de code inline. Plutôt des copier/coller avec
quelques petites variations de style.

En gros j'écris plusieurs routines de
vérification différentes sous forme de macro en saucissonant chaque
bout en plusieurs morceaux puis j'en saupoudre le code.

Pour ma part, certaines fonctions de vérification n'opèrent pas en une
séquence, mais par petits bouts successifs au hasard de l'utilisation du
logiciel. Par exemple, on compte des étapes, et si le code passe par une
fonction du logiciel qui comporte une phase de vérification et que
l'étape correspond, on pousse à l'étape suivante. Ainsi, le code de
vérification ne se présente pas sous la forme d'une séquence mais des
dizaines de petits bouts, sans même qu'on puisse être sûr que le soft
fera le tour des étapes à chaqueutilisation. C'est très chiant pour le
hacker.

C'est comme ça que j'ai un soft qui contient plus de 200 séquences de
vérification dispersées dans tous les coins, agissant sur plus d'une
quarantaine de variables de formats variés, certaines ne servant qu'au
recoupement ou à transmettre des états de vérification. Faut dire que ça
m'avait énervé que des Popovs s'amusent à sortir un crack même limité il
y a quelques années. Ca s'est jamais reproduit.

La faiblesse de cette méthode ce sera toujours qu'en mettant une
trappe sur la lecture des zones mémoire qui contiennent le numéro de
série on trouve rapidement les routines de vérification.

Une solution consiste à faire des opérations sur des variables
redondantes dispersées et codées différemment. J'utilise de nombreuses
variables qui agissent en cascade, dont certaines sont modifiées par
d'autres fonction du soft, sans conséquence sur le test de licence,
histoire de brouiller encore les pistes. Et surtout, le plus important
est de ne jamais réagir immédiatement quand le soft détecte que la
licence n'est pas bonne ou qu'il y a eu bidouille. Attendre et réagir
plus loin, beaucoup plus loin, et toujours de façon indirecte.

Mais comme elles sont dans des contextes différents, le compilateur
génère un code relativement varié qui oblige le cracker à passer du
temps sur chacune d'elles.

Le but est évidemment que le hacker passe le plus de temps possible,
pour que ça soit le moins rentable possible de craquer le programme, et
aussi qu'il ne soit jamais sûr que son travail est achevé. D'où les
aléas avec probabilités décroissantes. Le tout est de bien disséminer
son code, d'élaborer des procédures de vérification dont la séquence est
le plus dilué possible, de maximaliser le nombre de modifications des
variables en jeu (la plupart bidons), et enfin de ne jamais réagir
immédiatement quand on a flairé le loup. L'idéal est de ne pas bloquer
le fonctionnement du soft craqué, mais faire en sorte qu'il marche MAL,
et tant pis pour sa réputation.

Quand j'étais étudiant, je me suis amusé avec les copains à craquer des
softs plus ou moins bien protégés. Je n'ai jamais rencontré un hacker
qui passerait trois mois pleins à déplomber la bête tout en n'étant
jamais sûr d'être vraiment arrivé au bout. Ca finit par lasser.

Une autre solution consiste à avoir un soft très évolutif. Les hackers
aiment les défis, pas la routine. Ils ne vont pas refaire le boulot tous
les trois mois.

Le 14-09-2004, Bertrand Lenoir-Welter <bertrand.2004@galaad.net> a ?crit?:

La moralité de l'histoire c'est que la protection toute simple m'a
fait gagner un an. De passer du temps à la rendre plus robuste m'a
fait gagner 2 mois.

Oui, mais si vous aviez utilisé une méthode à 50 facettes différentes ou
plus, utilisées de façon aléatoire avec des probabilités d'appel de plus
en plus faibles, vous auriez peut-être gagné quelques années. C'est
certes du temps passé, mais après on n'y revient plus.

Bof. J'y aurai passé beaucoup de temps qui a été mieux employé à
travailler les fonctionnalités du logiciel. Si votre solution vous
convient et qu'elle est efficace, tant mieux.

Quand j'étais étudiant, je me suis amusé avec les copains à craquer des
softs plus ou moins bien protégés. Je n'ai jamais rencontré un hacker
qui passerait trois mois pleins à déplomber la bête tout en n'étant
jamais sûr d'être vraiment arrivé au bout. Ca finit par lasser.

Héhé, ça vaut aussi pour l'écriture de protections ça.

--
cns

Je trouve cette discussion très intéressante, parce que je voudrais moi
aussi protéger "efficacement" mon soft...

Mais j'avoue ne pas avoir trop compris la méthode que tu emploies...

Je relirai ça demain à tête reposée, ça ira peut-être mieux ;)

@+

Bertrand Lenoir-Welter wrote:

Je pense que le 1er cas est à privilégier pour des logiciels à grande
diffusion, et tant pis pour les quelques fuites de la part de clients
indélicats qui installent chez un lointain voisin. Le mieux est
d'afficher en gros le nom du client correspondant à la licence, ça
freine un peu les téméraires. Il va de soi que le nom doit être
vérifié et correspondre à la facture pour éviter les noms générique
genre "X".

Tu parles. Tu spy la mémoire du processus qui tourne, tu repère la chaîne de
caractère et tu patches avec le tien, au pire tu automatise la chose avec un
bout de code planqué à la fin d'une section du tien. Ou un hook externe pour
les débutants :-).

Pour ce qui est du cryptage, faites preuve d'imagination, et surtout
utilisez une information redondante avec des vérifications partielles
et aléatoires. Une simple comparaison de deux données est facile à
craquer. Une vérification aléatoire sur des données multiples,
stockées à différents endroits et cryptées différemment devient plus
difficile à faire sauter, à moins d'y passer beaucoup de temps pour
faire tous les cas possibles. Les vérifications elles-mêmes peuvent
s'opérer en plusieurs étapes disséminées dans le programme plutôt
qu'un test unique au lancement. Bref, plus c'est dilué (données et
vérification), plus c'est pénible à craquer. Ca vaut aussi pour les
dongles.

Moi, je n'ai jamais rien vu d'incraquable. Le temps que tu vas y passer est
proportionnel à l'intérêt de la chose, voire à la somme qu'on te paie pour
craquer le truc :-).

Crypter avec des critères matériels est sympa, mais engendre un tas de
problèmes énormes. De plus, tu ne peux pas prévoir les avancées en mantière
de hacking, quel que soit l'algorithme utilisé. Ton truc au hasard là, ça se
craque. C'est au pire une question de temps. Rien ne dit qu'on ne peut pas
le dérouter non plus. Voire créer un keygen en externe. Bref.

Moi, plutôt que d'empêcher les copies, je préfère qu'on ne puisse pas
copier/étudier mon code. Protéger un logiciel, s'il fait de grosses ventes,
un jour ou l'autre il sera craqué. Il suffit que cela en vaille la peine.
Or, écrire une protection efficace, ça prend du temps. Si tu rends ton code
illisible, au moins, tu évite le vol d'idée, à mon avis c'est plus rentable.
Mais c'est mon avis.

Bon, je devrais pas donner tous mes trucs...

Oh, tu saiss, il y a des forts/rusés en cracks, tiens un exemple :
http://www.crackmes.de/ Fouille un peu, il y a des cadors.

A+

--
AMcD®

http://arnold.mcdonald.free.fr/

> Tu parles. Tu spy la mémoire du processus qui tourne, tu repère la chaîne de
caractère et tu patches avec le tien, au pire tu automatise la chose avec un
bout de code planqué à la fin d'une section du tien. Ou un hook externe pour
les débutants :-).

Hé hé, bon courage pour trouver la chaîne. Ou plutôt les chaînes puisque
je suis pas assez couillon pour la stocker à un seul endroit, même
cryptées avec des algos différents. Tu peux chercher autant que tu veux
dans la mémoire, bon courage, surtout quand le code est gros.

Moi, je n'ai jamais rien vu d'incraquable. Le temps que tu vas y passer est
proportionnel à l'intérêt de la chose, voire à la somme qu'on te paie pour
craquer le truc :-).

J'ai jamais dit que c'était incraquable. Seulement que s'il faut y
passer des mois au minimum, et en plus sans garantie de la stabilité du
résultat (les vérifs aléatoires de plus en plus rares qui interviennent
une fois tous les 50 lancements, qui font que le hacker ne peut jamais
savoir s'il a fait le tour du sujet), bref ça peut pas mal freiner les
enthousiasmes.

Crypter avec des critères matériels est sympa, mais engendre un tas de
problèmes énormes. De plus, tu ne peux pas prévoir les avancées en mantière
de hacking, quel que soit l'algorithme utilisé. Ton truc au hasard là, ça se
craque. C'est au pire une question de temps.

Le temps que tu y arrives, j'aurai déjà une ou deux versions d'avance
sur le marché.

Bertrand Lenoir-Welter wrote:

Hé hé, bon courage pour trouver la chaîne. Ou plutôt les chaînes
puisque
je suis pas assez couillon pour la stocker à un seul endroit, même
cryptées avec des algos différents. Tu peux chercher autant que tu
veux
dans la mémoire, bon courage, surtout quand le code est gros.

Oui ben, à un moment donné faut bien que tu l'affiches ta chaîne, je hooke
la fonction DrawText(), TextOut(), bref celle qui faut et voilà... C'est pas
où est stockée ta chaîne qui m'intéresse, c'est le moment où tu l'affiches
:-).

Le temps que tu y arrives, j'aurai déjà une ou deux versions d'avance
sur le marché.

Bien sûr... Ce sont les gars aussi sûr d'eux que tu l'es qui font rire tous
les hackers :-).

Dis, t'as déjà fait du crack professionnel au moins ? Je parle pas de faire
du noping ou des guignolades à la Hackademyztrucsbidule hein. Du vrai de
vrai, genre virer 50 couches de layers d'obfuscation de code, dérouter un
moteur poly et autre jouyeusetés ? Tu sais, on sait/peut faire beaucoup de
chose. Ce n'est pas parce que toi t'es impressionné par ta méthode ou que tu
ne saurais pas la craquer que d'autres ne sauront pas le faire...

A+

--
AMcD®

http://arnold.mcdonald.free.fr/

D'après AMcD®:

Dis, t'as déjà fait du crack professionnel au moins ? Je parle pas de
faire du noping ou des guignolades à la Hackademyztrucsbidule hein.

Tiens, au fait, ils existent encore ceux là ?

David MAREC wrote:

D'après AMcD®:

Dis, t'as déjà fait du crack professionnel au moins ? Je parle pas de
faire du noping ou des guignolades à la Hackademyztrucsbidule hein.

Tiens, au fait, ils existent encore ceux là ?

Oui. Soyons justes, ils ont bien évolués depuis les "nike les pass des meufs
sur MSN" d'il y a deux ans. Il y a même parfois un truc potable. Mais bon,
les 3/4 c'est du pompé sur le Net et tu te demandes si le gars qu'a écrit le
texte y comprend quelque chose...

Puisqu'on en parle, il existe une revue récente, appelée hackin9, qui me
semble pas mal du tout et qui est du même tonneau que MISC. Si vous voyez un
numéro, essayez, c'est pas mal du tout.

Tant qu'on y est un petit lien pour les fanas tiens :
http://www.rootkit.com/index.php

A+

--
AMcD®

http://arnold.mcdonald.free.fr/