Programmers obfuscate code to conceal its purpose or its logic, in order to prevent tampering, deter reverse engineering. Program that obfuscates is called an obfuscator.
- Configuring Visual Studio for Obfuscation
- Giving a .NET Assembly a Strong Name
- Delay Signing
Assemblies can be obfuscated using a GUI and/or a command line program. GUI program helps in learning to select/define various settings which specify the different ways an assembly can be obfuscated. The obfuscator command line program is used in scripts that help automate the build process. In VS, the obfuscator command line program is executed in a project’s post-build event, immediately after the project’s assembly gets created.
Approach to obfuscate assemblies depend on the assembly type. Let us look at three type of assemblies. Private assemblies that may not be signed at all, Strong named assembly signed with the private key from a strong name key file. Delay signed assembly signed with the public key from a strong name key file. Obfuscating a private and a strong named assembly is straightforward. Obfuscating a delay signed assembly becomes tricky, when the assembly is installed in the Global Assembly Cache (GAC)
VS solution can have multiple build configurations. Which configurations do you apply obfuscation to? When the Debug solution configuration is selected then my tests are always run against the non-obfuscated assemblies. Do we generate both obfuscated and non-obfuscated assemblies under the Release solution configuration?
If a problem occurs in the obfuscated assemblies, developer wants to test for the problem occurrence in the non-obfuscated assemblies. The question becomes whether problem created is related to the process of obfuscation. Thinking deeply you question also how to configure VS to selectively build non-obfuscated assemblies in one run and then build obfuscated assemblies in another run?
The solution is to create a third solution configuration based on the default release configuration called Obfuscated Release. On selection, obfuscated assemblies are build.
How to confirm that your assemblies are being obfuscated? When the obfuscator is executed in the post-build event, it should log information in the VS output window. Hence, when you do not see this information in the VS output window then the obfuscator has not been executed.
One can make use of ILDASM.exe to view human-readable info about an assembly. If ILDASM displays such info then the assembly has not been obfuscated. On other hand, if ILDASM is unable to display such info, then assembly may have been obfuscated.
Does reflection and obfuscation play well together? Not always. If you write code that uses reflection to query information about MyClass then this code will fail because the name MyClass does not exist in the obfuscated assembly. Be prepared for obfuscation to introduce bugs into your applications that use reflection.
How to start debugging a problem with no prior obfuscation experience? Start with checking whether the problem occurs under in Debug and Release solution configurations with disabled obfuscation. If problem is reproduced, fix problem and end debugging.
If problem in production does not get reproduced, move forward to second step. Modify the obfuscator project file to disables every single obfuscation setting and try to rebuild the application to see if the problem reoccurs. If the problem does not occur, enable one obfuscation setting and test again.
Keep continue enabling obfuscation settings one at a time, and testing application until problem gets reproduced.