Introduction: The Android Manifest as a Blueprint

The AndroidManifest.xml file is the foundational blueprint of any Android application. It declares the app’s essential characteristics, its components (activities, services, broadcast receivers, content providers), the permissions it requires, and the hardware features it utilizes. For a reverse engineer or security analyst, this file is an invaluable resource, often revealing critical information about an app’s functionality, potential vulnerabilities, and desired interactions with the operating system and other applications. Understanding how to effectively reverse engineer and analyze the manifest is a cornerstone of Android application security assessment.

Why Manifest Analysis is Crucial

Beyond simply stating what an app does, the manifest often exposes what an app can do or what it expects to receive. Malicious applications might declare broad permissions or export components in ways that can be exploited. Legitimate applications might inadvertently expose sensitive functionality. A thorough manifest analysis can uncover:

• Unusual or excessive permissions.
• Exported components vulnerable to inter-component communication (ICC) attacks.
• Custom permissions defined by the app.
• Deep links or custom URL schemes.
• Application-specific features and requirements.

Tools of the Trade: Decompiling the Manifest

To access and analyze the manifest, we first need to extract it from the APK. The primary tool for this is apktool, which can decompile an APK into a more human-readable format, including the manifest in XML.

Step 1: Obtain the APK

For this lab, let’s assume you have an APK file named target_app.apk. You might acquire this from a device, an app store, or a public repository.

Step 2: Decompile the APK with Apktool

Open your terminal and execute the following command:

apktool d target_app.apk -o target_app_re

This command decompiles target_app.apk and places all extracted files, including the AndroidManifest.xml, into a new directory named target_app_re.

Step 3: Locate the Manifest File

Navigate into the newly created directory. You will find the manifest file at the root:

cd target_app_re
ls
# You should see AndroidManifest.xml along with smali, res, etc.

Dissecting Permissions: What an App Wants

Permissions are a critical security boundary in Android. The manifest declares both system-defined permissions an app requests (`uses-permission`) and custom permissions an app might define (`permission`).

Understanding <uses-permission>

These tags specify permissions the app needs from the system or other apps. Pay close attention to ‘dangerous’ permissions (e.g., READ_SMS, CALL_PHONE, ACCESS_FINE_LOCATION, READ_CONTACTS). Excessive or irrelevant dangerous permissions are a red flag.

Example Snippet:

<uses-permission android:name="android.permission.INTERNET" />
<uses-permission android:name="android.permission.ACCESS_FINE_LOCATION" />
<uses-permission android:name="android.permission.READ_CONTACTS" />

Lab Exercise: Searching for Dangerous Permissions

Use grep to quickly find potentially dangerous permissions. A common list of dangerous permissions can be found in Android’s documentation.

grep -E "ACCESS_FINE_LOCATION|SEND_SMS|READ_CALL_LOG|RECORD_AUDIO|CAMERA" AndroidManifest.xml

Understanding Custom <permission>

Apps can define their own permissions using the <permission> tag. These are often used to protect their own components or resources. The android:protectionLevel attribute is key here:

• normal: Default, low risk, granted automatically.
• dangerous: High risk, requires user consent.
• signature: Only granted if requesting app is signed with the same certificate.
• signatureOrSystem: Granted if same signature or if system app.

Custom permissions with normal or dangerous protection levels, especially if used to protect exported components, can be a vector for privilege escalation if not properly implemented.

Example Snippet:

<permission android:name="com.example.MY_CUSTOM_PERMISSION" android:protectionLevel="signature" />

Exploring Intent Filters: How Apps Interact

Intent filters are crucial for enabling inter-component communication (ICC) and defining how an app’s components respond to external requests. An <intent-filter> specifies the types of intents an activity, service, or broadcast receiver can handle.

Key Attributes within <intent-filter>

• <action>: The general action to be performed (e.g., android.intent.action.MAIN, android.intent.action.VIEW).
• <category>: Provides additional context to the action (e.g., android.intent.category.LAUNCHER, android.intent.category.BROWSABLE, android.intent.category.DEFAULT).
• <data>: Specifies the data URI scheme, host, port, path, or MIME type that the component can handle.

Analyzing Exported Components

Components can be explicitly or implicitly exported. If an activity, service, or receiver contains an <intent-filter> and does not explicitly set android:exported="false", it is implicitly exported. This means other applications can invoke it.

Example of an Exported Activity:

<activity android:name=".ExportedActivity">
    <intent-filter>
        <action android:name="android.intent.action.VIEW" />
        <category android:name="android.intent.category.DEFAULT" />
        <category android:name="android.intent.category.BROWSABLE" />
        <data android:scheme="myapp" android:host="secret" />
    </intent-filter>
</activity>

In this example, ExportedActivity is exported and can be triggered by a deep link like myapp://secret. This is a common attack surface for URL scheme-based vulnerabilities (e.g., XSS, parameter injection).

Lab Exercise: Identifying Exported Components and Deep Links

Search for components with intent filters that might indicate export or specific handling:

grep -E "<activity|<service|<receiver" AndroidManifest.xml | grep "<intent-filter"
grep -E "<data android:scheme" AndroidManifest.xml

Specifically look for android:exported="true" or components with an <intent-filter> but no explicit android:exported="false". Also, pay attention to the BROWSABLE category, which often implies web-based interaction or deep linking.

Vulnerable Broadcast Receivers

Broadcast receivers with intent filters are also common targets. If an exported receiver handles sensitive actions or data, it might be susceptible to malicious broadcasts from other apps.

Example Snippet:

<receiver android:name=".SensitiveReceiver" android:exported="true">
    <intent-filter>
        <action android:name="com.example.SECRET_ACTION" />
    </intent-filter>
</receiver>

A malicious app could construct an intent with action="com.example.SECRET_ACTION" and send it to trigger SensitiveReceiver.

Conclusion: The Manifest as Your Starting Point

The Android Manifest is far more than just a configuration file; it’s a security-critical document that outlines an app’s capabilities and interactions. By mastering the techniques to decompile and analyze this file, reverse engineers and security analysts gain a significant advantage in understanding an application’s attack surface. Always start your Android security audit by thoroughly reviewing the AndroidManifest.xml to uncover hidden permissions, exposed components, and potential vulnerabilities that might otherwise go unnoticed. This foundational analysis guides deeper dives into the application’s bytecode and runtime behavior.