次の方法で共有


Introducing code obfuscation

If you recall from an earlier post, I said that the main reason for signing an assembly and giving it a strong name was to prevent it being tampered with. For example, many of the assemblies that make up the .NET framework itself are strong-named assemblies that sit in the GAC. If I disassembled one of these, messed around with the IL code, and then reassembled it, I'd have to sign it with my signature. Running any existing applications that used the assembly I'd changed would now fail, because the signature had changed. That's all great in that it stops anyone tampering with existing, deployed assemblies.

What may still be a concern is that the IL code is still legible, so that anyone can see how your code works and what it does (provided they spend a bit of time getting familiar with IL code). This raises the issues of intellectual copyright and opens the potential for security breaches as unscrupulous developers can easily look for weaknesses in your application.

Enter code obfuscation (Dotfuscator on Visual Studio's Tools menu). This utility renders the contents of your assemblies (the IL code), incomprehensible to human readers, but leaving it so that it can still be run by the CLR. This is done by renaming everything in sight, variables, classes, methods etc with meaningless or duplicate names. Obfuscation is an excellent demonstration of how useful good names are to understanding code!

Comments

  • Anonymous
    June 12, 2009
    This raises the issues of intellectual copyright and opens the potential for security breaches as unscrupulous developers can easily look for weaknesses in your application.