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:  Overall Results 
1. Abstract of Cited Paper (BIB001):  Labeling a malicious executable as a variant of a known family is important for security applications such as triage, lineage, and for building reference datasets in turn used for evaluating malware clustering and training malware classification approaches. Oftentimes, such labeling is based on labels output by antivirus engines. While AV labels are well-known to be inconsistent, there is often no other information available for labeling, thus security analysts keep relying on them. However, current approaches for extracting family information from AV labels are manual and inaccurate. In this work, we describe AVclass, an automatic labeling tool that given the AV labels for a, potentially massive, number of samples outputs the most likely family names for each sample. AVclass implements novel automatic techniques to address 3 key challenges: normalization, removal of generic tokens, and alias detection. We have evaluated AVclass on 10 datasets comprising 8.9 M samples, larger than any dataset used by malware clustering and classification works. AVclass leverages labels from any AV engine, e.g., all 99 AV engines seen in VirusTotal, the largest engine set in the literature. AVclass’s clustering achieves F1 measures up to 93.9 on labeled datasets and clusters are labeled with fine-grained family names commonly used by the AV vendors. We release AVclass to the community.

Literature Review:
Based on the AndroZoo dataset, we are able to collect 15,297 repackaging pairs to be shared as repackaging reference dataset. We find that many apps are repackaged several times by different attackers, with a minimal, mean, and maximum times of 1, 2.168, and 176, respectively. Overall, our RePack dataset includes 15,297 repackaged apps for 2,776 original apps. Table 6 shows the top three original apps that are repackaged by over 100 different attackers. Interestingly, all those three apps are from the official Google Play store, suggesting that Google Play apps are somehow more favoured by attackers to repackage and distribute. Fig. 4 plots the distribution of DEX size of all the collected RePack apps, where the size ranges from 3.67 KB (minimal) to 16,180 KB (maximum), with a median and mean size of 965.2 KB and 88.67 KB respectively. This distribution suggests that RePack is quite diverse, containing small-size, middle-size, and large-size Android apps. We then go one step deeper to investigate the changes of DEX size between the two apps of a given pair. Among the 15,297 app pairs, over 70% of them have shown that repackaging will eventually enlarge the DEX file, suggesting additional code is usually injected during repackaging. However, for nearly 30% of repackaging cases, the DEX size of repackaged apps are smaller than that of the original apps. Fig. 5 and Fig. 6 further respectively plots the distribution of the number of Resource Files and Java Files for the benchmark apps. The number of resource files ranges from 12 to 10,529  , where the median and mean values are 150 and 247, respectively. For Java files, the number ranges from 6 to 7225, where the median and mean values are 662 and 1050, respectively. These two distributions once again suggest that the RePack dataset is quite diverse, where both  . The maximum number is considered as an outlier so that it is not presented at the boxplot. This explanation also applies to other boxplots. apps with a small number of resource/Java files and with a large number of resource/Java files are included. Interestedly, Spearman's rank correlation coefficient (i.e., ρ < 0.35) suggests that there is no strong correlation between the number of resource files and the number of Java files, further confirming the diversity of our benchmark dataset. 7 plots the distribution based on the diff of Creation time between the two apps of a given repackaging pair. Comparing to the creation time of the original apps, the repackaging delay ranges from several days to several years with an average, 88.67 days. This distribution also suggests that our collected RePack apps are diverse, containing different repackaging cases that could be interesting to malware analysts to investigate. Finally, we use the AVClass BIB002 labelling tool to assess the diversity of repackaged malicious apps in our dataset. Given a repackaged app, we consider it as malicious as long as one of VirusTotal hosted anti-virus products flags it as such. For a given app and its labels from VirusTotal antivirus engines, AVClass outputs a unique name of malware or adware family. We feed AVClass with all the repackaged malicious apps in our dataset. AVClass has successfully classified 5,960 repackaged apps of our dataset into 45 known families, while the Genome dataset includes 49 families. Moreover, our dataset includes about 9,337 repackaged apps that AVClass is not able to categorize into a known malware or adware family. Overall, all the aforementioned studies, covering different aspects, suggest that our collected repackaged pairs, namely RePack, is quite diverse, and therefore is reliable to be leveraged to support various analyses. Last but not the least, as discussed in our previous work  , for detecting repackaged Android apps, common libraries may cause both false positive and false negative results. Hence, we extend our benchmark to also provide library information for each repackaged pairs. We hope the extended information can encourage the community to innovate in-depth analyses for better understanding the facts between libraries and app clones, including malicious ones. The library usage (i.e., the 1,113 libraries summarised by Li et al.  ) of each app in the benchmark has been also made publicly available in our replication dataset. Moreover, to facilitate the use of library information for Android-based analyses, we provide a research-based prototype tool called LibExcluder for generating library-free versions of given Android apps. The goal of LibExcluder is to remove library code from a given Android app. Given a whitelist of common libraries, LibExcluder takes as input an Android app and outputs a new app version, which is generally as same as the inputted one except that the code belonging to libraries configured in the whitelist are excluded. Therefore, LibExcluder presents to existing state-of-the-art approaches a new app version where library code no longer exists. Without any modification (i.e., being non-invasive), existing approaches such as IccTA BIB001 can benefit from this work to perform library-free analyses. Our dataset is, to the best of our knowledge, the largest one containing repackaged app pairs. It is built from a representative set of apps, and includes a diverse set of repackaged apps.