**2. Android security architecture**

In a general sense, Android is not only an OS but a platform of three main building blocks: device hardware, Android OS, and the application runtime, see **Figure 1**.

First of all, the Android device hardware block refers to the wide range of hardware configurations where Android can be run, including smartphones, tablets, watches, automobiles, smart TVs, OTT gaming boxes, and set top boxes. Android is processor-agnostic, but it does take advantage of some hardware-specific security capabilities such as ARM eXecute-Never. Secondly, the Android OS building block refers to the Android OS itself, which is built on top of the Linux kernel, thus all device resources are accessed through the operating system. Thirdly, the Android application runtime block refers to the managed runtime used by applications and some system services on Android [2]. In this case, it must be taken into account that applications are written in the Java language and run in the Android runtime (ART). However, many applications, including core Android services and applications, are native applications or included native libraries. Both ART and native applications run with the same security environment, contained with the applications sandbox. Thus, applications get a dedicated part of the file system in which they can write private data, including database and raw files [1].

In this context, in terms of security, Android incorporates industry-leading security features and works with developers and device implementers to keep the Android platform and ecosystem safe. It was designed with multi-layered security that is flexible enough to support an

**Figure 1.** The main Android platform building blocks, adapted from [1].

Moreover, the growing trend of implementing bring your own device (BYOD) policies in organizations has also contributed to the adoption of these technologies, not only for everyday communication activities but to support enterprise systems, industrial applications, and commercial transactions, which raise new security issues. In this scenario, operating systems have also played an important role in the adoption and proliferation of mobile devices and applications, giving also space for the appearance of malicious software (malware). This is the case for the Android OS, which, due to its openness and free availability, has become not only a major stakeholder in the market of mobile devices but has also become an attractive target

Google, the Open Handset Alliance manufacturers, and the Android developers' community have made many efforts in order to improve Android's security. However, the emergence and evolution of new security threats continue being an important issue. Therefore, in this chapter, we advocate to present some current trends and results in the Android malware analysis and detection research area. We start by briefly describing the Android's security model, followed by a discussion of some static and dynamic malware analysis techniques in order to provide a general view to the analysis and detection processes to the reader. After that, a description of a particular set of software developments, which exemplify some of the discussed techniques, is presented accompanied by a set of practical results. Finally, a set of conclusions about the future development of the ideas explored in this chapter are drawn.

In a general sense, Android is not only an OS but a platform of three main building blocks:

First of all, the Android device hardware block refers to the wide range of hardware configurations where Android can be run, including smartphones, tablets, watches, automobiles, smart TVs, OTT gaming boxes, and set top boxes. Android is processor-agnostic, but it does take advantage of some hardware-specific security capabilities such as ARM eXecute-Never. Secondly, the Android OS building block refers to the Android OS itself, which is built on top of the Linux kernel, thus all device resources are accessed through the operating system. Thirdly, the Android application runtime block refers to the managed runtime used by applications and some system services on Android [2]. In this case, it must be taken into account that applications are written in the Java language and run in the Android runtime (ART). However, many applications, including core Android services and applications, are native applications or included native libraries. Both ART and native applications run with the same security environment, contained with the applications sandbox. Thus, applications get a dedicated part of the file system in which they can write private data, including database

In this context, in terms of security, Android incorporates industry-leading security features and works with developers and device implementers to keep the Android platform and ecosystem safe. It was designed with multi-layered security that is flexible enough to support an

device hardware, Android OS, and the application runtime, see **Figure 1**.

for cybercriminals.

198 Smartphones from an Applied Research Perspective

and raw files [1].

**2. Android security architecture**

open platform while still protecting all users of the platform. Security controls were designed to reduce the burden on developers. In this way, security-experienced developers can easily work with and rely on flexible security controls and developers less familiar with security concepts will be protected by safe defaults [1].

