Intro to Android app structure | mobile pentesting | part 2

بِسْمِ اللَّـهِ الرَّحْمَـٰنِ الرَّحِيم

In the name of Allah

Hello there, I’m Ahmed Hesham currently I’m studying mobile pentesting, i want to share what I’m learning with others maybe it can help u to understand the basic app structure, so sorry for any mistake, I’ll do my best to make it clear as possible, this is the second part in our series

in Part 1 we saw many files from unzipping or decompiling the APK

you can check part one here Intro to Android app structure | mobile pentesting | part 1

now lets talk about very important file which is

AndroidManifest.xml

The AndroidManifest.xml file is a critical configuration file in an Android application. It's located in the root directory of the app's source code and contains essential information about the app's structure, components, permissions, and metadata. This file is required for every Android app, and it serves as a blueprint that the Android operating system uses to understand and manage the app.

let's discuss the file one by one

<manifest xmlns:android="http://schemas.android.com/apk/res/android" android:versionCode="1" android:versionName="1.0" package="com.mwr.example.sieve">

The package attribute in the Android manifest file specifies the unique identifier for the Android application. The package name is used to uniquely identify the app on the device and in the Google Play Store which is here “com.mwr.example.sieve”.

2.

<uses-permission android:name="android.permission.READ_EXTERNAL_STORAGE"/>
<uses-permission android:name="android.permission.WRITE_EXTERNAL_STORAGE"/>
<uses-permission android:name="android.permission.INTERNET"/>

These lines declare permissions required by the app. The app requests permission to read and write external storage and access the internet. For pentesting, you’d want to review these permissions to ensure they are necessary and not overly permissive.

3.

<permission android:label="Allows reading of the Key in Sieve" android:name="com.mwr.example.sieve.READ_KEYS" android:protectionLevel="dangerous"/>
<permission android:label="Allows editing of the Key in Sieve" android:name="com.mwr.example.sieve.WRITE_KEYS" android:protectionLevel="dangerous"/>

These lines define custom permissions for the app. These custom permissions are related to reading and writing keys and are marked with a protection level of “dangerous.” As part of mobile pentesting, you should evaluate how these custom permissions are used in the app and if they are correctly protected and justified, custom permissions are related to the context of the app.

4.

<uses-sdk android:minSdkVersion="8" android:targetSdkVersion="17"/>

• android:minSdkVersion: This attribute specifies the minimum Android version (API level) that your application can run on. In this case, it's set to API level 8, which corresponds to Android 2.2 (Froyo). This means your application will only run on devices with Android 2.2 or higher.
• android:targetSdkVersion: This attribute specifies the target Android version that your application was designed for. In this case, it's set to API level 17, which corresponds to Android 4.2 (Jelly Bean). This doesn't necessarily mean your application won't run on newer versions; rather, it indicates that you've tested and optimized your app for this particular version.

Interestingly, if the targetSDK version is <= 17, and the stars align you could have RCE via CVE-2012–6636. just know it for now

5. Activity elements are the lines that define the various activities (screens) within the Android app. They contain information about the app’s user interfaces and their configurations, we will discuss it in the end.

6. we have the services that's the app needs to run properly, services are related to the context of the app, maybe by reading it you will understand what it does.

androidmanifest.xml file is extremely fun it gives you a quick info about the app and what it does.

now lets talk about App Permissions.

App Permissions

each application is sandboxed, meaning they cannot access the data of other applications each app has its own user on OS. Custom permissions can be defined to allow specific data sharing between applications. The protection levels for custom permissions are “dangerous,” “normal,” and “signature.”

“Dangerous” means the user needs to grant permission and ask to allow or not

“normal” grants permission automatically without asking

and “signature” allows access only for applications signed with the same key. Signature protection is the most secure but may not be practical in practice. Hence, “dangerous” protection level is commonly used, although it may lead to some security risks.

we have three files are part of the Android operating system and are related to various aspects of the system’s configuration and permissions. Here’s a brief overview of each file:

1. /data/system/packages.xml:

The packages.xml file is located in the /data/system/ directory of an Android device. This file is used by the Android Package Manager (PackageManager) to store information about installed packages (applications) on the device. It contains details about each installed app, such as package name, version, installation status, granted permissions, and other package-related information.

When an app is installed or uninstalled on the device, the Package Manager updates this file to reflect the changes in the system’s package database. The file is essential for keeping track of the installed apps and their permissions.

<?xml version='1.0' encoding='utf-8' standalone='yes' ?>
<packages>
    <package name="com.example.app1" codePath="/data/app/com.example.app1" nativeLibraryPath="/data/app/com.example.app1/lib" flags="..."
        version="12345" userId="10000" installer="com.android.vending">
        <!-- More details about the package -->
        <sigs count="1">
            <cert index="..." />
        </sigs>
        <perms>
            <item name="android.permission.CAMERA" granted="true" flags="0" />
            <item name="android.permission.INTERNET" granted="true" flags="0" />
            <!-- More permissions -->
        </perms>
        <!-- More details about the package -->
    </package>

    <package name="com.example.app2" codePath="/data/app/com.example.app2" nativeLibraryPath="/data/app/com.example.app2/lib" flags="..."
        version="67890" userId="10001" installer="com.android.vending">
        <!-- More details about the package -->
        <sigs count="1">
            <cert index="..." />
        </sigs>
        <perms>
            <item name="android.permission.CAMERA" granted="true" flags="0" />
            <item name="android.permission.RECORD_AUDIO" granted="false" flags="0" />
            <!-- More permissions -->
        </perms>
        <!-- More details about the package -->
    </package>
</packages>

the content is something like is

as we see every app has its own userid that can access the data belongs to this app only.

