Enterprise application development involves several moving parts. There may be different teams working on different components: server-side, client-side, GUI, API, database, etc. Each component may have a completely different release cycle, and each team may be working completely independent of one another. But however the work is divided, all these components must come together to work properly at runtime. Any professional application protection tool should have the ability to handle these complex scenarios without disrupting the development process.
Dotfuscator is designed with that at the center. The tool allows users to get up and running quickly, while providing full control to adjust for specific project requirements. Cross-Assembly Obfuscation is just one example of the many ways it provides us this flexibility.
Dotfuscator treats its inputs as a set of related assemblies. It examines all internal and external references, traverses the full inheritance hierarchy. It then performs “Cross-Assembly Obfuscation” meaning classes, methods, properties and their references are renamed uniformly across all input assemblies.
If it’s not feasible to obfuscate and deploy our entire application at the same time, this is not a problem for Dotfuscator. It can be approached a few different ways, but the easiest to maintain is to build with Library Mode enabled for each project. In Library Mode, Dotfuscator preserves public and protected types and member names and signatures. Only private and internal types and members will be renamed. Obfuscation transforms like Control Flow, String Encryption, and Tamper detection will be performed regardless of access modifier. This ensures that calls to the obfuscated assemblies work properly whether the calling assembly has been obfuscated in the same project or not.
A simple example can be downloaded here. This shows the same set of assemblies (two dll’s referenced by one main exe) obfuscated two different ways. In the first scenario, all assembly files are included in one Dotfuscator project. In the second scenario, each assembly is obfuscated separately, with Library Mode enabled to preserve references between them. In both scenarios, the obfuscated binaries come together to work properly at runtime.
Stay tuned for our continuation article, we will examine other strategies for approaching obfuscation spanning different teams. 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.