Android Hacking- Part 1
Introduction, Architecture, Security Model, Virtual Machines and more.
Photo by Guido Coppa on Unsplash
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 10188This 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.