Android Application Security: Android Application Architecture

In this series of articles, we are going to learn about Android application security. Before beginning into the security aspects of Android Apps, below are a few reasons to learn about Android AppSec as an Android developer, as a regular user of Android phones, or security engineer/analyst. 

Trends and Statistics

The global smartphone landscape has evolved significantly over the past decade. With Android holding around 70% of the market share globally and iOS capturing the rest, mobile devices have become essential in our daily lives. Here are some notable trends and statistics:

1. Growth in Mobile Device Usage

• Increased ownership: Smartphone adoption has surged. While global penetration was roughly 10% in 2010, today, over 85% of people worldwide own a smartphone. 
• Daily screen time: People now spend an average of over 4 hours each day on their smartphones, with younger users often exceeding this time. Activities range from social networking and streaming to gaming, messaging, and productivity.
• Expansion in emerging markets: Smartphone usage has particularly increased in emerging markets. Android’s affordability and broad functionality have made it popular in regions where it has become an accessible and essential tool.

2. App Usage and Installations

Number of Apps on Phones

The average user has between 60 and 90 apps installed, though they typically use around 30 regularly. Popular apps include essentials like messaging, social media, and streaming services.

At its core, the operating system is known as the Android Open Source Project (AOSP)[6] and is free and open-source software (FOSS) primarily licensed under the Apache License.

Google acquired Android in 2005 and open-sourced it. Then a lot of manufacturers started using it. Android is based on the Linux Kernel. Mobile devices have a dependency on battery, network, and screen size. Realtime users will expect similar performance of desktop/laptop on mobile devices as well. By keeping all these in mind, Android OS changed several key features.

From a simple mobile OS to a platform driving smartphones, tablets, wearables, and smart devices, Android’s evolution has been marked by continuous innovation, user-focused features, and a broad ecosystem that spans the globe. With its open-source nature and strong support from both Google and hardware manufacturers, Android remains at the forefront of mobile technology.

All the changes/details are out of scope for this series. We will concentrate on Android applications and their security aspects. 

Series Structure

The structure of the series is going to be:

• Android Application Architecture 
• Components of Android app and Reverse Engineering the app
• Security Controls available in the Android Operating System (OS) to protect the apps
• Developing our first Hello World App
• Tools to test/look into the app and testing types (SAST and DAST)
• Mobile OWASP Top 10 risks
• Open Source Tools installation and usage 
• Looking into Damn Vulnerable Apps (Intentional vulnerable apps)
• Securing the apps as user and developer.

Mostly the series going to be similar, based on how the outcome is coming for each article. Will split/merge the topics. There are several free/paid courses available on the internet. This one is going to be beginner-friendly. Let's go!

Android Platform Architecture

The Android Platform Architecture is layered to manage hardware interactions indirectly, providing both efficiency and security. At the foundation is the Linux Kernel, which ensures hardware resources are managed securely. However, hardware communication for components like Audio, Bluetooth, USB, Camera, and WiFi doesn’t happen directly with the kernel. Instead, it flows through multiple layers, each adding abstraction, as follows:

1. Linux Kernel Layer

The Linux kernel is the base of the Android OS, managing core system services like memory, process management, networking, and security.

It also includes drivers for device hardware, abstracting the details of hardware interaction and providing interfaces for higher-level components.

2. Hardware Abstraction Layer (HAL)

The HAL serves as an intermediary, allowing the Android system to interact with device hardware without knowing hardware specifics.

For each hardware type (such as Bluetooth or WiFi), there’s a corresponding HAL module, enabling Android’s high-level APIs to perform operations regardless of device manufacturer specifics.

3. Android Runtime (ART)

Android Runtime is where Android applications run. Each app operates on its own ART instance, providing isolation, security, and optimized performance.

4. Native C/C++ Libraries

Android includes a set of core libraries written in C/C++ that handle essential functions such as graphics rendering, media playback, and database management.

5. Java API Framework

The Java API Framework is the core of Android app development. It provides high-level services and is organized into components like:

• Activities and fragments: For UI and lifecycle management
• Content providers: To manage data sharing between applications
• Services: For background processing
• Broadcast receivers: For handling system-wide broadcast announcements
• Resource manager: Manages app resources like strings, layouts, and drawable assets

6. System Apps

