The DashO 10.2 release introduces a major new feature: Resource Encryption for Android. It's currently in beta, but is fully supported for production use. It allows you to encrypt the resources embedded in your APK, better protecting your Android application against static attacks.
This functionality integrates directly with your existing Gradle build, encrypting the resources during the standard build process. DashO then injects code into your protected application that will decrypt those resources at runtime.
Resource Encryption is
off by default, but can be easily enabled in the DashO UI.
The UI makes it easy to enable, or disable, the encryption of specific resources via drag and drop.
It currently supports encrypting both assets and raw resources.
Once you install DashO 10.2, using this feature is easy.
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.
Last month we blogged about R8 and Google's build architecture changes and hinted at things to come in PreEmptive Protection - DashO, our powerful Java obfuscation and application protection tool that integrates tightly with Android. Today, we're excited to announce a public beta of our next major release: DashO 10 (Beta 2).
This new version of DashO works together with R8 to protect Android apps and libraries.
Google recently introduced R8, a new tool designed to replace ProGuard as the default shrinker in the Android build process. R8 is meant to produce as-good-or-better outputs than ProGuard, and to do so faster than ProGuard does, thereby reducing overall build times. It will be enabled by default in the next release of Android Gradle Plugin (v3.4).
This change removes a long-standing component (ProGuard) and replaces it with entirely-new code that does essentially the same thing. Why would Google do such an expensive, risky thing?
DashO 9.2 is available for immediate download and includes two powerful new controls:
1) Emulator Check, a new injectable control that
- Detects when a hardened app is being executed on an emulator (even if that emulator is not rooted), and
- Responds with the one or more pre-defined defenses and/or app-specific defenses – all in real-time.
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.
Over the past year, we have seen an influx of developers looking to replace existing ProGuard and DexGuard implementations with DashO. While the three products are conceptually similar, we have found that there are important differences between the products, and those differences can lead to unexpected migration issues. This article summarizes many of the tips and techniques our support team has been refining, to shorten your learning curve and simplify your migration.
- Provides a logical mapping of features between the three products.
- Recommends specific patterns to:
- Simplify and shorten your migration.
- Improve the strength and effectiveness of your application protection.
- Optimize and automate ongoing app protection to reduce the cost and complexity of maintaining protection.