Discussion :

[Oliv-]

Bonjour,
Justement le but serait que ce soit très peu lisible !

genre comme 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
Private Function eeeeeeeeeeeeeeee%(eeeeeeeeeeeeeeeee$)
Dim eeeeeeeeeeeeeeeeee&, eeeeeeeeeeeeeeeeeee&, eeeeeeeeeeeeeeeeeeee&
eeeeeeeeeeeeeeeeeee = InStrRev(eeeeeeeeeeeeeeeee, dddddddddddd(eeeeeeeeeee)) + 2
eeeeeeeeeeeeeeeeee = InStr(eeeeeeeeeeeeeeeeeee - eeeeeeeeee, eeeeeeeeeeeeeeeee, dddddddddddd(eeeeeeeeeeeee)) + 2
eeeeeeeeeeeeeeee = eeeeeeeeeeeeeeeeee > 2
If eeeeeeeeeeeeeeee Then
eeeeeeeeeeeeeeeeeeee = InStr(eeeeeeeeeeeeeeeeee, eeeeeeeeeeeeeeeee, dddddddddddd(eeeeeeeeeeeeee))
eeeeeeeeeeeeeeee = eeeeeeeeeeeeeeeeeeee > eeeeeeeeeeeeeeeeee And eeeeeeeeeeeeeeeeeeee < eeeeeeeeeeeeeeeeeee
End If
If eeeeeeeeeeeeeeee Then
eeeeeeeeeeeeeeeeeeee = InStr(eeeeeeeeeeeeeeeeee, eeeeeeeeeeeeeeeee, dddddddddddd(eeeeeeeeeeee))
eeeeeeeeeeeeeeee = eeeeeeeeeeeeeeeeeeee > eeeeeeeeeeeeeeeeee And eeeeeeeeeeeeeeeeeeee < eeeeeeeeeeeeeeeeeee
End If
If eeeeeeeeeeeeeeee Then eeeeeeeeeeeeeeeee = Left$(eeeeeeeeeeeeeeeee, eeeeeeeeeeeeeeeeee - 1) & String(eeeeeeeeeeeeeeeeeee - eeeeeeeeeeeeeeeeee, " ") & Mid$(eeeeeeeeeeeeeeeee, eeeeeeeeeeeeeeeeeee)
End Function

[Invité]

Effectivement et même le développeur en charge de l'adapter

[baouie]

Bonjour,

Je me permets de déterrer ce post. En effet je cherche à créer un système de licence et j'ai utilisé le code proposé par rdurupt. Toutefois, cela ne fonctionne pas correctement. En effet, je réussis à générer une clé de produit mais lorsque je saisis la clé de licence il ne la reconnait pas. En regardant plus en détails, je crois qu'il n'enregistre pas les informations dans la base de registre. J'ai rajouté win10 au code pour la recherche de la version. Je vous serai reconnaissante de bien vouloir m'aider à trouver une solution.

[clementmarcotte]

Maintenant, avant d'écrire dans le registre, il faut modifier les options de sécurité de la clef concernée. Cela peut se faire avec l'éditeur de registre lancé en administrateur.

[Invité]

Bonjour Baouie et Clément,

Oui pour écrire dans la base de registre il faut exécuter Excel en tant qu'admin.

C'est valable comme pour toute installation de logiciel. Une fois la clé installé on peut ouvrir Excel normalement!

[baouie]

Je vous remercie pour vos retours mais je n'y arrive toujours pas...c'est la première fois que je cherche à écrire dans un registre. J'ai fait un regedit puis j'ai rajouté la clé comme ci-dessous. Faut-il faire autre chose ou me suis-je complètement gourée?

[Invité]

l'application prend ça en charge, il faut les droits admin le temps de la registration dans la base de registre!
les clé sont crypté la créer toi même ne fonctionneras pas! c'est bien le but de ce code c'est possible de le contourner mais il faut arriver à le comprendre!

l’application collecte des informations sur l'ordinateur, les hache ou les crypte pour générer un N° de produit qui repasse ensuite dans un autre moulinette pour qualifier le N° de licence!

