Malware family classification is grouping malware samples that have the same or similar characteristics into the same family. It plays a crucial role in understanding notable malicious patterns and recovering from malware infections. Although many machine learning approaches have been devised for this problem, there are still several open questions including, “Which features, classifiers, and evaluation metrics are better for malware familial classification”? In this paper, we propose a machine learning approach to Android malware family classification using built-in and custom permissions. Each Android app must declare proper permissions to access restricted resources or to perform restricted actions. Permission declaration is an efficient and obfuscation-resilient feature for malware analysis. We developed a malware family classification technique using permissions and conducted extensive experiments with several classifiers on a well-known dataset, DREBIN. We then evaluated the classifiers in terms of four metrics: macrolevel F1-score, accuracy, balanced accuracy (BAC), and the Matthews correlation coefficient (MCC). BAC and the MCC are known to be appropriate for evaluating imbalanced data classification. Our experimental results showed that: (i) custom permissions had a positive impact on classification performance; (ii) even when the same classifier and the same feature information were used, there was a difference up to 3.67% between accuracy and BAC; (iii) LightGBM and AdaBoost performed better than other classifiers we considered.

Code obfuscation is a technique that makes it difficult for code analyzers to understand a program by transforming its structures or operations while maintaining its original functionality. Android app developers often employ obfuscation techniques to protect business logic and core algorithm inside their app against reverse engineering attacks. On the other hand, malicious app writers also use obfuscation techniques to avoid being detected by anti-malware software. If malware analysts can mitigate the code obfuscation applied to malicious apps, they can analyze and detect the malicious apps more efficiently. This paper proposes a new tool, Deoptfuscator , to detect obfuscated an Android app and to restore the original source codes. Deoptfuscator detects an app control-flow obfuscated by DexGuard and tries to restore the original control-flows. Deoptfuscator deobfuscates in two steps: it determines whether an control-flow obfuscation technique is applied and then deobfuscates the obfuscated codes. Through experiments, we analyze how similar a deobfuscated app is to the original one and show that the obfuscated app can be effectively restored to the one similar to the original. We also show that the deobfuscated apps run normally.

The users of smartphones are rapidly expanding worldwide. These devices have user's security-sensitive data and are ready to communicate with the outside world. Various kinds of malware are attacking smartphones, especially Android phones, but the existing Android security measure does not work satisfactorily. One-third of the current Android malware were privilege escalation attacks, which try to obtain root-privilege to fully compromise the Android security. We propose a detection and prevention scheme that protects Android against such privilege escalation attack that tries to get full access to all data. The proposed scheme monitors important system calls from an application process. If the system call must be called by privileged Android system components in normal operation, the scheme prevent it from executing. The scheme can detect and prevent new and unknown malware as well as currently known one.

Unity is the most popular cross-platform development framework to develop games for multiple platforms such as Android, iOS, and Windows Mobile. While Unity developers can easily develop mobile apps for multiple platforms, adversaries can also easily build malicious apps based on the “write once, run anywhere” (WORA) feature. Even though malicious apps were discovered among Android apps written with Unity framework (Unity apps), little research has been done on analysing the malicious apps. We propose static and dynamic reverse engineering techniques for malicious Unity apps. We first inspect the executable file format of a Unity app and present an effective static analysis technique of the Unity app. Then, we also propose a systematic technique to analyse dynamically the Unity app. Using the proposed techniques, the malware analyst can statically and dynamically analyse Java code, native code in C or C ++, and the Mono runtime layer where the C# code is running.

Vehicle digital forensics includes the process of collecting and analysing digital data stored in vehicles to find evidence related to traffic accidents or crime scenes. Through this process, we can reconstruct digital events by recognizing various information such as driver behaviour, driving patterns, vehicle destinations, and smartphones connected to a vehicle. Recently, many vehicle digital forensic studies have been conducted, but few of them have dealt with Android-based infotainment (or audio video navigation, AVN) systems. While many AVN systems adopt Android as the operating system, digital forensics of Android-based AVN systems is not easy. This is because Android-based AVN systems support various storage devices and data formats and have various data sources, making consistent data collection or analysis difficult. In this article, we perform digital forensics on four AVN systems: two Android 4.2.2 Jellybean-based and two Android 4.4.2 KitKat-based, aiming to develop a data acquisition and analysis method appropriate for each Android version. As a data collection method for the AVN system forensics, logical data acquisition is performed on the Jellybean-based systems and physical data acquisition on the KitKat-based systems. For the collected data, we identify and analyse Bluetooth data, navigation data, and system logs individually. Next, we investigate the differences in the storage structure and file location of major digital artefacts depending on the Android versions and show the limitations of the individual data analysis. Finally, we construct a timeline for the driver’s activities by integrating and analysing the diverse artefacts which consist of Bluetooth data, navigation data, and system logs.