PS Product SecurityKnowledge Base

🍎 iOS Mobile AppSec Labs — DVIA and OWASP Crackmes

Intro: iOS testing usually has a steeper setup curve than Android, but it teaches a different kind of discipline: entitlements, keychain use, transport assumptions, deep links, and platform security boundaries matter a lot. This page gives you a practical iOS learning path without pretending the setup is as simple as Android.

What this page includes

  • what to use for iOS hands-on learning;
  • how DVIA and OWASP crackmes differ;
  • realistic setup advice;
  • what to look for in a defensive review.

Best lab choices

DVIA

DVIA is a deliberately vulnerable iOS application intended to help students and practitioners practice iOS penetration testing and security review skills.

Use DVIA when you want a broad iOS review target.

OWASP iOS UnCrackable Apps

Use these when you want narrower reverse-engineering and anti-tamper exercises.

Practical setup options

Option 1 — safest starter path

  • macOS host;
  • Xcode simulator;
  • source review and static review only;
  • proxy and app-flow learning.

Option 2 — deeper hands-on path

  • dedicated research Mac;
  • dedicated iOS test device where permitted;
  • Frida / objection / device instrumentation;
  • traffic interception and runtime inspection.

Do not mix a training device with a corporate daily-driver phone.

Tooling checklist

# macOS package examples
brew install class-dump
python3 -m pip install frida-tools objection

If you already have a built IPA or a sample app bundle, keep your evidence folder tidy:

mkdir -p ~/labs/ios/{ipa,logs,notes,proxy,findings}

Suggested DVIA workflow

Static review questions

  • what entitlements are present?
  • how does the app handle keychain and local data?
  • what deep links or URL handlers exist?
  • what backend hosts, paths, and feature flags are visible?

Dynamic review questions

  • what changes once a user authenticates?
  • what data is cached locally?
  • how does the app behave under hostile proxy conditions?
  • what trust decisions are happening in the client?

Example note-taking structure

App target: DVIA
Area reviewed: auth/session + local storage
What I observed:
- token persisted after logout
- device-side state used to unlock a privileged UI path
- debug logging reveals account metadata
What boundary failed:
- session invalidation and local trust assumptions
What fix likely belongs where:
- client clears state; backend rejects stale token or session reuse

iOS crackmes workflow

Use the crackmes for narrower goals such as:

  • identifying anti-debugging;
  • understanding jailbreak checks;
  • practicing static analysis and runtime hooks;
  • learning what tamper resistance can and cannot do.

What Product Security should learn from iOS labs

  1. Client integrity is not authorization.
  2. Secure storage mistakes become privacy and takeover problems quickly.
  3. The interesting question is whether a mobile flaw changes attacker capability in the real product.
  4. Some “mobile-only” fixes are actually backend trust-boundary fixes.

Common mistakes

  • assuming simulator observations equal device reality for every control;
  • treating anti-tamper bypass as if it automatically proves severe business impact;
  • forgetting the backend API review;
  • underestimating privacy exposure from logs, analytics, and caches.

---Author attribution: Ivan Piskunov, 2026 - Educational and defensive-engineering use.