|Use of Obfuscation In Android Apps|
|Written by Janet Swift|
|Wednesday, 10 January 2018|
Android apps are plagued by plagiarism and outright theft by way of malicious repackaging. Obfuscation is the main means of protection but only a quarter of Android apps on Google Play are obfuscated by their primary developer.
Starting from the premise that apps in the Google Play market are highly susceptible to reverse engineering, a team of researchers based primarily at the Leibniz University Hannover conducted an analysis of the use and challenges of software obfuscation in Android applications.
The research had three strands:
In the initial survey ProGuard, free software which is included in Android Studio, was found to be by far the most commonly used obfuscation tool. Of the 308 participants, 241 (78%) had heard of obfuscation; 187 (61% of participants/78% of those who had heard of obfuscation had thought about obfuscating their apps; and 148 (48% of those surveyed) had obfuscated one or more apps in the past.
While those surveyed thought that apps in general were likely to face the threats of reverse engineering, repackaging and plagiarism, they didn't feel the threats extended to their own apps - only 102 (33%) were afraid of theft of their intellectual property. The distribution of responses to questions about apps in general and the developer's own apps on a five-point Likert scale are shown in this chart.
The chart above also shows that survey participants had a fairly accurate estimate of the likelihood that other people's apps would be obfuscated with over 80% answering "likely" or "very likely".
Using Obfuscan the researchers actually detected the use of ProGuard or functionally equivalent tools in 64.51% of the apps they tested. However this wasn't necessarily due to the actions of the developers.
The researchers explain
A large percentage of apps were not intentionally obfuscated by the original developer, but contain third-party libraries that use obfuscation. While some libraries are distributed pre-obfuscated, others ship with ProGuard configuration files to configure obfuscation. The fact that libraries may be obfuscated, but main application code non-obfuscated, is an important distinction for understanding the use of obfuscation throughout the Android ecosystem. In particular, the presence of an obfuscated library does not indicate that core application components are actually being obfuscated.
This led to further analysis of main package obfuscation the headline finding of which was:
only 24.92% of apps (439,232 apps) are intentionally obfuscated by the developer
The researchers tested the hypothesis that popular apps would have a higher rate of main package obfuscation by virtue of being more sophisticated and complex and also at the greatest risk of plagiarism.
Commenting on the results shown in this table, the researchers write:
Most apps — the 98.9% (1,655,914 apps) of apps with less than 1 million downloads — are obfuscated at roughly the same rate, ranging from 23.9% – 27.3%. As download counts increase further, we see an increase in obfuscation in the most downloaded apps from 29.15% of apps with more than one million downloads to 50.0% of apps with more than 100 million downloads. While this does confirm our initial expectation, we were surprised that even the most popular apps are only obfuscated on average half of the time.
They also tested the hypothesis that the number of published apps per Google Play account would plays a role in the decision to obfuscate apps. Assuming that accounts with more submitted apps belong to experienced developers or to companies specialized in app development apps they expected these accounts would show a higher obfuscation rate. This was borne out by their results:
Apps from accounts with less than 100 apps have roughly the same average obfuscation rate between 21.8% – 26.5%. For accounts with 100 or more submitted apps this increases to about 35% and rises to 68.4% for accounts with 500 and more apps. The researchers comment:
This increase in average app obfuscation seems to confirm our hypothesis that experienced developers or specialized companies with a large number of submitted apps use obfuscation more often. A likely explanation for this could be that more experienced developers and companies want to protect their intellectual property further. This could be the results from previous experiences of intellectual property theft, or the result of placing a higher value on their apps, as they are likely an important source of income for professional developers and specialized app companies.
The final part of the study looked for reasons why so few of the apps in the study were obfuscated. The researchers hypothesized that it could be due to the shortcomings in the usability of ProGuard and to explore this invited developers to solve two ProGuard tasks that involved obfuscating an app in Android Studio and followed this up with a questionnaire. There were 78 valid participants for this study and while 70 (90%) were able to obfuscate the whole app in the easier Proguard task only 17 (22%) were able to solve the second task although 30 (38%) mistakenly thought that they had solved it. Developers who claimed to have ProGuard experience performed better on average that those without. These findings led to researchers to conclude that ProGuard is difficult to use correctly and that simplifying its use promote the use of obfuscation.
They also identified an attitudinal problem, stating:
Developers are not motivated to deploy obfuscation given a low perceived risk and high perceived effort. Developers also view obfuscation as an optional, possibly “app destroying” step instead of an integral part of the build process. While improved interfaces and automation for obfuscation may improve the perceptions of effort, more research and education regarding the risks of plagiarism is needed.
Their conclusion is that to prevent Android developers intellectual property being stolen and their apps being repackaged and redistributed as malware, obfuscation needs to be made more usable and developers themselves need to be educated as to the risks they face.
Dominik Wermke, Nicolas Huaman, Yasemin Acar, Brad Reaves, Patrick Traynor, Sascha Fahl
or email your comment to: firstname.lastname@example.org
|Last Updated ( Wednesday, 10 January 2018 )|