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.
Java 9 is an unusually-complex Java release. It comes with deep changes to some long-held norms, compatibility-breaking changes at build time and run time, and a new release cadence. There's a lot of great stuff, but development teams face tough decisions about what to migrate, how to migrate it, and when to do so.
Here at PreEmptive, we have an especially-complex problem because our flagship Java application, DashO, runs on the Java platform, integrates deeply with the Java platform, and supports apps developed with nearly all versions and implementations of the Java platform. DashO's migration to Java 9 requires deep understanding and extensive care to ensure that DashO continues to be able to inspect, obfuscate, and inject code into apps across all those platforms, while preserving behavior, performance, stability, and portability.
So we've been hard at work on our own migration plans, and we want to share what we've learned. Hopefully this article will make your Java 9 migration planning a little easier.
- Android-O support,
- Kotlin support,
- Improvements to our Android Wizard, and
- Build performance improvements.
BUT the feature I’m most excited about is the addition of our latest Check Type, Android Root Detection.
Harden applications against hostile and compromised environments – not just simple attacks.
Once a mobile device or an on-premises server or a PC… is known to be compromised or in hostile hands (detected, for example, when someone attaches a debugger to an app in what is a strictly production setting), doesn’t it make sense to be able to alter your app’s runtime behavior in real time? …and not just at the time of discovery – but also into the future – and for as long as the runtime environment remains suspect?
Pokefan Alert - augmented reality apps like Pokemon Go are rooted in the REAL WORLD (not a virtual one) – a real world with a host of very real dangers.
Pokemon Go players are walking into traffic, being lured into remote locations to be robbed, and last (but in no way least) they’re being duped into using counterfeit (tampered) Pokemon Go apps.