.NET Native; what's it mean for obfuscation and Dotfuscator in particular

October 28, 2015 10939 Views Sebastian Holst

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.

Here’s an excellent blog post from MSFT on this: .NET Native – What it means for Universal Windows Platform (UWP) developers.

While this probably eliminates most dev organizations in the near term, lets assume that a dev organization is fits into this narrow scenario. Let’s focus on comparing obfuscation to native-generation when both are available.

First, there is no doubt that many app dev teams that might have needed an obfuscator to prevent reverse engineering of their apps back into C# will no longer have that requirement.

However, .NET Native is a performance optimizer – NOT an app security tool – and so (while there is most certainly overlap) the two are not synonymous. For example,

One would not expect to see string encryption happen inside the .NET Native generation process (and sometimes that is all a bad actor is trying to look at)
None of this addresses “detective controls” (triggering defensive behaviors when an app is tampered with for example) Note – while not technically an “obfuscation transform” this is a feature included with Dotfuscator for non-universal apps.
When components run on a device as a universal app AND share function calls/name spaces, etc with non-universal components – cross-assembly renaming/obfuscation is still required for the non-universal components and then must be extended into the universal app when they need to interoperate. This can also apply when libraries are distributed across multiple dev organizations – that may not even be part of the same org and so the “protection” is on the library against library dev users.

Our view is that dev orgs should first assess what risks matter to them (not a technical metric) and then take appropriate steps to mitigate ONLY those risks – and for many (but not all) who develop exclusively standalone universal apps distributed through a MSFT marketplace (the VS2015 .NET Native generator in VS2015 is only for your testing – it’s the MSFT marketplace that ACTUALLY does this transform in production) – the .NET Native process will have the added benefit of eliminating the need for a commercial obfuscator. …BUT, there are many scenarios that will not fit neatly into this construct.

PS as a “fun fact” – PreEmptive’s first obfuscation product was for Java (it pre-dates the existence of .NET) and is (still) called DashO (“-o” is the “optimize” command for Java). So yes, the first obfuscator began its life as an optimization tool in the 1990’s – firmly establishing the the connection between optimization and obfuscation – but that does not make them synonymous.

Another “fun fact”, a large part of why MSFT asked us to build the .NET obfuscator in 2002 was because (prior to .NET) MSFT was a Java obfuscation client of ours.

Latest Blog Posts

Protecting Utilities and Infrastructure with PreEmptive's .NET Solution, Dotfuscator

Protecting Industrial Internet Applications

Bayshore Network Case Study

Today’s utilities, factories and other infrastructure are exposed to high risk. The software that controls many of these entities is not protected. In the last 20 years, the way industrial environments operate has completely changed. Many industrial systems were designed with permissive set-ups that assume only the “right people” in the “right place” would ever give instructions. Past systems were not built with exposure to the internet in mind, and as a result they relied on this “air gap” to limit access to only authorized personnel within the organization. The rate of innovation within technology and wireless systems has outpaced the rate of development in security features. Control centers have gotten better - high tech displays and more capability, but this has led to an exposure to untrusted environments… and in many cases this threat has not been addressed.

Application security can often be viewed by development teams as a time-consuming barrier to finishing a project. In a world where "time equals money", the rush to ship functional applications can overshadow the need to ensure those applications are secure. It is true --- features are what sell software and fixing bugs retains customers and loyalty. Both actions can be directly linked to revenue and profitability. So, what effect does an investment in application security have on a company's bottom line?

The coronavirus crisis is changing human behavior. From the persistent need for social distancing to the potentially permanent adoption of work-from-home mandates, the “new normal” is uncharted territory.

But the growing priority of public health also has knock-on effects in other fields, such as credit and debit payments. While the United Stated has historically lagged behind other countries such as Canada, the United Kingdom and Australia when it comes to the adoption of contactless card transactions, the demand for physical distance now trumps the functional familiarity of swipe-and-signature or chip-and-PIN interactions.

Facilitating “no contact normalcy”, the PCI Security Standards Council (PCI SSC) includes guidance for both commercial deployments and software applications to help solve potential payment security gaps. Here’s what you need to know.

Localization is often a key ingredient when building Xamarin Forms applications with a global audience. There are different ways to approach app localization, but most of these leverage the built-in tools provided by the .NET Framework. These include RESX files to configure localized strings and an auto-generated resource class which provides strongly-typed access to the string translation at runtime. This mechanism has been available since .NET 1.1, and is used for localization of WinForm, WPF, ASP.NET, and Xamarin applications.

In the months since we released the Dotfuscator 6 beta, we’ve been hard at work finishing the feature set, fixing issues, and putting on the final touches in preparation for the full release. Now, we are happy to announce the full availability of Dotfuscator 6!

.NET Native; what's it mean for obfuscation and Dotfuscator in particular

Protecting Utilities and Infrastructure with PreEmptive's .NET Solution, Dotfuscator

Mobile Application Protection Increases Profits

No Contact Normal: Solving the Payment Security Gap

Protecting Localized Xamarin Forms Applications

Dotfuscator 6: The Next Era of Dotfuscator

Latest Blog Posts

Protecting Utilities and Infrastructure with PreEmptive's .NET Solution, Dotfuscator

Mobile Application Protection Increases Profits

No Contact Normal: Solving the Payment Security Gap

Protecting JavaScript Code: The Making of JSDefender

Protecting Localized Xamarin Forms Applications

Twitter