Rebooting Research on Detecting Repackaged Android Apps: Literature Review and Benchmark <s> Manual Validation of Random Samples <s> With increased popularity and wide adoption of smartphones and mobile devices, recent years have seen a new burgeoning economy model centered around mobile apps. However, app repackaging, among many other threats, brings tremendous risk to the ecosystem, including app developers, app market operators, and end users. To mitigate such threat, we propose and develop a watermarking mechanism for Android apps. First, towards automatic watermark embedding and extraction, we introduce the novel concept of manifest app, which is a companion of a target Android app under protection. We then design and develop a tool named AppInk, which takes the source code of an app as input to automatically generate a new app with a transparently-embedded watermark and the associated manifest app. The manifest app can be later used to reliably recognize embedded watermark with zero user intervention. To demonstrate the effectiveness of AppInk in preventing app repackaging, we analyze its robustness in defending against distortive, subtractive, and additive attacks, and then evaluate its resistance against two open source repackaging tools. Our results show that AppInk is easy to use, effective in defending against current known repackaging threats on Android platform, and introduces small performance overhead. <s> BIB001 </s> Rebooting Research on Detecting Repackaged Android Apps: Literature Review and Benchmark <s> Manual Validation of Random Samples <s> Although anyone can easily publish Android applications (or apps) in an app marketplace according to an open policy, decompiling the apps is also easy due to the structural characteristics of the app building process, making them very vulnerable to forgery or modification attacks. In particular, users may suffer direct financial loss if this vulnerability is exploited in security-critical private and business applications, such as online banking. In this paper, some of the major Android-based smartphone banking apps in Korea being distributed on either the Android Market or the third party market were tested to verify whether a money transfer could be made to an unintended recipient. The experimental results with real Android banking apps showed that an attack of this kind is possible without having to illegally obtain any of the sender's personal information, such as the senders public key certificate, the password to their bank account, or their security card. In addition, the cause of this vulnerability is analyzed and some technical countermeasures are discussed. <s> BIB002
One of the major goals of constructing a benchmark of Repackaged Android apps is to support replication and comparison studies by the community. Towards demonstrating this ability, we need to ensure in the first place that our constructed benchmark is reliable. To this end, we randomly select 100 pairs of apps and manual validate their similarities. Based on the Sample Size Calculator provided by Creative Research Systems 7 , it is representative to sample100 pairs out of around 16,000 pairs, with a confidence level at 95% and a confidence interval at 10. It is actually non-trivial to decide whether a given two apps (which share over 90% of the code and are signed by different developers) are repackaged from one to another manually. We hence resort to dynamic analysis to validate the selected pairs. Given a pair of apps, we manually install them respectively on two emulators set up with exactly the same configurations. After the apps are installed, we manually launch and play with them and observe the similarity and difference between the two apps. Among the 100 selected pairs, our manual validation confirms that 89 of them are clearly repackaged pairs (sharing exactly the same UI page or at least similar UI skeleton), giving an accuracy of 89% at least for our harvested benchmark. The remaining 11 pairs have big changes in their UI pages that cannot be soundly confirmed. Nonetheless, we remind the readers that those app pairs, despite having different UI pages, have shared over 80% of code and thus could be repackaged app pairs as well. Table 7 illustrates five samples of the details we have observed from our manual validation process. The first column presents the hash values BIB001 of the selected pairs. The second and third columns illustrate the similarity scores yielded by SimiDroid, based on its method-based and resource-based similarity analyses, respectively. The last four columns show whether the package name, app name, icon and the main UI skeleton are respectively the same between the two apps in a pair. Regarding the main UI skeleton, we consider it is the same as long as the layout is more or less the same. For example, in this work, we consider the two pages shown in Fig. 8 (collected from pair FF57A0/74E764 ) have the same BIB002 . https://www.surveysystem.com/sscalc.htm 8. SHA256s, only the first six letters are shown. UI skeleton. If two apps (1) have over 90% of code similar from one another, (2) are signed by different developers (or teams), and (3) have similar look and feel (i.e., similar UI skeleton), we consider these two apps as true repackaged app pair. Hence, our manual validation confirms that all the randomly selected app pairs from our benchmark are true repackaged app pairs, suggesting that our benchmark is quite reliable. Subsequently, our benchmark should be capable of supporting replication and comparison studies between state-of-the-art approaches. Table 7 further reveals that a repackaged app may (or may not) change the package name, app name and icon of the original app. These findings once again suggest that our benchmark is diverse and is representative to different types of repackaging cases.