One of the advantages of managed code is that instead of being compiled directly into native CPU instructions, it gets built into “IL”, a higher-level binary code that is abstract from the actual CPU type the executable may be run on, and which contains enough meta data that it can be analyzed and verified to be “safe” by the run time, before actual execution.
The downside is that the higher-level code can also be easier to disassemble and reverse engineer, because it contains the full names of classes and their members, as well as code structures that are relatively easy to put back into readable code. Tools such as .NET Reflector or ILDASM which ships with the .NET Framework SDK, allow developers to look at and understand the ongoings in compiled .NET assemblies.
Sometimes this is not desirable, as code may contain trade secrets or confidential business logic that should not be readily accessible to users of the application. This is where so-called code obfuscation comes in. Obfuscation is a process that takes an existing .NET executable (or set of assemblies), and processes it to make the code unreadable with tools like Reflector, without actually changing the behavior or the code itself.
RemObjects Oxfuscator is a state-of-the-art obfuscation solution that integrates directly into the Visual Studio IDE and MSBuild compilation process, to let developers obfuscate their executables as part of the regular compile cycle. Oxfuscator can process assemblies generated with C#, Visual Basic .NET, Oxygene or any other .NET language. It can be controlled and configured using Attributes inside the code, or via its project property pages within the IDE.
Oxfuscator is deeply integrated with the Visual Studio IDE, and offers a great workflow and seamless interaction with the development cycle. It provides its own project system, allowing your obfuscation project to show in the Solution Explorer alongside your regular code projects. It re-uses the already familiar concept of References to refer to the assemblies that are part of the obfuscation process, including support for file and project references. With this, Oxfuscator automatically participates in the dependency management provided by Visual Studio, making sure Obfuscation happens at the right time within the build cycle.
As with any project in Visual Studio, Project Property sheets are provided to configure and control the project. For Oxfuscator, this means providing detailed control over the obfuscation process, including the ability to selectively exclude classes, members, or even whole namespaces from obfuscation. This is crucial when obfuscating internal parts of libraries that expose public APIs that should remain accessible.
Obfuscation excludes can also be controlled via attributes in the source code, where possible.
Obfuscation itself is implemented as an MSBuild task, so that it fully integrates with your solution's build cycle, not only inside Visual Studio, but also when building from the command line or in your automated builds or continuous integration system.
XBuild, Mono's implementation of the MSBuild system, can be used to obfuscate projects when building your projects on Linux or Mac OS X.
In addition to control over which names will get obfuscated and which will be excluded (i.e. preserved), Oxfuscator also provides different levels of obfuscation, ranging from readable (but nonsense) identifiers that make it easy to debug obfuscated solutions, all the way to using identifiers that consist purely of whitespace and other unreadable unicode characters — making it next to impossible to keep track or make sense of code in tools like Reflector or ILDASM.
The screenshot below shows one of Oxygene's sample projects in Reflector; on the left is the original, unobfuscated executable, on the right is the resulting output of the default Oxfuscator obfuscation: