Field Guide to the Android Manifest File

Black Hills Information Security, Inc.

Bad Habits: An ANTISOC Operation Same Problem, Different Angles: When Red Team and Blue Team Actually Talk to Each Other How to Identify and Exploit New Vulnerabilities Swapper – A Pure Regex Match/Replace Burp Extension A Practical Guide to BloodHound Data Collection Network Engineering Basics Signed, Trusted, and Abused: Proxy Execution via WebView2 Getting Started In Pentesting – Advice From The BHIS Pentest Lead Cloud Security: Tips and Resources for Securing the Cloud Lessons From A Chatbot Incident How to Lead Effective Tabletops Understanding GRC: How to Navigate Risks and Compliance Standards The “P” in PAM is for Persistence: Linux Persistence Technique Malware Analysis: How to Analyze and Understand Malware OSINT: How to Find, Use, and Control Open-Source Intelligence What to Do with Your First Home Lab When the SOC Goes to Deadwood: A Night to Remember Social Engineering and Microsoft SSPR: The Road to Pwnage is Paved with Good Intentions Common Cyber Threats Finding the Right Penetration Testing Company Deceptive-Auditing: An Active Directory Honeypots Tool The Curious Case of the Comburglar How to Set Smart Goals (That Actually Work For You) Inside the BHIS SOC: A Conversation with Hayden Covington Abusing Delegation with Impacket (Part 3): Resource-Based Constrained Delegation Why You Got Hacked – 2025 Super Edition Abusing Delegation with Impacket (Part 2): Constrained Delegation Abusing Delegation with Impacket (Part 1): Unconstrained Delegation GoSpoof – Turning Attacks into Intel Model Context Protocol (MCP) Bypassing WAFs Using Oversized Requests Getting Started with AI Hacking Part 2: Prompt Injection Wrangling Windows Event Logs with Hayabusa & SOF-ELK (Part 2) DomCat: A Domain Categorization Tool Wrangling Windows Event Logs with Hayabusa & SOF-ELK (Part 1) Microsoft Store and WinGet: Security Risks for Corporate Environments Default Web Content MailFail Commonly Abused Administrative Utilities: A Hidden Risk to Enterprise Security Stop Spoofing Yourself! Disabling M365 Direct Send Bypassing CSP with JSONP: Introducing JSONPeek and CSP B Gone Offensive Tooling Cheatsheets: An Infosec Survival Guide Resource DNS Triage Cheatsheet GraphRunner Cheatsheet Burp Suite Cheatsheet Impacket Cheatsheet Wireshark Cheatsheet Hashcat Cheatsheet EyeWitness Cheatsheet Nmap Cheatsheet Netcat (nc) Cheatsheet Hunt for Weak Spots in Your Wireless Network with Airodump-ng from the Aircrack-ng Suite Detecting ADCS Privilege Escalation Vulnerability Scanning with Nmap Getting Started with NetExec: Streamlining Network Discovery and Access How to Use Dirsearch Augmenting Penetration Testing Methodology with Artificial Intelligence – Part 3: Arcanum Cyber Security Bot How to Design and Execute Effective Social Engineering Attacks by Phone Abusing S4U2Self for Active Directory Pivoting Why Use a Macro Pad? Espanso: Text Replacement, the Easy Way Caging Copilot: Lessons Learned in LLM Security Augmenting Penetration Testing Methodology with Artificial Intelligence – Part 2: Copilot Augmenting Penetration Testing Methodology with Artificial Intelligence – Part 1: Burpference Intercepting Traffic for Mobile Applications that Bypass the System Proxy How to Root Android Phones Communicating Security to the C-Suite: A Strategic Approach Offline Memory Forensics With Volatility Getting Started with AI Hacking: Part 1 Go-Spoof: A Tool for Cyber Deception How to Test Adversary-in-the-Middle Without Hacking Tools Canary in the Code: Alert()-ing on XSS Exploits How to Hack Wi-Fi with No Wi-Fi Why Your Org Needs a Penetration Test Program Burp Suite Extension: Copy For Light at the End of the Dark Web Wi-Fi Forge: Practice Wi-Fi Security Without Hardware Avoiding Dirty RAGs: Retrieval-Augmented Generation with Ollama and LangChain Gone Phishing: Installing GoPhish and Creating a Campaign 5 Things We Are Going to Continue to Ignore in 2025 John Strand’s 5 Phase Plan For Starting in Computer Security Questions From a Beginner Threat Hunter GRC for Security Managers: From Checklists to Influence AI Large Language Models and Supervised Fine Tuning Attack Tactics 9: Shadow Creds for PrivEsc w/ Kent & Jordan One Active Directory Account Can Be Your Best Early Warning Introduction to Zeek Log Analysis Indecent Exposure: Your Secrets are Showing Creating Burp Extensions: A Beginner’s Guide Pitting AI Against AI: Using PyRIT to Assess Large Language Models (LLMs) The Top Ten List of Why You Got Hacked This Year (2023/2024) ICS Hard Knocks: Mitigations to Scenarios Found in ICS/OT Backdoors & Breaches Intro to Data Analytics Using SQL Finding Access Control Vulnerabilities with Autorize The Detection Engineering Process Cyber Risk Lessons We Can Learn From Hurricane Preparedness Intro to Desktop Application Testing Methodology What Is Penetration Testing? Adversary in the Middle (AitM): Post-Exploitation Pentesting, Threat Hunting, and SOC: An Overview

