Protecting Android Applications That Use Crashlytics

July 2, 2018 2815 Views Johnny

With our recent DashO releases, we’ve been working to make our Android support even easier to use. A great example of this is our evolved support for Crashlytics, which is an analytics framework that can provide detailed reports on application crashes from the field.

When applications have been obfuscated, the stack traces will contain obfuscated class and method names. To prevent this from complicating debugging, Crashlytics provides a utility to automatically deobfuscate stack traces, so that the reporting server shows the original class and method names. It does so by reading the map file, which is a file created by the obfuscation tool to pair the obfuscated class and method names with the original names. Crashlytics expects this map file to be in a ProGuard-compatible format, which differs from the DashO map file format.

If you were using Crashlytics with a version of DashO prior to our 8.5, this would likely have caused issues. You might have experienced an error during the Gradle build, from the Crashlytics plugin:


A problem occurred configuring project ':app'.
> path may not be null or empty string. path='null'

To resolve this build error, you could add custom scripting to your build.gradle file to call DashO's ConvertMap utility, which could convert the DashO map file into ProGuard format.

After adding the custom scripting, your Gradle build would complete. However, when you viewed your Crashtlyics portal, you still might see obfuscated stack traces:


…
Caused by java.lang.ArithmeticException: Could not complete product registration 

       at classes.foobaz.f(Unknown Source)

       at classes.foobaz.k(Unknown Source)

       at classes.foobaz.q(Unknown Source)

       at classes.foobar.a(Unknown Source)

       at classes.foobar.w(Unknown Source)

       at com.example.the.crashlyticsexample.MainActivity.forceCrash(Unknown Source)

       at java.lang.reflect.Method.invoke(Method.java)

       at android.support.v7.app.AppCompatViewInflater$DeclaredOnClickListener.onClick(AppCompatViewInflater.java:384)

       at android.view.View.performClick(View.java:5198)

       at android.view.View$PerformClick.run(View.java:21147)

       at android.os.Handler.handleCallback(Handler.java:739)

       at android.os.Handler.dispatchMessage(Handler.java:95)

In order to ensure that the stack traces appeared in an unobfuscated format, additional settings were required in your dasho.gradle file.

With our 8.5 version, after initially running your Android project through the Wizard, DashO will automatically manage the translation of the map file from DashO map format to ProGuard format, and put it where Crashlytics expects to find it, so that it will be uploaded to the Crashlytics server without any additional configuration.

While DashO continues to support a full range of Java applications, we’ve been paying special attention to our support of Android applications. This is just one of several reasons why you should always stay current with your DashO version.

For more detail about this topic, please refer to our Gradle documentation. You can also contact us at support@preemptive.com.

Latest NIST publication reinforces Developer Obligations (and liability)

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).

Why are more Xamarin.Android apps going unprotected?

I recently had the opportunity to sit down with Sebastian Holst, PreEmptive’s Chief Strategy Officer, to talk about his most recent trip to Capitol Hill where the topic of the day was copyright protection for small businesses – and for development shops in particular.

The life of a security architect is rarely simple. Assessing, defending and improving corporate networks requires thorough knowledge of industry best practices designed to secure critical data, combined with real-world understanding of hacker tricks and tactics meant to undermine this purpose.

As noted by the InfoSec Institute, this is an in-demand job that often comes with high expectations, odd hours and the need for constant professional evolution to stay ahead of cybercriminal threats. Complicating matters is the breakneck pace of technological advancement. The rapid rise of cloud deployments, mobile applications and IoT devices can make even best-laid security strategies seem like flies in amber — hopelessly out-of-date and effectively immobile.

Here’s a look at what’s really bugging security architects — and how they can break the mold of static security to combat emerging threats.

Protecting Android Applications That Use Crashlytics

Latest NIST publication reinforces Developer Obligations (and liability)

Put the Protection in the App

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

Are Xamarin.Android app users at risk?

Changes are coming for US Copyright – Should Developers Even Care?

Fly in Amber: What’s Bugging Infosec Architects?

Latest Blog Posts

Latest NIST publication reinforces Developer Obligations (and liability)

Put the Protection in the App

Are Xamarin.Android app users at risk?

Changes are coming for US Copyright – Should Developers Even Care?

Fly in Amber: What’s Bugging Infosec Architects?

Twitter