Introduction

• Android is based on the Linux Operating System.

• Linux device commands work the same way ls, cat, etc.

• Permissions are dependent on the Linux OS filesystem permissions

Android Architecture

Source: Mobile Pentesting Gitbook

Each layer builds on the layers beneath it, relying on the security of the lower layers.

• Major Layers

  • Linux Kernel

    • Ties all layers together, it arbitrates all access to the underlying device hardware via Device drivers

    • Manages memory, processes and power management.

    • Run application on different API levels to see if vulns can be uncovered.

    • Support for multiple CPU types (ARM, SoC) and 32/64bit.

    • Applications are explicitly told which version of the ART/API version to run on

      • Android Manifest -minSDKVersion

      • The higher the better but developers want backwards compatibility

      • Lower version have more security issues

      • Access to physical components of the linux devices controlled by drivers like BT, etc.

  • Hardware Abstraction Layer (HAL)

    • Abstraction layer that allows applications to access hardware components irrespective of the device manufacturer or type

    • Allows apps to easily access camera or microphone without needing manufacturer specific drivers.

    • New HAL Types

      • Automotive - Android Auto / Apple Car Play

      • IoT

        • Fitness wearables, devices, google home etc.

      • Gaming peripherals

  • Libraries (Native C or ART)

    • C and C++ is the device's native language

      • Does not require a VM

      • Webkit - built in web browser for the app (iFrame)

      • OpenMAX AL, OpenGL ES - UI frameworks for 2D/3D models

    • Java is easier to code in so devs use this however they are moving to Kotlin fully as the recommended language.

    • Dalvik VM Specific libraries:

      • Direct interaction with a Dalvik VM instance

    • Java Interoperability Libraries:

      • Subset of core Java libraries adapted for Dalvik VM use

    • Android Libraries:

      • libraries used in Android app development

  • Java API Layer

    • This allows for your app to interact with other apps and also the device itself as defined in the Android App.

    • Content Providers - a way of sharing data to other applications via a specific directory (if exported)

      • content://<app-URI./directory

    • View System - used for making the Apps UI and normalizing it

    • Managers

      • Manages and runs things like:

        • Notifications - app popups for reminders

        • Telephony - calls/contacts etc.

        • Package - managing the application package, updates etc.

        • Location - manager of location services

  • System Application Layer

    • Individual applications we install and run/reside.

      • Pre installed applications

        • contacts, phones, etc

        • vendor specific apps

      • You can always set a new default app to replace a vendor app which is something iOS does not like you doing.

Android Security Model - Model & Identity and Access Management

There are two layers to the Android Security Model, first layer is implemented in the OS and keeps installed applications fundamentally isolated from one other. Second is the security layer of the application itself which allows developers to selectively expose certain app functionality to other apps.

UID Separation

This is the foundation of the Android Application Sandbox that prevents anything other than the application, certain OS features, or the "root" user from accessing the data.

• Owner will have a UID (10000-999999) like u0_a188 for UID 10188

• This stops interaction of applications within each other unless explicitly granted permissions or a Content Provider/Broadcast Receiver is exposed (when you click "Share to").

• Root user/System level accounts

  • Emulators w/non-Google play APIs allow root

Profiles

• Separated app data, for stuff like BYOD

  • Wifi bluetooth etc still accessible but isolated aspects like DLP clipboard, contacts, camera etc.

  • Work Profile, always on VPN can be limited to one profile so it doesn't have access to other items.

  • Primary User: This is the user created the first time you start a phone is started, always running, can only be removed by factory reset

  • Secondary User - Additional users added to the device can be updated by Primary user

  • Guest User - One guest user at a time, a fast way to give guest access

  • Kids Mode - specific for kids to access certain things like Samsung Kid Mode

A Note on Sandboxing

Android Application Sandbox creates a separation of files and code execution between applications on the same device. It is implemented in the OS, rather than the VM which allows for the VM to interact with the native code in the same application without constraints. The sandboxing is accomplished because each application runs as a separate process, under a separate userID as discussed above.

Android Virtual Machines

Virtual machines are abstraction layers between the application and underlying Android device. Apps are written in Java/Kotlin but are compiled into platform independent Dalvik Executable (DEX or ODEX), bytecode.

Dalvik vs ART |Source: MASPT Caendra Inc.

Android VMs run the DEX bytecode directly compiled from Java. It handles all the differences for translation between OSes. The VM concept exists so that devs do not need to be concerned about writing apps for specific devices/OS's.

Applications downloaded from the play store are typically in the DEX format and ODEX is used by OEMs to optimize apps that run at boot time or specific to device architecture.

DALVIK vs Android Runtime

• Every Android application runs in a Virtual Machine called Android Runtime

• DALVIK was the original runtime VM still references as Dalvik bytecode (more on this later)

• Android Runtime: Modern translation later from the applications Bytecode to device instructions

  • Every application runs in its own sandboxed VM

Filesystem applications are isolated from each other by creating a new user unique to the application.