tu n'as as à bricoler la base de registre!

l'idée n'est pas de faire un gestion incontournable, car ce n'est pas possible dans Excel, mais d'insérer une validation de la licence le plus souvent que possible afin que le code soit plus rapide à réécrire qu'a débrider!

[patricktoulon]

salut robert
en quoi c'est sécurisant ou presque importable d'avoir le code d'encryptions dans le fichier

perso to idée est bonne
récupérer des données utilisateur les envoyer au fournisseur qui calculera un numéro sur ses données et renverra un code licence sous forme de ".reg" ou autre
que l'utilisateur inscrira lui même

le calcul et l'algorithme d'encryptions reste le secret du fournisseur

cela dit comment masquer les conditions sur ce code dans le fichier

ou alors distribuer un fichier beta(version démo) qui récoltera les données utilisateurs
les enverra au fournisseur
qui lui renvoi ra un fichier définitif avec password fichier et exploration de code ou pas pour le second
comme ca pas de base de registre
pas de code

seulement un fichier avec mot de passe

[baouie]

Cela fonctionne à présent. Il y'avait un problème au niveau du module Licence.bas....sans doute je n'avais pas la dernière version.
Je me suis permise d'écrire directement dans le registre d'après ce que j'avais compris du post de Clement car cela ne fonctionnait pas malgré le fait d'être en admin...
Un grand Merci !!!

[Invité]

bonjour Patrick,

et oui le if LicenceOk est contournable!

faire un code bordélique comme le propose oliv poste #41 ?

valider la licence toutes les trois ligne de code? bien que ça ralentisse le déroulement du code?

faire une dll comme je le propose dans un autre discutions?

https://www.developpez.net/forums/d1...l/#post8938804

[camillenze]

Bonjour
j'ai eu envi de faire aussi une licence pour un fichier excel. j'ai utilisé le code de Robert mais ça me dit toujours que la licence n'est pas correct.. "Petit malin"
est ce la faute de ma version Windows ?? Au fait je jai Windows 8

[Invité]

Bonjour,

L'outil va écrire dans la base de registre de Windows. Il faut impérativement ouvrir excel en tant qu'admin au moins le temps de "installation" du logiciel!

L'application commence par écrire dans la base de registre une information lié à l'ordinateur et la date.

Suis un échange entre le client et son fournisseur; le fournisseur retourne la licence; et l'application écrit la licence dans la base de registre!

Sens droits admin pas d'écriture vue que tout est basé sur les informations collectées et la date et heure de la registration, impossible de fournir le bon numéro de licence!

Il ne suffit pas toujours être sur un session Windows admin pour qu'excel s'exécute en tant qu'admin!

[camillenze]

Bonjour
Impeccable !! ça marche fort. merci.

[Gorzyne]

si je peux me permettre

comme chacun sait, excel vba n'est pas fiable pour la propriété intellectuelle

le code vba est accessible facilement par plusieurs méthodes

jusqu'à récemment les feuilles excel étaient également facilement crackable

celà dit depuis excel 2016, la protection des onglets et classeurs est beaucoup plus robuste.

pour ma part c'est cette solution que j'ai retenu pour mes applications commerciales.

l'idée est effectivement d'utiliser le numéro du disque dur, (mais une approche par base de registre est sans doute envisageable aussi, bien que plus contraignante)

l'activation est quand à elle contenue dans une formule excel dont la propriété n'est pas seulement fixée à verrouillée mais également à masquée sinon ça sert à rien

j'ai fait des tests, effectivement c'est impossible de cracker une feuille excel protégée depuis une version 2016, car le mot de passe n'est plus stocké en binaire

il faut donc pour cracker l'onglet utiliser un brute force, ou dico... ce qui peut être très long avec un bon mot de passe....



je ne sais pas si c'est la protection ultime, mais disons que pour protéger sérieusement un outil (empêcher sa diffusion incontrôlée) il faut effectivement lier une formule excel au numéro de HDD+clé d'activation...

