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.