Announcing DashO v9.0

August 13, 2018 703 Views Nathan Arthur

DashO v9.0 is out, and it has a new major version number for a very good reason: we've made some major improvements!

Java 9 and 10 support, including module support

In DashO v8.4, we introduced "provisional" Java 9 support, and we published an article describing our Java 9 roadmap. Java 9 support was provisional because there were cases where DashO would process a Java 9 app in a way that DashO thought was correct but would actually result in a broken app. As part of our commitment to the "principle of least surprise", we didn't want users to discover those issues by accident, so we made Java 9 support require an opt-in.

As of DashO 9, Java 9 (and 10) support is no longer provisional; it is a fully-supported feature, without an opt-in - and without surprises. There are a few edge cases, still, but those will generate build warnings or errors, as appropriate.

One notable edge case is our support for Java Modules as introduced in Java 9. DashO fully supports processing modules (including .jmods) as support libraries. DashO also supports processing modules as inputs, but module support remains provisional - it requires some hand-configuration, and there are some special cases to be careful about. But DashO can process modules - and it is the only obfuscator able to do so today!

DashO's Checks are also fully supported on Java 9 (and 10), and they work just like they do on every other Java version.

See the Java 9 and Later page in the user guide for details, and other notes.

Specify the app's target JDK

In all prior versions, DashO would use the JRE that it was running on to resolve class dependencies for inputs. In general, this was fine; most developers build and run on the same version of Java.

Now, when DashO is run on a Java 9 (or later) JRE, the framework classes aren't available - the JRE is distributed in a way that we can't read and parse as usual. We've therefore created a new Include JDK setting, so that DashO knows where to look for dependencies. Starting with v9.0, DashO will require that projects be configured with a specific JDK, if those projects include any Java 9 (or later) inputs. (Note that the JDK configuration can take advantage of property references so it is very easy to have flexible install locations for JDKs.)

The old way of using the JRE DashO is running on is still supported for Java 8 and earlier, but it will generate a warning even on those versions.

This means that DashO can now:

