Android Architecture

• Android is based on linux OS, so the android phone can take commands like any linux device ls, cd, rm, etc..
• Folders and Apps depend on the linux os permission model
  

The figure below shows the main components of Android platform

System Apps

• This layer includes both the pre-installed applications like Camera & Calender and the 3rd pary apps which is installed by the user like facebook.
• The apps run within the Android runtime

Java API Framework

• This component provides software tools and interfaces for building Android applications.
• Allows the app to interact with other apps and it also provides abstraction for HW access
• It also manages the UI

consists of many things like:

• Content Provider: helps in sharing data to other apps via specific directory which should be exported content://<app-URI>/directory
• View System: Making the UI of the application
• Managers:
  • Activity => the single activity is a single UI screen of the app
  • Notification => application’s reminders and popups
  • etc….

Android Runtime (ART)

• The base of the app and it powers the app with the help of core libraries
• Virtual Machine to generate .dex file as a result of compliation and optmization
• Introduced in Android 5 as a replacement for the Dalvik VM
  • ART and DVM are different in comilation strategies
    • ART : uses Ahead-of-Time (AOT) compilation at which the app is compiled during installation which leads to faster app and improved performance in runtime.
    • DVM : uses Just-in-Time (JIT) compilation at which some app functions are compiled during runtime when they are needed.
      • It was in the first versions of the Android
      • apps are compiled into java bytecode then to dalvik bytecode packaged in .dex of .odex format
    • Unlike the Java Virtual Machine (JVM), which is stack-based, the Dalvik VM is a register-based virtual machine. This architectural difference allows for more efficient execution on devices with limited CPU and memory resources, which is ideal for mobile environments.
  • In later Android versions, ART evolved to include hybrid JIT + AOT and Profile-Guided Optimizations (PGO), further enhancing runtime efficiency and battery performance.

Native C/C++ libraries

• In the same layer of Android runtime
• Contains core libraries like sqlite for db, openssl for secure connection, etc…

Hardward Abstraction Layer (HAL)

• Allows apps to access HW components irrespective of the type or manufacturer of the device like camera, bluetooth, GPS, etc…
• New HAL types like IOT devices, gaming peripherals, etc..

Linux Kernel

• Supp multiple CPU types (ARM, SoC, 32 bit, 64 bit)
• The version of the Android Runtime/ API version is determined in Manifest => min SDK version
• The higher the better but there’s a trade of between using higher version and serving as many customers as possible because not all phones supports the higher versions
• Low version means more danger (more vulnerable)
• The kernel also controls the available drivers by which the access to the devices during runtime occurs

Important directories

Android seperates the flash storage into two main partitions /system/ & /data/

• /system/ is used by OS and needs rooted mobile to access it
• /data/ is used for data and app installation

Application Journey

• Source Code (written in Java or Kotlin) + lib + resources ==compile==> DEX
  • The source code is compiled but lib just helps in compilation which is done by virtual machine giving DEX file
• DEX ==build==> APK
• APK ==sign==> signed APK
  • The APK must be signed using a certificate exist at the developer
• The signed APK is uploaded to google play and now can be installed on user’s device

Android Security Model

Android consists of 2 security layers: DAC-Discretionary Access Control & MAC-Mandatory Access Control

• Each application has its on user who is the oner of the app.
• users have UID between 10000 and 999999
• the username u0_a188 has UID 10188
• Apps can’t interact ith each other unless explicitly granted permissions or Content Provider/Broadcast Receiver is exposed.

Application components

Activity

• It’s the UI with which the user interacts
• Each activity in the app is a single screen
• login page is an activity and register page is another activity

Services

• It handles the background processes the works behind the UI like downloading or any process

Broadcast Reciever

• It handles communication between the apps with the OS of Android.
• When you connect ur phone to internet the system broadcasts a message saying that the phone is connected to the internet then the apps do their work depending on getting connected to internet

Local Storage

• How the app is stored in the system
• consists of
  • Shared Preferences: Sometimes to improve the application’s performance some data is stored on the device locally
  • DB (content provider): data is saved in SQlite db, The app reached the data through the content provider which must be configured properly to avoid local sqli vulnerability
  • Files: stored for each app and isolated from other app and sometimes stored on SDcard this was vulnerable in android 4.4 and the SDcard could be accessed by other apps

Additional components

• Fragments: part of activity
• Views
• Layouts
• Intents: method by which the components communicate (discussed later)
• Resources
• Manifest: The most important file in the app as it contains all the components of the application (discussed later)

Developer Options

It offers you a collection of great tools that we will use in the upcoming sections like

• USB-Debugging
• Select mock location app
• Select debug app/ Wait for debugger
• Pointer Location
• Bluetooth HCI Snoop Log

Enabling Developer Options

• Go to System
• About Phone
• Go to build number and click it, then you will see if you are developer and if not it will tell you how many clicks you should do to be developer

