Discussion :

[Patrice740]

par exemple j'ai deux variables aabababaa et aabababaab
... commencer par les plus longues, mais pour ça ...

Déjà pour l'exemple, au lieu de a et b, nnmnmnmnn et nnmnmnmnnm ou jjijijijj et jjijijijji (en hommage à Ti )
Mais ça, ce n'est que du visuel, sans vouloir t'offusquer , une macro de dé-obfuscation est d'une simplicité enfantine .

[Invité]

Bonsoir,
Ça ne me gène pas de prendre des Je commence à en avoir l'habitude ,car à l'arrivé ce n'est qu'un débat de personnes qui pensent détenir la vérité et sanctionnent les bien ou male pensant avec le pouce lève ou baissé.

À la vérité il n'existe aucune sécurisation possible et même pour les logiciels compilés!
Dans mon jeune temps je déplombais le logiciel en pistant l'interruption 21 puis en modification le code assembleur du logiciel.

Microsoft propose un en téléchargement un dé compilateur dot.net pour l'avoir utilisé je sais qu'il fonctionne et il ce fiche de savoir si il y a ou pas un mot de passe!

Il appartient à Chaque un de savoir le niveau de sécurité dont il a besoin et le prix qu'il est prêt à mètre pour ça !

Il vendra certainement moins de licences avec un simple InputBox qu'une Dll et un web service mais il en vendra.

J'avais développé une macro pour un client, il a mis un mot de passe sur les macros qu'il a oublié!
Et bin moi je m'en fiche je n'est pas pour vocations de pirater.

Les clients préfère payer et avoir un suivi que de pirater!

Je me suis attiré les foudres des mes contemporain et je continue apparemment dans la mauvaise direction !

De plus en plus des sociétés paye des prestataires pour adapter des logiciels libre.
Ce n'ai plus avoir gratuit qui compte mais une bonne prestation et un bon suivi.

Il y a plusieurs discutions sur le sujet, certaines allant jusqu'à dénigrer la qualité du code sens même le avoir!

Un cambrioleur chevronné met en moyenne 70 seconde pour ouvrir une porte avec serrure standard !
Pourquoi mettons nous des verrous à nos portes?

parce que rien ne dit qu'il s'intéressera à la notre et en attendant ça dissuade le voisins!

[clementmarcotte]

Bonjour,

PLus 1 pour Dysorthographie et unparia

Il y a peut-être deux semaines. on a vu du code VBA "confidentiel" sorti directement de l'enregistreur de macros de Word. VBA pour Office est tellement bien connu depuis qu'il est dans les parages qu'à peu près n'importe qui de moindrement familier avec le programme peut deviner les principes de base de n'importe quelle application moindrement standard rien qu'en regardant les résultats. La seule chose qui mérite une certaine protection, incomplète au demeurant, ce sont des programmes ultra-spécialisés. Et encore, la plupart des algorithmes mathématiques connus peuvent être récupérés et plusieurs sont libres de tous droits à cause de leur "vieillesse".

[Gorzyne]

Les clients préfère payer et avoir un suivi que de pirater!

c'est exactement ça
à partir du moment où vous offusquez votre code, et vous appuyez sur le chiffrage fort des feuilles, vous n'empêcherez pas une enterprise déterminée à mettre les moyens pour se procurer votre programme, mais le coût pour l'entreprise sera supérieur au coût de la licence, et le logiciel ne bénéficiera pas des mises à jours... en effet, les logiciels peuvent bénéficier d'une mise à jour annuelle voire mensuelle...

donc il faut mettre en regard du niveau de protection, les efforts et le temps nécessaire pour les contourner, sans parler du fait que faire un desoffuscateur est un jeu d'enfants pour certains, mais dans une entreprise très compartimentée, connaître la bonne personne qui sera capable de faire çaà condition qu'elle ne soit pas occupée à autre chose... d'autant plus qu'on demande à cette personne de se mettre dans une position pas forcément légale...

donc dans cette optique, les logiciels sous excel/vba end-user seront utilisées par des personnes qui ont peu de chance d'arriver à contourner les protections. Au mieux on aura un bidouilleur qui arrivera à faire sauter la protection vba et se retrouvera du code offusqué, ou quelqu'un qui arrivera à accéder aux datas du Excel mais aura du mal à rétro-documenenter les fonctionnalités...

sur cette question de la rétro-ingénierie, arriver à retrouver les fonctionnalités précises d'un logiciel avec tous les cas particuliers, ça me paraît compliqué également, surtout s'il manque une partie de la chaîne de traitement qui est planquée dans des formules excel.

[clementmarcotte]

donc dans cette optique, les logiciels sous excel/vba end-user seront utilisées par des personnes qui ont peu de chance d'arriver à contourner les protections. Au mieux on aura un bidouilleur qui arrivera à faire sauter la protection vba et se retrouvera du code offusqué, ou quelqu'un qui arrivera à accéder aux datas du Excel mais aura du mal à rétro-documenenter les fonctionnalités…

