Announcing DashO v9.0

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!