A popular method that attackers may use to distribute malicious functionality is through repackaging genuine applications. This topic is discussed in the following section.
2.5 Application Repackaging
Repackaged applications pose a serious threat to the Android ecosystem and can be used in order to perform various types of attacks, including a variation of relay attacks (discussed in previous sections). In the past, they have been found to be responsible for approximately 86% of the Android malware distribution [171].
In the context of this thesis, repackaged applications are defined as applications that impersonate a genuine application by slight modifications/variations to the genuine application’s artwork and/or changes to its source code in a way that the repackaged application looks and/or feels like the genuine application. The main objective of a repackaged application is to mimic a genuine application so it can target novice users that gravitate towards the popularity/functionality of the genuine application. In this definition, applications that infringe the potential intellectual property of the original application and present themselves as unique/different applications, are not included.
2.5.1 Threats to the Android Ecosystem
Major threats posed by application repackaging can be separated into those concerning the application developer and those concerning the user.
Threats to the Developer
Developers are given the opportunity to gain financial profit through their applications.
Repackaged applications pose a threat to them in various ways.
• Unauthorised redistribution: An attacker can redistribute an application, signed using their own private key, and possibly sell it in an application store, without the original developer’s permission.
• Advertisements: Potential revenue from an application might be redirected to the attacker, as they might have altered the developer’s account with their account, thus receiving the advertisement revenue. More specifically, Android applica-tions can include advertisements that are linked to a user’s account, typically the developer’s. The linked account is credited based on the advertisement clicks or impressions. An attacker can alter the advertisement package and replace it with theirs. In this way, the profit from users who install the repackaged application will be going to the attacker instead of the original developer [61].
48 Chapter 2. Relay Attacks in Contactless Transactions
• Cracking (Piracy): Application repackaging might distribute pirated copies of a genuine paid application, by bypassing any implemented verification and validation mechanisms.
Threats to the User
Repackaged applications that aim to harm the user may achieve their goal in different ways.
• Trojan horse: A repackaged application could act as a Trojan horse. Malicious code can be implanted in the original application, capable of intruding the platform’s security and/or the user’s privacy. For example, repackaging an application that requires permissions to access the Internet and the device’s storage can allow an attacker to steal the user’s images.
• Denial of upgrade: An Android application should be signed using the same private key as the version that is already installed in order to get updated. A repackaged application will not be updated by a genuine application’s update, since the signatures will not match. Therefore, the user will not be able to upgrade once a repackaged application has been installed. Not being able to update an application can pose a threat. An attacker, for example, can take advantage of a known vulnerability in an application by re-signing and distributing the unpatched version of the application. This way, the user will be unable to upgrade to the newer, patched version, without uninstalling the already installed application first.
• Variation of Mafia/Terrorist Fraud Attack: An untrusted user (prover) is usually described in the definition of a Terrorist Fraud Attack, who is cooperating with the attacker either willingly, or after being threatened. In the case of a Mafia Fraud Attack, the attacker typically uses some relay equipment, while the user (prover) is considered to be trusted. In the field of smartphones, an attack is also applicable that combines elements from both, in which the user is considered to be legitimate but the device has been compromised by the attacker. While the architecture of the attack, as well as the attacker’s access to the user’s resources, remain the same as in a traditional Terrorist Fraud Attack, the user is unknowingly cooperating. A malicious application is used in order to retrieve the relevant information from the user’s device. Such an attack has been demonstrated in [131]. Repackaged applications can be used for the distribution of such applications.
2.5.2 Related works
AndroGuard was proposed by Desnos and Gueguen [45]. Their proposal is based on Control Flow Graphs, used to measure the similarity between decompiled applications.
2.5. Application Repackaging 49
Crussell et al. proposed DNADroid that uses Program Dependency Graphs to detect similar applications [41]. The authors claim that their system produces a low false positive rate. However, the authors state that advanced obfuscation techniques can go undetected. To increase the system’s performance, they only compare the application in question against applications with similar names.
Zhou et al. used Fuzzy Hashing for repackaging detection [170]. This method is based on generating a hash of the application by breaking it down into small chunks and combining their hashes. They also remove string operands that can easily be altered from the instructions prior to hashing, in order to prevent common obfuscation techniques. They have created an application called DroidMOSS. They state that although their system is very robust, detection may fail if big chunks of code have been added to the original application.
Another solution, proposed by Hanna et al., introduces the idea of Feature Hashing for the detection of similar applications [75]. The main goal of this approach is to detect pirated applications and applications that use already known malicious code.
For this purpose, a tool called Juxtapp was created, that according to the authors is resilient to some amount of obfuscation.
Hu et al. [82], proposed MIGDroid, which makes use of method invocation graph-based static analysis as a means for repackaging detection. The aim of their proposals is to detect repackaged applications injected with malware, complementing prior solutions. High effectiveness of the solution was reported, with 1,260 malware-contaminated repackaged applications being detected.
Zhauniarovich et al. [167] proposed detection of repackaged applications based on the contents of the .apk file. Their method showed results similar to those of techniques that involve code analysis. SHA1 is used for the comparison of all the files between different applications. A repackaged application with slight changes on many files might go undetected. The authors propose a combination of their method with code analysis in order to overcome this issue.
In [48], the authors statistically extracted data-flow features based on API calls triggered by user interactions with the application’s interface. According to the authors, very high detection rate was achieved, comparative to the state-of-the-art at the time of publication. Even though the primary goal of this technique is malware detection rather than repackaging detection, the authors reported some effectiveness in detecting repackaged applications as well.
Other methods have also been developed that do not have as primary goal repackaging detection, but may detect it in many occasions [24, 91, 160, 168]. A framework capable of measuring the obfuscation resilience of algorithms used in repackaging detection programs was also proposed in 2013 by Huang et al. [84]. Other researchers have also proposed methods for detection of repackaged applications as well, or have investigated the subject [40,135,166].
In [134], the authors used the Kullback-Leibler Divergence metric to detect repackaged applications. Based on smali opcode [65] (i.e. disassembled Android Java
50 Chapter 2. Relay Attacks in Contactless Transactions
code) that can be common on both genuine and repackaged applications, a population distribution is built for genuine and potentially repackaged applications. The authors report high detectability of repackaged applications.
Aldini et al. [3] proposed PICARD, which is a collaborative approach to repackaging detection, by generating contracts based on the analysis of the behaviour of an application, at runtime. Certain application behaviours are not only categorised in terms of being known or unknown, but also in their likeliness to occur. Their approach is suggested to be complementary to static analysis tools.
In [147], the authors base their detection technique on code heterogeneity analysis.
Machine learning is used to classify code regions based on their behavioural features.
The authors report a very low false negative rate and a low false positive rate.
Due to the computational complexity of many methods that have been proposed, these methods are only meaningful on an application store level. For this reason, Zhou et al. [169] proposed client side initiated repackaging detection, with AppInk.
Their method uses application watermarking in order to confirm the authenticity of an application. In order to achieve that, a few additional steps have to be taken by the developer in order to embed the watermark.
Sun et al. [145] proposed detection of visually similar Android applications by comparing Android layout files of genuine and potentially repackaged applications.
Two approaches were proposed, a server-based and a client-based. The server-based approach calculates the distance between the tree of the layout files of genuine and potentially repackaged applications. The client-based approach is based on generation of hashes of the layout tree. The authors state that it is not as accurate as the server-based approach, but its aim is to provide protection for users who do not rely on application stores for installing applications on their devices. High detectability is reported, however the authors do not take into consideration layouts that are generated dynamically, for example through Java code.
In order to tackle this issue, Malisa et al. [110] used Graphical User Interface (GUI) crawling techniques to capture screenshots of applications, which were then compared for similarity. High detectability rate of perceptually similar applications was detected in this case as well. Their approach was later evaluated through a large-scale field trial, and they implemented a detection system capable of estimating the deception rate [109].
Chen et al. [26] proposed MassVet. Their technique combines repackaging and malware detection by first looking for applications with similar user interface as the suspected application and then looking for differences between the subject and the visually similar applications. The effectiveness was found to be higher than popular anti-malware software and was even capable of detecting potential zero-day malware.
In [100], the authors use text and image similarity detection techniques to detect visually similar applications based on their names, icons, descriptions, and screenshots.
Their aim is to detect camouflaged applications, meaning applications that try to imitate genuine applications in terms of style. The authors report high effectiveness of