MobSF
APK/IPA analysis via REST API (requires Docker). Part of AuditCore's automated security audit pipeline — runs on every scan in the Enterprise tier and above, with findings normalized into a single severity-rated table.
What is MobSF?
MobSF (Mobile Security Framework) is the OWASP-backed Swiss Army knife for mobile app analysis. Upload an APK (Android) or IPA (iOS) and it produces a comprehensive report covering manifest analysis, certificate validation, embedded secrets, hardcoded URLs, dangerous permissions, code-level patterns (insecure crypto, debug logs, exec calls), and SSL pinning checks — all in a single static analysis pass.
AuditCore runs MobSF in a Docker container alongside our Python-based mobile analyzers (APK Manifest Analyzer, APK Permissions Auditor, etc.). The two-track approach means: MobSF gives you the comprehensive 'Industry-standard mobile audit' report (useful for security reviews, compliance), and our custom Python analyzers provide focused, fast checks that get deduplicated into the unified AuditCore vulnerability table. You can read the full MobSF report or just trust the AuditCore-curated findings.
MobSF's secret sauce is its accumulated knowledge of mobile-specific patterns: detecting common mobile SDKs (Firebase, Crashlytics, Facebook SDK, Google Mobile Ads), flagging exported activities/services/receivers in AndroidManifest.xml, parsing Info.plist for iOS-specific issues, decompiling smali to look for hardcoded encryption keys. It's been maintained since 2015 with hundreds of contributors — depth that would take years to replicate.
Limitations: MobSF requires you to provide the APK/IPA file. We don't reverse-engineer apps from app stores (that's borderline legal in most jurisdictions). It's also static-only — runtime behavior, dynamic analysis (Frida instrumentation), and network traffic inspection require a separate tool (MobSF has dynamic analysis but it requires a connected device/emulator which our cloud setup doesn't provide). For full mobile pentest, combine MobSF static + manual Frida + network traffic inspection.
What it tests
- AndroidManifest.xml: debuggable, allowBackup, exported components, intent filters, min SDK
- iOS Info.plist: ATS configuration, bundle settings, URL schemes
- Embedded secrets: API keys, tokens, hardcoded credentials in strings.xml / source
- Hardcoded URLs (HTTP vs HTTPS, dev/staging URLs left in production)
- Dangerous permissions usage and risky combinations
- Insecure crypto patterns (ECB mode, hardcoded IVs, MD5 for passwords)
- WebView misconfigurations (JavaScript bridge exposing native code)
- Certificate pinning detection
- SSL/TLS configuration (network_security_config.xml)
- Exported components without proper permissions
- Tracker SDK detection (analytics, ads, crash reporters)
- Code-level dangerous patterns: `Runtime.exec()`, `DexClassLoader`, `ContentResolver` flaws
Where it runs in the AuditCore pipeline
Phase 5/5 · Static / Code & Mobile
Source-code, dependency and mobile-binary analysis — Semgrep rules, gitleaks secrets, Trivy CVEs, APK / IPA manifest, permissions, strings, network and native-binary hardening.
Source: scanners/mobsf_scanner.py
Sample findings
App debuggable=true in production manifest
Critical. `android:debuggable="true"` allows attackers with USB access (or root) to attach a debugger and dump memory, hook methods, modify behavior. Should NEVER be true in production builds. Mitigation: ensure Gradle's release variant disables debuggable; check your CI build doesn't accidentally ship debug-flavored APKs.
Hardcoded Firebase API key in strings.xml
Medium. `<string name="google_api_key">AIza...</string>` is in the APK. Firebase API keys aren't strictly secrets (they identify the project, not authenticate it), but combined with weak Firebase Security Rules, they enable unauthorized read/write to your Firestore/Realtime DB. Mitigation: tighten Firebase Security Rules so the API key alone can't read sensitive data. Restrict the API key in Google Cloud Console to your bundle ID.
WebView JavaScript bridge exposed to all origins
Critical. `webView.addJavascriptInterface(jsBridge, "AndroidBridge")` plus `webView.getSettings().setAllowFileAccessFromFileURLs(true)` exposes Android methods to any HTML loaded in the WebView. If the WebView ever loads attacker-controlled content (deep links, redirects, MITM on HTTP), attackers can call native methods. Mitigation: restrict WebView to HTTPS-only allow-list; remove `addJavascriptInterface` if not strictly needed; for Android 17+, annotate exposed methods with `@JavascriptInterface`.
App allows cleartext HTTP traffic
High. `android:usesCleartextTraffic="true"` (or missing network_security_config.xml restricting it) means the app will send data over HTTP, allowing trivial MITM on hostile networks. Mitigation: set `usesCleartextTraffic="false"` in manifest; if you need HTTP for specific dev endpoints, use network_security_config.xml to allow-list specific domains.
Other static / code & mobile scanners
FAQ
Why does AuditCore run MobSF AND our own Python APK analyzers?
Different tradeoffs. MobSF gives you a comprehensive industry-standard report (~50+ pages of findings, useful for security audits and compliance evidence). Our Python analyzers are faster and produce cleaner findings normalized into AuditCore's unified vulnerability model — you see them next to your web app findings, with consistent severity scoring. Run both, use whichever output suits your audience.
Can MobSF analyze apps I don't have the source for?
Yes. MobSF takes the compiled APK/IPA file and reverse-engineers it (decompiles smali → Java for Android, IPA → ARM disassembly for iOS). It can't recover original variable names or comments, but it identifies dangerous patterns just fine. Caveat: heavily obfuscated apps (R8/ProGuard with aggressive renaming) reduce MobSF's effectiveness — the static analyzer can't reason about `a.b.c.d()` calls as easily as `paymentService.processPayment()`.
Does MobSF work on iOS apps without a Mac?
Yes for static analysis. AuditCore runs MobSF in Linux Docker — IPA static analysis works fully (parses Info.plist, decrypts binaries with theos/dsdump-like tools, extracts strings, checks signatures). iOS dynamic analysis (Frida runtime instrumentation) requires a physical jailbroken device, which AuditCore doesn't provide.
How long does MobSF analysis take?
5-15 minutes for typical APKs (50-200MB). Larger APKs (>500MB) can take 30+ minutes due to decompilation cost. AuditCore times out at 30 minutes; if your APK is genuinely too large, contact us for an Enterprise option.
What APK / IPA size limits does AuditCore accept?
500MB upload limit. Most production mobile apps are 30-150MB; the 500MB limit covers ~95% of real-world apps. Games and apps with embedded ML models can hit the limit; contact us for larger uploads.