SDK Analysis: Third-Party Library Security

This skill defines techniques for identifying, fingerprinting, and assessing third-party SDKs embedded in mobile applications. It is used by hunter agents when analyzing frameworks (iOS) and library dependencies (Android).

Why SDKs Matter

Third-party SDKs are high-value targets because:

1. Developers trust them blindly: SDK code runs with the app's full permissions
2. Updates lag: apps often ship with outdated SDK versions containing known CVEs
3. Debug features leak: SDKs may include debug capabilities left enabled in production
4. Configuration errors: SDK misconfiguration (open Firebase, debug keys) is common
5. Supply chain risk: a vulnerable SDK affects every app that embeds it

SDK Identification

iOS: Framework Detection

Embedded frameworks live in AppName.app/Frameworks/:

# List all embedded frameworks
ls Payload/AppName.app/Frameworks/

# Use framework_scanner.py for automated detection
python3 tools/analysis/ios/framework_scanner.py --app <app_bundle>

Detection methods:

• Framework bundle name matching against wordlists/sdk_signatures.txt
• Info.plist inside framework bundles (CFBundleIdentifier, CFBundleShortVersionString)
• Binary strings containing SDK identifiers
• Mach-O load commands (otool -L) showing linked frameworks

Android: Package Detection

SDK code appears in the decompiled source tree:

# Use sdk_fingerprinter.py for automated detection
python3 tools/analysis/shared/sdk_fingerprinter.py --source <jadx_output>

# Manual: check package directories
ls jadx/sources/com/google/firebase/
ls jadx/sources/com/facebook/
ls jadx/sources/io/sentry/

Detection methods:

• Package name matching against wordlists/sdk_signatures.txt
• build.gradle or pom.xml fragments in decompiled sources
• String patterns: "Firebase/, "fb_sdk_version", "sentry-"
• Native .so library names (libfb*.so, libhermes.so)

Version Extraction

Accurate version identification is critical; a finding without a confirmed version is unverifiable.

iOS Version Sources

Android Version Sources

Extraction Example

# iOS: Firebase version from framework Info.plist
plutil -p Payload/App.app/Frameworks/FirebaseCore.framework/Info.plist | grep CFBundleShortVersionString

# Android: Firebase version from BuildConfig
grep -r "VERSION_NAME\|SDK_VERSION" jadx/sources/com/google/firebase/

Vulnerability Assessment

Step 1: Match SDK + Version Against CVE Database

For each identified SDK with a confirmed version:

1. Search NVD/MITRE for CVEs: <sdk_name> <version>
2. Check the SDK's GitHub/changelog for security advisories
3. Verify the CVE applies to the mobile platform (some CVEs are server-only)
4. Confirm the vulnerable code path is reachable in this app's integration

Step 2: Assess Reachability

A CVE in an embedded SDK is only a finding if:

• The app uses the vulnerable feature/API of the SDK
• The vulnerable code path is reachable from user-controlled input
• The SDK version is confirmed (not just estimated)

Example, Firebase Realtime Database:

• CVE exists for unauthenticated read access
• App embeds Firebase SDK v9.x (vulnerable version)
• App uses Realtime Database (confirmed by FirebaseDatabase framework presence)
• Authorization check, before any request leaves the machine: the Firebase project is third-party hosted infrastructure owned by the program, so probe it only if that project is a listed in-scope asset and the program has given written permission to test it
• Permitted test: curl https://<project-id>.firebaseio.com/.json
• If data returns → FINDING (HIGH)
• If 401/permission denied → the SDK is vulnerable but Firebase rules prevent exploitation → NOT A FINDING for this app
• If the authorization check fails → report the reachable configuration from static evidence and ask the program to run the check themselves; do not probe

High-Risk SDKs

Debug/Development SDKs in Production

These should NEVER appear in App Store / Play Store builds:

Finding: Debug SDK in production is standalone reportable (MEDIUM-HIGH). The SDK itself provides an attacker with inspection capabilities.

SDKs with Known Vulnerability History

Cross-Platform Frameworks

Apps built with React Native, Flutter, or Cordova have unique attack surfaces:

React Native:

• JS bundle at assets/index.android.bundle (Android) or Payload/<App>.app/main.jsbundle (iOS)
• Bundle may contain hardcoded secrets, API endpoints, business logic
• Detect Hermes bytecode by magic bytes c6 1f bc 03 at offset 0 (vs. plain JS text)
• For string extraction on HBC v96+ (RN 0.74+) use the in-house tools/analysis/shared/hermes_extractor.py; it parses the string table directly and emits one clean string per entry. hbctool does not support v96, and strings(1) concatenates adjacent entries because Hermes packs all strings into a single storage blob.
• For full bytecode decompilation (control flow, function bodies), hermes-dec is still the right tool when available; the in-house extractor covers the string-level recon surface.
• Pipe extractor output into secret_scanner.py and api_endpoint_extractor.py for automated triage.
• Check for __DEV__ flag left enabled in production

