Well it did obfuscate some code (b the property, b the method ), for the rest there is not a lot to obfuscate.

You should not write this.Property, but _privateMembervar, which might create more obscure code.

After playing around a bit - i found like you said that you have to write code with obfuscation in mind. It almost feels like writing over complex code to do something simple but i guess it has to be done to hide the code a bit.

Well, an uninteresting routine isn't worth obfuscating . But if you go over your code and make every public method which is only used by classes internally, internal, same with classes. It increases the obfuscation tremendously.

Obfuscation of inner code is not that important, what's important is that obvious code-paths are obfuscated.

I have only now gotten to the security issue that i was talking about a few months ago. I am wondering about something. Can you use a strongkey and use an obfuscator? I will propably find out later today, but i was just wondering if someone can tell me before i waste my saterday.

Okay, whoo... what a weekend. I added strong names into all my assemblies - except one that was using a Com control. As i thought you can't obfuscate the assemblies with strong names - according to some docs that i read you need to obfuscate and then add the strongnames afterwards - still need to get to this.

Here is the security protection scheme that i followed.

1. Made all class not needed to be public Internal.

2. Made all forms Internal and not Inheritable.

3. Rewrote \ Redesigned alot of protected and public methods to rather call private methods. (So i moved the code that was inside the protected & public method into another new method that is private and then called this private method from the protected \ public method) This will make it more difficult to follow the code after obfuscating.

4. Added a Internal Singleton licensing class with 1 public static method (AddLicenseKey) this method also act as the constructor of the Intertnal licensing class all the other methods doing the validation of the key is all marked as Internal methods to the Internal class.

5. Added checks for a licensekey in a few random places.

6. Added checks in random places for a valid strongname token.

7. Do not raise exception if not licensed or missing strong name - rather cause unexpected events.

8. Added strongnames to all assemblies. (The order of strongname and obfuscating will have to change)

9. Still need to obfuscate.

I hope i covered all possible entry points - let me know if you guys think that i missed anything.

PS - Any idea how to automate the adding of strongkeyname after obfuscation - Me thinking Normal old BAT file.

Also make sure they can't create an instance of your main-form from another .exe. In .NET you can rename a .exe into a .dll and reference it from another .exe, then simply create an instance of the mainform, use a private member invoke to set a license key internally using reflection and then showing the form, viola, cracked. So use a separate startup class which contains your main function, which creates the internal main form, which is also sealed so they can't create a subclass from it.

You can automate the obfuscation in a simple .cmd file and use sn.exe to sign the assembly again. I do that too:

call vsvars32.bat
"C:\Program Files\Microsoft Visual Studio .NET 2003\PreEmptive Solutions\Dotfuscator Community Edition\dotfuscator.exe" /q obfuscate_exe.xml

echo re-signing obfuscated dlls
sn -R "C:\Myprojects\VS.NET Projects\LLBLGen Pro\Distribution\DemoVersion\Obfuscated\LLBLGenPro.exe" c:\myprojects\mystrongkey.key
copy /y "C:\Myprojects\VS.NET Projects\LLBLGen Pro\Distribution\DemoVersion\Obfuscated\LLBLGenPro.exe" "C:\Myprojects\VS.NET Projects\LLBLGen Pro\Distribution\DemoVersion\LLBLGenPro.exe"

Thanks frans, what a mission to keep a persons source code protected.

No, these libs are very lame. It took me 2 minutes to crack the protection of Xheo's demo protection logic, just with reflector and it could have been even less than 2 minutes.

R, you talking about the version without the source code? Because that would make sence - can't be to difficult to remove the calls to the external dll or create a fake dll with same name and exposed public calls with the same signatures.

The other option with included source code should not be that easy to crack.

wayne wrote:

No, these libs are very lame. It took me 2 minutes to crack the protection of Xheo's demo protection logic, just with reflector and it could have been even less than 2 minutes.

R, you talking about the version without the source code? Because that would make sence - can't be to difficult to remove the calls to the external dll or create a fake dll with same name and exposed public calls with the same signatures. The other option with included source code should not be that easy to crack.

Without the sourcecode, just an app downloaded which had that xheo protection. The Xheo licensing lib uses signed xml files, which is good, but the time-trial code uses a registry setting which is easily found, and thus can be renewed or altered.