VERROUILLER DEFINITIVEMENT VBA
Brosske
Messages postés
98
Date d'inscription
jeudi 25 novembre 2004
Statut
Membre
Dernière intervention
12 août 2010
-
3 sept. 2006 à 20:35
us_30 Messages postés 2065 Date d'inscription lundi 11 avril 2005 Statut Membre Dernière intervention 14 mars 2016 - 20 sept. 2006 à 22:11
us_30 Messages postés 2065 Date d'inscription lundi 11 avril 2005 Statut Membre Dernière intervention 14 mars 2016 - 20 sept. 2006 à 22:11
Cette discussion concerne un article du site. Pour la consulter dans son contexte d'origine, cliquez sur le lien ci-dessous.
https://codes-sources.commentcamarche.net/source/39404-verrouiller-definitivement-vba
https://codes-sources.commentcamarche.net/source/39404-verrouiller-definitivement-vba
20 sept. 2006 à 22:11
Il n'y a pas d'inconviénent particulier pour lancer la procédure autrement, puisque tu ne changes rien au principal. A noter que "Debug.Print p1" pourrait être retiré... Je corrigerai ce détail... MAIS, pour le fichier Excel, tu n'es pas obligé de me l'envoyé avec toutes ces données... Vide devrait faire l'affaire... donc devrait réduire la taille...
Amicalement,
Us.
Merci au passage pour la note...
20 sept. 2006 à 10:58
J'ai bien obtenu ton mail mais il y a systématiquement un échec lors de l'envoi de mon fichier. Peut-être est la taille de ce dernier qui est en cause (4.7MO après "zippage"). toutefois, comme je l'ai précisé j'ai bidouillé ton script pour l'adapter à mes besoins. J'ai peut-être commis une erreur. Le voici :
Sub Verrouille_VBA()
'charge form
'Load UserForm1
'paramètres
Dim F As String 'Nom fichier sélectionné
Dim B As String 'Chaîne
Dim NewF As String 'Nom de copie de secours
Dim Pointeur As Long 'Position pointeur
Dim LgFile As Long 'Longueur de F
Dim Cle As Boolean 'clé effacée
Dim p1 As Long 'position début cle
Dim p11 As Long 'position fin cle
'Ouverture fichier
'With UserForm1
'.CDialog.Filename = ""
'.CDialog.Flags = &H4 + &H200 + &H80000
'.CDialog.DialogTitle = "Choix du fichier"
'.CDialog.Filter = "*.*"
'.CDialog.ShowOpen 'ouverture
F = Application.GetOpenFilename 'récupère le nom
'End With
If F "" Then Exit Sub 'Aucun choix> sort
'Copie de sauvegarde du fichier sélectionné
NewF = F & ".tmp"
If Dir(NewF) <> "" Then Kill NewF 'efface fichier tempo
FileCopy F, NewF
'Ouverture fichier
Open F For Binary As #1
LgFile = LOF(1)
B = Space$(512)
Do
Pointeur = Loc(1) 'position pointeur
Get #1, , B
'recherche clé ID="
p1 = InStr(1, B, "ID=" & Chr$(34) & "{", vbBinaryCompare)
Debug.Print p1
If p1 > 0 Then
Debug.Print p1
'recherche des guillemets de fermeture
p11 = InStr(p1 + 4, B, Chr$(34), vbBinaryCompare)
If p11 > 0 Then 'efface toute la clé
Mid(B, p1, p11 - p1 + 1) = Space$(p11 - p1 + 1)
Put #1, Pointeur + 1, B
Cle = True
Exit Do
End If
End If
'recule de 100 octets pour éviter une coupure
Seek #1, Loc(1) - 99
Loop Until Pointeur > LgFile
Close #1
'Message
Select Case Cle
Case False
Kill NewF
MsgBox "Projet déjà verrouillé ou sans code VBA"
Case Else
MsgBox "opération terminée." & vbNewLine _
& "Sauvegarde temporaire présente : " _
& vbNewLine & NewF
End Select
'décharge form
'Unload UserForm1
End Sub
Merci pour tes précieux renseignements.
E.
20 sept. 2006 à 10:38
Pour ma part 10 est largement mérité .
Bravo
20 sept. 2006 à 09:35
J'ai une version 2000.
Bonne journée.
20 sept. 2006 à 09:22
Désolé je ne sais pas comment opérer pour t'envoyer un fichier n'ayant pas ton mail.
Peux tu me préciser la procédure.
Sinon je ne suis pas passé par un userform. Pour indiquer le chemin du fichier à protéger/déprotéger j'ai utilisé la méthode getopenfilename, ce qui m'évite de réécrire le chemin complet.
Merci.
H
19 sept. 2006 à 21:47
Jusqu'à maintenant je n'ai pas rencontré de problème.
IL est bien entendu que, ce que je propose n'est écrit dans aucune notice ! bien sur... LE but de mettre ce code ici, c'est aussi pour le discuter, et trouver un vrai contre exemple (si cela est possible)... Par conséquent, si tu es dans ce cas, pourrais-tu me transmettre ton fichier, svp, afin que je puisse voir par moi-même. (par e-mail)
Quelle est ta version d'Excel ?
Amicalement,
Us.
19 sept. 2006 à 15:24
Je suis atteré par les développeurs d'Excel. La méthode d'US30 pour dévérouiller le code VBA fonctionne très bien. J'ai pu ouvrir un des fichiers XLA fourni par microsoft + tous mes fichiers que je croyais protégés contre les intrus.
Ce qui me désole davantage US30 c'est que ta méthode pour empêcher n'importe qui de déverouiller l'affichage du code VB NE FONCTIONNE PAS. J'ai réalisé un test sur un de mes fichiers et rien à faire. Je peux toujours afficher le code VBA même après avoir utilisé ton code "vérouillant définitivement VBA". Mais je suis peut être passé à côté de quelquechose.
Es tu sûr du code figurant sur ce site.
Cordialement.
Eric.
11 sept. 2006 à 09:53
9 sept. 2006 à 12:18
Vraiment là ! il y a une grosse différence, entre ce que me dit et ce que j'observe; et je n'observe pas de différence de comportement en fonction de la version ! De plus, un ID nulle fait bugger certaine version, donc c'est une clé qui ne peut et doit pas être générée.
Je vais détailler les modifications que j'observe lorsque j'enregistre un fichier Excel.
CAS TRIVIAL : SANS CODE
-------------------------
A1. Enregistrons un fichier seule. (sans code)
Là, aucune des 4 clés n'est présente. => Conclusion : si on ne touche pas au VBE alors les clés de contrôle ne sont pas rajoutées.
A2. Reprenons le fichier, ouvrons VBE, et enregistrons à partir de VBE, sans rien rajouter (aucun module).
On observe alors les 4 clés :
ID="{B6958D9C-F689-468F-A01D-ED964681EB09}"
CMG="141614023C1240124012401240"
DPB="282A282B292B292B"
GC="3C3E3C2A443F453F45C0"
A3. Poursuivons, en enregistrant de nouveau à partir de VBE sans rien rajouter, après l'avoir rouvert (ce qui suppose de le fermer avant).
On observe alors que les 4 clés, sont recalculées :
ID="{6C611E4C-C55F-418C-ACFD-E3F458C26831}"
CMG="B9BBB9BFBDBFBDBFBDBFBD"
DPB="727072C92ACA2ACA2A"
GC="2B292B90E591E5911A"
On apercevra au passage le côté "légèrement" cyclique... Donc le cryptage n'est pas très sophistiqué, comme le RSA.
A4. Si on enregistre de nouveau sans rien rajouter, mais à partir d'Excel cette fois : Toutes les clés ont disparues.
AVEC CODE
--------
B1. Mettons un petit code dans un module, puis enregistrons :
sub test()
msgbox "ok"
end sub
Les 4 clés sont changées ici en :
ID="{12A5E3FC-7C07-4C8A-AB03-EE6032AEECE6}"
CMG="383A235127512751275127"
DPB="70726B8C6C8C6C8C"
GC="A8AAB3C4B4C4B43B"
On remarque qu'en absence de mot de passe le petit côté cyclique reste. En fait cette cyclicité prouve qu'elles ne sont pas calculées par un cryptage très sophistiqué, comme le RSA.
B2. Reprenons le fichier, ouvrons VBE, et enregistrons à partir de VBE, sans rien rajouter.
Que sont devenus les clés ?
ID="{12A5E3FC-7C07-4C8A-AB03-EE6032AEECE6}"
CMG="46445DC165C107C507C507C507C5"
DPB="E4E6FF9F033C043C043C"
GC="8280990536063606C9"
Donc les 3 dernières clés sont recalculer, mais pas ID ! !
B3. Rouvrons le fichier, et mettons un mot de passe : fred . Puis enregistrons.
Voici les clés :
ID="{12A5E3FC-7C07-4C8A-AB03-EE6032AEECE6}"
CMG="2D2F36E14A884E884E884E884E"
DPB="D8DAC3F0C8F0C8965C6DA5D1"
GC="8381983742384238BD"
Qu'observez-vous ? La clé ID reste encore identique ! contrairement aux 3 autres.
B4. On peut également cocher l'option de verrouillage au cas où :
ID="{12A5E3FC-7C07-4C8A-AB03-EE6032AEECE6}"
CMG="DEDCC5AC7B5CD260D260D260D260"
DPB="393B225327532735FFC20026"
GC="95978EEEB64BB74BB74B"
Verdict ? L'ID reste le même.
B4. Si on ouvre le fichier, cette fois dans VBE en cliquant sur le fichier, on est face à une boite de dialogue demandant le mot de passe. Normal, on vient de cocher le verrouillage.
Si on a oublié son mot de passe, il suffit de supprimer les 3 dernières clés. C'était l'objet d'une de mes sources précédentes. L'ID n'a ici aucun rôle. D'ailleurs, cette clé est manifestement indépendante des 3 dernières.
MAIS, maintenant ce que je propose en modifiant ID, c'est de bloquer complètement le verrouillage. La boite de dialogue proposant de rentrer le mot de passe ne sera même plus accessible. Par conséquent, il n'est pas nécessaire de rentrer un mot de passe pour le verrouillage. Néanmoins, on prendra la précaution de refermer l'arbre avant l'enregistrement, dans ce cas.
B5. Modifions ID. Par exemple, changeons le premier chiffre 1 en 2. Dans ce cas dés le premier click dans VBE sur le fichier, on obtient le message « le projet ne être affiché » (voir capture, déjà dit).
B6. Remettre le premier chiffre à 1, nous fait revenir à la situation précédente.
B7. Faisons, n'importe quel changement, et on verrouille le projet. Même l'utilisation d'une ancienne clé ne fonctionne pas. CAR ID EST UNIQUE ! (déjà dit) et ne peut pas être changé par une autre clé.
=
Maintenant, je viens de réaliser (de nouveau) toutes ces manipulations sur toutes les versions que j'ai pu. A savoir Excel 97, 2002, 2003. ET le principe est identique.
J'invite le lecteur à faire les mêmes tests pour s'en convaincre. Pour cela il suffit de disposer d'un logiciel ultra-sophistiqué : Bloc Note. (pour la visualisation seulement)
Par conséquent je pense, DarkVapeur, que tes observations, tu les as fait sans rentrer de code VBA. Car dés qu'il y a un code, l'ID reste fixe.
Par ailleurs, si vous êtes observateur, vous pouvez également voir qu'on retrouve presque le code rentrer en clair? Bien sur, certains caractères sont étranges et intercalés par d'autres? mais dans les grandes lignes... Ainsi, comme je l'avais déjà dit ailleurs, on peut toujours retrouver un code écrit en VBA. Ceci est évident puisque VBA est interprété, il faut bien que le logiciel qui l'utilise puisse le retrouver.
Voilà, j'espère avoir étais assez clair et convainquant.
Amicalement,
Us.
8 sept. 2006 à 10:04
".../..."
C'est Faux !
Le GUID reste le même ! IL est simple de le vérifier...
=======================================================
Il ne t'est pas venu à l'idée que le comportement de l'application pouvait différer avec la version ?
Dans mon cas (XL10-version 2002) les clés ID, CMG, DPB, GC sont recalculées (modifiées) à chaque enregistrement
=> (le GUID ne reste donc pas le même dans cette version)
et j'ai bien un GUID null pour l'ID dès qu'un mot de passe est entré dans la boite de propriétés de l'IDE (Alt OE) -
(avec ou sans verrouillage de l'affichage du code).
Si le classeur protégé est sauvegardé à nouveau, l'ID conserve son GUID null
et les clés CMG, DPB et GC sont à nouveau recalculée (et modifiée);
ces 3 clés se comportant comme pour un cryptage RSA (DPB recevant appremment le mot de passe crypté).
Du coup, je m'interroge à savoir si l'ID ne peut-être remplacée par une clé quelconque ?
As-tu essayé ?
7 sept. 2006 à 23:00
"Quand un projet est verrouillé par un mot de passe, l'application remplace le GUID original (que tu supprimes)
par le GUID null indiqué plus haut ( {00000000-0000-0000-0000-000000000000} )"
C'est Faux !
Le GUID reste le même ! IL est simple de le vérifier...
Us.
7 sept. 2006 à 20:43
Bon, je regarderai plus en détail ce que tu dis, un peu plus tard (étant pas trop en forme)...
Mais, soyons clair. Je supprime le GUID, sans pour autant avoir défini un mot de passe. Dans ce cas, remettre le GUID rempli de zéro, ne redonne pas la visualisation du code. C'est l'objet de mon dernier propos.
Là où cela serait différent, c'est dans le cas où un mot de passe serait déjà défini; d'après tes propos... Ai-je bien compris ?
Je testerai...
De plus, je pense que le GUID n'est pas aléatoire, mais dépend de la date et l'heure de l'enregistrement... C'est beaucoup plus logique...
A+,
Amicalement,
Us.
6 sept. 2006 à 22:49
Quand un projet est verrouillé par un mot de passe, l'application remplace le GUID original (que tu supprimes)
par le GUID null indiqué plus haut ( {00000000-0000-0000-0000-000000000000} ).
Il suffit donc de remplacer les espaces que tu utilises par un GUID null afin de restaurer la possibilité d'accès au mot de passe.
Ensuite, c'est effectivement un autre problème.
PS: il est fort probable que la composition du GUID identifiant le project VBA du classeur soit aléatoire-
le contraire n'apporterait rien puisqu'il est effectivement créé unique dès la création du classeur.
6 sept. 2006 à 20:59
Bien sur, je faissais un trait d'humour avec :
" Kepler ? c'est tout. "
Car se faire comparer à Kepler... c'est un compliment très flatteur... voir un honneur.
Note qu'on pourrait avec un simple changement de caractère, en dire encore un peu plus...
" Kepler, c'est tout."
Ce qui m'aurais encore un peu plus fait craquer mes godases. -:);
DarkVader, on ne verrouille pas mieux un projet avec ID="{00000000-0000-0000-0000-000000000000}". Déjà prendre cette valeur est générateur d'erreur avec Excel 2002. Avec Excel 97, se fonctionne, et verrouille définitive le projet. J'ai pas encore regardé avec d'autres applications, mais bon...
Ce qui faut savoir, c'est dés qu'une valeur de cette clé (ou bien si elle n'est pas reconnue) est erronnée, alors on verrouille le projet VBA, MAIS ! sans que VBE n'aille plus loin. En clair, le verrouillage est différent qu'avec les options de VBE !... C'est là, la grande différence. Ainsi, dès qu'on clique sur le projet à ouvrir dans VBE, on arrive directement sur le message "Le projet ne peut être affiché". (je viens de mettre une capture pour illustration)
Maintenant, on aurait pu seulement modifier "{" en "(" ou en autre chose. Ou encore, faire un cryptage avec les nombres avec un XOR, par exemple. Cela conduit nécessairement au verrouillage... D'où les possibilités d'extension de ce code. En effet, un créateur pourrait crypter simple quelques nombre de cette clée pour verouiller ou déverouiller le projet.
l'ID est unique. Deux fichiers Excel strictement identique, n'auront pas le même ID, et ne seront pas inter-changeable. LE seul moyen de déverouiller le projet, est de mettre la bonne clé ID générée. Ou bien de savoir recalculer cette clé... mais là, il restera plus beaucoup de chance au Macro commercialisé de se faire ouvrir les entrailles.
Amicalement,
Us.
PS : Merci, à tout deux de prendre soin de mon âge... et avec l'âge vient l'expérience...
6 sept. 2006 à 16:39
C'était juste un moyen de t'encourager mais approcher le 1/3 de la façon de travailler de Kepler c'est pas donné. Bien qu'il ne soit pas le plus doué des savants, il fait partir de mes préférés et inspirateur depuis le lycée donc il y'a fort fort longtemps.
Je n'ai pas eu le temps de tester tes 2 sources bien que download ais au vu des commentaires je me dis c'est encourageant surtout pour ton âge.
6 sept. 2006 à 15:11
Qu'est-ce que ce code apporte de plus par rapport à un projet verrouillé par un mot de passe dont l'ID="{00000000-0000-0000-0000-000000000000} ?
Il suffira de restituer le GUID nul en lieu et place des espaces pour pouvoir afficher le code.
Je ne pense pas que cela arrête longtemps un vrai cracker.
Vu ton grand age, on ne t'en voudra pas 8)
6 sept. 2006 à 10:42
-:);
Ammicalement,
Us.
4 sept. 2006 à 10:34
3 sept. 2006 à 23:03
Et bien, l'astuce vient de ma matière grise...
Amicalement,
Us.
3 sept. 2006 à 20:35