bounty-program-mobile-android

Bounty Program Mobile Android

This workflow is intentionally Android-specific because the Codex-ready mobile tooling in this repo centers on APKs and rooted-device testing.

Load these references on demand:

• ../../references/bounty-standard.md
• ../../references/codex-ready-building-blocks.md
• ../../references/android-framework-matrix.md
• ../../references/report-checklist.md

Inputs

• APK or installed package name
• Rooted device or emulator access if dynamic testing is expected
• Existing proxy path on port 18088 and any testing account guidance
• Prior traffic captures or Burp project if one exists

Workflow

1. Fingerprint the app stack using android-framework-matrix.md.
2. Start with static surface mapping:
   • manifest, exported components, deeplinks, webviews
   • embedded endpoints, keys, and Firebase configuration
   • storage locations and debug toggles
3. Reuse Codex-ready building blocks when installed:
   • firebase-apk-scanner for Firebase keys, project IDs, storage, and leaked mobile config
   • workers-app-tester to verify the preconfigured proxy/cert path, auto-seed hosts from the APK or merge them from traffic, patch config.yaml, then run rooted-device traffic interception on port 18088, UI driving, and Frida-based checks
   • burpsuite-project-parser when prior traffic evidence exists
   • supply-chain-risk-auditor for mobile dependency risk if source code is also in scope
4. Prioritize bug classes in this order:
   • IDOR and account-boundary failures in mobile flows
   • exported activity, service, or broadcast abuse
   • deep-link takeover, open redirects, or auth handoff bugs
   • WebView and JavaScript bridge trust
   • insecure local storage, logging, and clipboard exposure
   • Firebase misconfiguration and exposed backend resources
   • SSL pinning or root checks that collapse under runtime hooking
5. If the app mainly fronts a server-side repo that is also in scope, hand the backend portion to bounty-program-web.
6. Group findings by boundary failure instead of filing one report per screen.

Rules

• Do not claim a mobile-only bug if the real issue is backend authorization.
• Use dynamic testing to confirm reachability whenever static analysis finds an interesting path.
• Compare every candidate against scope/target.json, scope/in-scope.md, scope/rules.md, and prep/severity-conditions.md before assigning severity.
• Low-only findings do not end the hunt. Keep going until a medium+ finding exists or an exact blocker is recorded.
• Keep the proof safe: avoid mass requests, destructive writes, or broad data extraction.