Run on a Java 9 (or later) JRE without issue.
Provide JDK-version-appropriate configuration options and build-time warnings and errors.
Process apps built with a newer JDK than DashO is running on. (Up to the latest version that we've released support for.)
Be sure that it is finding the correct version of any JDK classes referenced.

Control Flow improvements (especially for Android)

DashO 9 introduces a new Control Flow obfuscation technique, block splitting. Block splitting targets segments of code that have no inherent control-flow logic. It splits them up and adds new, complex control-flow logic, making them extremely difficult to understand.

This new technique is especially important for Android apps, where the transformation from Java to Dex (and back to Bytecode, when decompiling) could partially undo some of the other Control Flow techniques (for simple basic blocks). This new technique is not undone by that round-trip process, so it maintains protection even for simple - but potentially sensitive - parts of the code.

Block splitting can be tuned by setting the target size of the split blocks; smaller sizes result in more splits, and stronger protection, but also in more code added to the app.

This new technique is enabled by default for all projects processed by DashO v9.0 (or later) that have Control Flow enabled - even projects created with older versions of DashO. It works alongside our other Control Flow techniques - block jumbling and try/catch injection - to provide even-stronger protection.

Breaking changes

With this release, we took the opportunity to remove some unused or unnecessary features, to help make our ongoing development easier and faster. These include:

PreEmptive Analytics injection, which was deprecated in DashO v8.4, has been completely removed.
"Quick Jar" mode, which was deprecated in DashO v8.2, has been completely removed. (Projects will be auto-converted.)
It was possible to configure DashO entirely via our Ant integration, in prior versions. That detailed configuration capability was deprecated in DashO v8.5, and has been completely removed. (The Ant integration itself is still fully supported.)
The "Append current Java runtime" and "Use classpath from environment" features have been deprecated for Java 8 and under, and are not supported for Java 9 and above.
DashO's startup scripts had hard-coded memory limits, which have been removed. This may result in build performance improvements for some users, but it might also result in unexpected memory use by DashO, so we waited until we had a major version bump to release it.
There are other minor breaking changes documented in [the changelog].

Smaller enhancements, changes, and fixes

Every DashO release has some smaller improvements, and this release is no exception. A few notables:

This release may include protection enhancements not described here.
A few aspects of the New Project Wizard have been updated to improve usability.
The various configuration property editors (mostly on the include/exclude screens) have been reworked to make their features more discoverable and easier to use.
Google introduced Google Play App Signing which affects how DashO users will need to configure our Tamper Check; this release includes instructions and support for doing so.
Additional enhancements, changes, and fixes are documented in [the changelog].

Getting Started with DashO 9

There are many changes in DashO 9, but even so, we've worked hard to make this release as backwards-compatible as possible. If you aren't directly using one of the features that we removed (or if it is a feature we auto-migrate!) then you probably won't be affected by our changes - go ahead and upgrade as usual and your build should work - as usual!

And with your upgrade you'll automatically get a wide range of new features:

Java 9 and 10 support
Control Flow improvements
Flexible handling of build-time JDKs
Usability improvements
and more!

Free Trial

Request Quote

Request Demo

Protecting .NET applications that use the MVVM pattern

Model–View–ViewModel (MVVM) is a common pattern used in WPF, Xamarin, and other types of .NET applications. There are different ways to apply the MVVM pattern, but they all share a few underlying concepts. I’d like to discuss these concepts, and how to successfully configure protection with Dotfuscator for MVVM-based apps.

Credentials are a problem for your app. Why? Because they’re a critical access gateway: If attackers get their hands on working usernames and passwords they can cause havoc — everything from stealing user accounts to compromising high-level application functions.

It’s big business; Sensor Tech Forum notes that 85 malicious apps on Google Play were stealing login credentials, while Verizon’s 2018 Data Breach Investigation Report found that 81 percent of hacking incidents used weak or stolen passwords.

And while part of the problem rests with users choosing username and password combinations that are easy to remember and easy for attackers to guess, applications have their own issue: Hard coding. From smart city software to stock trading applications, the use of hard-coded credentials saves time upfront but significantly impacts security.

Don’t become an easy mark for hackers: Here are six ways to boost credential control and reduce total risk.

In 2017 and again in 2018, PreEmptive Solutions surveyed over 15,000 professional developers asking about their organization’s current and projected use of a broad cross-section of development languages and frameworks.

Evaluating each annual survey result on its own and again together as a whole offers insights into current practices, assumptions about future trends as well as the actual trends that played out during the time between the two survey collection points.

The white paper, The Future of Language and Framework Survey shows a professional development community striving to reduce the number of languages and frameworks they rely upon while simultaneously increasing their commitment and investments in the technologies they retain. As this maturation occurs, overall clarity and confidence in their architecture and mission improves.

Prevention, detection, and response

Today, Microsoft announced Azure DevOps – Loosely, it is TFS and VSTS, with its services broken out into distinct components that can be used together or separately. The Azure DevOps services are Azure Boards, Azure Repos, Azure Pipelines, Azure Test Plans and Azure Artifacts. When Azure DevOps was VSTS and TFS, we supported integration with PreEmptive’s Dotfuscator. Today, none of that changes. As Azure DevOps evolves, we will continue to improve our integration, so that you can easily add multi-layered protection to your valuable apps.

In Mindset shift to a DevSecOps culture, Buck Hodges, Director of Engineering for Visual Studio Team Services, stressed the importance of both preventing breaches and “assuming breaches. ”In essence, prevention only gets you part of the way there. “Assuming a breach” allows for effective incident detection, response and recovery process planning.

The .NET Conference is right around the corner. Make sure to mark your calendar because this virtual three-day developer event is not one you will want to miss. Included will be a wide variety of live sessions for beginners to advanced developers to attend.

Learn to build and the latest techniques for:

Announcing DashO v9.0