Natalia Yashenkova

Head of Marketing and PR at StarForce Technologies

Natalia Yashenkova has more than 15 years experience in software development and information security. Before StarForce Technologies she worked at Netris and Vimcom Optic.

In 2015 the penetration of mobile internet exceeded half the world's population by number of users. It means that every second person on the Earth has a mobile device to connect to the internet and download different applications. Mostly people are interested in games, but there are also communication and social networking apps, business and navigation apps, bonus programs and so on. Statista reported that the number of Android applications slightly exceeded the number of apps for iOS. In May 2015, Google Play hosted 1.5 million applications, while Apple Store had 1.4 million apps.

It is believed that mobile applications are easier to develop than programs for computers and thus, are cheaper. This partly explains the appearance of such a large number of programs for mobile devices. However, applications are not developed for fun - they are a source of income for developers and publishers. How do they earn them money? There are three ways:

• Paid apps.
• Advertisement in free apps.
• Paid options in free apps.

The last two can be combined in one app.

Google Play, the largest store of Android apps, provides authorization, storefront, billing system and file delivery. When a user buys an app, he or she gets a standard file without personalization or binding to the device. Thus, if the developer had ignored the question of licensing and protection, the APK file downloaded from Google Play can be copied to different devices without restrictions and subsequently propagate freely.

So, let’s imagine that you designed a really good app, published it at Google Play and are waiting for big revenues. And you do get some, but not as much as you expected. The reason lies in the ease with which APK files can be hacked.

This problem is also painful for the corporate segment. The popularity of the BYOD approach made corporate developers create special versions of their solutions for mobile devices, e.g. CRM or ERP. These applications as a rule are free for downloading but developers want to control the code integrity and usage of the license with the help of reliable tools, e.g. a DRM system.

In this post I’m going to give a brief analysis of several DRM systems. Some of them were created for the leading stores of Android apps, the others were developed by independent companies specialized in software licensing and protection.

Google Play Licensing

Google Play Licensing is a tool to protect Android applications against unauthorized distribution. To be more specific, we are talking about Google Play Licensing Verification Library, or in short LVL. This software library allows to request data concerning the purchase of the application from Google Play. This data either confirms or does not confirm the fact that this application was purchased from the current account of the user. For more details about Google Play Licensing please visit its site. By the way, it looks much the same as the first method of protection for Steam games.

According to the license verification result, the system provides one of three possible options:

1. The validity of the license is confirmed, and the application starts.
2. The fact the application has been purchased is not confirmed and the application is blocked from running.
3. The system can not give a definite answer and displays an error (for example, if there is no internet connection).

The answers from the server are signed with a private key of the developer (publisher). A public key is stored in the application. In the situation when internet connection is absent, the system allows caching the answers of the server.

LVL allows to bind a purchased application to a particular device, but this must be implemented by a developer himself. A developer or a publisher also develops methods to get a unique device identifier and provides a server to store the database of device identifiers.

To make a long story short, LVL is a separate, high-level component to be added to the application. But it is not enough. If a developer wants to have a reliable protection, he needs to make several serious improvements. Moreover, LVL does not provide mechanisms to protect the code of the application and the library itself. This DRM system is developed on Java and its source code is available for everyone. It means that it can be easily decompiled and modified to overcome license restrictions. Google recommends using third-party tools to protect code, e.g. different obfuscators.

A few words about tamper resistance. As mentioned above, this DRM does not protect its code so it can be easily analyzed and deactivated. There is at least one project available on the internet that takes off the DRM limitation in automatic mode – this program finds LVL code in APK files and neutralizes it.

Amazon DRM

The largest internet store sells almost everything including Android applications, protected by its own Amazon DRM. The main working principle of this system is identical to Google Play Licensing (the application verifies the purchasing data on the remote server), but there are some peculiarities. The most visible is automatic insertion of DRM functions into the application. A developer uploads his application to Amazon server and the module of protection is added automatically.

During the protection the application code gets additional classes to perform DRM functions. It works like this: the code is dissected and the DRM system inserts calls of the functions to verify these classes. According to testimonials on the internet, it works with unpredicted result – sometimes apps close with a verification error in JVM.

The tamper resistance of Amazon DRM is also not that high . The licensing system is not integrated deeply into the application code. To take off restrictions it is enough to dissect the code, find and delete the function calls or even simpler, switch off verification in the protection core or replace it with “an empty shell”. After this the application can be used without limitations.

Android Licenser

This is a paid DRM service to provide licensing and protection for Android apps on a subscription basis. A developer or a publisher pays per month for placing an Android app on the Android Licenser site. The procedure is the following: a user pays for the app via PayPal or GoogleCheckout and gets a personal link to download the app. The key benefit of this DRM is that there’s no need to modify an application to use it.

The DRM is based on AndroidLicenser Library. This is an alternative to LVL. When a user buys an app (the way I’ve described above or on any other partner site, e.g. Google Play), he or she receives an activation key via email. To start the purchased application, a user needs to insert the key. The key verification is performed on the Android Licenser server. This DRM system is extremely simple and open (source code is available).

Android Licenser provides a low level of protection because its code is open, easy to analyze and easy to modify. Secondly it uses a common, unencrypted channel to deliver keys, which allows using a proxy-server to bypass the protection.

Droid Activator

Droid Activator has much in common with Android Licenser. It also has a server part and an embedded library. And the operation logic is the same: an application is sold via Google Play or some other online store and this initiates the creation of a unique purchasing account on the Droid Activator server. The buyer receives an email with an activation key right away. When a user runs the app for the first time, he enters this key. The key is compared to the one that is kept on the servers and if they match, the app starts to work. But Droid Activator and Android Licenser have some differences as well. A developer needs to deploy its own server to store the server part of the Droid Activator protection.

The system is delivered with source code (GNU GPL2 Public License).

Speaking about hacker resistance, this DRM has the same disadvantages as the previous one: too easy to modify and too easy to intercept activation keys.

Arxan EnsureIT

In contrast to all previous systems, Ensure IT provides protection only for software code. To be more specific, it protects the native part of application code written in C / C ++. Java is not supported.

The source code is decompiled using Clang + LLVM into an intermediate bytecode semi-automatically. Then the bytecode is protected using tools like obfuscation, checksums, etc., and the result of this procedure is a standard object file. After linking, the app is processed again for checksums calculating and placement.

This product is designed to protect Android applications against analysis and modification and it has no DRM functionality. A disadvantage is that it only supports Linux and Mac OS platforms for developers.

StarForce C++ Obfuscator

This solution is also used for C/C++ code protection. Developers deploy it when there is some important data (DRM keys) inside an application that needs to be strongly protected against leakage to third parties.

The obfuscator supports more than 30 obfuscation methods, including:

• Conversion of C++ code into virtual machine code;
• Encryption of strings and arrays;
• Code conversion into a state machine;
• Insertion of dummy links;
• Code section merging.

The solution works on Windows and Linux platforms, and it can provide protection for software applications developed for any operational system. DRM functionality is not supported.

Comparative Table

The results of the DRM study are summarized in the following table:

* The code itself is not protected but it has many built-in calls of the protection core.