2. /etc/permissions/platform.xml:

The platform.xml file is part of the Android operating system’s configuration and is located in the /etc/permissions/ directory. This file defines the system-wide permissions for all applications on the device. It contains a list of permission definitions, each with a unique name and protection level.

As mentioned in the previous response, permissions defined in platform.xml determine how sensitive data or device features can be accessed by different applications. The file plays a crucial role in enforcing security and access controls across the entire Android system.

<?xml version="1.0" encoding="utf-8"?>

<permissions>
    <!-- Define permission groups -->
    <permission-group name="android.permission-group.LOCATION" >
        <item name="android.permission.ACCESS_FINE_LOCATION" />
        <item name="android.permission.ACCESS_COARSE_LOCATION" />
    </permission-group>

    <!-- Define permissions -->
    <permission name="android.permission.ACCESS_FINE_LOCATION" >
        <group gid="android.permission-group.LOCATION" />
        <!-- More details about the permission -->
    </permission>

    <!-- More permission groups and permissions -->
</permissions>

3. Android_filesystem_config.h:

The Android_filesystem_config.h file is a header file in the Android source code. It defines the permissions and attributes for various directories and files in the Android filesystem. Each entry in this file specifies the default permissions (owner, group, others) and the SELinux context for a specific path in the Android filesystem.

When the Android system is built, this file is used to set the appropriate permissions and attributes for different directories and files. It ensures that the correct security context and permissions are applied to system resources during runtime.

note that these files are part of the Android operating system’s internal configuration and are not meant to be directly modified or accessed by regular users “until you root the device” or third-party applications. Making changes to these files without proper understanding or authorization can lead to system instability or security issues. They are primarily used by the Android OS itself to manage app installations, permissions, and filesystem configurations.

but how can APP 1 read data from APP 2?

To enable one app to access data or perform specific actions in another app, you can define a custom permission using the <permission> element in the manifest of the app providing the data or functionality, and then use the <uses-permission> element in the manifest of the app that wants to access that data or functionality.

1. Provider App (Providing Data):

Assume you have an app that provides some sensitive data, and you want to allow other apps to access this data only if they have a specific permission.

 <permission
        android:name="com.example.providerapp.PERMISSION_ACCESS_DATA"
        android:label="Access Provider App Data"
        android:protectionLevel="dangerous" />

2. Client App (Accessing Data):

Assume you have another app that wants to access the data provided by the first app. This app needs to request and be granted the custom permission defined in the provider app’s manifest.

 <!-- Request permission to access data from the Provider App -->
    <uses-permission android:name="com.example.providerapp.PERMISSION_ACCESS_DATA" />

The Provider App defines a custom permission named PERMISSION_ACCESS_DATA using the <permission> element. The permission has a protection level of "dangerous", which requires explicit user consent.

The Client App wants to access data from the Provider App. It requests the PERMISSION_ACCESS_DATA permission using the <uses-permission> element.

When the client app is installed, it will need to explicitly request the PERMISSION_ACCESS_DATA permission from the user. If the user grants the permission, the client app can then access the data or perform the allowed actions provided by the provider app.

last ting we will talk about today is Activities which is the first component.

Activities

The speaker explains that there are four key components in an Android application, and half of the vulnerabilities are related to network traffic (e.g., HTTPS) while the other half involves the four components (Activities, Services, Broadcast Receivers, Content Providers)

An activity represents a single user interface screen. It’s the primary way that users interact with your app. Each screen or “activity” in your app is typically represented by a separate activity component. Activities can be used to display information, gather user input, and respond to user interactions. They’re the basic building blocks of the user interface.

ok but now lets say i have an application that includes a QR code scanner and i want to access this activity but not the app itself or even how can the OS access an activity??

let's go back to androidmanifest.xml we ignored something i left with a rectangle around.

so what is exported and intent-filter??

An “exported” activity in Android refers to an activity component that can be accessed and launched by other apps or components outside of its own app. When an activity is marked as “exported,” it means that other apps can potentially interact with it, start it, and communicate with it.

that's mean if the QR code scanner activity is exported i can start it and scan the code without opening the application.

we have to types of exporting an activity explicit and implicit.

1. To determine if an activity is exported in an Android application, you can look at the Android manifest XML file, specifically at the activity’s declaration. Within the `<activity>` element, there is an attribute called `android:exported`. This attribute indicates whether the activity is accessible to other applications or components outside of the app. explicit

For example:

<activity
android:name=".MainActivity"
android:exported="true">
<! - Other activity attributes and elements go here →
</activity>

In the above example, the `MainActivity` activity is exported (`android:exported=”true”`), meaning it can be launched by other applications. If `android:exported` is set to `”false”`, the activity is not exported and can only be launched within the app.

2. Regarding `<intent-filter>`, it is used within the `<activity>` element to specify which types of intents the activity can respond to. Intents are messages that allow components to request actions from other components or apps. implicit

For example:

<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>

In this example, the `MainActivity` is defined as the main launcher activity (`android.intent.action.MAIN` and `android.intent.category.LAUNCHER`), which means it will be the entry point of the application when the user opens it from the app launcher.

By checking both the `android:exported` attribute and `<intent-filter>` of an activity in the Android manifest, you can identify if the activity is exported and understand its launch behavior in the application.

note that :

last thing for today let’s take this scenario.

we have an application that has a welcome screen and you have to enter the password to access the profile or the stored data on the application and so on but we have an exported activity which is QR code scanner, what if instead of scanning a code we click on back button does that mean we can bypass the password on the first activity?

I think this blog includes too much information so next time we will see a demo that brings together all the concepts we talked about. This will help us better understand and visualize the process.

if u have a question just text me on @ahmedMhesham12 on X

Best Regards.