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

• 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

• 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

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

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…
• com : no interesting data for us
• lib : contains .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
• res : maybe considered like assets directory as it contains images, etc..
• AndroidManifest.xml: We will dive into it later as it very important
• classes.dex : The most important file for us as it contains the JAVA source code.
  • and java is compiled in dex format
• resources.arsc : contains resources like resources used in the application.
  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