Problem Definition and Motivation

Initially released on 5 November 2007 [211] as the first product of the Open Hand- set Alliance (an industry consortium of, as of January 2015, 84 “technology and mobile companies” [7]), the Android mobile platform [12] has seen wide adoption in the consumer market. Ephemeral market statistics [84] of “estimated worldwide Android-based mobile device shipments reaching 1.4 billion units in 2015” aside, a recent measurement study [205] on the official Android app market (i.e., Google Play Store) that crawls over 1.1 million apps furnishes enough evidence on the scale of the

current Android mobile platform. This tremendous growth is reflected by a surge of academic research on the application [183, 184, 25, 116, 152] and, particularly, secu- rity [204, 69, 236, 149, 228, 43] of the Android platform. The research body is too numerous to be enumerated here; some recent representative works that are closely related to the objective of this chapter are surveyed in Section 6.2.

The research objective of this chapter is to propose, implement, and evaluate declarative graph analysis as a scalable and robust approach for identifying and ex- plaining similarity between Android application packages (known by its acronym

“APK” in Android platform development documentation). Before moving on to

present the design (Sections 6.4 and 6.5) and evaluation (Section 6.6) of this work, we first address the following questions:

• What do we mean by “similarity between APKs”? • Why do we need to identify and explain such similarity?

• Why emphasizing the attributes “declarative, scalable, and robust?”

What do we mean by “similarity between APKs”? Similar APKs perform similar

functionality and/or share similar program structure due to, for example, identical authorship, common libraries, or software theft/plagiarism. Apps instantiated from similar APKs produce similar effects on the environment that include other apps and the underlying Android system. A closely related concept from software engineer- ing research is software birthmarks [142, 132, 20, 235, 215, 209, 110], defined as a unique characteristic of a program that can be used “as a software theft detection technique” [142] or “to determine the program’s identity” [110]—both focusing on es- tablishing the identity or origin of programs for detecting software theft/plagiarism. As we will discuss next, detecting similar APKs have wider practical applications than software theft/plagiarism.

Why do we need to identify and explain such similarity? Identifying similar APKs is a common theme underlying several current research problems, which can be cat- egorized into adversary scenario and non-adversary scenario.

Two prominent applications in adversary scenario are app plagiarism detection [62, 233, 55, 97, 234, 56, 229, 44, 225] and malware detection [85, 232, 164, 128, 219, 78, 16]. App plagiarism is a specialization of software theft/plagiarism (briefly discussed above) in the domain of Android apps, with the idiosyncrasies of the Android platform both simplifying (e.g., identifying platform API) and complicating (e.g., multiple- entry and reactive nature of apps) the task (this will be elaborated in Sections 6.4 and 6.5). A major line of recent research [85, 164, 219, 78, 16] that uses machine learning techniques for Android malware detection is based on the assumption that malware has structural/behavioral similarity that can be captured by proper training on a representative dataset [16]. The observation that real-world malware samples often share common malicious payloads or code [237, 16] (due to, for example, black market trading [77]) support the approach of detecting malware through similarity.

Applications in non-adversary scenario include app categorization [60, 216] (“this app is a flashlight tool”) and app recommendation [54, 223, 208, 127] (“you might also like these apps that provide similar functions”). A recent measurement study [205] reveals inadequacies in current app market such as coarse granularity of categories, mutual exclusion of categories in which apps may reasonably belong to multiple cate- gories, and app authors may exaggerate or misrepresent their apps’ functionality and quality for undeserved benefits. Identifying app similarity facilitate the categoriza- tion and vetting of apps on the market.

Explaining “how a group of apps are related”, or result explainability/inter- pretability, complements the identification of these apps and often provides insights that are needed to vet the identification results (we will discuss concrete examples later). Machine-learning-based techniques are often susceptible to the choice between accuracy and interpretability. One treatise on this topic [31] puts this trade-off plainly in its title “Machine learning: Between accuracy and interpretability.” The most accu-

rate models in practice are rarely the most explainable ones [32]. Result interpretabil- ity emerges as a main objective in recent Android malware detection research [85, 16].

Why emphasizing the attributes “declarative, scalable, and robust?” The size and

growth of the Android app market as revealed by recent measurement study of the official Google Play Store [205] (and not to consider the numerous alternative mar- kets such as Amazon Appstore [8]) leads to what researchers refer to as “a billion opcode problem” [44, 97]: The number of Android apps, and the resources/opcodes that determine their semantics, has grown to a scale that the performance gap be- tween linear and quadratic complexity in processing and cross-examining them (such as the task we are undertaking) make the difference between practical and imprac- tical. Pair-wise comparison of apps that are used in early app plagiarism detection works [62, 233, 55] do not scale well, and hence later works focus on improving this aspect by, for example, localizing the search of similar apps (such as the use of Vin- tage Point Tree [222] in detecting piggybacked apps [234]) or applying clustering techniques to apps encoded in metric spaces [97].

Real-world app analysis rarely has access to app source code, and is often per- formed in an uncooperative or even hostile scenario, in which the apps under analysis employ techniques to prevent such analysis. One example is the real Android mali- cious app analyzed in Section 6.3. A robust analysis is one that assumes an uncooper- ative/hostile scenario by default, and can withstand certain anti-analysis attempts at an affordable cost : As the adages “there is not free lunch” and “there is no panacea” go, an app analysis that claims robustness must be clear on “what scenarios it ap- plies to” and “at what cost.” We will elaborate on this point later concerning the presented work.

The benefits of the declarative approach to computational problem solving [130] are manifested in, for example, the standardization of SQL [59] for database queries and the application of Prolog [50, 88] to artificial intelligence research. A declarative approach to Android app analysis has the similar benefit of separation of concerns: An analyst, who has the domain knowledge of which app features are pertaining to

the task at hand, only needs to declare what features to find, rather than specify how to find the features. As surveyed in details in Section 6.2, most existing works on Android app analysis towards malware/plagiarism detection focus on specific aspects of the “how,” and the support for “what”-style exploration receives little investigation. An exception is the recent work by Feng et al. [78], in which the proposed system supports using Datalog [4], a subset of Prolog, to find privacy-leaking apps. A major objective/contribution of the present work is to advance the research on this front by proposing a methodology and devising a software tool to support declarative APK analysis.

The rest of the chapter presents an approach that addresses these aspects in the task of identifying/explaining Android app similarity in specific, and of Android app analysis in general.