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.

Organizations can’t afford to leave apps unprotected. Attackers are growing more sophisticated, leveraging targeted malware campaigns and advanced evasion tactics to compromise applications and cause long-term damage. And according to Forbes, even antivirus tools designed to protect devices and software can increase overall risk: recent research found that more than 28 million Android phones were subject to security vulnerabilities thanks to insecure virus protection apps.

As a result, many companies looking to boost application protection and security without breaking their budget or introducing unexpected risk are considering in-house builds of better defenses using a combination of IT talent and publicly available tools.

The challenge? Homegrown solutions introduce the potential for DIY disasters. Let’s dig in and discover why they can’t measure up.

Currently charging up the hype cycle slope? The rush to become a “technology-forward” organization.

But delivering on digital transformation potential demands more than buzzwords — along with C-suite support, end-user buy in and robust data defense, companies must develop “protection-forward” strategies to secure the IT front line: Applications.

Tech-Forward Trends

What is a technology-forward organization? One that prioritizes digital transformation — the ongoing shift away from cumbersome physical processes and outdated IT solutions to always-connected, digitally-enabled services that empower user access and data analytics to drive long-term ROI.

When properly implemented, tech-forward strategies pay big dividends: As noted by Forbes, businesses like Target and Best Buy — both at risk of going under just a few years ago — have substantially improved both performance and revenue by leaning into digital solutions. According to Tech Republic, 66 percent of business leaders now plan to implement digital transformation strategies and expect them to drive 17 percent ROI over the next year.

Earlier this month, I had come across Scott Hanselman’s excellent blog post, What's better than ILDasm? ILSpy and dnSpy are tools to Decompile .NET Code where he had shared his insights on the strengths and limitations of a laundry list of reverse engineering and debugging tools. In the comments that followed, someone had asked for an obfuscation recommendation for those times when a developer wants to protect their code against reverse-engineering (a reasonable question to be sure).

Unfortunately, comments had been disabled by that point, and so I had sent an email to Scott that mapped Dotfuscator’s anti reverse-engineering/tamper/debugging capabilities to the collection of developer tools that he had covered.

Before I start, I would like to thank PreEmptive for inviting me to write a guest post.

I would like to start my blog with a discussion about the growing cyber threats all over the world. I assume readers are well aware of cyber threats and how they are addressed by people, process, and technology. The continuous planning and advancement of security in the cyber world including but not limited to applications is an interesting read. Here, in my blog, I would like to discuss how companies can support mobile application security for better and safer use of stored data.

On June 11, NIST released Mitigating the Risk of Software Vulnerabilities by Adopting a Secure Software Development Framework. While a solid piece of work in its own right, this document is noteworthy because it stands as one more proof point - in an already long list of proof points, that development processes, the developers themselves, and the organizations they belong to, ALL share some degree of responsibility (liability) for:

Untrusted Environments, Valuable Apps? Put the Protection in the App.

IT environments are evolving. Disappearing are the days of in-house, fixed-endpoint, limited access server stacks — replaced instead by a combination of private and public cloud solutions, mobile applications and IoT devices.

As noted by research firm IDC, public cloud spending now outpaces all other IT infrastructure with a growth rate topping 10 percent year-over-year, while Statista reports that users downloaded more than 178 billion apps in 2017 alone — and are on track to break 250 billion over the next few years.

What does this mean for organizations? That application environments are quickly moving beyond the purview of in-house IT, exposing both apps and network services to steadily growing risk. It creates a paradox: Companies can’t deny the benefits of third-party environments and application partnerships, but also can’t ignore the threat of app and data compromise or reverse-engineering and tampering.

In a recent developer survey, Xamarin.Android developers were 50% less likely to have included rooted device detection or anti-tamper prevention as their Java Android peers were. Yet, both sets of apps are being deployed through the same marketplaces onto the same devices and are governed by the same regulations (PCI, GDPR, HIPAA to name just a few that expect these kinds of controls).