Note: this document is deprecated. Please see Obfuscating Xamarin Applications with Dotfuscator for up to date instructions on obfuscating Xamarin applications.
We've previously blogged about Using Dotfuscator Professional with Xamarin Applications. We've also blogged about the recently added command line support for Dotfuscator Community Edition. Now it is time to put these two concepts together, and show how to make reverse-engineering your Xamarin application more difficult by integrating Dotfuscator Community Edition (CE) into your Visual Studio build process.
Code obfuscation and the doctrine of “contributory negligence”
On May 11, 2016, President Obama signed the Defend Trade Secrets Act of 2016.
Enjoying unprecedented bipartisan support (Senate 87-0 and the House 410-2), this bill expands trade secret protection across the US and substantially increases penalties for criminal misconduct – and what could go wrong with that?
At Microsoft Build 2016, we introduced a new feature for Dotfuscator Community Edition (CE): command line support. This will allow you to integrate Dotfuscator into your automated build process, so that your builds and releases can automatically use Dotfuscator for obfuscation, tamper protection, usage tracking, and expiration. To help you get started, this post will walk through how to use the command line interface (CLI), as well as how to integrate it into MSBuild and Visual Studio for automated builds.
Question: True or False, Seat belts are to Driver Safety as Obfuscation is to Application Risk Management
The correct answer is FALSE!
The equivalence fails because a seat belt is a device and obfuscation is a control. Why might you (or the application stakeholders) be in danger? First, read through the key descriptors of these two controls.
I recently got a question from a client asking why .NET Native (the process of transforming a .NET assembly into a native app to improve performance) did not also make products like Dotfuscator irrelevant. Here's my response (with personal details removed of course).
First, the .NET Native process is only applicable to Universal Apps distributed through a Microsoft marketplace. If you are developing .NET (using VS2015 or anything else) BUT are targeting anything other than a Universal App architecture - .NET Native does not apply – also, if you’re developing in F# - even if Universal - .NET Native does not apply.
Live technical support from PreEmptive’s (world class) product support team plus an application protection white paper
The fine print… Visual Studio 2015 users who register Dotfuscator CE (it's inside Visual Studio 2015 already) will receive immediate access to the recent white paper, Application Protection. Why bother? AND receive a credit to open one (1) support ticket with PreEmptive's product support team any time in (you guessed it) 2015.
For the first time since its launch in 2003, Dotfuscator Community Edition (CE), the no cost obfuscator included with Visual Studio, can send anonymous usage data for analysis (only after opt-in of course). …and after one week and 500 users, the resulting application analytics is already proving its worth.