AsDroid: detecting stealthy behaviors in Android applications by user interface and program behavior contradiction

Abstract

Android smartphones are becoming increasingly popular. The open nature of Android allows users to install miscellaneous applications, including the malicious ones, from third-party marketplaces without rigorous sanity checks. A large portion of existing malwares perform stealthy operations such as sending short messages, making phone calls and HTTP connections, and installing additional malicious components. In this paper, we propose a novel technique to detect such stealthy behavior. We model stealthy behavior as the program behavior that mismatches with user interface, which denotes the user's expectation of program behavior. We use static program analysis to attribute a top level function that is usually a user interaction function with the behavior it performs. Then we analyze the text extracted from the user interface component associated with the top level function. Semantic mismatch of the two indicates stealthy behavior. To evaluate AsDroid, we download a pool of 182 apps that are potentially problematic by looking at their permissions. Among the 182 apps, AsDroid reports stealthy behaviors in 113 apps, with 28 false positives and 11 false negatives.

IccTA: Detecting Inter-Component Privacy Leaks in Android Apps

“…However, those tools are not able to detect ICC leaks. AsDroid [25] and AppIntent [48] are two other tools using static analysis to detect privacy leaks in Android apps. Both of them try to analyze if a data leak is a feature of the application or not.…”

DroidRA: taming reflection to support whole-program analysis of Android apps

“…Because it is unrealistic to implement a brute-force technique to the password, we simply exclude such apps from our analysis. However, to allow tools such as FlowDroid to continue their analyses, we propose an instrumentation that conservatively solves this problem: we explicitly mock all the classes, methods and fields that are reported by the RAM module 7 but are not existing in the current class path 7 This means that we only take into account reflective calls.…”

“…We have conducted a quick review of recent contributions on static analysis-based approaches for Android, and have found that over 90% of around 90 publications [5] from top conferences (including ICSE and ISSTA) do not tackle reflection. Indeed, most state-of-the-art approaches and tools for static analysis of Android simply ignore the use of reflection [6,7] or may treat it partially [8,9]. By doing so, the literature has produced tools that provide analysis results which are incomplete, since some parts of the program may not be included in the app call graph, and unsound, since the analysis does not take into account some hidden method invocations or potential writes to object fields.…”

Using Weighted Bipartite Graph for Android Malware Classification

“…Moreover, the permissions stated in the Android-Manifest.xml are not necessarily employed by the App [8,9]. Several researches considered the API call used in the apps' code to differentiate between malware and goodware apps [10,11,12,13,14]. However, these methods need many API calls for malware classification.…”