ADB (Android Debug Bridge)

Let’s look on Its components and how it works.

ADB Components

The components are:

• adb server on your machine
• adbd (the daemon on the mobile) running by default on the device, so you don’t need to install it or somehink like that
• adb client (binary) (in platform-tools and it comes with sdk)

adb protocol is text based protocol and we will look into it in the future

ADB process

How it works:

• adb client sends command to adb server
• adb server sends the command to the mobile
• The command is executed on the mobile then sends it back the server
• The response is forwarded back to the client
  

if we have single device connected we can use adb shell command, but if there are multiple devices we will use abd -s <serial> shell

ABD-Fowarding

consider there’s a service on port 31415 on the mobile, but it’s accessed locally only.
to access it through our localhost we use port forwarding

by using adb forward tcp:1337 tcp:31415 we will be able to access port 31415 on the mobile by accessing localhost:1337

Forwarding can also be reverse, but it’s not popular
by using adb reverse tcp:80 tcp:8080 we will be able to access port 8080 on our localhost through the mobile on port 80

Additional Notes

• sdcard and tmp directory are both accessible from our local device to the mobile without root privileges so we can use adb push file path_on_mobile and the path can be /sdcard/
• adb push to uplaod file to the mobile
• adb pull to download file from the mobile
• logcat is a great command you can run when u run app and the logs will be stored and you can get interesting info
• adb kill server then start again this will resolve many issues if occured with the server

Android Application Structure

• assets : contains resources used in the app like images, music, etc…
  • Xamarin, Cordova, and React-Native applications will use this folder to save code and DLL’s as well.
• com : no interesting data for us
• lib : This folder contains native libraries with compiled code targeting different device architectures. The libraries are stored as shared objects .so files which are compiled c/cpp files because they are better than java in specific task like rendering 3d effects. (sometimes developer hide data in c/cpp code instead of java code)
  • armeabi : compiled for the platform of the original device
  • x86 : compiled for our vm as example

• META-INF : related to signing the application. it contains verification information. Any modification made to the APK file will lead to invalidation, and the APK will need to be resigned.

    0xK4K45H1@htb[/htb]$ ls -l META-INF/
  
    total 664
    -rw-r--r--  1 bertolis  bertolis   1103 Jan  1  1981 CERT.RSA
    -rw-r--r--  1 bertolis  bertolis  77917 Jan  1  1981 CERT.SF
    -rw-r--r--  1 bertolis  bertolis  77843 Jan  1  1981 MANIFEST.MF
    <SNIP>
  

  • CERT.RSA : Contains the public key and the signature of CERT.SF.
  • CERT.SF : Contains a list of names/hashes of the corresponding lines in the MANIFEST.MF file.
  • MANIFEST.MF : Contains a list of names/hashes (usually SHA256 in Base64) for all the files of the APK, and is used to invalidate the APK if any of the files are modified.
• res : maybe considered like assets directory but it cannot be modified by the user at runtime, unlike assets. It has XML files defining UI layouts, fonts, etc…
• AndroidManifest.xml: It defines the essential parts of the app and We will dive into it later as it very important
• classes.dex : The most important file for us as it contains the JAVA or Kotlin classes in DEX format which can be executed by Android Runtime (ART) on Android 5 and higher devices of Dalvik VM on earlier versions.
• resources.arsc : This file contains precompiled resources that are used by the app at runtime and maps these resources to their actual values. the resources can be strings, layouts, colors, etc…
  It also includes a binary representation of XML resources.
  Let’s recap this
  

DEX/ODEX files

We are going to discuss it a very high view
You have an app and it is got compiled using Java Virtual Machine

• For Java app on your PC : It’s got compiled to Java Bytecode (main.class) and it is not good for smart phone as it need more resources which won’t fit with mobile battery
• For mobile app : IT’s got compiled to dalvik executable (classes.dex) which is suitable for smart phones

  Note: classes.dex contains at most 65535 methods and if we have more than this number we will have many .dex files which is called MultiDexing
  

Decompilation

To decompile an apk we need to get it first
And to get an apk

$ adb shell
$ pm list packages
$ pm path
$ adb pull <path>

to compile the app we use
apktool d <APK>
to build the app again
apktool b <APP PATH>
There are options like:

• -r to not decode resources like android manifest as it will cuz problems if decoded in this case
• -s to not decode source code as it will cuz problems if decoded in this case
• --force-manifest this is good if the problems in resources other than manifest so it will decode manifest even if decoding resources is set to false

When we compile we will get these files (let’s compare them to unzipping we saw before)

The identical files:

• assets
• lib
• META-INF and AndroidManifest.xml = original
• res and resources.arsc = res and note that it contains values dir which contains resources.arsc data
• com = in unknown

Different

• smali which contains .dex files so we have java src code and we have .smali files