Protéger un code source VBA - anti crack
Bonjour, merci beaucoup pour votre aide précieuse
Je dois empêcher mes employés d’accéder au code source VBA d’un classeur Excel. Quelles options sérieuses existent ? Définis des objectifs clairs: empêcher la lecture, la copie et la modification. Contexte: parc Windows, Microsoft 365, et utilisateurs non admins mais curieux.
Commence par verrouiller le projet VBA par mot de passe et signer numériquement le classeur. C’est le minimum, mais insuffisant. Le mot de passe décourage, la signature garantit l’intégrité et l’éditeur de confiance.
Le mot de passe VBE se contourne avec des utilitaires connus. Je ne peux pas le considérer comme une vraie barrière. Je cherche un contrôle qui résiste à un employé compétent.
Ajoute une obfuscation : renommer variables/fonctions, aplatir la structure, chiffrer des chaînes, vérifier l’intégrité des modules à l’ouverture. Objectif: rendre l’analyse coûteuse. Évite les noms sémantiques et introduis du faux code.
L’obfuscation ne stoppe pas un analyste motivé. On peut toujours lire le P-Code ou exporter les modules. Elle retarde seulement, elle ne bloque pas.
Bonjour et bienvenue sur le forum,
L'option sérieuse qui existe c'est de garder le code VBA en question dans un autre fichier, non partagé aux employés.
Une solution simple est de Astuce VBA : protéger le code VBA par mot de passe, mais elle a ses limites pour les "très curieux".
Le plus simple comme toujours si vous ne voulez pas que quelqu'un accède à quelque chose, vous ne lui en donnez pas l'opportunité : simple et efficace.
Pour info tous les codes VBA peuvent être lancés depuis un autre classeur sans pb.
Alors déporte la logique critique hors VBA. Laisse du “glue code” minimal et mets l’algorithme ailleurs. Ainsi, même si le VBA fuite, l’IP reste protégée.
D’accord pour séparer, mais comment lier proprement A et B sans révéler le code de B ? Je pense à Application.Run ou à des références VBA, mais cela n’empêche pas un utilisateur d’ouvrir B si jamais il l’obtient.
Référencez B en lecture seule dans un emplacement réseau restreint et chargez-le à la volée. Exposez uniquement des fonctions publiques à paramètres contrôlés; journalisez chaque appel. Même si B est vu, son accès doit rester limité par l’ACL du partage.
Le verrouillage réseau est utile, mais si quelqu’un copie B, il peut ouvrir le VBE. Le mot de passe n’est pas une barrière réelle. Je veux une solution qui résiste à l’export de modules.
Obfuscation minimale: renommage agressif, aplatissage, chaînes chiffrées, vérification d’intégrité au démarrage. Ça n’est pas infaillible mais élève le coût. Idéalement, réduisez le VBA à de la “colle” et déplacez la logique ailleurs.
“Ailleurs” signifie quoi concrètement si je reste dans l’écosystème Excel ? Je veux garder l’UX Excel.
Compilez le cœur en bibliothèque native: DLL ou XLL (C/C++). VBA n’appelle que des wrappers, donc pas de code métier lisible côté VBE. L’XLL s’intègre mieux aux fonctions feuille.
Une DLL/XLL peut être décompilée et déboguée. Les chaînes et exports aident l’analyse. Comment durcir le binaire ?
Supprimez symboles, exportez par ordinaux, ofusquez le flot de contrôle, chiffrez les chaînes, contrôlez l’intégrité au runtime et détectez le debugging/hooking. Terminez silencieusement si anomalie.
Posez-vous deux minutes : vos employés ont-ils vraiment besoin d'utiliser des macros qui doivent leur être cachées ?
Si oui, c'est étrange, car quand on clique sur un bouton c'est quand même bien de savoir ce qu'il se passe.
Si non, ce qui devrait être le cas courant, alors vous tenez vos macros "admin" dans un fichier "admin", et d'autre part vous avez vos macros "user" dans le fichier partagé.
Et puis si vous pouviez détailler un peu votre processus "ce que font vos macros" ce serait utile, car si c'est juste de la lecture/filtrage de data vous pourriez passer par PowerQuery et l'identification via compte Office, comme ça c'est robuste.
EngineeringSolving et ArmandXL sont la même personne
Sujet verrouillé.