System apps provide essential functionality and include apps like the dialer, SMS, and email client. These interact with the Java API Framework and provide standardized features users expect from Android devices.

This layered architecture ensures:

• Security: By isolating each layer and limiting direct hardware access
• Compatibility: Allowing Android apps to function consistently across various hardware
• Modularity: Simplifying upgrades and enabling flexibility in adding new features or hardware capabilities

Android Application File Structure

We now understand the Android Platform Architecture a little bit (it's not required to understand in depth). However, we need to understand the Android Application Architecture in detail. Then it is easy to secure the application. 

We use Android Studio to develop Android applications as a primary IDE. Android Studio bundles all the required information into an APK file. APK file is a simple ZIP file that contains several Android application-related files. 

An example of a file command on an APK file is below:

file InsecureBankv2.apk 
InsecureBankv2.apk: Java archive data (JAR)



It's a JAR file similar to any Java application. We can rename it as a ZIP and extract the contents of the APK file easily.

There are several image and XML files. However, the source code of the Android application will be bundled and packed as a DEX file. We can find that as well in this extraction as the classes.dex file.

As we discussed earlier, the Android application was developed by keeping the mobile device in mind. This DEX file is constructed in a way that helps the mobile devices compared to the JAR file. We will discuss more about this in the "Reverse Engineering of Android Application" post. 

This is the overall structure of the Android application. However, Android applications will have different components that are crucial in interacting with users and performing different tasks.

Android Application Architecture in Detail

Android apps are built on a structured architecture that consists of layers and components designed to handle UI, data, and business logic separately. This organized structure helps ensure the application is secure, maintainable, and performant.

Primary Components of an Android Application

• Activities: The entry points for user interactions and managing individual screens within the app
• Services: Background tasks, such as playing music or fetching data, without a direct UI
• Broadcast receivers: Handle system-wide broadcast announcements, like battery-low alerts, network changes, etc.
• Content providers: Enable data sharing between applications securely, allowing controlled access to structured data

These components interact through a well-defined Android Component Lifecycle, which helps manage resources and enhances security, especially around permissions and access control.

Next, we will create a simple "Hello, World!" Android application with the help of Android Studio.

"Hello, World!" With Android Studio

We can use any IDE to create Android Applications, but Android Studio is the recommended one since it has all the required tools to develop, build, bundle, compile, and package the code into a proper release application. 

Use this URL to download the required package that matches your OS. 

After installation, you can open the Android Studio to get started to create your first app. 

Click on "Start a new Android Studio project," then Empty Activity in the window of Create New Project. Then provide details like Name, Package Name, and Language (keep Java for now); then click "Finish."

It will take a few minutes to build and pull the required info. Once everything is loaded, you can click on the "Run" button in the menu to push your app onto the device/emulator. In the screenshot below, we can see the "Hello, World!" app installed on the emulator.

There is a complete tutorial from Android to get started with Android development. You can start learning from it more, but it's better to do a few levels in that course so you get some understanding of Android development which is going to help in security as well. 

This installed application will be in the /data/app/ folder of the Android device/emulator. Usually, Android OS will keep restrictions for accessing. But with rooting, we can access the files on the device. 

Below is the location of our app on the device:

/data/app/~~atRscmYr-Kvc_yK65rt1-Q==/com.example.myapplication-_Gg47qOt2dTPI3KgbERKuw==

To navigate to the folder, we use the adb utility/tool. adb will come as part of Platform-tools. Android documentation about adb will help to deep dive into details.

 adb shell
barbet:/ $ su
barbet:/ # cd /data/app
barbet:/data/app # ls
~~-rqmW-D3jLv6Unt7mmY1NQ==  ~~En-qhd9ZYwBn2WR5JTYBcg==  ~~P3F95WUpMy39FcKO7eU03Q==  ~~_cSSbxrLyLbwHYR6Ksf89A==  ~~j_HCTKzJrbJ7OVjNxm45Dw==  ~~v4O7AepCsIhtVRd5fixRXA==
~~1nX4hy_FhP0yBMqkZEbLvg==  ~~FJoYOGW-GvPOhDmzvVCD6g==  ~~PJdxNEYsLbwC7lorFMKTrg==  ~~a8g4zDUcy3FKkURT0ykUTA==  ~~kBtnjOPS0xEWY_XlfvLTaA==  ~~vD_rgwS55aJpet3R2BZmPw==
~~2GwlmPplPlupYx578cZSmA==  ~~GBA13F4IeKV0o6qXCPTI8A==  ~~PvKQU8YpEThBvEXGbsGiUQ==  ~~atRscmYr-Kvc_yK65rt1-Q==  ~~kqjZb9dWNges19EqXSVr3Q==  ~~vM80pt2jacKCCUjiKCh9UA==
~~2eFNNEK0J5-bfUpxfOnNGw==  ~~GLlG_-fANspcUHyWrrkFFQ==  ~~Q8Q8A8TF7ftxZGmXtJbsfg==  ~~bJmj0-JgGxRBZ1iODG7vUw==  ~~laR5tZJN4MVohgzjWMymJg==  ~~vvRXqZtaVpDagq6KtxMXQg==
~~3512wiuKuyLlXW5V9BmS8g==  ~~GmHjeZQ1_rb8jMtL0kCF8g==  ~~QOHLg7084hj8rNBvVYHYeg==  ~~cEDCX6WL0sRJaLtmgWl7hA==  ~~lhSezs3nbH70PIeAuAD-eg==  ~~wevBmhHPg6c48ZMT0lLlJg==
~~4j8mryNrn_BL-goFhz4jDA==  ~~GwXqxlgIdPLNI_7eB8dgrA==  ~~Qdd7zzYfVflMMaAGBQ8ZMw==  ~~dIPaGPNnH8lyO1N9Vtc8QA==  ~~njhSbqT2przJCsa2wUtcTQ==  ~~wrRC-eio-UhI9iShqMiJhA==
~~526Xh_LWBS8PqYnh5ufGKw==  ~~K1ZiefwUDqHVxXpQWI4JuA==  ~~R6X2QcWawNgijDDi18KlJA==  ~~dxB60eNmVCGZryLNyh9gPQ==  ~~o3qRhMV3nXSq7ODgYML0Dg==  ~~xMY3IOD_zktCOpPPZ-yYfg==
~~5KxnjIRFeKK_kHZIMBoRcQ==  ~~K54AJWrwOFyTE0DEI7jZTg==  ~~SIh-Q3Vd7J7HIyQzc3KNrA==  ~~eT3Y4fNFWDlrAbvdSIe2vA==  ~~pkWtz4EwF1LrEspjHXTdaQ==  ~~xdYzhm8KB0Ozafv8-IA7Og==
~~79VpiihF8TC3doHF4maEtA==  ~~LBtCo2pnLZRNu_bG1KmjIQ==  ~~SddUHnfa4Gi7iYGlKhcsxg==  ~~fHP9dScxf6_QCIJCzH-O5A==  ~~q0tc3vnCP5lI_gKjvh4vhA==  ~~xmWPghJbFqJh7Avs_ScrQg==
~~7YgLrFPweZu0S1qObP0bGg==  ~~M7APp4BSWjwbgg9xliub8A==  ~~TU9zLt0XNPdlo26BAr_aIw==  ~~fK-XM_oEN56YiasPAwALpQ==  ~~r-geYB8DIHRqz1uNSWn1fg==  ~~xtxwpYgzvM7Eq5rh8QG0tQ==
~~8N6Bf6xjvbx-P6OK1DeDyQ==  ~~MSw6x4JmrypY_E2G71wchw==  ~~U-9BzMakQpXF8fQn7oRyPQ==  ~~gndAwbGNwp0mzMUTP556Sg==  ~~sqZ9r75UA-KLblUwjUMQWg==  ~~zmzsA3nKuagzX2kJ2aoHcg==
~~AK82hlWJIrFJf2cgbVRR3g==  ~~N49G7i5xxnv8maYh5dC3xQ==  ~~Wv_H-lsX3qm0X8U6rn1F7Q==  ~~hfTx_FzGJ_VJ0ixIGudCZg==  ~~tIU6CE_K1gMAkxGc7TZ-1Q==
~~AVhLCUnFut_aUgIInmFjgA==  ~~OBMQu8GzOqNe4xU8h5AWuA==  ~~Y2ZhTq-_VcR0uNO0UF1sOQ==  ~~iZPWpc6onxTHPKpBcNXSng==  ~~uT4a003atzz5a0yjqIt-iQ==
~~CYMvruobvnTWdcu3ngZixQ==  ~~OjyvGDx0SlDou4g1S7NCvg==  ~~ZFaVzX-ty4fCpi7KEsM0Xw==  ~~j1xfzC4nBI5XhxNHOMtE4w==  ~~uX5e3AVDCt_uzVvXqCYAAw==
~~EPE-bpPb0AIjHi6UCl0SbA==  ~~OlAIzQ4y5WUTXaB4bCzwSw==  ~~_K9L_i0t1sRm54q7MsoS2A==  ~~jMmQ6FtaqWQ_HmLd85T_pQ==  ~~ufGic1Fu6VN7_Ak4kJI5Sw==

barbet:/data/app/~~atRscmYr-Kvc_yK65rt1-Q==/com.example.myapplication-_Gg47qOt2dTPI3KgbERKuw== # ls

base.apk

Let's understand what's going on here: When installing any application, Android OS will create a folder in the /data/app/ directory with Base64 value to avoid any collisions. To find our app, we can search all the folders with our app name or quick ls -lR | grep <appname>.

Let's pull our Hello World app and see what's inside. Extract the contents from the APK file. 

adb pull /data/app/~~atRscmYr-Kvc_yK65rt1-Q==/com.example.myapplication-_Gg47qOt2dTPI3KgbERKuw==/base.apk <currentfolder>

cd tmp
➜  tmp mv base.apk base.zip
➜  tmp unzip base.zip
Archive:  base.zip
  inflating: res/layout/notification_action.xml
  inflating: res/anim/btn_checkbox_to_unchecked_check_path_merged_animation.xml
  inflating: res/interpolator/btn_checkbox_checked_mtrl_animation_interpolator_0.xml
 extracting: res/drawable-xxhdpi-v4/abc_ic_star_half_black_16dp.png
  inflating: res/drawable/btn_radio_on_to_off_mtrl_animation.xml
  inflating: res/drawable-v21/abc_list_divider_material.xml
  inflating: kotlin/reflect/reflect.kotlin_builtins
 extracting: res/drawable-xhdpi-v4/notification_bg_low_pressed.9.png
  inflating: res/layout-v17/select_dialog_singlechoice_material.xml
 extracting: res/drawable-ldrtl-xxhdpi-v17/abc_spinner_mtrl_am_alpha.9.png
 extracting: res/drawable-xxhdpi-v4/abc_list_divider_mtrl_alpha.9.png
  inflating: res/color-v23/abc_btn_colored_text_material.xml

Folder structure:

Even though we didn't write a single line of code manually while creating this app, we see a bunch of files and code. 

It's all handled by Android Studio which does the magic.

Reverse Engineering the APK

Reverse engineering of the Android application is easy compared to the iOS application. But if an Android app uses any obfuscation methods (converting human-readable code to a non-readable format, but machines can understand it), it's not easy to understand what's going on in the code.

Let's consider there are no obfuscation methods used similar to our basic "Hello, World!" app. Then there are several tools available to get the original code back. 

The detailed build process has several steps and is out of scope for this series. But it's good to have a high level of understanding. This diagram shows the compilation process.

Source: Android Build Process

Now we are at the .apk step and navigating back to the src/MainActivity.java and AndroidManifest.xml, etc. files. The below tools help in this process. 

• Apktool 
• Jadx-gui

You can directly install these tools with apt-get install/brew install or follow the steps listed on the websites. 

Going forward, we use several tools for testing/analyzing the apps. Tool installation steps won't be available in these posts. 

Jadx-gui provides an easy way of accessing the code by just opening the APK file. The below screenshot provides an overview of our "Hello, World!" app.

The APK tool will be from the command line.

➜  tmp apktool d base.apk
I: Using Apktool 2.10.0 on base.apk with 12 thread(s).
I: Baksmaling classes.dex...
I: Loading resource table...
I: Decoding file-resources...
I: Loading resource table from file: /Users/dhanvi/Library/apktool/framework/1.apk
I: Decoding values */* XMLs...
I: Decoding AndroidManifest.xml with resources...
I: Regular manifest package...
I: Copying assets and libs...
I: Copying unknown files...
I: Copying original files...

The file structure below will be extracted.