App metadata contains everything an attacker needs to understand how an iOS app behaves before even touching the binary. Metadata is stored in the application bundle and includes Info.plist, entitlements, provisioning profiles, ATS rules, URL schemes, permissions and capabilities. This chapter provides a full practical workflow for extracting, analyzing and interpreting every metadata component inside an IPA or installed application.
Step 1: Accessing App Metadata
Metadata is found inside:
Payload/AppName.app/
If you already extracted the IPA:
cd extracted/Payload/AppName.app/
If you are inspecting a jailbroken device:
ssh root@localhost -p 2222
cd /var/containers/Bundle/Application/<UUID>/AppName.app/
All metadata files will be available here.
Step 2: Converting Info.plist to Readable Format
Info.plist is the core metadata file. It contains:
-
App permissions
-
ATS rules
-
URL schemes
-
Background modes
-
Bundle identifiers
-
Privacy usage descriptions
-
UI behavior
-
Supported device capabilities
Convert it to XML:
plutil -convert xml1 Info.plist
Open it:
cat Info.plist
Step 3: Analyze App Transport Security (ATS)
ATS defines whether the app forces HTTPS, allows insecure HTTP or uses exceptions.
Search for ATS keys:
grep -i "AppTransportSecurity" -n Info.plist
Look for:
-
NSAllowsArbitraryLoads
-
NSExceptionDomains
-
Allowing HTTP endpoints
Example insecure config:
<key>NSAllowsArbitraryLoads</key><true/>
This allows plaintext traffic and is a major finding.
Step 4: Enumerating URL Schemes
URL schemes are used for app-to-app communication. Misconfigured schemes lead to hijacking attacks.
Extract schemes:
grep -A2 -i CFBundleURLSchemes Info.plist
Look for entries such as:
myapp://
myapp-login://
Testable with:
openURL myapp://
Apps with sensitive URL actions may allow bypassing authentication or triggering unintended functionality.
Step 5: Analyzing Permissions (Privacy Usage Keys)
iOS apps must declare why they need access to sensitive data.
Search for permission usage descriptions:
grep -i "UsageDescription" -n Info.plist
Common keys include:
-
NSCameraUsageDescription
-
NSPhotoLibraryUsageDescription
-
NSLocationWhenInUseUsageDescription
-
NSBluetoothPeripheralUsageDescription
Check for:
-
Missing descriptions
-
Overly broad permissions
-
Permissions not used in the app (security smell)
Step 6: Inspecting Background Modes
Background modes define functions that continue running after the app is closed.
Search:
grep -A5 -i UIBackgroundModes Info.plist
Common risky modes:
-
location
-
voip
-
bluetooth-central
-
audio
Apps using location in background often store location history locally—check later during dynamic analysis.
Step 7: Checking for Universal Links and Deep Links
Look for associated domains:
grep -A4 -i AssociatedDomains Info.plist
Look for:
applinks:example.com
webcredentials:example.com
These allow deep linking and password sharing. Misconfigurations may allow takeover of login flows.
Step 8: Extracting Entitlements (Critical for Security)
Entitlements describe sensitive capabilities granted to the app.
Extract them:
codesign -d --entitlements :- AppName
Look for dangerous capabilities:
-
com.apple.private.*
-
get-task-allow (allows debugging the app)
-
keychain-access-groups
-
application-identifier mismatches
-
push / cloud entitlements
Example dangerous finding:
<key>get-task-allow</key><true/>
This allows process debugging even on release builds.
Step 9: Reviewing the Provisioning Profile
Provisioning profiles reveal signing identities, team IDs, entitlements and device limitations.
Export:
security cms -D -i embedded.mobileprovision > profile.plist
Inspect:
cat profile.plist
Look for:
-
Expired certificates
-
Insecure wildcard app identifiers
-
Custom entitlements
-
Device-specific provisioning weirdness
Common risk:
<key>application-identifier</key><string>*</string>
Wildcard identifiers increase attack surface.
Step 10: Analyzing App Capabilities
Check for sensitive capabilities in Info.plist:
grep -i "UIRequiresFullScreen" Info.plist
grep -i "UIFileSharingEnabled" Info.plist
grep -i "LSSupportsOpeningDocumentsInPlace" Info.plist
The most dangerous is:
<key>UIFileSharingEnabled</key><true/>
This exposes app files via iTunes File Sharing, letting attackers extract sensitive data without jailbreak.
Step 11: Finding Hardcoded Endpoints in Metadata
Search for URLs inside metadata:
grep -R "http" -n .
Look inside:
-
Config files
-
JSON files
-
Internal settings bundles
Common findings:
-
Internal API endpoints
-
Staging servers
-
Dev/QA URLs left in production app
These reveal backend attack surface.
Step 12: Automating Metadata Enumeration
Basic metadata dump using built-in tools:
plutil -p Info.plist
Dump everything into one file:
plutil -convert xml1 Info.plist -o full_metadata.xml
You can also automate with a script:
grep -RiE "http|UsageDescription|ATS|URLSchemes|Entitlement" .
Step 13: Mapping Findings to Attack Vectors
Metadata analysis is not just reading files. Every key leads to a pentesting direction:
-
ATS exceptions → MITM → API tampering
-
URL schemes → URL hijacking → token theft
-
Permissions → privacy abuse → data leakage
-
Entitlements → privilege escalation → debug abuse
-
Background modes → data logging → location exposure
-
Associated domains → deep link takeover
-
Provisioning profile → insecure signing → potential repack attack
Metadata forms the blueprint of the entire attack surface.
Intel Dump
-
Info.plist reveals ATS, permissions, URL schemes and background modes
-
Entitlements show capabilities like debugging, keychain groups and private APIs
-
Provisioning profiles expose signing info and entitlements
-
ATS exceptions, arbitrary loads and insecure domains indicate MITM potential
-
URL schemes may allow hijacking or direct action execution
-
Hardcoded endpoints expose backend attack surfaces
-
Metadata analysis guides static, dynamic and reverse engineering workflows