>>
>>Yes, I see the variable name. But it may be argued that it does not exist in any variable table. So, I searched for another example:

private hello
>>hello=1
>>public hello

It indeed produces an error message with a full variable name. Hmmm...
>
>Hi
>But try to see how this looks when decompiled :)
>

>#define _upper 		_1F301IKQZ_1F301IL3J_1F301QU38_1F301QUJR
>#define _lower 		_1F301J0AP_1F301J0JR_1F301QWNR_1F301QWSG
>#define cstring1		_1F301KI1M_1F301KI9A_1F301QYAL_1F301QYCK
>#define cstring2		_1F301KWZ4_1F301KX4T_1F301QZXO_1F301R018
>
>
>?'Upper', _upper('some string')
>?'Lower', _lower('some string')
>
>PROCEDURE _upper
>LPARAMETERS cString1
>RETURN UPPER(cString1)
>
>PROCEDURE _lower
>LPARAMETERS cString2
>RETURN LOWER(cString2)
>

Hi Dorin.

This technique looks much more confusing than it actually is. Once decompiled the cracker would global replace those long, visually confusing variable names with simple to read names like xVar_001. Then it becomes much easier to read and track the variables through the program.

imo, this is a type of "security through obscurity", which is virtually no security. By the time this technique comes into play the cracker has your source code in hand! I think by that point you are seriously in danger of losing it.

You get far more security for your code by applying an exe packer/compressor like Konixse, Thinstall, etc.