PS Product SecurityKnowledge Base

📱 Mobile Security Lab Track — NowSecure, iOS, and Android Learning Flow

Intro: Mobile security becomes much easier to study when you separate the training platform, the standards baseline, and the hands-on vulnerable targets. This page turns those moving parts into one learning path that works for Product Security, mobile AppSec, and DevSecOps practitioners.

What this page includes

  • how to structure a practical mobile learning track;
  • where NowSecure fits and where it does not fit;
  • which Android and iOS labs are worth your time;
  • how to combine static, dynamic, and manual work without getting lost.

The correct mental model

Treat the mobile lab track as three layers:

  1. Reference model — MASVS, MASTG, MASWE.
  2. Learning platform and workflow — NowSecure Academy and NowSecure Platform style testing flow.
  3. Hands-on vulnerable targets — Android and iOS labs such as AndroGoat, DVIA, and OWASP crackmes.

A common mistake is to expect a commercial testing platform to behave like a vulnerable lab. It will not. NowSecure is a training and testing workflow, not a goat environment.

Stage Goal Best tool or lab Output you should produce
1 Learn the vocabulary OWASP MASVS / MASTG / MASWE one-page notes on controls and test ideas
2 Learn the workflow NowSecure Academy or NowSecure-style testing flow a repeatable mobile review checklist
3 Learn Android attack surface Android Mobile AppSec Labs Android review notes and evidence
4 Learn iOS attack surface iOS Mobile AppSec Labs iOS review notes and evidence
5 Learn triage discipline Mobile Application Security Testing severity, exploitability, fix ownership
6 Learn release decisioning Mobile Testing Quality Gates and DefectDojo Integration pass/fail criteria and exception notes

What a good mobile study loop looks like

Pass 1 — understand the platform and app architecture

  • mobile client boundaries;
  • auth and token flows;
  • local storage and caches;
  • transport protection;
  • backend API assumptions;
  • build and signing assumptions.

Pass 2 — test one class of issue at a time

Do not test everything at once. Pick one class:

  • insecure storage;
  • TLS / certificate validation;
  • exported components or deep links;
  • WebView abuse;
  • sensitive logs;
  • jailbreak or root detection bypass;
  • hardcoded secrets or environment endpoints.

Pass 3 — write the reviewer conclusion

For each issue, answer:

  1. what boundary failed?
  2. what real attacker capability does this create?
  3. does the fix belong in the client, the backend, or both?

Build your local mobile lab workstation

# Android / reverse engineering essentials
brew install jadx apktool
python3 -m pip install objection frida-tools

# optional: MobSF locally for static + dynamic workflows
mkdir -p ~/labs/mobsf-data

docker run --rm -it \
  -p 8000:8000 \
  -v "$HOME/labs/mobsf-data:/home/mobsf/.MobSF" \
  opensecurity/mobile-security-framework-mobsf:latest

Android emulator and ADB sanity check

adb devices
adb shell getprop ro.build.version.release
adb logcat | head

iOS note

For iOS labs, the easiest path is usually:

  • a macOS host;
  • Xcode simulator for benign review tasks;
  • a dedicated jailbroken or research device only if your organization allows it;
  • Frida / objection on a dedicated training workstation.

How Product Security should use this track

Use mobile labs to strengthen review judgment, not only exploit muscle.

Ask questions like:

  • does the client make an authorization decision that the backend should own?
  • is sensitive data retained on the device longer than the product actually needs?
  • would a compromised device expose reusable secrets or tokens?
  • do our mobile release criteria distinguish between a privacy issue, a fraud issue, and a hardening issue?

Best follow-up pages

References

  • OWASP Mobile Application Security project
  • NowSecure Academy
  • NowSecure mobile testing platform documentation

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