[C#] Comment créer une clé d'enregistrement

Version imprimable

Voir 40 message(s) de cette discussion en une page

29/09/2006, 17h19
Oberown

[C#] Comment créer une clé d'enregistrement

Comment faire pour protéger l'application, avec une clé d'enregistrement ?

L'utilisateur utilise pour la première fois le logiciel et il doit entrer un clé d'utilisation.
02/10/2006, 19h38
Mose

Faut le coder.
03/10/2006, 09h25
joefou

Citation:

Envoyé par Mose

Faut le coder.

+1

Pour ma part je fais référence au numéro de série du disque dur, par le biais d'une API, puis je fais ma cuisine avec un algo de codage/décodage pour avoir la clé de controle.
03/10/2006, 11h08
Mose

Citation:

Envoyé par joefou

Pour ma part je fais référence au numéro de série du disque dur, par le biais d'une API

Ah ouais ? Marrant :) C'est quelle API ?

Bon c'est en VB.NET, je la déclare comme ceci:

Code:

1
2
3
4
5
6
7
8
9
10
11
12
 
 
Private Declare Function GetVolumeInformation Lib "kernel32" _
        Alias "GetVolumeInformationA" ( _
        ByVal lpRootPathName As String, _
        ByVal lpVolumeNameBuffer As String, _
        ByVal nVolumeNameSize As Integer, _
        ByRef lpVolumeSerialNumber As Integer, _
        ByRef lpMaximumComponentLength As Integer, _
        ByRef lpFileSystemFlags As Integer, _
        ByVal lpFileSystemNameBuffer As String, _
        ByVal nFileSystemNameSize As Integer) As Integer

Et j'utilise dans la méthode suivante:

Code:

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
 
 
    Private Function ObtenirNumeroSerieDisquePoste() As String
        Dim root As String
        Dim volume_name As String
        Dim serial_number As Integer
        Dim max_component_length As Integer
        Dim file_system_flags As Integer
        Dim file_system_name As String
        Dim pos As Integer
        Dim Retour As String
        Try
            root = "c:\"
            volume_name = Space(1024)
            file_system_name = Space(1024)
 
            If GetVolumeInformation(root, volume_name, Len(volume_name), serial_number, max_component_length, file_system_flags, file_system_name, Len(file_system_name)) = 0 Then
                Throw New Exception("")
            Else
                Retour = serial_number.ToString()
            End If
        Catch ex As Exception
            m_Erreur += vbCrLf & "Problème de récupération d'information du volume" & vbCrLf & ex.Message
            Retour = ""
        End Try
        Return Retour
    End Function

Il y a surement d'autres façons de procéder, j'ai hérité ça d'un projet VB5. Peut-être qu'avec le Framework 2.0 on a ça tout de suite dans une classe qui va bien. ;)

Intéressant ! La même en C# pour les amateurs

Code:

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
// on importe le fonction GetVolumeInformation du moyau
[DllImport("kernel32.dll")]
private static extern long GetVolumeInformation(string PathName, StringBuilder VolumeNameBuffer, UInt32 VolumeNameSize, out uint VolumeSerialNumber, out uint MaximumComponentLength, out uint FileSystemFlags, StringBuilder FileSystemNameBuffer, UInt32 FileSystemNameSize);
/// <summary>
/// Récupère le numéro de série du volumne
/// </summary>
/// <param name="driveletter">la lettre d'un volume : 'c', 'd', ...</param>
/// <returns>le numéro de série du volume donné</returns>
public static string GetHddSerial(char driveletter)
{
	// le serial
	uint serial = 0;
	// nb max de fichiers sur ce volume
	uint nbfilemax = 0;
	// label du volume
	StringBuilder volumelabel = new StringBuilder(256);
	// volume flags. voir http://msdn.microsoft.com/library/default.asp?url=/library/en-us/fileio/fs/getvolumeinformation.asp
	uint volumeflags = 0;
	// nom du file system
	StringBuilder filesystemname = new StringBuilder(256);
	// chemin du lecteur
	string drivepath = driveletter + ":\\";
	// on appelle l'api
	long res = GetVolumeInformation(drivepath, volumelabel, (UInt32)volumelabel.Capacity, out serial, out nbfilemax, out volumeflags, filesystemname, (UInt32)filesystemname.Capacity);
	// on retourne le sérial
	return serial.ToString();
}

27/06/2007, 18h31
vladvad

Citation:

Envoyé par joefou

+1

Pour ma part je fais référence au numéro de série du disque dur, par le biais d'une API, puis je fais ma cuisine avec un algo de codage/décodage pour avoir la clé de controle.

Intéressant ! Et tu aurais quelques conseils sur le choix de l'algo de codage/décodage ??

Merci
27/06/2007, 18h54
Thomas Lebrun

Voila un truc intéressant à mettre dans la FAQ :)
27/06/2007, 22h16
dev01

Au passage je rappel que le framework embarque sa propre API pour gérer les licences ;)

http://msdn2.microsoft.com/fr-fr/lib...er(VS.80).aspx

A la base c'est utilisé pour les compos redistribuable mais bon ;)
28/06/2007, 08h55
SaumonAgile

Citation:

Envoyé par joefou

+1

Pour ma part je fais référence au numéro de série du disque dur, par le biais d'une API, puis je fais ma cuisine avec un algo de codage/décodage pour avoir la clé de controle.

Oui mais si le gars veux changer son disque ensuite ? Il se passe quoi ?
28/06/2007, 11h42
vladvad

Citation:

Envoyé par SaumonAgile

Oui mais si le gars veux changer son disque ensuite ? Il se passe quoi ?

