Android Application Framework

Why Know the App StructureSearch on YouTubeBookmarkSaved

The deck covers six topics: app folder structure, AndroidManifest.xml, resources, Android components, the Activity lifecycle and permissions.

There are two ways to pentest a mobile app. Both need this knowledge.

1. Through the interface. Open the app and give inputs through its screens (activities). Check its security, try different payloads, intercept the traffic, then modify it and add payloads.
2. Reverse engineer the APK. Get the source code and analyse it. This is also how static malware analysis works. You must understand the app structure to read it.

Android ComponentsSearch on YouTubeBookmarkSaved

An Android app has four main components.

Alarm app exampleSearch on YouTubeBookmarkSaved

App Folder StructureSearch on YouTubeBookmarkSaved

The Android Studio demo shows the project tree:

app/
  manifests/
    AndroidManifest.xml
  java/
    com.example.<app>/          (Java or Kotlin source, e.g. MainActivity)
  res/
    drawable/                   (bitmap images: jpg, png)
    layout/                     (activity_main.xml)
    mipmap/                     (launcher icons, ic_launcher.webp)
    values/                     (colors.xml, strings.xml, themes)
    xml/
Gradle Scripts/                 (build.gradle, proguard-rules.pro, ...)

Android Manifest FileSearch on YouTubeBookmarkSaved

AndroidManifest.xml:

• sits at the root of the project, with exactly this name;
• describes essential information about the app to the Android build tools (to build the APK), the Android OS and Google Play;
• declares the components of the app: all activities (launch info, permissions, intents used for communication), services, broadcast receivers and content providers.

A trimmed version of the sample manifest on the slide:

<?xml version="1.0" encoding="utf-8"?>
<manifest xmlns:android="http://schemas.android.com/apk/res/android">
    <uses-permission android:name="android.permission.SEND_SMS"/>
    <application
        android:allowBackup="true"
        android:label="@string/app_name"
        android:theme="@style/Theme.ActivityHello">
        <activity
            android:name=".MainActivity"
            android:exported="true">
            <intent-filter>
                <action android:name="android.intent.action.MAIN" />
                <category android:name="android.intent.category.LAUNCHER" />
            </intent-filter>
        </activity>
    </application>
</manifest>

Manifest in forensics and malware analysisSearch on YouTubeBookmarkSaved

• In static malware analysis, check the permissions. Example: a game app asking for the contacts or call list is suspicious.
• Check whether a service tag runs continuously in the background.

ResourcesSearch on YouTubeBookmarkSaved

Resources are the extra files and static content the code uses: bitmaps, layout definitions, animation instructions and so on.

ActivitySearch on YouTubeBookmarkSaved

An Activity represents a single screen with a user interface.

• An app can have more than one activity.
• All activities are declared in the manifest.
• The main activity is declared with an <intent-filter> that has the MAIN action and the LAUNCHER category.
• The main activity is the first screen the phone shows the user.

<intent-filter>
    <action android:name="android.intent.action.MAIN" />
    <category android:name="android.intent.category.LAUNCHER" />
</intent-filter>

IntentSearch on YouTubeBookmarkSaved

An Intent is a messaging object that requests an action from another app component. It enables communication between components (activities, services, broadcast receivers, content providers).

An intent object contains:

• Action: the mandatory part. A string naming the action to perform.
• Category: optional. A string with extra information about the kind of component that should handle the intent.

Two types of intentsSearch on YouTubeBookmarkSaved

Content ProviderSearch on YouTubeBookmarkSaved

A Content Provider supplies content or data to apps, from the Android system or from other apps.

Use it when one app must share data with, or access data from, a system or user-installed app. Example: WhatsApp accessing contacts or making a call.

Operations through a content provider:

• insert, update and delete data in a database
• read and write the contact list
• access photos, play music, and so on

The content provider hides which app or location accesses the data, and where the data comes from. Its data can live in a database, in files or come from the network.

Content ResolverSearch on YouTubeBookmarkSaved

Example: App 2 wants the contact list from App 1.

1. App 2 provides a URI (Uniform Resource Identifier) for the contact list.
2. The URI is passed to the content resolver.
3. The resolver resolves the content from the content provider's central repository.
4. Through the content provider, App 1 accesses the contact list.
5. The contacts return to App 2 as a cursor.

PermissionsSearch on YouTubeBookmarkSaved

Permissions protect the privacy of the Android user.

• Apps must request permission to access sensitive user data (contacts, SMS) and some system features (camera, internet).
• Depending on the feature, the system grants the permission automatically or prompts the user.
• By default, no app may do anything that harms other apps, the OS or the user. This covers reading or writing the user's private data, reading or writing another app's files, network access and keeping the device awake.
• An app declares the permissions it needs with <uses-permission> tags in its manifest. (The slide writes <user-permission>; the real tag is <uses-permission>.)

<manifest xmlns:android="http://schemas.android.com/apk/res/android"
    package="com.example.snazzyapp">
    <uses-permission android:name="android.permission.SEND_SMS"/>
</manifest>

SandboxingSearch on YouTubeBookmarkSaved

Each app gets:

• a separate instance with a unique ID (Linux user ID)
• separate resources
• a separate DVM

One app cannot access the resources of another. If a malicious app brings in malware, the malware stays inside its own instance.

• Sandboxing works by running apps in different processes with different Linux IDs.
• It is implemented at kernel level. So it applies to native apps and OS apps alike.

Binder (IPC)Search on YouTubeBookmarkSaved

Processes need an IPC (inter-process communication) framework to exchange data and signals. Android uses Binder.

• Binder is a service that lets one process access resources of another process or app securely.
• Intents and content providers are built on top of the Binder framework.
• Example: an app in process A uses a service in process B. A is the client and B is the server. WhatsApp reading the contact list from the database works this way.

Permission LevelsSearch on YouTubeBookmarkSaved

The protection level decides whether a runtime permission request is needed.

Normal permissions cover access to data or resources outside the app sandbox that pose little risk to privacy or device operation.

Dangerous permissions can affect user privacy or normal device operation.

Dangerous permission groups (from the slide)Search on YouTubeBookmarkSaved

Each name is prefixed by android.permission. (groups by android.permission_group.).

Runtime permission modelSearch on YouTubeBookmarkSaved

• On Android 6.0 (API level 23) and higher, the user is not told about permissions at install time. The app asks for dangerous permissions at run time (Deny or Allow).
• Up to Android 5.1.1 (API level 22), the user had to grant all dangerous permissions at install time.
• If an app update needs new permissions, the user must accept them before the update.

Activity LifecycleSearch on YouTubeBookmarkSaved

Reference for the theory: the Android developer guide page on the activity lifecycle.

The lifecycle diagram also has onRestart(). It runs when a stopped activity comes back, before onStart(). If an app with higher priority needs memory, the system can kill a paused or stopped app's process. When the user returns, it starts again at onCreate().

Good use of the lifecycle callbacks helps the app avoid:

• crashing if the user gets a phone call or switches to another app;
• using system resources when the user is not active in it;
• losing the user's progress if they leave and come back later;
• crashing or losing progress when the screen rotates between landscape and portrait.

Quick self-testSearch on YouTubeBookmarkSaved