The most widely used .NET obfuscator – and now, much more
This morning, as we readied our latest Dotfuscator Community Edition (CE) announcement, it struck me that this remarkable piece of software has a unique story to tell. A story that can’t be expressed in a feature table or change log.
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.