Moreover, Android provides a set of key security features, which are: robust security at the OS level through the Linux kernel, mandatory application sandbox for all applications, secure interprocess communication, application signing, and application-defined and user-granted permissions [1]. In the first case, as shown in the Android software stack, see **Figure 2**, each component assumes that the components below are properly secured. In this scheme, with the exception of a small amount of Android OS code running as root, all code above the Linux kernel is restricted by the application sandbox [1]. It is important to notice that the Android kernel is slightly different from a "regular" Linux kernel, the differences are due to a set of features originally added to support Android, and some of them are the low memory killer, wakelocks, anonymous shared memory, alarms, paranoid networking, and Binder. However, Android's security model also takes advantage of the security features offered by the Linux kernel. In a Linux system, which is a multi-user operating system, the kernel can isolate user resources from one another, just as it isolates processes. Consequently, one user cannot access another user's file, unless explicitly granted permission, and each process runs with the identity of the user that started it. In a traditional system, a user ID (UID) is given either to a physical user that can log into the system and execute commands via the shell or to a system service (daemon) that executes in the background. At this point, it is also worth to notice that Android was originally designed without the need for registering different physical users with the system, thus the physical user is implicit and UIDs are used to distinguish applications instead. This forms the basis of Android's application sandboxing [3].

On top of the Linux kernel layer is the hardware abstraction layer (HAL). This layer provides a standard method for creating software hooks between the Android platform stack

**Figure 2.** Android software stack, adapted from [1].

and the hardware. The HAL allows to implement functionality without affecting or modifying the higher level system [4]. In the next layer, the libraries component acts as a translation layer between the kernel and the application framework. The native libraries in Android are written in C and C++, most of which are ported from Linux, but are exposed to developers through a Java API. At the same level, there are also components from the Android runtime and core libraries. The virtual machine is an important part of the Android operating system and executes system and third-party applications [4, 5].

At the next level, the Android framework layer provides a suite of services or systems that are useful when writing applications. Commonly referred to as the application programming interface (API) is one of the building blocks for the final system or end-user applications. Finally, at the top most layer, applications component of the Android OS is located, which is the layer closest to the end user. All finished developed products will execute in this space by using the API libraries and the runtime environment [5].

As mentioned before, Android apps are composed of different components and each app is sandboxed by executing it in a separate process with a distinct user ID and assigning it to a private data directory on the file system. The four basic Android application components are *Activities*, *BroadcastReceivers*, *ContentProviders*, and *Services*. All components can be interconnected remotely across process boundaries by using different abstractions of Binder inter process communication (IPC) [6]. These interconnections are commonly referred to as inter-component communication and are the primary communication mechanism in Android although it can provide classical channels such as files or sockets. Android apps can either contact system services or communicate directly with each other. User space processes can communicate with each other over Binder IPC via the Binder kernel module. Android's design provides different levels of abstraction for Binder IPC, allowing developers to easily make use of Binder IPC at the application level to connect different apps' components (stubs, proxies, and managers). All inter-component communication (ICC) is built on the top of Binder IPC [7], see **Table 1**.

Moreover, every application that is run on the Android platform must be signed by the developer. Application signing allows developers to identify the author of the application and to update their application without creating complicated interfaces and permissions.


**Table 1.** Inter-component communication (ICC) builds on top of Binder IPC.

and the hardware. The HAL allows to implement functionality without affecting or modifying the higher level system [4]. In the next layer, the libraries component acts as a translation layer between the kernel and the application framework. The native libraries in Android are written in C and C++, most of which are ported from Linux, but are exposed to developers through a Java API. At the same level, there are also components from the Android runtime and core libraries. The virtual machine is an important part of the Android operating system

At the next level, the Android framework layer provides a suite of services or systems that are useful when writing applications. Commonly referred to as the application programming interface (API) is one of the building blocks for the final system or end-user applications. Finally, at the top most layer, applications component of the Android OS is located, which is the layer closest to the end user. All finished developed products will execute in this space by