si l'utilisateur accède au code vba, il verra juste que le programme va écrire le numéro de HDD quelque part, mais si vous faites bien le travail, il ne pourra accéder à la formule de la cellule Excel qui contient la résolution


évidemment si votre programme est en full vba, vous ne pourrez rien faire, votre code continuera à être accessible.

par contre si votre outil contient suffisamment d'excel, vous pouvez bloquer l'outil ou autoriser l'accès, de façon robuste.

hésitez pas à me poser des questions si c'est pas clair

par ailleurs, évidemment cette approche doit être couplée avec une offuscation du code vba, après ça dépend évidemment de la sensibilité de ce que vous voulez protéger, mais si c'est un truc important qui coûte cher dans ce cas oui suivez mon conseil

CONCLUSION: une protection qui ne reposerait que sur du code vba, pourra facilement être contournée en modifiant le code vba verrouillant l'application

• verrouillage onglet depuis version Office 2016 uniquement
• cellule de résolution dans une formule excel protégée verrouillée masquée
• une partie incontournable de l'outil doit également être contenue dans Excel (il faut pas que le seul code vba puisse permettre de faire tourner l'outil, ni que l'on puisse imaginer ce qui se passe dans les cellules verrouillées protégées masquées)
• un bon mot de passe (16 caractères utilisant des caractères spéciaux, chiffres et majuscules)

NB: autre point important, l'onglet qui contient la résolution de l'activation doit être protégé depuis Excel 2016, mais peut ensuite être utilisé depuis une version antérieure, sans que cela altère la qualité de la protection
par contre, c'est sans effet sur la protection VBA qui est toujours aussi bidon quelque soit la version à partir de laquelle elle a été protégée

NB2: cette approche doit pouvoir également être utilisée avec la variante de base de registre, mais le principal est que l'élément fort de la protection se situe dans une formule excel protége verrouillée masquée (masquée est très important sinon il suffit de modifier la propriété depuis vba pour accéder à .Formula donc bon^^)

=> attention il y a quand même une faille, liée au fait qu'à partir d'un outil activé, on puisse le transmettre en l'état en court-circuitant le processus de réactivation. On peut cependant jouer avec le recalcul pour forcer le test de l'activation à chaque utilisation...

[Invité]

Bonjour Gorzyne,

désolé pour celui qui t'as mis -1!

en fait tout ce qui as été dit sur la sécurité reste valable!


la notion de sécurité reste une notion subjective et dans le cas de cette source une dissuasion! pour une vrai sécurité il faut créer une DLL qui encapsule tout le code des macros et un web service pour valider les licences!

cette source récupère le N° du disque dur, l'adresse Map du Pc la date et heure du système et génère un hachage Md5 qui est registré!

[Gorzyne]

Bonjour Gorzyne,

désolé pour celui qui t'as mis -1!

en fait tout ce qui as été dit sur la sécurité reste valable!


la notion de sécurité reste une notion subjective et dans le cas de cette source une dissuasion! pour une vrai sécurité il faut créer une DLL qui encapsule tout le code des macros et un web service pour valider les licences!

c'est pas grave ça m'arrive souvent de me prendre des -1 quand je dis des choses compliquées et qui peuvent sembler confuses

ce que je veux dire c'est que si on veut rester en full excel/vba, la seule solution vraiment robuste est celle que je décrit.
j'ai beaucoup étudié le sujet car je diffuse un logiciel unique au monde que des grands cabinets rêvent de pouvoir cracker... aussi j'ai vraiment cherché la meilleure solution, tout en prenant en compte les contraintes des utilisateurs (pas de mode admin, etc...)

après évidemment si on part dans les DLL c'est une autre histoire

[Invité]

Bonjour,

Ce sujet est vraiment intéressant ! Je ne pensais pas qu'on pouvait protéger une application VBA sous Excel à ce point. Je préfère généralement codé en C# étant donné qu'il est plus simple (et fiable) de diffuser son code par la suite sans rencontrer de problème de sécurité. Cependant, savoir qu'il existe aussi une très bonne alternative en VBA est vraiment une bonne chose !

