Je souhaite appliquer une protection plus sérieuse du code VBA que celle
obtenue par la propriété standard de protection d'un projet VBA (mot de
passe).
Existe-t-il d'autres façons de faire?, merci d'avance à ceux qui auraient
déjà planché sur ce thème et auraient des solutions à me proposer.
Cette action est irreversible, confirmez la suppression du commentaire ?
Signaler le commentaire
Veuillez sélectionner un problème
Nudité
Violence
Harcèlement
Fraude
Vente illégale
Discours haineux
Terrorisme
Autre
Ange Ounis
Malheureusement, l'absence de réponse à ce genre de question n'est pas due au fait que les programmeurs veulent garder jalousement leurs secrets pour eux ! Il n'existe aucune protection vraiment "sérieuse" du code VBA. Pour du (plus) sérieux, il faut sortir d'Excel : un programme compilé, en Visual Basic, Delphi, C++ ou autre, qui pilote Excel par exemple. Mais c'est une autre histoire.
---------- Ange Ounis ----------
Bonjour à tous,
Je souhaite appliquer une protection plus sérieuse du code VBA que celle obtenue par la propriété standard de protection d'un projet VBA (mot de passe).
Existe-t-il d'autres façons de faire?, merci d'avance à ceux qui auraient déjà planché sur ce thème et auraient des solutions à me proposer.
Malheureusement, l'absence de réponse à ce genre de question n'est pas due au
fait que les programmeurs veulent garder jalousement leurs secrets pour eux !
Il n'existe aucune protection vraiment "sérieuse" du code VBA.
Pour du (plus) sérieux, il faut sortir d'Excel : un programme compilé, en Visual
Basic, Delphi, C++ ou autre, qui pilote Excel par exemple. Mais c'est une autre
histoire.
----------
Ange Ounis
----------
Bonjour à tous,
Je souhaite appliquer une protection plus sérieuse du code VBA que celle
obtenue par la propriété standard de protection d'un projet VBA (mot de
passe).
Existe-t-il d'autres façons de faire?, merci d'avance à ceux qui auraient
déjà planché sur ce thème et auraient des solutions à me proposer.
Malheureusement, l'absence de réponse à ce genre de question n'est pas due au fait que les programmeurs veulent garder jalousement leurs secrets pour eux ! Il n'existe aucune protection vraiment "sérieuse" du code VBA. Pour du (plus) sérieux, il faut sortir d'Excel : un programme compilé, en Visual Basic, Delphi, C++ ou autre, qui pilote Excel par exemple. Mais c'est une autre histoire.
---------- Ange Ounis ----------
Bonjour à tous,
Je souhaite appliquer une protection plus sérieuse du code VBA que celle obtenue par la propriété standard de protection d'un projet VBA (mot de passe).
Existe-t-il d'autres façons de faire?, merci d'avance à ceux qui auraient déjà planché sur ce thème et auraient des solutions à me proposer.
johncurtisgunther
Sorry I don't speak French, but if my guess at your meaning is correct this link should help you:
http://invisiblebasic.sourceforge.net/
John
Sorry I don't speak French, but if my guess at your meaning is correct
this link should help you:
Sorry I don't speak French, but if my guess at your meaning is correct this link should help you:
http://invisiblebasic.sourceforge.net/
John
Ange Ounis
Yes, your guess is correct. Obfuscation is a good way to delay crackers'action. But delay only, IMO (and do not pretend more anyway). The addin pointed by your link must have minor changes (names of the months) to be localized. Thanks for your input. Regards (and sorry for my english :)
---------- Ange Ounis ----------
Sorry I don't speak French, but if my guess at your meaning is correct this link should help you:
http://invisiblebasic.sourceforge.net/
John
Yes, your guess is correct.
Obfuscation is a good way to delay crackers'action. But delay only, IMO (and do
not pretend more anyway).
The addin pointed by your link must have minor changes (names of the months) to
be localized.
Thanks for your input.
Regards
(and sorry for my english :)
----------
Ange Ounis
----------
Sorry I don't speak French, but if my guess at your meaning is correct
this link should help you:
Yes, your guess is correct. Obfuscation is a good way to delay crackers'action. But delay only, IMO (and do not pretend more anyway). The addin pointed by your link must have minor changes (names of the months) to be localized. Thanks for your input. Regards (and sorry for my english :)
---------- Ange Ounis ----------
Sorry I don't speak French, but if my guess at your meaning is correct this link should help you:
http://invisiblebasic.sourceforge.net/
John
johncurtisgunther
Your English is many orders of magnitude better than my French...
On the ability of obfuscation to deter crackers:
Without comments and meaningful variable names, much of the information in the original code is simply unavailable to the cracker. The cracker can still guess the meaning of your code without comments and meaningful variable names, but this can be surprisingly difficult to do in practice. The Invisible Basic User's Guide has a simple example (showing code before/after obfuscation) that illustrates this.
Note that since variable names are replaced with a fixed, meaningless, name sequence a, b, c, ... aa, ab, ... there is no way to "un-obfuscate" the names. Thus the "variable name info" --just like the comments--really is simply removed from your code. Some other ofuscators merely encrypt the variables--in which case un-obfuscation would be possible.
On localization problems in France:
Thank-you for reporting the localization problems, of which I was previously unaware. If the date problem is what I am guessing that it is, then:
If you added a list of French month abbrieviations/names translated from the English shown below to the special "visible_names.txt" file, would that would allow you to work around the date problems you mentioned?
jan feb mar apr may jun jul aug sep oct nov dec January February March April May June July August September October November December
If this works for you, could you me send the French equivalent of the above list so I can add this list to "visible_names.txt" file for the next release?
I don't really know everything that would be required for proper localization, though. Beside the "date literals" issue you mentioned, the other thing that comes to mind is the "," vs "." decimal delimiter issue (3.14 vs. 3,14) but I think it's not a problem because commas are passed through unchanged and the numeric literals are therefore OK without any special handling. Am I right about this? Any other localization issues I should look into fixing that you know about?
I'd like to try to get this problem fixed in the next release (at least for France) any info/suggestions regarding how to fix this problem would be appreciated.
John
Ange Ounis wrote:
Yes, your guess is correct. Obfuscation is a good way to delay crackers'action. But delay only, IMO ( and do not pretend more anyway). The addin pointed by your link must have minor changes (names of the mont hs) to be localized. Thanks for your input. Regards (and sorry for my english :)
---------- Ange Ounis ----------
Sorry I don't speak French, but if my guess at your meaning is correct this link should help you:
http://invisiblebasic.sourceforge.net/
John
Your English is many orders of magnitude better than my French...
On the ability of obfuscation to deter crackers:
Without comments and meaningful variable names, much of the information
in the original code is simply unavailable to the cracker. The cracker
can still guess the meaning of your code without comments and
meaningful variable names, but this can be surprisingly difficult to do
in practice. The Invisible Basic User's Guide has a simple example
(showing code before/after obfuscation) that illustrates this.
Note that since variable names are replaced with a fixed, meaningless,
name sequence a, b, c, ...
aa, ab, ... there is no way to "un-obfuscate" the names. Thus the
"variable name info" --just like the comments--really is simply removed
from your code. Some other ofuscators merely encrypt the variables--in
which case un-obfuscation would be possible.
On localization problems in France:
Thank-you for reporting the localization problems, of which I was
previously unaware. If the date problem is what I am guessing that it
is, then:
If you added a list of French month abbrieviations/names translated
from the English shown below to the special "visible_names.txt" file,
would that would allow you to work around the date problems you
mentioned?
jan
feb
mar
apr
may
jun
jul
aug
sep
oct
nov
dec
January
February
March
April
May
June
July
August
September
October
November
December
If this works for you, could you me send the French equivalent of the
above list so I can add this list to "visible_names.txt" file for the
next release?
I don't really know everything that would be required for proper
localization, though. Beside the "date literals" issue you mentioned,
the other thing that comes to mind is the "," vs "." decimal delimiter
issue (3.14 vs. 3,14) but I think it's not a problem because commas are
passed through unchanged and the numeric literals are therefore OK
without any special handling. Am I right about this? Any other
localization issues I should look into fixing that you know about?
I'd like to try to get this problem fixed in the next release (at least
for France) any info/suggestions regarding how to fix this problem
would be appreciated.
John
Ange Ounis wrote:
Yes, your guess is correct.
Obfuscation is a good way to delay crackers'action. But delay only, IMO ( and do
not pretend more anyway).
The addin pointed by your link must have minor changes (names of the mont hs) to
be localized.
Thanks for your input.
Regards
(and sorry for my english :)
----------
Ange Ounis
----------
Sorry I don't speak French, but if my guess at your meaning is correct
this link should help you:
Your English is many orders of magnitude better than my French...
On the ability of obfuscation to deter crackers:
Without comments and meaningful variable names, much of the information in the original code is simply unavailable to the cracker. The cracker can still guess the meaning of your code without comments and meaningful variable names, but this can be surprisingly difficult to do in practice. The Invisible Basic User's Guide has a simple example (showing code before/after obfuscation) that illustrates this.
Note that since variable names are replaced with a fixed, meaningless, name sequence a, b, c, ... aa, ab, ... there is no way to "un-obfuscate" the names. Thus the "variable name info" --just like the comments--really is simply removed from your code. Some other ofuscators merely encrypt the variables--in which case un-obfuscation would be possible.
On localization problems in France:
Thank-you for reporting the localization problems, of which I was previously unaware. If the date problem is what I am guessing that it is, then:
If you added a list of French month abbrieviations/names translated from the English shown below to the special "visible_names.txt" file, would that would allow you to work around the date problems you mentioned?
jan feb mar apr may jun jul aug sep oct nov dec January February March April May June July August September October November December
If this works for you, could you me send the French equivalent of the above list so I can add this list to "visible_names.txt" file for the next release?
I don't really know everything that would be required for proper localization, though. Beside the "date literals" issue you mentioned, the other thing that comes to mind is the "," vs "." decimal delimiter issue (3.14 vs. 3,14) but I think it's not a problem because commas are passed through unchanged and the numeric literals are therefore OK without any special handling. Am I right about this? Any other localization issues I should look into fixing that you know about?
I'd like to try to get this problem fixed in the next release (at least for France) any info/suggestions regarding how to fix this problem would be appreciated.
John
Ange Ounis wrote:
Yes, your guess is correct. Obfuscation is a good way to delay crackers'action. But delay only, IMO ( and do not pretend more anyway). The addin pointed by your link must have minor changes (names of the mont hs) to be localized. Thanks for your input. Regards (and sorry for my english :)
---------- Ange Ounis ----------
Sorry I don't speak French, but if my guess at your meaning is correct this link should help you:
http://invisiblebasic.sourceforge.net/
John
Ange Ounis
If you added a list of French month abbrieviations/names translated from the English shown below to the special "visible_names.txt" file, would that would allow you to work around the date problems you mentioned?
Yes, I think so.
jan janv feb févr mar mars apr avr may mai jun juin jul juil aug août sep sept oct oct nov nov dec déc January Janvier February Février March Mars April Avril May Mai June Juin July Juillet August Août September Septembre October Octobre November November December Décembre
Didn't see anything else, but quickly tested only. Regards
---------- Ange Ounis ----------
Your English is many orders of magnitude better than my French...
On the ability of obfuscation to deter crackers:
Without comments and meaningful variable names, much of the information in the original code is simply unavailable to the cracker. The cracker can still guess the meaning of your code without comments and meaningful variable names, but this can be surprisingly difficult to do in practice. The Invisible Basic User's Guide has a simple example (showing code before/after obfuscation) that illustrates this.
Note that since variable names are replaced with a fixed, meaningless, name sequence a, b, c, ... aa, ab, ... there is no way to "un-obfuscate" the names. Thus the "variable name info" --just like the comments--really is simply removed from your code. Some other ofuscators merely encrypt the variables--in which case un-obfuscation would be possible.
On localization problems in France:
Thank-you for reporting the localization problems, of which I was previously unaware. If the date problem is what I am guessing that it is, then:
If you added a list of French month abbrieviations/names translated from the English shown below to the special "visible_names.txt" file, would that would allow you to work around the date problems you mentioned?
jan feb mar apr may jun jul aug sep oct nov dec January February March April May June July August September October November December
If this works for you, could you me send the French equivalent of the above list so I can add this list to "visible_names.txt" file for the next release?
I don't really know everything that would be required for proper localization, though. Beside the "date literals" issue you mentioned, the other thing that comes to mind is the "," vs "." decimal delimiter issue (3.14 vs. 3,14) but I think it's not a problem because commas are passed through unchanged and the numeric literals are therefore OK without any special handling. Am I right about this? Any other localization issues I should look into fixing that you know about?
I'd like to try to get this problem fixed in the next release (at least for France) any info/suggestions regarding how to fix this problem would be appreciated.
John
Ange Ounis wrote:
Yes, your guess is correct. Obfuscation is a good way to delay crackers'action. But delay only, IMO (and do not pretend more anyway). The addin pointed by your link must have minor changes (names of the months) to be localized. Thanks for your input. Regards (and sorry for my english :)
---------- Ange Ounis ----------
Sorry I don't speak French, but if my guess at your meaning is correct this link should help you:
http://invisiblebasic.sourceforge.net/
John
If you added a list of French month abbrieviations/names translated
from the English shown below to the special "visible_names.txt" file,
would that would allow you to work around the date problems you
mentioned?
Yes, I think so.
jan janv
feb févr
mar mars
apr avr
may mai
jun juin
jul juil
aug août
sep sept
oct oct
nov nov
dec déc
January Janvier
February Février
March Mars
April Avril
May Mai
June Juin
July Juillet
August Août
September Septembre
October Octobre
November November
December Décembre
Didn't see anything else, but quickly tested only.
Regards
----------
Ange Ounis
----------
Your English is many orders of magnitude better than my French...
On the ability of obfuscation to deter crackers:
Without comments and meaningful variable names, much of the information
in the original code is simply unavailable to the cracker. The cracker
can still guess the meaning of your code without comments and
meaningful variable names, but this can be surprisingly difficult to do
in practice. The Invisible Basic User's Guide has a simple example
(showing code before/after obfuscation) that illustrates this.
Note that since variable names are replaced with a fixed, meaningless,
name sequence a, b, c, ...
aa, ab, ... there is no way to "un-obfuscate" the names. Thus the
"variable name info" --just like the comments--really is simply removed
from your code. Some other ofuscators merely encrypt the variables--in
which case un-obfuscation would be possible.
On localization problems in France:
Thank-you for reporting the localization problems, of which I was
previously unaware. If the date problem is what I am guessing that it
is, then:
If you added a list of French month abbrieviations/names translated
from the English shown below to the special "visible_names.txt" file,
would that would allow you to work around the date problems you
mentioned?
jan
feb
mar
apr
may
jun
jul
aug
sep
oct
nov
dec
January
February
March
April
May
June
July
August
September
October
November
December
If this works for you, could you me send the French equivalent of the
above list so I can add this list to "visible_names.txt" file for the
next release?
I don't really know everything that would be required for proper
localization, though. Beside the "date literals" issue you mentioned,
the other thing that comes to mind is the "," vs "." decimal delimiter
issue (3.14 vs. 3,14) but I think it's not a problem because commas are
passed through unchanged and the numeric literals are therefore OK
without any special handling. Am I right about this? Any other
localization issues I should look into fixing that you know about?
I'd like to try to get this problem fixed in the next release (at least
for France) any info/suggestions regarding how to fix this problem
would be appreciated.
John
Ange Ounis wrote:
Yes, your guess is correct.
Obfuscation is a good way to delay crackers'action. But delay only, IMO (and do
not pretend more anyway).
The addin pointed by your link must have minor changes (names of the months) to
be localized.
Thanks for your input.
Regards
(and sorry for my english :)
----------
Ange Ounis
----------
Sorry I don't speak French, but if my guess at your meaning is correct
this link should help you:
If you added a list of French month abbrieviations/names translated from the English shown below to the special "visible_names.txt" file, would that would allow you to work around the date problems you mentioned?
Yes, I think so.
jan janv feb févr mar mars apr avr may mai jun juin jul juil aug août sep sept oct oct nov nov dec déc January Janvier February Février March Mars April Avril May Mai June Juin July Juillet August Août September Septembre October Octobre November November December Décembre
Didn't see anything else, but quickly tested only. Regards
---------- Ange Ounis ----------
Your English is many orders of magnitude better than my French...
On the ability of obfuscation to deter crackers:
Without comments and meaningful variable names, much of the information in the original code is simply unavailable to the cracker. The cracker can still guess the meaning of your code without comments and meaningful variable names, but this can be surprisingly difficult to do in practice. The Invisible Basic User's Guide has a simple example (showing code before/after obfuscation) that illustrates this.
Note that since variable names are replaced with a fixed, meaningless, name sequence a, b, c, ... aa, ab, ... there is no way to "un-obfuscate" the names. Thus the "variable name info" --just like the comments--really is simply removed from your code. Some other ofuscators merely encrypt the variables--in which case un-obfuscation would be possible.
On localization problems in France:
Thank-you for reporting the localization problems, of which I was previously unaware. If the date problem is what I am guessing that it is, then:
If you added a list of French month abbrieviations/names translated from the English shown below to the special "visible_names.txt" file, would that would allow you to work around the date problems you mentioned?
jan feb mar apr may jun jul aug sep oct nov dec January February March April May June July August September October November December
If this works for you, could you me send the French equivalent of the above list so I can add this list to "visible_names.txt" file for the next release?
I don't really know everything that would be required for proper localization, though. Beside the "date literals" issue you mentioned, the other thing that comes to mind is the "," vs "." decimal delimiter issue (3.14 vs. 3,14) but I think it's not a problem because commas are passed through unchanged and the numeric literals are therefore OK without any special handling. Am I right about this? Any other localization issues I should look into fixing that you know about?
I'd like to try to get this problem fixed in the next release (at least for France) any info/suggestions regarding how to fix this problem would be appreciated.
John
Ange Ounis wrote:
Yes, your guess is correct. Obfuscation is a good way to delay crackers'action. But delay only, IMO (and do not pretend more anyway). The addin pointed by your link must have minor changes (names of the months) to be localized. Thanks for your input. Regards (and sorry for my english :)
---------- Ange Ounis ----------
Sorry I don't speak French, but if my guess at your meaning is correct this link should help you:
