30. Protecting Applications from Software Piracy

Search in book...
Toggle Font Controls
Create new playlist

Name your new playlist

Playlist description (optional)
Sign In

Email address

Password

Forgot Password?

or

Continue with Facebook

Continue with Google
Sign Up

Full Name

Email address

Confirm Email Address

Password

or

Continue with Facebook

Continue with Google

30. Protecting Applications from Software Piracy

Android application developers face numerous threats to success in the real world. Apps can be illegally copied and made available for download in alternative locations. A free application might be exploited, causing damage to a brand and leveraging valuable product resources like server bandwidth. All apps are vulnerable to hacking, resulting in rogue downloads with embedded malware, or using knowledge learned to hack a server or other underlying service. Unfortunately, this malicious behavior does happen. Protecting yourself is an ongoing battle; the opposition is constantly improving its methods, and you need to stay a step ahead. In this chapter, we talk about some of the ways you can protect yourself from becoming a victim of software piracy.

All Applications Are Vulnerable

Perhaps you’ve heard some of the startlingly high statistics about the number of mobile applications that are illegally downloaded each year. For the application developer, this loss in revenue, in addition to the other ramifications of software piracy, is staggering; most developers try to take some steps to protect their intellectual property.

All applications deserve protection whether they are paid or free. Just because you’re giving away the software doesn’t mean that it doesn’t contain valuable intellectual property or revenue-making content that you should protect. The last thing you want is for your awesome technology to be copied, misused, or misrepresented simply because you left your work unprotected. This applies to your brand and professional reputation as well. They are all pieces in this puzzle.

The truth is, there is no such thing as a truly invulnerable app (or developer), but you can make your app a hard target. There are various actions Android developers can take to help protect their applications from exploitation. Some of these methods include:

Use secure coding practices.

Obfuscate your binary code using ProGuard.

Leverage the License Verification Library (LVL).

Let’s talk about each of these methods in more detail.

Using Secure Coding Practices

As usual, the first step in developing and publishing secure applications is to make security a priority and use common sense. Take a hard look at your application design; look for its vulnerabilities. Where is data stored? How is it accessed? What is plaintext and readable? How would you exploit your application?

Begin by battening down the hatches. Keep developer keys and digital signatures safe so that your development identity cannot be easily exploited. Make sure the passwords that protect these assets are not “password.” The same goes for application server accounts and credentials.

Applications that send data over the network can be exploited in a variety of ways. Start by ensuring that your application servers are secure; use strong passwords and all the safeguards you should to protect any network resource. Network sniffing can be a problem, so it’s important to safeguard any communication between your application and its server. Here are some tips for protecting network communications and resources:

Don’t send any information across the network unless it’s absolutely necessary.

Don’t store any private user information remotely unless it’s absolutely necessary.

Don’t use predictable or spoofable network communication protocols.

Use secure network protocols, such as HTTPS and SSL (or TLS), even when data is not sensitive.

Warning

In a game, someone might be able to gain points, levels, experience, swords of smiting, or anything else that is useful simply by performing the same or similar network commands multiple times. If the method for performing the action is easily determined through sniffing, smart users might decide to write a script to do the work for them, regardless of whether the network content is encrypted or not. Although they have a valid account, and have possibly even paid for the game, they will have an unfair advantage over other users. Some cheaters simply do this for their own benefit, while other more entrepreneurially minded cheaters may monetize their findings and provide them to others. Make sure your network communication is sufficiently unpredictable to avoid these repeat offenders.

Obfuscating with ProGuard

Android applications are written in Java. Java is especially susceptible to reverse engineering due to the fact that it supports reflection, or the capability to look up code objects at runtime by name. These labels are kept when the application is compiled. When someone has knowledge of what your application does and the ability to systematically inspect the elements of your code in a human-readable fashion, it takes only a short amount of time to unwind your hard work and exploit it.

Android developers can use the ProGuard tool to make code more difficult to interpret and understand. ProGuard obfuscates, shrinks, and optimizes your code. The end result is a smaller, more secure application package file. Enabling ProGuard is simple in the Android IDE. For Android developers, there’s little excuse not to provide at least this moderate level of protection for application source code.

Tip

Using ProGuard changes the code inside the packages and may have implications for how your application works. Be sure to thoroughly test the release version of your application prior to release.

ProGuard processing occurs when you export a signed or unsigned APK file using the Android tools in the Android IDE. Besides the added protection of obfuscation, package files are often reduced in size. We routinely see package size reductions of around 25 percent. Surely users will appreciate the faster downloads and having more free space on their devices.

Configuring ProGuard for Your Android Applications

ProGuard is an open-source tool for compacting and obfuscating compiled Java code. From a protection point of view, the resulting binary files are much harder, but not impossible, to reverse engineer. Android projects created with the Android IDE include a default ProGuard configuration file, called proguard-project.txt. To enable ProGuard, add the following configuration line to the project.properties file:

Click here to view code image

proguard.config=proguard-project.txt

Note

The project.properties file says not to make changes, otherwise they’ll be erased. Don’t worry. This change won’t be erased even if you edit the Android settings for the project. At least, it never has been for us, and this is the way suggested by the Android team.

ProGuard is now enabled, but only when you use the Android Developer Tools to export a signed or unsigned package with a release version of the application. However, there are several common scenarios when the default ProGuard configuration file doesn’t work. During the export process, ProGuard may display some errors. One common error looks like this:

Click here to view code image

[2014-03-10 16:52:07 - SampleFragments] Warning: android.support.v4.app
.ActivityCompat: can't find referenced method 'void invalidateOptionsMenu()'
in class android.app.Activity
[2014-03-10 16:52:07 - SampleFragments] Warning: android.support.v4.app
.ActivityCompat: can't find referenced method 'void dump(java.lang.String,java
.io.FileDescriptor,java.io.PrintWriter,java.lang.String[])' in class android.app
.Activity
[2014-03-10 16:52:07 - SampleFragments] Warning: android.support.v4.view
.MenuCompat: can't find referenced method 'void setShowAsAction(int)' in class
android.view.MenuItem

The error messages go on to talk about how the classes are inconsistent. This might happen when you try to use ProGuard on a project using the Android compatibility library. The warnings, all of which end in Compat, are for compatibility classes that are used to call the compatibility versions of methods. This happens only when they are available when compiling to previous SDK versions, as you probably are with the compatibility library. You can safely ignore these warnings by adding the following warning suppression line to your ProGuard configuration file (proguard.cfg):

-dontwarn **Compat

Then, in a manner similar to the existing -keep statements that exist in the file by default, you’ll want to include classes that you use. For instance, if you’re using fragments, you should add this line:

Click here to view code image

-keep public class * extends android.support.v4.app.Fragment

This keeps any unreferenced class that extends the Fragment class. If you’ve referenced only your fragments through XML, this is absolutely required.

After you have edited the proguard.cfg file to suit your project, you’re ready to test your application thoroughly. Going through the trouble of configuring ProGuard will help protect your application from tampering and reverse engineering, regardless of your distribution method.

Dealing with Error Reports after Obfuscation

Now that your Android application source code is obfuscated, your error reports will also be obfuscated, making debugging release builds difficult by design. Luckily, the ProGuard tool outputs a file named mapping.txt that can later be used to de-obfuscate the error report. In the SDK tools directory, there is a directory named /proguard. In a subdirectory, you’ll find a tool called retrace. This tool takes an obfuscated stack trace and makes it readable again. The mapping.txt file is stored in a directory named /proguard, which is found in the root of your project.

There’s one important caveat, though. Every time you make a release, the mapping.txt file is re-created. It’s not necessarily the same every time. This means that each time you actually release an application to users, you need to keep track of which mapping.txt file goes with which release. Otherwise, stack traces are basically useless to you. Needless to say, keep your mapping.txt files secure so they are not exploited either.

Leveraging the License Verification Library

Let’s look at another scenario. Let’s imagine that you have developed a killer application and published it a month ago to Google Play. So far it has been downloaded 25,000 times. But wait! There are 100,000 unique users according to your server logs. Welcome to the world of software piracy. One solution is to live with it and be happy that your application is good enough that people took the time to steal it. Another solution is to fight back; you can start by using the License Verification Library (LVL) to further protect your application from piracy.

Tip

The LVL verifies only Google Play paid applications and free apps that include APK expansion files. LVL is not a solution for developers who have published free apps without APK expansion files, including those with in-app billing or those using alternative markets.

The LVL is available for download through the Android SDK Manager. The library works only with Google Play and is meant for paid applications or free applications that include APK expansion files. If you distribute your application through other means, you need to use a separate licensing scheme, and you might need to provide separate binaries to support these differing means.

It’s up to you to determine whether it’s worth the effort to use LVL with your specific project. Unlike ProGuard, the LVL is not a turnkey solution; it takes time and effort to get it set up, integrated with your application, and working properly. You have to manage keys, policies, and testing. In addition, even the LVL itself is prone to exploitation. As a public shared library, LVL code compiles the same way against all applications. While obfuscation through ProGuard does help, even that leaves similar patterns for pirates to look for and take advantage of. Identical Java code through ProGuard turns into identical obfuscated code and, ultimately, identical binary. A person looking to crack the licensing can do so much faster if multiple apps use the exact same code patterns; thus, you’ll want to modify what you can.

The consensus is that modifying the LVL code base to make it different from all other implementations used by other parties, while keeping the functionality, is your best defense. For that reason, we aren’t going to provide code examples here; you’d just have to change them. Instead, we recommend that if you think the LVL is right for you, consult the documentation provided, available at http://d.android.com/guide/publishing/licensing.html.

Other Antipiracy Tips

If piracy is a huge concern for you or your company, there are other methods to help protect your applications. Although piracy can never be stopped completely, here are a few things you might be able to do to combat it:

Use in-app billing on a free app. Careful control over features that can be enabled through in-app billing allows more users to try your app for free, while the features that must be paid for are protected by requiring accurate billing information. The leak of your compiled binary will no longer be devastating.

Update your application with great features frequently. Creating an awesome application means supporting your application and adding new features. If this is done frequently, you create more work for those trying to pirate your app while giving an incentive to people to pay for and get updates more frequently.

Block old versions of your application from accessing server resources. If you know a particular version has been pirated and you provide free updates (as most mobile apps do), simply push out an update and provide a message to users of the old version that they must update to continue.

Price your services and apps appropriately. If your application is overpriced for what it is, it’s more likely to be pirated by people who won’t pay that amount. If it’s priced correctly, people will be happy to pay for it.

Provide free trial versions of your app or, if your app is highly valuable and priced correctly, provide cheap trial editions. Without any way to evaluate a paid app, users who actually do want to evaluate the app first may search for a pirated version. If that version actually works, there’s little incentive for them to go out and buy the full version.

Although none of these methods are foolproof, the point is to provide a great experience to the user that will bring in more paying users in total. Make people want to pay for what you’re offering rather than want to find a workaround to not pay.

Summary

In this chapter, you have learned a variety of straightforward methods to protect your Android applications from theft and tampering. Although no method is perfect, there’s no reason to be an easy target. Use commonsense techniques for securing your applications, protect your network communication from cheaters, obfuscate with ProGuard, and consider validating application licensing with the LVL. The longer it takes for your application to be cracked and stolen, the more likely it is that those software pirates will simply turn to easier prey.

Quiz Questions

1. What are some ways to prevent software piracy?

2. True or false: ProGuard is a tool for preventing hackers from installing malware into your application’s code.

3. How do you enable ProGuard to your project?

4. True or false: The –stopwarn flag is used to suppress warnings in your ProGuard configuration file.

5. What is the name of the file that ProGuard outputs to de-obfuscate the error report?

Exercises

1. Use the online documentation to determine the name of the ProGuard file that lists the classes and members that are not obfuscated after running ProGuard.

2. Use the online documentation to help you configure an application for license verification and use an Activity to perform a license check.

3. Use the online documentation to determine which LVL classes and interfaces are used for data obfuscation.