Discussion :

[Oberown]

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.

[Mose]

Faut le coder.

[joefou]

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.

[Mose]

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 ?

[joefou]

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

Code :

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

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 :

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

[Mose]

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

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
// 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();
}

[vladvad]

+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

[Thomas Lebrun]

Voila un truc intéressant à mettre dans la FAQ

[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

[SaumonAgile]

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

[vladvad]

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

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

D'ailleurs la clé, ça se stocke où, dans le registre ?

[vladvad]

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

[smyley]

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 ?

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# ...

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

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

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

après :

Code :

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

if(true){...}

[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

[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

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

[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

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

[smyley]

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