# Machine-Learning-Based Android Malware Family Classification Using Built-In and Custom Permissions
## 2 Background  
### Android Permission Model  
The APK file is an archive that contains all the contents of an Android app. An APK includes three files and four folders, as shown in Figure 1. In this article, our discussion is confined to two main files: classes.dex and AndroidManifest.xml. Classes.dex contains binary codes called the Dalvik bytecode that implements the app's functionality. The manifest file, AndroidManifest.xml, contains a set of information about the app: package name, version number, entry points, permissions, etc. Android employs a permission-based security mechanism to restrict apps from accessing the resources of systems [6; 11; 31]. If an app tries to access hardware or software resources, it has to request the corresponding permissions through the AndroidManifest.xml file. The permissions are associated with an app's behaviors and capabilities with API calls. The permission mechanism is a key in the security model of Android. For instance, if an Android app needs to access the security-critical or privacy-sensitive methods of the Android application framework, the app must hold the corresponding permissions [32]. There are two kinds of Android permissions: _built-in_ and _custom_[13; 33; 34; 35; 36]. A built-in permission, also called a _system permission_ or _native permission_, is a predefined one introduced by the native Android Operating System (OS), and thus is available by default on Android. An Android device contains many built-in permissions for its functionality such as monitoring incoming MMS message, accessing the camera device, connecting to  
Figure 1: Structure of APK files. paired Bluetooth devices, broadcasting a notification, enabling/disabling location update notifications, etc. The constant values of the built-in permissions begin with the prefix android.permission. Examples of built-in permissions are android.permission.BROA DCAST_PACKAGE_REMOVED, android.permission.CONTROL_LOCATION_UPDATES, etc. The number of built-in permissions is continuously increasing. Android API Level 15 supports 166 permissions, and API Level 28 supports 325 permissions [13]. As more permissions are available, there are more ways to exploit them. A custom permission is defined by the developers of third-party apps to regulate access to their app-specific components by other apps [33; 34; 35]. Examples of custom permissions include com.android.launcher.permission.UNINSTALL_SHORTCUT and com.google.android.googleapps.permission.GOOGE_AUTH [12]. The permission com.android.launcher.permission.UNINSTALL_SHORTCUT allows the app to delete home screen shortcuts without user involvement, but is no longer supported. The permission com.google.android.googleapps.permission.GOOGE_AUTH allows apps to sign into Android services through the account saved on the device. All custom permissions defined by app developers are under the _dangerous_ protection level [13]. Since the number of built-in permissions is increasing and app developers can commonly define more custom permissions in Android, malware has plenty of chances to gain control over sensitive data and devices. Thus, in analyzing recent Android malware samples, it is very important to consider newly introduced permissions. In addition, built-in and custom permissions are poorly separated, and they are treated the same by Android. This might allow malicious apps to obtain unauthorized access to system resources through custom permissions. The combination of multiple permissions may reflect some harmful behaviors. Requesting specific permissions is essential for Android malware to achieve its goals. Therefore, the permissions requested by apps can play a crucial role in malware analysis [10]. As a result, Android permissions are very popular features and the most used in many Android malware research works [6]. Moreover, they cannot be easily obfuscated by malware writers because scrambling them can destroy the Android programming model [37]. Another issue is the _runtime permissions_.