N'importe qui peut trouver des programmes, peu importe le langage, des tansformations de Fourier, de la méthode du trapèze, de la méthode de Simpson, des moindres-carrés, de la résolution d'équations, de la méthode de Newton-Raphson, de la métode du Transport, de la méthode du simplexe et d'à peu près toutes les opérations mathématiques connues. Même si le programme n'est pas en VBA, même si les données ne sont pas sur Excel, à peu près tous les problèmes connus ont déjà été résolus d'une façon ou d'une autre. Excel est juste un outil parmi d'autres. Avec un peu d'efforts et de connaissances, n'importe quel programme, ou à peu près, peut être converti en VB ou VBA. Que ce soit en ADA, BASIC, Fortran, Pascal, COBOL, List, assembler etc; une boucle c'est une boucle et une décision, c'est une décision, True c'est true et false c'est false. La programmation c'est une entité en elle-même, indépendante d'un langage. Il faut apprendre un langage pour apprendre à utiliser ou faire de la programmation. Mais la théorie de la programmation peut s'appliquer à n'importe quel autre langage. J'ai appris la programmation en Fortran. En appliquant la connaissance de la programmation, j'ai appris BASIC et même à programmer des calculatrices programmables.

sur cette question de la rétro-ingénierie, arriver à retrouver les fonctionnalités précises d'un logiciel avec tous les cas particuliers, ça me paraît compliqué également, surtout s'il manque une partie de la chaîne de traitement qui est planquée dans des formules excel.

