You are presented with multiple paper abstracts, alongside the associated literature review and chapter titles. Given the provided information, you are going to do a literature review. Please generate a coherent literature review that synthesizes the content, draws connections between different works, highlights major findings, and identifies any gaps in the existing research.

Literature Review Title: Rebooting Research on Detecting Repackaged Android Apps: Literature Review and Benchmark 
Chapter Title:  Manual Validation of Random Samples 
1. Abstract of Cited Paper (BIB001):  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.

Literature Review:
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.