Discussion :

[CognitiKom]

Bonjour

Comme je l'indiquais dans un autre message, je suis en train d'"obfusquer" mon code pour éviter son "piratage".
Pour compléter le tout, je souhaite mettre en place une protection contre la recopie par le biais notamment de l'utilisation de la "mac address" du poste de travail.
Pour compliquer la tache de mes éventuels pirates () et puisque l'obfuscation ne fait pas tout, je voudrais remplacer certains termes "évidents" par des chaînes de caractères définies ailleurs.
Je m'explique sur un exemple avec une fonction telle que celle-ci :

Code :

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

1
2
3
4
5
6
7
8
9
10
11
12
13
14
  Function MacAdressCourante()
        Dim objVMI As Object
        Dim vAdptr As Variant
        Dim objAdptr As Object
 
        Set objVMI = GetObject("winmgmts:\\" & "." & "\root\cimv2")
        Set vAdptr = objVMI.ExecQuery("SELECT * FROM Win32_NetworkAdapterConfiguration WHERE IPEnabled = True")
        For Each objAdptr In vAdptr
            If objAdptr.MACAddress <> "" Then
                MacAdressCourante = objAdptr.MACAddress
                Exit For
            End If
        Next objAdptr
    End Function

Pour éviter que "objAdptr.MACAddress" ne se voie comme le nez au milieu de la figure, je voudrais (je simplifie) définir plusieurs constantes (a="objad": b="ptr.MACAd":c="dress") définies "ailleurs" et écrire quelque chose du genre :
MacAdressCourante=Evaluate(a&b&c)
mais ça ne marche pas, pas plus d'ailleurs que MacAdressCourante=Evaluate("objAdptr.MACAddress")... J'obtiens une erreur 2029.

Pouvez-vous m'aider, s'il vous plait ? Est-ce simplement Evaluate qui ne marche pas comme je le crois ?

Merci d'avance
Gilbert

[Marc-L]

Bonjour, bonjour !

Tout ce que tu entreprends est facilement contournable pour quelqu'un d'un peu expérimenté …

Sinon, as-tu lu l'aide VBA interne concernant cette méthode Evaluate ?!
Elle n'évalue qu'au niveau d'Excel comme par exemple une formule de calculs ou encore la valeur d'une cellule nommée …

______________________________________________________________________________________________________
Je suis Paris, Charlie, …

[CognitiKom]

Bonjour Marc

Je ne suis pas certain que comprendre plus de 45 000 lignes de VBA (hors lignes blanches et commentaires) dans lesquelles près de 2500 noms de variables, de types, de constantes, de procédures / fonctions, mais aussi les noms des formulaires, des modules, des shapes et autres "controls" sont remplacés (Cf. exemple ci-dessous) soient des plus faciles à comprendre. Je suis moi-même totalement incapable de suivre le code "obfusqué" en pas à pas, même en ayant ma "table de renommage" à côté...
En plus, je ferai en sorte que chaque version que je livrerai soit "obfusquée" avec des noms différents.



Cela étant, oui j'ai découvert que "Evaluate" n'évaluait que de l'Excel et donc c'est râpé : merci de ta confirmation !
Et passer par du VbScript ?

En fait, pour revenir à mon idée de base je voudrais :

1. écrire un morceau de code dans lequel on ne verrait pas directement que je cherche la "macaddress" (d'où mon idée d'écrire la ligne de commande dans plusieurs constantes, elles-mêmes légèrement chiffrées et que je déchiffrerais et concaténerais quand j'en aurais besoin)
2. multiplier ce morceau de code dans mon programme pour "noyer le poisson"
3. ne pas interrompre le programme immédiatement quand je constaterai que la MacAddress est fausse (pour rendre difficile l'identification de la fonction qui identifie l'anomalie) et probablement ne pas mettre de message d'erreur explicite (style "Vous utilisez probablement une copie illicite de SÆCI RS") mais plutôt faire en sorte que le programme se plante pour une raison x ou y aléatoire.

J'ai tout à fait conscience que je suis dans Excel, mais en attendant de récrire mon programme (dans quel langage d'ailleurs ??), je voudrais le protéger au maximum de ce que je peux.
Je suis donc preneur de toute bonne suggestion

Merci d'avance
Gilbert

[joe.levrai]