Probablement qu'il faut regénérer une clé 8O

D'ailleurs la clé, ça se stocke où, dans le registre ?
29/06/2007, 17h35
vladvad

Citation:

Envoyé par joefou

+1

Pour ma part je fais référence au numéro de série du disque dur, par le biais d'une API, puis je fais ma cuisine avec un algo de codage/décodage pour avoir la clé de controle.

Question d'un novice en cryptographie :

J'imagine que ta clé de controle est forcément dans ton programme donc "facilement" lisible par un petit futé qui peut alors recréer l'algorithme de création des codes d'activation ? :roll:
30/06/2007, 04h26
smyley

Citation:

Envoyé par vladvad

J'imagine que ta clé de controle est forcément dans ton programme donc "facilement" lisible par un petit futé qui peut alors recréer l'algorithme de création des codes d'activation ? :roll:

Peut être qu'il faudrait que l'application en C# s'articule autour d'un module en C++ chargé de générer/vérifier les clefs ... vu qu'il est beaucoup plus difficile de décompiler du C++ ou de jouer dans l'asm que d'utiliser Reflector sur le C# ...
30/06/2007, 15h35
davcha

Dans tous les cas, un programme en MSIL qui ne serait pas obfusqué et qui serait sujet à license, ça fait rire, puisqu'il suffirait, même dans le cas où le programme s'articulerait autour d'un module en C/C++ gérant la license, de modifier le code MSIL, tout bêtement, du style...

avant :

Code:

if(licence.isValid()){....}

après :

Code:

if(true){...}
30/06/2007, 16h07
smyley

a moins ( mais c'est limite comme solution ) de coder l'interface en C# et les fonctions du programme en C++ natif ... avec des passerelles en C++/CLI. Celà me semble sur car le code exécutant réelement quelque chose est protégé par le C++ natif et en même temps on peut bénéficier de l'interface en .NET.
Cependant il serai fastidieux de faire une telle architecture :?
04/07/2007, 10h42
joefou

Houla, j'ai du retard sur la discussion moi, désolé ! ;)

Pour répondre à un peu toutes les questions:

Ma clé de contrôle se trouve effectivement dans le code, donc un petit malin qui sait jouer avec le code assembleur peut retrouver ça (d'ailleurs un pote l'a fait).

Ma clé, elle, se trouve consignée dans un fichier ini. Je recompare à chaque lancement de l'appli.

Si on change de disque dur, forcément le numéro de série change, et là il faut redonner une nouvelle clé.

C'est sûr c'est pas la panacée, mais comme je le disais, c'est du code qui date, tout fait à la main au burin :lol:
04/10/2007, 13h55
vladvad

Ce sujet est très intéressant et mériterait vraiment un petit tuto comme suggéré précédemment ...

Personne n'en a vu sur un autre site ? 8O
04/10/2007, 14h01
theMonz31

salut

à mon avis, un moyen un peu plus sur serait d'avoir une DLL en C++ classique non managé qui t'offre un truc du genre :

bool isKeyValid(string keyAEncoder);

Bon evidemment, on peut toujours "regénérer" une dll pour by passer le problème, mais rien n'empeche de vérifier dans le code de la dll sa signature ou un checksum de controle... ca en rebutera déja plus d'un :)

Apres, suffit un "bon" algorithme de cryptage dans la dll :)

EDIT : Autre solution envisageable ... on ne lance pas l'exe managé mais un EXe classique non managé, qui vérifie les données et ensuite, autorise l'execution du vrai exe par exemple...

Et cet exe pourrait etre "resident" pendant toute l'application ou vérifier le checksum de l'appli managé et si l'appli managé a été modifiée, que ca plante ou un truc du genre :)

Cela dit, aucune protection n'est "incassable".. surtout en managé ou il est facile d'aller modifier le code et de "recompiler" l'application :)

The Monz, Toulouse
04/10/2007, 14h21
ced600

Vous parliez de modifier à la main le code MSIL, mais MS n'a t il prévu des protection pour que le code ne puisse pas être lu ?
Parce que sinon facile de pomper l'algo de son concurrent !!!!

Pour récupérer le numéro de série d'un disque dur, je ne suis pas sur que tu sois obligé de passé par la dll Kernel32.dll, WMI peux le faire je crois, non ?

Pour la gestion de licence, d'installation unique, il existe plein de solution, une des meilleurs restent cela :
Ton prog génére une clé unique primaire, le client va sur un site web (ou le programme contact un serveur) et fournis la clé primaire, alors une clé secondaire est généré sur le serveur (et il peut vérifier si le soft en question a déjà été installé) et elle est renvoyé au programme qui la compare avec la clé secondaire qu'il a généré lui même.
04/10/2007, 23h11
smyley

Citation:

Envoyé par ced600

Vous parliez de modifier à la main le code MSIL, mais MS n'a t il prévu des protection pour que le code ne puisse pas être lu ?
Parce que sinon facile de pomper l'algo de son concurrent !!!!

Aucune méthode n'est présente nativement dans le .NET Framework pour contourner ce problème ou protéger le code : on peut seulement signer l'assembly pour ne pas que l'on puisse aisaiment changer les dlls d'une application donnée pour qu'elle fonctionne ( genre cracker l'appel à IsValid et recompiler la dll, car il faudrait le fichier utilisé pour signer l'assembly ) mais là encore on peut modifier en hexa la dll pour retirer la signature ...

Les seuls moyens purement .NET sont ceux utilisés par les obfuscateurs qui offrent un peut plus de protection, mais en général il s'agit juste de changer le nom des fonctions et des variabes ...

Voir 40 message(s) de cette discussion en une page