Announcing DashO v9.0

August 13, 2018 917 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!

Protecting Java applications that use Spring Framework Core

DashO has support for protecting applications that use Spring Framework Core. Spring can be configured either by custom annotations or XML configuration files, and DashO has support for both. However, applications that use custom annotations require additional handling.

There’s big money in artificial intelligence (AI) — reaching almost $12 billion over the next six years. As noted by research firm McKinsey & Company, companies are now in the process of building out the technology foundation they need for AI deployment, with 45 percent of executives already worried about not investing enough in AI to keep up with the competition. It’s not a baseless fear: The McKinsey research also suggests that AI adoption is following a standard “S-Curve” model, which starts with slow adoption by a limited number of businesses followed by rapid mass adoption as market opportunities increase and then slows again as stragglers are left behind.

Given the wide range of potential applications for AI and the evolution of core intelligence technologies, increased business interest is no surprise. What companies may not be prepared for, however, is the uptick in hacker usage of AI tools and solutions — what happens when attackers flip the AI script?

That was the title of yesterday's congressional briefing organized by ACT | The App Association (in cooperation with the Congressional IP Caucus which is co-chaired by Rep. George Holding, Rep. Adam Smith, & Rep. Hakeem Jeffries).

As is often the case when presenting to different kind of audience (not software-centric), you’re forced to reorganize your thoughts – here are few that might be worth sharing.

Attendees were promised the following agenda:

Learn how rogue apps steal content;
Understand what access devices are enabling the piracy of content;
Learn about a range of app piracy methods used to exploit U.S. companies;
Gain insight into existing industry best practices and enforcement methods for combating IP piracy.

App development now happens at breakneck speeds as companies recognize the need for first-to-market applications that exceed consumer expectations for usability and performance. The root of this rapid release cycle? DevOps — the combination of development and operations teams to deliver best-in-class applications ASAP.

But more apps on the market more quickly means more chances for security issues — as noted by Bank Info Security, 60 percent of all breaches over the last two years started with known software vulnerabilities. Bottom line? DevOps is getting apps out of development, but lack of security is putting them in harm’s way. There are no second chances when it comes to first impressions; users won’t come back if applications expose personal data or become malware distribution drones.

The solution? DevSecOps: Security as a fundamental aspect of application development. Here’s what you need to know.

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.

Announcing DashO v9.0