BHIS · 2023-04-07 · via Black Hills Information Security, Inc.

Cameron Cartier //

Every Android application has a “manifest.xml” file located in the root directory of the APK. (Remember APKs are just zip files.) The manifest file is like a guide to the application. It describes all of the components of the app, the application permissions, and the required hardware/software features. Developer misconfigurations to this file — for example, marking an activity as exported — can have serious effects on the application’s security. Many static analysis tools (i.e., MobSF) get a lot of their information by simply parsing this file.

In this blog, we are going to walk through a sample of the fun things you can learn from an apps manifest file as a hacker. We will be using the monolithic social media app “TikTok” for this analysis.

Now, lets have some fun.

The manifest file is in “binary xml” format. This means that if you unzip the APK file, you will see that manifest.xml is mostly undecipherable.

To fix this, we decompile the app with Apktool instead.

Apktool Command: apktool d app.apk

This may take a few minutes since we are using a large app. Now opening the manifest file in a text editor shows us the human-readable version (depending on your definition of human-readable that is).

The first thing worth noting is the package name.

package="com.zhiliaoapp.musically"

This is what is used by the operating system to identify your app. It also tells you the app’s internal storage location. Apps store their data (cache, databases, etc.) at /data/data/<PackageName>. You can also determine if the app shares a sandbox with any other applications. If the app does share a user ID, it will have the entry android:SharedUserId=<Some UID>. For example, many system applications will share android.uid.system (IID 1000). This allows them to share data and operate with higher permissions than user-installed apps.

In older applications, the manifest file will include the minimum and maximum Android SDK versions. As of Android 11, this is no longer allowed, and these must be declared in the Gradle files instead.

There are also a set of flags that allow/disallow actions on the application. Here are two you should pay attention to as a tester, as they can be dangerous:

Android:Allowbackup = "true" This allows anyone with access to the device to make a copy of all of the application’s data. An example of when this could be dangerous is if an adversary with device access is able to download un unencrypted database.
Android:Debuggable = "true" Apps should never be released with the debuggable flag set to true. This can lead to sensitive information exposure. It can also allow an attacker with device access to run arbitrary code using the applications permissions.

Permissions

The manifest file is also required to specify which components of the device the app can interface with. The user decides whether to grant the application these permissions at runtime. An application cannot access any external features of the device unless it is explicitly declared with a <uses-permission> tag. Knowing what permissions an app is likely to have access to can be useful to an attacker when paired with another vulnerability that allows for code execution under the app’s user. As a security tester, you want to call out any permissions that seem unnecessary. Which permissions are necessary depends on the specific application.

Here is a small subset of the permissions requested by the TikTok app:

    <uses-permission