As mentioned before, Android apps are composed of different components and each app is sandboxed by executing it in a separate process with a distinct user ID and assigning it to a private data directory on the file system. The four basic Android application components are *Activities*, *BroadcastReceivers*, *ContentProviders*, and *Services*. All components can be interconnected remotely across process boundaries by using different abstractions of Binder inter process communication (IPC) [6]. These interconnections are commonly referred to as inter-component communication and are the primary communication mechanism in Android although it can provide classical channels such as files or sockets. Android apps can either contact system services or communicate directly with each other. User space processes can communicate with each other over Binder IPC via the Binder kernel module. Android's design provides different levels of abstraction for Binder IPC, allowing developers to easily make use of Binder IPC at the application level to connect different apps' components (stubs, proxies, and managers). All

inter-component communication (ICC) is built on the top of Binder IPC [7], see **Table 1**.

Moreover, every application that is run on the Android platform must be signed by the developer. Application signing allows developers to identify the author of the application and to update their application without creating complicated interfaces and permissions.

and executes system and third-party applications [4, 5].

**Figure 2.** Android software stack, adapted from [1].

200 Smartphones from an Applied Research Perspective

using the API libraries and the runtime environment [5].

Applications that attempt to install without being signed will be rejected by either Google Play or the package installer on the Android device. Application signing ensures that one application cannot access any other application except through well-defined IPC. Applications can be signed by a third-party or self-signed. It is also possible to declare security permissions at the Signature protection level, restricting access only to applications signed with the same key while maintaining distinct UIDs and application sandboxes. A shared application sandbox is allowed via the shared UID feature where two or more applications signed with same developer key can declare a shared UID in their manifest [8].

Android applications can access only their own files and any world-accessible resources on the devices due to the sandboxed nature of Android. However, Android can grant additional, fine-grained access rights to applications in order to allow for richer functionality. Those access rights are called permissions, and they can control access to hardware devices, Internet connectivity, data, or OS services. Applications can request permissions by defining them in the AndroidMAnifest.xml file. At the application install time, Android inspects the list of requested permissions and decides whether to grant them or not. Once granted, permissions cannot be revoked and they are available to the application without any additional confirmation. For some features, explicit user confirmation is required for each accessed object, even if the requesting application has been granted the corresponding permission [3].

Additionally, Android also enforces security by providing preinstalled and user-installed applications. Pre-installed applications work as users applications and as providers of key devices' capabilities that can be accessed by other applications. This application may be a part of the open source Android platform or they may be developed by a device manufacturer for a specific device. On the other hand, Google Play, Android's application official store, offers users hundreds of thousands of applications, including many third-party applications [1].

Outside these security features, Android also provides a set of cloud-based services that are available to compatible Android devices with Google Mobile Services. These services are not part of the Android Open Source Project, but are included on many devices. See **Figure 3**.

**Figure 3.** The primary Google security services.

Briefly described, *Google Play* is a collection of services that allow users to discover, install, and purchase applications from their Android device or the web. It also provides community review, application license verification, application security scanning, and other security services. The *Android update service* delivers new capabilities and security updates to selected Android devices, including updates through the web or over the air (OTA). The *Application services* term refers to a set of frameworks that allow Android applications to use cloud capabilities such as (backing up) application data and settings and cloud-to-device messaging (C2DM) for push messaging. The *Verify Apps* service warns or automatically blocks the installation of harmful applications, and continually scan applications on the device, warning about or removing harmful apps. *SafetyNet* is a privacy preserving intrusion detection system to assists Google tracking and mitigating known security threats in addition to identify new security threats. The *SafetyNet Attestation* is a third-party API to determine whether a device is CTS compatible. Attestation can also assist to identify the Android application communicating with the application server. Finally, the Android device manager is a Web and Android application to locate lost or stolen devices [1].

As it can be observed from the previous description, Android has become a continuously evolving complex ecosystem composed of multiple subsystems and services that put together an enormous challenge in terms of security. In this context, in the following section, a brief discussion of some attempts to conceptualize and characterize the Android attack surface and key security challenges is presented prior to the later discussion of some of the main malware analysis and detection techniques, as an initial landmark from where techniques and research approaches presented later on may be better referred to or mapped to specific security aspects of the Android ecosystem.
