The Dark Side of Native Code on Android

Abstract

<p>From a little research experiment to an essential component of military arsenals, malicious software has constantly been growing and evolving for more than three decades. On the other hand, from a negligible market share, the Android operating system is nowadays the most widely used mobile operating system, becoming a desirable target for large-scale malware distribution. While scientific literature has followed this trend, one aspect has been understudied: the role of native code in malicious Android apps. Android apps are written in high-level languages, but thanks to the Java Native Interface (JNI), Android also supports calling native (C/C++) library functions. While allowing native code in Android apps has a strong positive impact from a performance perspective, it dramatically complicates its analysis because bytecode and native code need different abstractions and analysis algorithms, and they thus pose different challenges and limitations. Consequently, these difficulties are often (ab)used to hide malicious payloads. In this work, we propose a novel methodology to reverse engineering Android apps focusing on suspicious patterns related to native components, i.e., surreptitious code that requires further inspection. We implemented a static analysis tool based on such methodology, which can bridge the “Java” and the native worlds and perform an in-depth analysis of tag code blocks responsible for suspicious behavior. These tags benefit the human facing the reverse engineering task: they clearly indicate which part of the code to focus on to find malicious code. Then, we performed a longitudinal analysis of Android malware over the past ten years and compared the recent malicious samples with actual top apps on the Google Play Store. Our work depicts typical behaviors of modern malware, its evolution, and how it abuses the native layer to complicate the analysis, especially with dynamic code loading and novel anti-analysis techniques. Finally, we show a use case for our suspicious tags: we trained and tested a machine learning algorithm for a binary classification task. Even if suspicious does not imply malicious, our classifier obtained a remarkable F1-score of 0.97, showing that our methodology can be helpful to both humans and machines.</p>

Unmasking the Veiled: A Comprehensive Analysis of Android Evasive Malware

“…This section discusses the results of the analysis we conducted over the malware and the goodware datasets. Starting from the app's execution traces, we developed a post-analysis routine that identifies DETs and IETs by looking at the list of events that occurred after the first access to the base.apk file (which, as explained by Ruggia et al [78], signals the start-up of an Android app). When reporting the results of evasive behaviors and methods, we will use the unique identifier (in uppercase) we introduced in Section 3.4.…”

“…This technique can be exploited for detecting hooking (e.g., Xposed) and rooting (e.g., Magisk) apps. Even if there is proper permission for doing it, Ruggia et al [78] demonstrated that there are tricks a malicious app can leverage to bypass this protection mechanism. For instance, restrictions are not applied to apps targeting API level 30 or lower, which can retrieve the metadata of any app in the system.…”

VEDRANDO: A Novel Way to Reveal Stealthy Attack Steps on Android through Memory Forensics

“…6 in Table 4 is a Trigger Event; that is, it alerts the user that a suspicious event has possibly occurred, which initiates an investigation process. It is typical for realistic malware aiming to be stealthy to wait until it is the right time to execute [57]. In this case, the malware waits until the hijacked app is not in use, so as not to alert the user of abnormal behavior.…”