Plateforme Level Extreme
Abonnement
Profil corporatif
Produits & Services
Support
Légal
English
How to protect be decompiled?
Message
 
À
03/01/2005 09:23:07
Information générale
Forum:
Visual FoxPro
Catégorie:
Autre
Divers
Thread ID:
00972325
Message ID:
00973805
Vues:
30
Hi JOs,

> One could then global replace these plain variable names with more meaningful names once the variable purpose is more clearly understood

I should have added a few remarks to my message that I made in my session. First of all, obfuscation (which includes replacing variable names) is meant to make it harder to reader source code, not to make it impossible. The best you can expect with any technique is to increase the time that a cracker needs to get what he wants. Your bets are worse if you have an application that is usable for a long period and doesn't require updates, you bets are much better with software that requires permanent updates. Part of my work is writing business software were people need the new version a few days after we sent it, because by then there are legal requirements to handle things in a specific way. This is in the Health Care industry and fortunately our politicians are chaning the rules every few months. <g> If you can delay the decompilation just by two weeks, you make cracking useless for anyone who really needs to use the software.

Back to variable names. Search and replace is definitely the biggest issue with this kind of obfuscation. Therefore my recommendation was to reuse names as much as possible. That means all procedures use exactly the same obfuscated names for their local variables. The same names are used for procedures, for classes, and everything else where VFP can distinguish a name by its type. Furthermore, names should be subsets of other names. If one variable is named abcdefg, a second one should be abcdefgh, that is, extended by one letter. A third variable might be bcdefgh, that is, the first character has been dropped. This way, you need to write a more sophisticated parser to replace strings. It's not impossible, but it's harder to do.

Next, you should change the names with every build you generate. The same applies to the order of variables in the LOCAL statement. Your code doesn't care if you write LOCAL lc1, lc2 or LOCAL lc2, lc1. But internally, the variable names are assigned numbers. By changing the name and the order, you make it impossible to use the name table or the declaration position to identify a variable. Instead you have to store the pattern in which a variable is used and re-locate the pattern to identify a variable once the name changed. Again, not impossible, but harder to do.
--
Christof
Précédent
Répondre
Fil
Voir

Click here to load this message in the networking platform