• Some users have recently had their accounts hijacked. It seems that the now defunct EVGA forums might have compromised your password there and seems many are using the same PW here. We would suggest you UPDATE YOUR PASSWORD and TURN ON 2FA for your account here to further secure it. None of the compromised accounts had 2FA turned on.
    Once you have enabled 2FA, your account will be updated soon to show a badge, letting other members know that you use 2FA to protect your account. This should be beneficial for everyone that uses FSFT.

Protect .NET source code by obfuscating it???

I cannot answer your question, however I believe that the tool that you want does not exist:
It should prevent of decoding our code by disassemblers.
Click to expand...

The best you can do is "make it more difficult" to disassemble the code. Given the means (cash) and motivation, I doubt that there is any way to prevent decoding.
 
write your assemblies the way you normally would, then encrypt the resulted dll, embed that in another dll, load the original from a resource. decrypt, and invoke through reflection.

thats a pretty safe way to go about it, but will add a slight performance and dependency hit.

otherwise http://www.xenocode.com/ is a fairly good obfuscator (gives you enough to shoot yourself in the foot with)
 
The best you can do, period, is make it more difficult to get at your source code. That is true for any program residing on the client's computer, whether it is written in .net or any other language. Java and .net apps are just easier to decompile by default.

With code protection, I see two main goals:

1) Keep the casual snoops out
2) Make it more difficult for the real hackers/thieves

For #2, you want the process of stealing your work to approach the difficulty of just creating a similar program from scratch. That is as good as it gets for this type of thing.

Almost any obfuscation tool should handle #1. All of them should also start on #2 but some are better than others. The most-used decompiler is Reflector so you can use that as a nice benchmark on how hard it is to read your code after obfuscation. As for the different obfuscators, I would download the trials and test them out. I know a coworker is looking at codeveil and demeanor.net.

As for _madHatter's idea of encrypting the the assembly, I would recommend against that as your sole means of protection. It would handle the goal #1 but not #2 as the program required to load the encrypted assembly would easily be decrypted, modified, and made to write the unencrypted assembly back out to disk. It could be included as a layer of defense if you also obfuscated the assembly you are encrypting, but in my opinion it would not be worth the extra complexity. However it might sound good when you tell your boss or other exec, and that can sometimes be more important :)

The only real way to keep your code safe it not to have your program reside with the client. Perhaps using a webservice to handle your proprietary algorithm, though that might be clunky and ill-fitted for many applications.

So in summary, use some sort of obfuscation since it is by far better than nothing. I don't know which obfuscators can be part of the build process.
 
Yes the community edition is included with Visual Studio 2003 and 2005 but it is basically a lite version. Muich better than nothing most certainly though!

Check the results out with Reflector and decide if it is enough protection for your needs, and if not then look at your alternatives. Make sure to check if the strings are encrypted, I don't recall offhand if they are in the community edition.
 
You must log in or register to reply here.
Back
Top