Bonjour,

un code obfusqué ... oui c'est plus compliqué à déchiffrer, on va dire que ça multiplie le temps par 2 ou 3, mais pas plus pour quelqu'un qui sait organiser cette opération !
on peut même, par manipulation de VBE via une macro, réaliser 80% du boulot

enfin, je vais pas non plus donner des pistes, ça serait pas malin voir dangereux, mais je laisse d'autres contributeurs confirmer ce que j'énonce.

Et j'anticipe LA question : oui je l'ai déjà fait (un mauvais garçon qui avait quitté une société en mauvais termes et qui s'est cru malin à obfusquer un outil important), avec en plus un classeur protégé, un projet verrouillé etc... Au final une seule procédure a carrément mal été dechiffrée et j'ai dû débugger à la main ... mais ce fut facile car le reste était "clair".

[CognitiKom]

Bonsoir Joe

Pour le coefficient multiplicateur, je ne sais pas. Au pif, j'aurais annoncé au moins 10 fois plus, car le code "en clair" est, en soi, plutôt compliqué, même avec des noms de variables, constantes, fonctions, etc. très explicites (j'essaye de faire en sorte que le programme se lise un peu "comme un roman"). Compliqué parce que le sujet lui-même est compliqué (je ne crois pas que l'outil que je développe ait d'équivalent sur le marché).
D'ailleurs, en toute honnêteté, à supposer que je fasse une pause de 2 à 3 mois, je ne suis pas certain que je pourrais comprendre ce que fait le programme en ayant seulement le code obfusqué, et pourtant ça fait près de 15 mois que je bosse dessus, 7 j / 7, entre 15 et 17 h / j.

Reste ma question actuelle : comme exécuter du code en minimisant la possibilité que ça se voie...

Gilbert

[eriiic]

Bonjour,

Joe.levrai t'a donné la réponse à l'insu de son plein gré :-)

on peut même, par manipulation de VBE via une macro ...

à toi d'imaginer la suite.
eric

[Marc-L]

mais je laisse d'autres contributeurs confirmer ce que j'énonce.

Je pensais l'avoir déjà fait !

Je confirme, l'obfuscation n'est pas une protection en soit mais juste un ralentisseur !
Certes cela peut décourager le tout venant mais pour d'autres, c'est un challenge !
J'ai remarqué les codes obfusqués à la base bien pensés, bien écrits étaient plus faciles à décrypter
que les codes moins efficaces écrits par des bourrins (ou de manière volontaire) ou pratiquant le dirty code …

Une protection efficace en VBA ? Oui, si externe au VBA !
Par exemple une application VB / VB.net / Visual Studio pilotant Excel, peut-être via une dll …

J'ai déjà codé une procédure dans un fichier en VBScript pilotant Excel pour arranger une connaissance
et c'est suffisant tant que le pot aux roses n'est pas découvert … Mais pas envisageable dans un contexte commercial !

Joe a utilisé un code VBA pour désobfusquer lui ayant certainement fait gagner du temps (et ce n'est pas très compliqué à coder) …

Comme l'obfuscation en VBA est revenue à la mode depuis Office 2010 et avec la confirmation de la version 2013 en force
via les virus et autres malwares, il y a donc des outils disponibles pour éclaircir dirais-je les codes VBA ou autres …
Même s'ils ont été créés à des fins de sécurité évidente, ils peuvent servir à loisir à d'autres desseins !

Extrait du tutoriel de ce site de Hugo Etiévant concernant l'obfuscation dans son chapitre consacré à ses limites :
« La sécurité par l'opacité est un mythe !
L'obfuscation protège le code source contre la piraterie intellectuelle durant un temps assez court. »

Et dans sa conclusion :
« L'obfuscation ne peut être vue comme une solution durable pour la protection de la propriété intellectuelle
d'autant que la qualité et les performances d'une application obfusquée vont être sérieusement dégradées. »

[clementmarcotte]

Bonjour,

Une protection efficace en VBA ? Oui, si externe au VBA !
Par exemple une application VB / VB.net / Visual Studio pilotant Excel, peut-être via une dll …

Pas vraiment plus sécuritaire en .net. Tout assembly (dll ou exe) .net peut être désassemblé le plus facilement du monde avec l'outil approprié. Il y a même un dans le Framework.