>>>Here's what I think should be the perfect protection. A tool that goes throught a VFP project and does a replace of all the variables, function names, procedure names ... by a meaningless name.
>>
>>Yep...and what do you name all this stuff? pick like ones (1) and the letter L's (l), zeros (0) and hte letter O (O)...things like that...so someone sees a varable/procedure named 110Oll1lOO00OO11l010l ....not going to help them out too much...hehehe
>>
>>I've been following this thread pretty closely, as this problem is one I've been interested in. IMO, what it boils down to is just how hard you want to make it for the cracker (note that this is a cracker, not a hacker).
>>If the cracker has no choice but to do a memory dump and then reassemble the thing, at least make it difficult to do much with it once they've got to that point (hence, the 1's and 0's trick).
>>There is also the hardware way - with the little dongle thingy - but again crackable. As for that armadillo thing - sorry guys but it's protection scheme was cracked several months ago.
>
>Victor,
>
>First of all, thanks for reminding me that it is indeed cracking, not hacking.
>
>About decompiling natively encrypted code, without debugging info: Since many years I have this idea in my head that all variables are nonsensical in the output that refox produces. Now I'm not sure anymore. Who knows more about this aspect?


"Debug info off" and "encryption" do nothing to variable names. How can your app know the variable name and not the decompiler? Stick a "variable not found" error in your "debug-off/encrypted" VFP exe and run it. See the variable name? Debug-off and "encryption" did not remove the variable name. It is not an obfuscator.