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

October 28, 2015 9909 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

Non-Traditional Attack Vectors: Three Questions Every CISO Needs to Ask

Malicious actors — like any thieves — live by a simple rule: If the front door is locked, break the window.

It’s why threats like fileless malware and crypto-jacking have seen substantial gains over last few years. It’s why — despite increasing employee education and IT training — hackers are still hooking phish by developing more sophisticated and authentic-looking email spoofs. Cybercriminal communities, meanwhile, continue to grow on the dark web, allowing attackers to share info, purchase exploit kits and identify potential targets.

What does this mean for CISOs? That typical defense efforts are being outpaced as familiar attack vectors are replaced with non-traditional threats. But it’s not all bad news; here are three questions every CISO needs to ask to help close the doors, bolt the windows and leave hackers out in the cold.

Gabriel, you have been in the security industry for over 2 decades. You have seen many different tools and services. Why create a company around something as specific as obfuscation and in-app protection?

Our customers build a lot of really innovative apps that enable their users and customers to do new and cool things. These apps frequently run on untrusted client computers/devices and they control access to customer’s sensitive data or critical devices.

And after all the effort of designing, building, debugging, and deploying their applications, the last thing they want is for an attacker to steal their work or use it to look for vulnerabilities to break into their system.

Long ago, we built a Java code optimizer, but it became clear to us that our customer cared more about the obfuscation effects of the optimization than the actual performance improvement. That is when we really began to focus on app protection. First with Java, then .NET, Android, iOS, Xamarin, JavaScript, etc.

Gartner calls In-App Protection “crucial” in their July 2019 Market Guide for In-App Protection In-App Protection. The guide’s summary advises security and risk management leaders to “take due care in protecting their application clients” in order to avoid “security failure.”

This raises the question – what constitutes “due care?” Obviously, no development organization looks to recklessly expose their applications or sensitive data to attack or compromise. On the other hand, over-engineered (or poorly engineered) security controls can quickly lead to excessive development costs, performance and quality issues, and, ultimately, unacceptable user experiences. While terms and terminology may vary, there is broad consensus on how to best define “due care” for any given application/user scenario.

If you don’t follow application security closely, you might think of application obfuscation and symbol renaming as being synonymous – and with good reason. Many platforms and languages, like .NET, Java, and JavaScript have popular obfuscators that do little else--our own Dotfuscator Community Edition for .NET and ProGuard for Java are good examples. However, obfuscation is far more than symbol renaming – and in-app protection is far more than obfuscation. Much of this expansion has been driven by new security requirements, shifting attack vectors, the rise of mobile and IoT computing and, lastly, the growing recognition inside regulations and legislation of the exposure that can result from inadequately protected software.

PreEmptive has partnered with Microsoft for 16 years and we’ve been involved with .NET since before version 1.0 shipped. From that perspective, it’s hard for us to pinpoint a time where the energy and enthusiasm in the .NET community has been higher than it is now. Over the past few years, Microsoft has put together the annual .NET Conf, completely online with viewers, participants, and local events all over the world. The event is virtual and streamed live over three days.

The big news at this year's .NET Conf was the launch of .NET Core 3, the next step in the continued evolution of .NET. .NET Core 3 is a huge effort, with many moving parts, and Microsoft announced many related releases to support it. Highlights for us included:

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

Non-Traditional Attack Vectors: Three Questions Every CISO Needs to Ask

Q&A With PreEmptive CEO Gabriel Torok

Gabriel, you have been in the security industry for over 2 decades. You have seen many different tools and services. Why create a company around something as specific as obfuscation and in-app protection?

The Secret to Effective In-App Protection

Symbol Renaming: App Security’s Maginot Line?

Highlights from .NET Conf 2019

Latest Blog Posts

Non-Traditional Attack Vectors: Three Questions Every CISO Needs to Ask

Q&A With PreEmptive CEO Gabriel Torok

The Secret to Effective In-App Protection

Symbol Renaming: App Security’s Maginot Line?

Highlights from .NET Conf 2019

Twitter