How to Leverage Incremental Obfuscation when Protecting Large Applications￼
Published on June 2, 2022 by John Brawner
In the previous Support Corner article, we discussed the significance of Cross-Assembly Obfuscation when configuring Dotfuscator. Cross-Assembly Obfuscation ensures that classes, methods, properties and their references are automatically renamed uniformly across all Dotfuscator inputs.
Separated Assemblies Obfuscated
When related assemblies are obfuscated separately, they’re processed in Library Mode by default. Library Mode does not rename public and protected types and members so that they can still be called by assemblies not included in that Dotfuscator project. (Obfuscation transforms like Control Flow, String Encryption, and Tamper detection will be performed regardless of access modifier).
What if the different components of our app must be obfuscated as separate projects, but we still want to fully rename public types and members? This can be achieved by using Incremental obfuscation.
Incremental obfuscation uses Dotfuscator’s Rename Map file to maintain consistent identifier renaming across Dotfuscator builds. It was created to enable patching a subset of assemblies for an obfuscated app already in production. It can also be used to rename serializable types, so that full Renaming can still be performed on apps that persist serializable types to file.
Along these same lines, Incremental Obfuscation can be used to maximize renaming when separating components of an app into multiple Dotfuscator projects.
Consider the following example: a company maintains a set of common assemblies used by several different projects. Each project has completely different sprints and release cycles. In this scenario, the team maintaining the common assemblies uses Dotfuscator to fully obfuscate and rename publics. They store the Rename Map file with their build artifacts. Any team creating a front-end app will use that map file to rename references to the shared assemblies in their Dotfuscator project. Only the map file is needed – they do not need to re-obfuscate the common assemblies. When it’s time to deploy to production, all public and protected types and members for the full application will be renamed.
A simple example illustrating this concept can be downloaded here.
If you have feedback on this topic or other topics you would like us to discuss in the Support Corner, please feel free to contact our Support Department.