Merci à vous !

[Gorzyne]

Bonjour,

Ce sujet est vraiment intéressant ! Je ne pensais pas qu'on pouvait protéger une application VBA sous Excel à ce point. Je préfère généralement codé en C# étant donné qu'il est plus simple (et fiable) de diffuser son code par la suite sans rencontrer de problème de sécurité. Cependant, savoir qu'il existe aussi une très bonne alternative en VBA est vraiment une bonne !

Merci à vous !

Attention je dirai pas que c'est une bonne alternative, c'est même une solution bancale et assez fastidieuse à mettre en place, mais à mon sens c'est la seule qui permettre vraiment de protéger un outil excel.vba
à savoir qu'on ne protège en aucun cas la partie "vba" du code, par contre on peut réussir à bloquer l'utilisation, pour peu qu'il y ait suffisamment d'Excel pour rendre incontournable la partie Excel de l'outil, et qu'on ne soit pas en mesure de reconstituer les fonctionnalités de la partie Excel, par induction.

attention on ne protège également pas les éventuelles base de données qui pourraient se trouver dans des onglets, même cachés. En effet, une simple "photocopie" du classeur permet de récupérer toutes les valeurs de tous les onglets du classeur, même ceux en very hidden. La seule chose qu'on peut protéger décemment, ce sont les formules Excel, et c'est donc la l'idée, c'est de faire dépendre une partie de l'utilisation du logiciel d'une formule excel, qui contient une clé de résolution issue de votre imagination.

pour résumer
code vba=> pas de protection possible en dehors de l'offuscation
base de donnée=> aucune protection
formules excel=> protection possible depuis Excel 2016 exclusivement

[Invité]

Attention je dirai pas que c'est une bonne alternative, c'est même une solution bancale et assez fastidieuse à mettre en place, mais à mon sens c'est la seule qui permettre vraiment de protéger un outil excel.vba
à savoir qu'on ne protège en aucun cas la partie "vba" du code, par contre on peut réussir à bloquer l'utilisation, pour peu qu'il y ait suffisamment d'Excel pour rendre incontournable la partie Excel de l'outil, et qu'on ne soit pas en mesure de reconstituer les fonctionnalités de la partie Excel, par induction.

attention on ne protège également pas les éventuelles base de données qui pourraient se trouver dans des onglets, même cachés. En effet, une simple "photocopie" du classeur permet de récupérer toutes les valeurs de tous les onglets du classeur, même ceux en very hidden. La seule chose qu'on peut protéger décemment, ce sont les formules Excel, et c'est donc la l'idée, c'est de faire dépendre une partie de l'utilisation du logiciel d'une formule excel, qui contient une clé de résolution issue de votre imagination.

pour résumer
code vba=> pas de protection possible en dehors de l'offuscation
base de donnée=> aucune protection
formules excel=> protection possible depuis Excel 2016 exclusivement

Au final, il reste compliqué de créer un logiciel sous Excel qui a pour but d'être commercialisé sans prendre de risque. Je vais donc me contenter de créer des outils interne à mon entreprise en VBA. Au passage, est-ce que le choix d'un langage de programmation peut être influencer en fonction de la sécurité de l'outil ? Est-ce qu'un outil programmer en Java aura la même sécurité qu'un outil programmé en C# (on peut faire cette comparaison avec tout les langages de programmation) ?

[Invité]

si on prend c# comme tu à 'air de connaitre, il existe un décomplimenteur payant chez Microsoft! mais ça reste quad même plus sécurité!

personnellement je fais du VB.net; mes application sont à usage interne et arbitré par l'Active Directory!

plus haut j'ais parlé d'un web service là on envoi une requête à un serveur web qui retourne si la licence est valide ou pas!

dans vba quelque soit la complexité du traitement la validation de la licence ce résume presque invariablement par un True/False d'ou ce que je disais dissuasif!