PreEmptive Protection - Dotfuscator began life as the world's first .NET obfuscator; nearly fifteen years later, Dotfuscator has grown beyond just obfuscation to become the industry-standard .NET protection tool, able to protect your .NET applications against IP exposure, tampering, and unauthorized debugging.
We are pleased to announce that Visual Studio 2017 honors the tradition set by its predecessors and ships with a free copy of Dotfuscator Community Edition.
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.
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.