ios-redteam-pipeline – Other skill for AI agents

> ⚠️ AUTHORIZED USE ONLY

> This skill is for educational purposes or authorized security assessments only.

> You must have explicit, written permission from the system owner before using this tool.

> Misuse of this tool is illegal and strictly prohibited.

> Mandatory confirmation gate

> Before running any command that probes, exploits, changes, persists on, extracts data from, or attempts credential access against a target:

> 1. Ask the user to state the exact target URL, IP, account, or resource.

> 2. Ask the user to confirm written authorization and the permitted scope.

> 3. Show the exact command(s) and explain their expected effect.

> 4. Wait for explicit confirmation in the current conversation.

>

> Without that confirmation, remain read-only and provide defensive guidance only. Prefer a sandbox, disposable VM, or controlled lab.

When to use this skill

Trigger when:

• Recon surfaces 1+ apps under the target's Apple Developer / App Store publisher page
• A TestFlight public link or enterprise/ad-hoc .ipa/manifest.plist (OTA install) is found
• Customer-facing app, dealer/partner portal, or employee mobile companion app ships on iOS
• Bug bounty program lists iOS in scope
• apk-redteam-pipeline already found Android endpoints/secrets — the iOS build often ships a *different* backend version worth diffing (see hunt-shadow-api)

DO NOT use for:

• Android-only targets — that's apk-redteam-pipeline
• A task limited to web bundles with no authorized iOS scope; React Native/Flutter native bridges, entitlements and platform storage still need iOS-specific review when in scope
• Server-side only assessments with no mobile client in scope

---

Use a dedicated authorized test device/account and private evidence directory. Establish whether app binary, backend, credential validation, TLS instrumentation and test-CA/profile changes are each in scope; record/remove test profiles and artifacts afterward. Never use discovered keys merely because they exist: public Firebase config is not automatically a secret, and network access needs separate target confirmation. Create a virtual environment before Python installs, pin/review tools/scripts and check installed --help; legacy flags such as --no-pause and objection subcommands may differ. No universal TLS hook guarantees coverage across all stacks.

Stage 0 — Inventory all org-owned iOS apps

# App Store search API (no auth, no scraping needed)
curl -s "https://itunes.apple.com/search?term=<brand>&country=us&entity=software&limit=50" | python3 -m json.tool

# Pull the full metadata for a known bundle ID (once you have one)
curl -s "https://itunes.apple.com/lookup?bundleId=com.<brand>.app&country=us"

Extract: trackId, bundleId, sellerName (developer account — pivot to find sibling apps), version,

releaseNotes (changelogs often reference deprecated/removed API behavior — feeds hunt-shadow-api).

Cross-reference sibling-app bundle IDs surfaced from Android APK inventories (same

multi-brand conglomerate usually reuses com.<corp>.<sub-brand> naming on both platforms).

---

Stage 1 — IPA acquisition

Primary: from a real device you control (no jailbreak needed for a purchased/free app)

# Obtain an owner-provided test IPA/build when possible. Installing/listing apps does not
# itself export a decryptable IPA; Configurator/Xcode extraction depends on supported workflow.
# Or via libimobiledevice:
brew install libimobiledevice ideviceinstaller
ideviceinstaller -l              # list installed apps + bundle IDs

Secondary: TestFlight (if the program distributes betas publicly)

Open the public TestFlight link, install via the TestFlight app, then extract as above.

TestFlight builds are frequently LESS hardened than App Store releases (debug logging left on,

staging API hosts hardcoded) — compare channel/build/version; a beta finding does not establish production exposure.

Tertiary: enterprise / ad-hoc distribution (OTA install)

# itms-services:// links embed a manifest.plist with a direct .ipa URL
curl -s "https://<target>/manifest.plist" | plutil -convert xml1 -o - -
# Look for <key>software-package</key> — that URL is a directly downloadable, unencrypted IPA
curl --fail --show-error --proto =https --proto-redir =https --max-time 120 "<approved-software-package-url>" -o target.ipa

Enterprise/ad-hoc IPAs are not FairPlay-encrypted — no jailbreak or decryption tooling needed,

unlike an App Store binary pulled from a device.

Decrypting an App-Store-sourced binary (only if extracted from a jailbroken device)

App Store binaries are FairPlay-encrypted at rest; a binary copied off a jailbroken device

needs runtime decryption (frida-ios-dump, bagbak, or flexdecrypt) before static tools can

read it meaningfully:

python -m pip install frida-tools
# with frida-server running on the jailbroken device and the app in foreground:
python3 dump.py <bundle_id>          # frida-ios-dump — outputs a decrypted .ipa

---

Stage 2 — Unpack and static analysis

# An IPA is just a zip
unzip -l target.ipa  # inspect archive paths/size first; reject traversal/symlinks/oversized entries
# Extract only in a fresh private directory with an archive tool that enforces containment.
unzip target.ipa -d extracted_target/
cd extracted_target/Payload/*.app

# Info.plist — bundle ID, URL schemes, ATS config, entitlements hint
plutil -convert xml1 -o - Info.plist

# Entitlements — codesign reads the .app bundle (or the Mach-O binary), NOT Info.plist
codesign -d --entitlements :- . 2>/dev/null || \
  security cms -D -i embedded.mobileprovision | plutil -convert xml1 -o - -

# class-dump for Objective-C symbol/class recovery (compiled binary, not the .app bundle)
brew install class-dump
class-dump -H <AppBinaryName> -o headers/

# Swift binaries: class-dump won't show much — use Hopper, Ghidra, or `nm`/`strings` instead
nm -a <AppBinaryName> | grep -i swift | head -50
strings -a <AppBinaryName> > strings_target.txt

For a fast triage pass without a disassembler, the strings dump alone usually surfaces most of

what Stage 3 is looking for.

---

Stage 3 — Secret grep (same catalog as apk-redteam-pipeline, iOS-specific sources added)

# URL grep — owned-domain references
grep -oE 'https?://[a-zA-Z0-9.-]+\.(target1|target2|target3)\.(com|io|net)[a-zA-Z0-9./_?=&%-]*' strings_target.txt | sort -u

# Cloud credentials (same 60-pattern catalog as Android — reuse verbatim)
grep -oE 'AKIA[A-Z0-9]{16}' strings_target.txt          # candidate ID, not proof of valid credential
grep -oE 'AIza[A-Za-z0-9_-]{35}' strings_target.txt     # may be public/restricted app configuration
grep -oE 'eyJ[A-Za-z0-9_-]+\.eyJ[A-Za-z0-9_-]+\.[A-Za-z0-9_-]*' strings_target.txt   # JWT

# iOS-specific: GoogleService-Info.plist (Firebase config bundled per-platform)
find . -iname "GoogleService-Info.plist" -exec plutil -convert xml1 -o - {} \;
# Look for API_KEY, PROJECT_ID, STORAGE_BUCKET, GCM_SENDER_ID, GOOGLE_APP_ID — same Firebase
# public-read tests as apk-redteam-pipeline Stage 6.

# iOS-specific: hardcoded config plists shipped in the bundle
find . -iname '*.plist' ! -iname 'Info.plist' -exec sh -c 'for p do printf "=== %s ===\n" "$p"; plutil -convert xml1 -o - "$p"; done' sh {} +

# App Transport Security exceptions (Info.plist) — tells you if arbitrary/insecure loads are allowed
plutil -extract NSAppTransportSecurity xml1 -o - Info.plist 2>/dev/null

Keychain items left in a backup (if you have a device backup, encrypted or not)

python -m pip install iphone_backup_decrypt   # for encrypted local backups
# keychain-dumper (run ON a jailbroken device) for live keychain contents:
./keychain-dumper -e   # -e also decodes entitlements per item, showing which app owns which secret

---

Stage 4 — App Transport Security (ATS) misconfig + certificate-pinning bypass

Check for blanket ATS disablement (the single most common iOS network misconfig)

plutil -extract NSAppTransportSecurity xml1 -o - Info.plist

Red flags in the output:

• NSAllowsArbitraryLoads = true at the top level — HTTP (cleartext) allowed anywhere, app-wide.
• Per-domain NSExceptionAllowsInsecureHTTPLoads = true for a domain that carries auth tokens.
• NSAllowsArbitraryLoadsInWebContent = true — WKWebView traffic exempted, common blind spot.

A blanket ATS exception + a network position (rogue AP, ARP spoof, malicious VPN profile) =

plaintext credential/token interception without touching pinning at all.

Certificate-pinning bypass (when pinning IS present and correctly configured)

python -m pip install frida-tools objection
objection --gadget <bundle_id> explore
# inside objection:
ios sslpinning disable

If you want a Frida script instead, don't hand-roll one — use a maintained universal bypass

(e.g. the widely-used frida-ios-pinning/ios-ssl-bypass community scripts). Modern iOS TLS goes

through **Bo

… (full content is in the download package)