Peut-être, si c'est le seul programme à traiter d'un problème tellement rare que personne d'autre ne l'a rencontré. Mais, encore… Les fonctions Excel utilisent probablement toutes des algorithmes connus. (Et que l'on peut probablement trouver le plus simplement dans une bibliothèque, ou sur Wikipédia.) Mais si une personne a été capable de solutionner ce problème-là; il y en a d'autres qui sont capables de le solutionner; avec ou sans Excel.

N'importe qui qui a Visual Studio Community (gratuit), ou même Visual Studio Express (gratuit) peut lire, modifier ou écrire n'importe quel fichier Office, sans avoir Office. (C'est dans System.IO.Packaging) Et toute la documentation de VBA est accessible gratuitement sur le site de Microsoft. ET Open XML, la norme de constitution d'un fichier Office est un standard international dont la document est disponible à tous Qu'Excel et VBA Excel soient les seuls outils appropriés pour résoudre un problème, découlent de l'exception rarissime. C'est sûr que cela reste plus facile de prendre directement les fonctions d'Excel que de les reprogrammer, mais si quelqu'un a réussi à programmer Excel, quelqu'un d'autre peut le faire, peut-être différemment, mais au final si cela fait la même chose, cela importe peu. Et puis tiens, juste pour le fun, les fonctions financières d'Excel ont déjà été reproduites en F# et le programme est disponible sur le site de MS. Et F#, est compatible avec la plate-forme .net, donc le programme est réutilisable tel quel avec n'importe quel langage compatible avec la plate-forme .net.

[unparia]

A Clément :

La programmation c'est une entité en elle-même, indépendante d'un langage.

Un gran abrazo et je regrette de ne pouvoir te mettre mille
C'est très bien, de l'avoir dit aussi clairement.

[Gorzyne]

la discussion est résolue je pense que ces digressions sont fallacieuses
ce qui devait être dit est fort simple et a déjà été dit

on adapte son niveau de protection au niveau de la menace.
- les données: vous ne pouvez pas protéger les données avec Excel, jamais

- la propriété intellectuelle: vous pouvez protéger imparfaitement la propriété intellectuelle d'un logiciel. A moins de traiter de sujets ultra-sensibles, auquel cas l'utilisation d'Excel n'est peut être pas optimale, on peut atteindre un niveau dissuasif de protection (offuscation+formules masquées+office2016/365) qui rendra le temps/coût de rétro-ingénierie trop élevé. On ne parle pas que d'algorithmes (vision abstraite) mais de nombreuses connaissances métiers intégrées à ces logiciels. On a peu de profils qui ont la double casquette par exemple juriste+informaticien. Il faut donc former des équipes pour espérer dépiler votre logiciel, donc un coût de plusieurs dizaines de milliers. Si la seule propriété intellectuelle de votre logiciel est supérieure à ~100k€ pour la concurrence, alors effectivement utilisez un autre langage de programmation

- l'usage: idem que pour la propriété intellectuelle. Il s'agit essentiellement de limiter l'usage, de contrôler un nombre de licence. Une entreprise préfera sans doute payer pour utiliser votre logiciel

[Gorzyne]

je fais un petit update de ce que j'ai dit, j'ai prétendu que depuis Office 2016, il y avait un chiffrement fort au niveau de la protection feuilles/classeurs, et qu'on pouvait s'appuyer dessus pour masquer des formules à condition de passer leur propriété en masquée (pas seulement verrouillée)

mais en fait ceci était par rapport à l'ancienne attaque brute force, qui je pense marchait très bien parce qu'il y avait bcp de colisions en binaire, et qui du coup se cassait les dents sur le nouveau chiffrement

malheureusement il existe une autre méthode, assez ancienne d'ailleurs, qui permet de façon très simple et élégante de déprotéger la feuille... le principe étant du même acabit que la déprotection du mot de passe vba; et qui continue de fonctionner sur la nouvelle version du chiffrement feuille/classeur

Gorz

[Pierre Fauconnier]

Quel temps perdu à vouloir protéger un truc en Excel alors que Clément a déjà tout dit.

Nous n'inventons riens, et les algos que nous mettons en place, d'autres sont capables de les mettre en place aussi. Se triturer pour essayer de verrouiller Excel est une perte de temps, et illustre une très (trop) haute estime de ce que l'on a produit. Peu ou prou, n'importe quel "logiciel" Excel est reprogrammable à moindre coût.

Quand je vois ce que certains veulent protéger, vendre à coup de licences ou dongles, je me marre gentiment. Leur code est truffé de conneries, de chausse-trappes, d'erreurs de programmation, d'erreurs fonctionnelles, ça plante à chaque clic ou à peu près mais on veut protéger, verrouiller et vendre. C'est à se taper par terre de rire.

[Gorzyne]

Pierre avec tout le respect que j'ai pour toi, je pense que ta visio est caricaturale des SI et un peu insultante vis à vis des équipes métiers qui ils me semblent subissent quand même plus de pression que les devs, et font ce qu'elles peuvent pour livrer dans les délais

on sait très bien que le passage par les DSI est incompatible avec les cycles métiers, et d'ailleurs les défauts inhérents que tu fustiges ne sont pas spécifiques à Excel/VBA en particulier, mais en fait à tous les développements de nature SI effectués par les équipes fonctionnelles, ça peut être de ce que tu veux en terme de langage, ça ne sera jamais aux standards SI

ce n'est donc pas spécifiquement Excel/VBA qui est en cause. Le souci est peut être que VBA est un langage à la fois puissant et "trop" facile et donc à la portée de personnes qui n'ont pas le niveau pour programmer proprement... d'où les erreurs de programmation que tu désignes

Par ailleurs, je ne comprends pas trop l'intérêt de rebondir sur un update de nature parfaitement technique. J'ai expliqué minutieusement les limites d'Excel dans mes posts précédent de ce topic, selon les versions, en terme de sécurité, et je faisais juste un petit update suite à une découverte récente qui vient donc tempérer ce que j'avais expliqué avant.

Gorz

[Pierre Fauconnier]

Salut Gorz,

Je ne parle à aucun moment des SI. Je parle de ce qui est fait en VBA pour Excel, et si une SI développe en VBA/Excel, ça n'a jamais, selon moi, suffisamment de valeur que pour être verrouillé, protégé, licencié, vendu à grande échelle, etc. J'imagine que lorsqu'une SI développe pour Excel et qu'elle veut le verrouiller, elle le fait à l'heure actuelle en dot.net et j'ose espérer que c'est plus costaud comme code que ce qu'on voit sur les forums. Pour ce qui est de ne pas pouvoir faire les choses proprement en SI parce que incompatible avec les cycles métier et autres, chacun sa vision et ça mériterait un débat, mais je ne partage pas du tout ton avis

Cela dit, ce dont je parle ici, c'est ce qu'on voit à tout bout de champ sur les forums VBA, Excel comme Access, et que certains essaient de verrouiller/licencier parce qu'ils ont eu l'idée du siècle. C'est souvent mal torché sur le plan fonctionnel comme sur le plan technique, mais même bien torché, ce n'est jamais que la traduction en langage informatique, peut importe lequel, du besoin métier, et ça a assez souvent peu suffisamment de valeur marchande que pour nécessiter de s'amuser à jouer avec des licences. Ceci est juste mon avis et à chacun d'avoir son opinion, bien sûr. Et il n'y a rien de condescendant vis-à-vis de qui que soit dans ce que j'exprime. C'est la réalité du code auquel nous sommes confronté sur les forums VBA de DVP

[Invité]

Bonjour,
Moi je suis passé à autre chose!

ceci dit ce fils à bien voyagé je suis tombé dessus par hasard!

Pierre oui sur le fond non sur la forme!

[Gorzyne]

oui ok c'est bien joli tout ce que vous dites mais à la base je balançais une info technique certes mineure, mais bon rebondir dessus, ça fait juste enterrer une info qui d'ailleurs j'attire votre attention sur ce point, va exactement dans le même sens que vous, c'est à dire que Excel/VBA ne permet pas de protéger du code, mais bon j'ai expliqué ce que j'avais testé, et pourquoi je considérais que c'était pas un langage sûr ... mis à part peut être pour la protection d'accès disponibles dans les options générales lors de l'enregistrement, de mémoire elle était facilement crackable mais c'était dans les anciennes versions... depuis il faudrait réessayer. Bref c'est bien joli de dire que VBA c'est "bidon" mais faut expliquer pourquoi

[Pierre Fauconnier]

Je n'ai personnellement jamais dit que le vba c'était bidon, et j'ai largement expliqué pourquoi ça ne servait à rien de vouloir le protéger... 😉