Programs written for .NET are easy to reverse engineer. .NET applications compile to a high-level, expressive file syntax called MSIL (Microsoft Intermediate Language) that contains method and variable names and can be easily decompiled back into source form.
Attackers can use freely available decompilers to easily see the source of any .NET application, exposing software licensing code, copy protection mechanisms, and proprietary business logic - whether it's legal or not. Anyone can peruse the details of a software application for security flaws to exploit, unique ideas to steal, features to crack, or worse.
This is not the only option, though. Obfuscation is a technique that provides seamless renaming of symbols in assemblies as well as other tricks to foil decompilers. Properly applied obfuscation increases protection against decompilation by orders of magnitude, while leaving the application intact.
When an obfuscator tool goes to work on readable program instructions, a side effect is the output will confuse a human interpreter and break the decompiler the human interpreter was using. While the executable logic is preserved, the reverse semantics are rendered non-deterministic. As a result, attempts to reverse-engineer the instructions fail because the translation is ambiguous. Deep obfuscation creates a myriad of decompilation possibilities, some of which produce incorrect logic if recompiled. The decompiler, as a computing machine, has no way of knowing which of the possibilities could be recompiled with valid semantics. Humans write and employ decompilers to automate decompilation algorithms that are too challenging for the mind to follow. It is safe to say that any obfuscator that confuses a decompiler poses even more deterrence to a human attempting the same undertaking.
Additional layers of protection, beyond obfuscation, are also available. These include Checks, which can actively detect possible attacks (such as tampering, debugging, or running on rooted devices) and can respond with pre-defined behaviors or with custom logic. All these protections work together to make an application extremely difficult to reverse engineer or modify.
Post-compile Protection
It is important to understand that Dotfuscator is a "post-compile" tool - it protects .NET assemblies (.dll and .exe files) that you have already compiled. The development environment and tools do not change to accommodate protection, and source code is never altered, or even read, in any way. Protected assemblies are functionally equivalent to traditional assemblies (except where intentionally changed) and will execute on the Common Language Runtime (CLR) with identical results. (The reverse, however, is not true. Even if it were possible to decompile strongly obfuscated assemblies, it would have significant semantic disparities when compared to the original source code.)
The following illustration shows the flow of a typical build process with and without Dotfuscator:
As shown in the illustration, your application will compile normally and then Dotfuscator will protect those assemblies. Dotfuscator will take the assemblies as input, perform the protection per your configuration settings, and generate protected versions of those assemblies as output.
Getting Started
To get started using Dotfuscator Professional, first install it on your development machine.
- For Windows machines, use the Windows Installer (
.msi). - For macOS and Linux machines, use the NuGet package.
Then, see Protect Your App.
Before Releasing the Protected App
Before releasing your protected app or library, please review the Release Checklist. It gathers in one place all of the topics that should be considered as part of releasing your protected software.