Authors: Jinjian ZHAI, Yang SONG
The developers of paid apps in Google Play depend on a protection algorithm to prevent unauthorized installation and monetary losses of pirating and repackaging activities globally. During our research, we found that there is a loophole in the paid app protection algorithm on the Google Play store, in which crawlers can easily harvest many paid apps automatically, and distribute those apps at a lower price, or freely install them into other cell phones with a brand new Google account (without any credit card information registered).
By Nikolay Elenkov, Page 82, “Free apps are decrypted and the APKs end up in /data/app/, while an encrypted container in /data/app-asec/ is created and mounted under /mnt/asec/<package-name> for paid apps.” Yet the paid apps in the research do not behavior like that.
The sample being researched is the paid version of the popular app “Weather Live”. This paid version has more than 100,000 downloads, and the free version has more than 5,000,000 downloads. The price for the paid version is $0.99 per installation as shown in Fig. 1 .
Fig. 1 The paid version of the Weather Live app costs $0.99.
As shown in Fig. 2-4, we set-up a valid credit card in the Google account to purchase the app. The app installed successfully. After the installation, the customer can choose to uninstall and refund the charge within a certain amount of time. The customer can also “OPEN” the app to play for a while before going back to the Google Play page to “REFUND”.
Fig. 2. The first phone is equipped with a Google account which has a credit card registered.
Fig. 3. The purchasing and downloading process on the first phone is fast.
Fig. 4. After installation, a “REFUND” button is shown in the first phone with valid credit card information for the Google account.
Fig. 5. The functions of the paid app on the first phone with valid credit card information.
As shown in Fig. 5, the paid app that we purchased works well on the first phone that has valid credit card information in the Google account.
Fig. 6. The APK of the paid version of the Weather Live app can be pulled from the first phone that has the credit card information in Panel A. Then it is installed on the second phone with a brand new Google account that does not have credit card information in Panel B.
In order to test the validity of the paid app’s protection, we first tried to pull the APK from the first phone. As shown in Fig. 6, the pulling process is successful. The APK size matches the size on the Google Play page, and we can unzip it without any encrypting protection. Then the app is tested if it can be installed in another phone, which is also successful.
Fig. 7 The paid version of the Weather Live app is installed on the phone of the Google account without valid credit card information by adb install.
As shown in Fig. 7, the APK of the paid app has been shown on the home screen of the second phone after adb installation. The second phone has a brand new Google account for which we have not input any credit card information yet, as shown in Fig. 8.
Fig. 8. The Google account on the second phone is a brand new one without any credit card information.
As shown in Fig. 8, the Google account in the second phone is totally different with that of the first phone. And it should be noted we do not possess any purchasing capability on the second phone.
It’s interesting that when browsing the Google Play page of the paid version of the “Weather Live”, we found the app has been labeled as installed as shown in Fig. 9-10 . The only different button from the first phone ( as shown in Fig. 4 ) is the “UNINSTALL” button, as in Fig. 9 you are not capable of refunding the charge of the app. It’s our hypothesis that the Google service put it into another track of the logic without checking the validity of the payment. When they found the app can not be refunded due to null payment, they just show the uninstall button as any other free apps, instead of alerting the abnormal behaviour. In this sense, many users are capable of taking advantage of the paid APKs, which are possibly collected by any automatic crawler. This might cause potentially large monetary losses for Android developers.
Fig. 9. In the second phone without credit card information, the “REFUND” button is just replaced with the “UNINSTALL” button. The download counts (100,000) are still revealing that the app is the paid version.
Fig. 10 . In the app manager of the second phone without credit card information, the paid version, and only the paid version, is installed.
In order to fully understand if there is any difference between the app installed in the paid environment and the unpaid environment, we play with the “Weather Live” app and found the functions of the app on the two phones are exactly the same, as shown in Fig. 5 and 11.
Fig. 11. Playing with the app in the second phone (without credit card information), we found the functions are the same as on the first phone.
Last but not the least, the paid APK which was pulled from the first phone does not have any encryption protection, and can be easily reversed engineered by apktools and JD-GUI, as shown in Fig. 12.
Fig. 12 . The pulled APK can be reversed engineered.
In general, the Google Play store should have provided a feasible protection algorithm for the paid apps of Android developers, otherwise their hard work can be easily fooled by a crawler and third party Android markets around the world, where the authentic apps might be sold at a lower price, or even distributed freely. Further, the paid apps risk the same level of repackaging activities from hackers as any free apps distributed inside and outside Google Play.
The bug has been reported to Google Android Open Source Project and was accepted with bug tracking number 194525.
The bug was considered “working as intended” in the reply of the developer, yet they failed to address the issue why the paid app of one Google account is not only considered free app of that specific Google account but also of any Google accounts. Such intended mechanism can be easily abused by pirating and repackaging activities.
If you would like to know the list of affected MD5s or access to the detailed report, please contact firstname.lastname@example.org