Visual Studio 2015 Dotfuscator CE Adoption: The first 500 users

August 10, 2015 10288 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.

Tools don’t hack apps, hackers do: Securing Android apps against Frida

Search for lockpicking and you’ll see that there’s no shortage of suppliers ready to serve locksmiths and hobbyists, each community having a perfectly legitimate need. Is there any reason to believe that burglars don’t shop the same sites?

Hackers are developers and they have a long history of enthusiastically embracing and adapting development (and DevOps) innovations to speed their work, extend their reach, and ship software – the only difference is that they’re more likely to use those development tools and platforms on YOUR software rather than on their own. Static code analysis tools, debuggers, and even public bug tracking databases are all go-to hacker resources.

Can you tell the difference? Exception or the norm?

Of course, everyone is “for security” in principle. The hard question that each organization has to answer for themselves is “how much is enough?” Over-engineering is (by definition) excessive, and over-engineering application security can, in fact, be devastating as overly-complex algorithms, architectures and processes can compromise user experience, degrade performance and slow development velocity. On the other hand, punishment is swift for organizations that cut corners and do not effectively secure their applications, their data and, most importantly their users and business stakeholders. Finding and maintaining that balance can be time consuming and, because you can never be sure you’ve gotten it exactly right, it can also be a thankless job.

JavaScript is everywhere. It’s currently the world’s most popular programming language; as noted by GitHub, JavaScript has the highest number of contributors and repositories, handily outpacing other alternatives such as Python, PHP and Ruby.

The problem with all this popularity? Massive amounts of great open-source code create opportunities for both in-house development teams and malicious actors. The sheer volume of JavaScript-based services means it’s not enough just design apps with security in mind — businesses must actively mitigate emerging threats by obfuscating critical code to frustrate hacker efforts.

Not sure where to start? Here’s what you need to know about the brewing storm of JavaScript attacks and the simplest ways to reduce your total risk.

Over a year ago we wrote instructions for migrating from ProGuard or DexGuard to DashO. Since that time, Google introduced R8, fundamentally changing the Android build process. Now, we have released PreEmptive Protection DashO for Android & Java, version 10.0 with a new Android Mode that is designed to work with R8. With this release, migrating from ProGuard or DexGuard to DashO is so simple that it almost doesn't need instructions - so we're posting new instructions to make that clear!

Welcome to our new instructions!

Before we begin, let's make sure we're all on the same page. We assume you are currently:

We are proud to announce the public release of PreEmptive Protection DashO for Android & Java v10.0, the next major version of DashO, our powerful Android & Java obfuscation and app protection product.

This release has major changes to our Android support. We've blogged about R8 and Google's build architecture changes before, and this new version of DashO works together with R8 to protect Android apps and libraries. R8 does what it is best at: minification (renaming & removal) and performance (build and runtime), while DashO provides strong protection: Control Flow, String Encryption, and runtime Checks for Tamper, Debug, Root, Emulators, and more. Together you get the best of both worlds.

To accomplish this new integration, we rethought DashO from the ground up, creating a brand new Android Mode with big changes to UI, build-time behaviors, and the way DashO integrates into a Gradle build. It's DashO unlike you've ever known it: even easier to integrate, easier to understand and configure, and easier to keep up to date as your code and Android evolve.

Visual Studio 2015 Dotfuscator CE Adoption: The first 500 users

Tools don’t hack apps, hackers do: Securing Android apps against Frida

Trusted Computing: Panacea or Magical Thinking?

Can you tell the difference? Exception or the norm?

No Beans About It: Why You Need JavaScript Obfuscation

Migrating from ProGuard or DexGuard to DashO - Updated!

DashO 10: Android support, rebuilt from the ground up

Latest Blog Posts

Tools don’t hack apps, hackers do: Securing Android apps against Frida

Trusted Computing: Panacea or Magical Thinking?

No Beans About It: Why You Need JavaScript Obfuscation

Migrating from ProGuard or DexGuard to DashO - Updated!

DashO 10: Android support, rebuilt from the ground up

Twitter