Flutter:

• Dart code compiled to native, which is harder to reverse
• libflutter.so (Android) or Flutter.framework (iOS) contains engine
• libapp.so (Android) or App.framework (iOS) contains app code
• Snapshot-based analysis tools exist but are version-dependent

Cordova / Capacitor:

• Web assets in assets/www/ (Android) or the app bundle (iOS)
• Full HTML/JS/CSS source is readable
• Plugin bridge exposes native capabilities to JavaScript
• Check for debug plugins, sensitive data in JS, insecure plugin configurations

SDK Configuration Analysis

Authorization Boundary for Configuration Testing

Every command in this section sends a request to a live service using a credential extracted from the app. Extracting the credential is static analysis of a binary you hold; using it is testing. Before running any of them, both of these must be true:

1. In stated scope. The asset being reached (Firebase project, storage bucket, API key, backend endpoint) is covered by the program's stated scope, not merely referenced by an in-scope app.
2. Written permission for third-party hosted services. When the service is operated by a third party (Google, Firebase, AWS, and similar), the program has authorized this testing in writing. The program owns that account and its provider agreement; a request you send consumes and can alter an account you do not own, and the provider never agreed to your test.

If either is false, stop at static evidence. A hardcoded-secret finding is still reportable without a live probe: state where the credential was found, which service and key type it is, what the provider documents that key type as granting, and ask the program to verify server side. That is a complete finding, and it is the only correct output when authorization is absent.

The rest of this section assumes both conditions hold.

Firebase

# Static, always allowed: locate the config in the extracted app
find <app_dir> -name "GoogleService-Info.plist" -o -name "google-services.json"

# Live, requires in-scope asset + written permission (see above)
# Extract project ID and API key, then test for open Firestore/Realtime Database
curl "https://<project-id>.firebaseio.com/.json"
curl "https://firestore.googleapis.com/v1/projects/<project-id>/databases/(default)/documents/<collection>"

# Test for open Storage bucket
curl "https://firebasestorage.googleapis.com/v0/b/<project-id>.appspot.com/o"

Google Maps / Places API

# Live, requires in-scope asset + written permission: the request bills the program's Google account
curl "https://maps.googleapis.com/maps/api/geocode/json?address=test&key=<API_KEY>"

# Unrestricted key → FINDING if it can access paid APIs
# Restricted to Maps only → informational

Use a single request per check. Repeated or scripted calls against a third-party account are billable traffic on someone else's bill and read as abuse regardless of intent.

Output Format

SDK analysis findings follow the standard finding JSON with additional SDK-specific fields:

{
  "id": "ios_sdk_vuln_001",
  "platform": "ios",
  "vuln_class": "XP-04",
  "title": "Debug Framework (FLEX) in Production Build",
  "severity_estimate": "medium",
  "confidence": "HIGH",
  "affected_component": "FLEX.framework v5.22.1",
  "evidence": {
    "sdk_name": "FLEX",
    "sdk_version": "5.22.1",
    "detection_method": "Framework bundle in Payload/App.app/Frameworks/",
    "description": "FLEX debugging framework is embedded in the production App Store build, providing any user with runtime inspection capabilities including network traffic, view hierarchy, keychain contents, and UserDefaults."
  },
  "exploitation": {
    "attack_scenario": "User launches FLEX via shake gesture or programmatic trigger. FLEX displays all network requests, stored keychain items, and UserDefaults entries.",
    "prerequisites": "Physical access to device with app installed (or screenshots from debug menu)",
    "test_command": "Launch app, shake device or trigger FLEX programmatically"
  },
  "potential_impact": "Exposes internal API endpoints, authentication tokens, keychain credentials, and app configuration to any user",
  "cvss_estimate": "5.5",
  "chain_potential": [],
  "remediation": "Remove FLEX.framework from the production build configuration. Ensure FLEX is only included in Debug build schemes, not Release."
}

Analysis Workflow

1. Identify: Run framework_scanner.py (iOS) and sdk_fingerprinter.py (both) to catalog all SDKs
2. Version: Extract exact version for each SDK using the methods above
3. Debug check: Flag any debug/development SDKs in production builds immediately
4. CVE check: For each SDK + version pair, search for applicable CVEs
5. Config check: For Firebase, Google APIs, and other configurable SDKs, look for misconfigurations. Clear the authorization boundary above before sending any request to a live service; without it, this step is static only.
6. Reachability: For CVE matches, verify the vulnerable code path is actually used by the app
7. Document: Record findings with SDK name, version, detection method, and evidence

Time budget: 5 minutes per SDK. If version extraction or CVE matching takes longer, note it as "needs further investigation" and move on.