Visual Studio 2015 Dotfuscator CE Adoption: The first 500 users

August 10, 2015 10602 Views Sebastian Holst

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.

Before I share some of the insights, let me also point out that the instrumentation now inside Dotfuscator CE is the very same as what Dotfuscator CE has been able to inject into .NET apps for Visual Studio users since VS2010. In other words, you can use Dotfuscator CE to achieve these same kinds of results inside your own applications.

Opt-in: of course we collect no information without a user’s informed consent. Happily, 93% of all of our users opted-in (thank you Dotfuscator CE users!). Note, Dotfuscator can inject opt-in policy enforcement too.

Visual Studio SKUs: One important data point we were keen to know was the distribution of our users across the new Visual Studio 2015 SKU’s (Enterprise, Professional and Community Edition). One important historical note: Dotfuscator CE was never included in Visual Studio Express – only the paid SKU’s. For the first time, Dotfuscator CE is now available inside the new (free) Visual Studio CE SKU – and over half of our initial users are coming from this new community. Does this suggest that our total Dotfuscator CE community will double as Visual Studio users migrate to VS 2015? We sure hope so! …and how does this tie back to user registrations? You can bet that we will be tracking this closely.

.NET Runtimes: We can infer quite a bit about the kinds of development our users are focused on by the .NET runtimes their apps target (not the .NET runtime installed with VS2015 which his 4.5 of course). While everyone is excited by the promise of modern development and universal apps, many development organizations’ current projects are still grounded in earlier .NET generations. Clearly, our application protection and analytics will need to support these runtimes for some time to come.

Equipment Manufacturers: In much the same vein, when looking at the underlying devices of these early VS2015 users, we see that they are mostly running on-prem (note, we are looking exclusively at VS2015 Dotfuscator CE users). While everyone is excited about Windows 10 and embracing Azure; early use is still mostly on-prem and, it is for this exact scenario, that our application protection and analytics support on-prem dev environments (and app deployments).

Follow links for:

A comparison of Dotfuscator CE and our other Dotfuscator versions

Stay tuned for more Visual Studio 2015 insights via Dotfuscator CE.

Latest Blog Posts

Protecting C# Applications That Use Dynamic Types

The dynamic type in C# provides flexibility that is not available in other statically-typed languages. Since its introduction in C# 4.0 (.NET 4.5), we have worked with customers who wanted to know more about how dynamic types are impacted by the obfuscation process.

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.

Visual Studio 2015 Dotfuscator CE Adoption: The first 500 users

Protecting C# Applications That Use Dynamic Types

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?

Latest Blog Posts

Protecting C# Applications That Use Dynamic Types

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?

Twitter