android:name="android.permission.SYSTEM_ALERT_WINDOW"/>
    <uses-permission android:name="android.permission.REORDER_TASKS"/>
    <uses-permission android:name="android.permission.INTERNET"/>
    <uses-permission
android:name="android.permission.ACCESS_NETWORK_STATE"/>
    <uses-permission
android:name="android.permission.READ_EXTERNAL_STORAGE"/>
    <uses-permission
android:name="android.permission.WRITE_EXTERNAL_STORAGE"/>
    <uses-permission android:name="android.permission.ACCESS_WIFI_STATE"/>
    <uses-permission android:name="android.permission.CAMERA"/>
    <uses-permission android:name="android.permission.RECORD_AUDIO"/>
    <uses-permission android:name="android.permission.FLASHLIGHT"/>
    <uses-permission android:name="android.permission.WAKE_LOCK"/>
    <uses-permission android:name="android.permission.GET_TASKS"/>
    <uses-permission android:name="android.permission.READ_CONTACTS"/>
    <uses-permission
android:name="android.permission.RECEIVE_BOOT_COMPLETED"/>
    <uses-permission android:name="android.permission.VIBRATE"/>
    <uses-permission android:maxSdkVersion="30"
android:name="android.permission.BLUETOOTH"/>
    <uses-permission android:name="com.meizu.c2dm.permission.RECEIVE"/>
    <uses-permission
android:name="com.zhiliaoapp.musically.permission.READ_ACCOUNT"/>

In addition to permissions, there is also the <uses-feature> tags. Each of these declares a hardware or software feature the application requires to function properly. The requires="true" means the app will not be able to run in an environment without that feature present (i.e., bluetooth capability). The Google Play Store may filter out applications requiring features the user’s phone does not have.

Application Components

An application is required to have a manifest entry for each of its components. These include activities, services, content providers, and broadcast receivers. Similar to public/private classes in object-oriented languages, each individual instance of one of these can be exported or not exported. If the exported flag is set, it can be accessed from other apps as well.

First, let’s talk about activities. Each activity will be declared with an <activity> tag in the manifest file.

Activities are activated by “intents” (as are services and broadcast receivers). The intent is passed to the system, and the system determines which component of the app can handle the intent using the intent filters. These filters are declared in the manifest with “intent-filters.”

By declaring intent filter(s) for an activity, you make it possible for other apps (or the system) to launch your application.

Every app will have an activity with an intent-filter block that looks very similar to the following code block:

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

This indicates the entry point of the application. The line android.intent.category.LAUNCHER says to the app, “When the user clicks the icon for this app, launch this activity.” Figuring out where the app starts is a good first step in reverse engineering.

Above shows the entry point for the TikTok app.

Another thing you would want to look for as a tester is exported activities. An activity is exported if either they have the android:exported attribute set to “True”, OR they have an <intent-filters> block and the exported attribute is unset.

Services differ from activities in that they do not have a UI component and are often used to run background tasks. Otherwise, all the rules above still apply.

Looking at the intent filters can also give us clues as to the function of an component. Take this service from the TikTok app for example:

<service android:exported="true"
    android:name="com.heytap.msp.push.service.DataMessageCallbackService"
    android:permission="com.heytap.mcs.permission.SEND_PUSH_MESSAGE">
    <intent-filter>
       <action android:name="com.heytap.mcs.action.RECEIVE_MCS_MESSAGE"/>
       <action android:name="com.heytap.msp.push.RECEIVE_MCS_MESSAGE"/>
    </intent-filter>
</service>

From just the manifest entry and some quick Google searches, without looking at the source code, we can tell that this service is responsible for handline Android push notifications.

Further Research

If you really want to take a deep dive into how the android manifest works, the Android Developers Reference is a great place to start: https://developer.android.com/guide/topics/manifest/manifest-element

Ready to learn more?

Level up your skills with affordable classes from Antisyphon!

Pay-What-You-Can Training

Available live/virtual and on-demand

此内容由惯性聚合(RSS阅读器)自动聚合整理，仅供阅读参考。原文来自 — 版权归原作者所有。

推荐订阅源

Black Hills Information Security, Inc.

Permissions

Application Components

Further Research