Phase 04 - Android Platform and Application Security

Duration: 8 weeks (Months 8-9)
Objective: review Android applications and reason about Android platform trust transitions from app code through Binder, native code, kernel policy, and hardware-backed services.

Deep guides: WARMUP.md maps Android boot, sandbox, Binder, components, WebView, storage, and JNI boundaries; HITCHHIKERS-GUIDE.md gives an authorized assessment workflow, commands, attack fixtures, and hardening checks.

Required Theory

Android boot chain, Verified Boot, partitions, update model, app signing, package management, Zygote, ART, AOT/JIT, and APK/AAB structure.
UID sandbox, permissions, runtime permissions, SELinux domains, Binder IPC, intents, services, activities, broadcast receivers, content providers, pending intents, and exported components.
Storage, backups, logs, clipboard, screenshots, Keystore, hardware-backed keys, attestation concepts, biometrics, and credential lifecycle.
WebView, deep links/app links, network security configuration, certificate pinning tradeoffs, mobile API authorization, and privacy.
JNI/native libraries, memory safety, ABI, ARM64, fuzzing, and safe dynamic instrumentation.
Static vs dynamic analysis, obfuscation limits, anti-tamper/root-detection limits, secure mobile SDLC, OWASP MASVS/MSTG.

Lab Application

Build one intentionally vulnerable field-operations app using synthetic data and a local API. Keep it in an isolated emulator. Maintain vulnerable and hardened variants so every issue has a reviewable fix and regression test.

8-Week Lab Sequence

Week	Labs	Required result
1	APK anatomy, manifest, signing, JADX and apktool comparison	annotated component/data-flow map and tool limitations
2	insecure storage, logs, backups, screenshots, clipboard	instrumented proof, secure storage/UX fix, tests
3	exported activities/services/providers/receivers and permission design	component access matrix and negative tests
4	intents, pending intents, deep links, task behavior	controlled abuse-case fixtures and explicit-intent/validation fixes
5	WebView bridge/navigation/content risks and mobile API authz	allowlist, isolation, browser handoff, API tenant tests
6	network security config, local proxying, pinning and rotation	lab interception proof, production-safe trust decision and rotation plan
7	Binder toy service and SELinux reasoning	AIDL interface, caller validation, permission model, policy trace
8	JNI parser, ARM64 review, fuzzing	sanitizer crash, minimized input, safe fix, regression corpus

Runnable lab portfolio

These cover component exposure, deep-link origin/tenant/parameter abuse, and offline storage, backup, screenshot, clipboard, Keystore, retention, online-only action policy, and a sanitizer-tested Kotlin-to-C++ parser boundary.

Use Frida only against the owned lab app to observe method arguments, state transitions, and certificate-validation behavior. Do not create reusable bypass scripts for third-party apps.

Exact Deliverables

Kotlin vulnerable and hardened applications;
local test API with cross-account authorization fixtures;
APK static-analysis notebook and component inventory;
authorized dynamic-analysis scripts;
storage, component, WebView, network, Binder, and JNI findings;
Android threat model covering app, OS, device, user, backend, and supply chain;
MASVS control mapping;
responsible-disclosure-style report with no real target.

Capstone - Android Security Research Portfolio Project

Conduct a full assessment from scope through retest. Present one chain showing how two individually moderate design errors combine, then break the chain with independent controls. Include a conference-style paper: architecture, hypothesis, method, evidence, root cause, remediation, variants, limitations, and ethics.

Tools and Sources

Android Studio, emulator, adb, Gradle, JADX, apktool, MobSF, Frida, Ghidra, clang sanitizers, libFuzzer, mitmproxy/Burp against local services.

Read Android Developers security guidance, AOSP architecture/security/SELinux/Binder docs, Android Security Bulletins, OWASP MASVS/MSTG, and source for the APIs under study. For public historical issues, study patches and bulletins; reproduce only in compatible owned builds.

Measurable Outcomes

All application components have an exposure and caller-validation decision.
Hardened variant passes unit, instrumentation, API authorization, and native fuzz smoke tests.
No secrets or sensitive synthetic records appear in logs, backups, screenshots, or clipboard.
Native harness runs at least one million executions or a documented resource-bound equivalent.
Report clearly separates application, platform, OEM, backend, and user responsibilities.

Evaluation Checklist

Explain Android's UID sandbox, Binder identity, and SELinux interaction.
Trace an intent from manifest resolution to receiving component validation.
Choose between Keystore protection, encrypted storage, server-held data, and no storage.
Explain why pinning and root detection are not authorization boundaries.
Triage a JNI crash and assess reachability without overstating impact.
Produce developer-ready Kotlin/manifest/native fixes and retest evidence.

Common Mistakes and Interview Questions

Mistakes: reporting exported components without reachable impact, treating decompilation as source, embedding secrets, disabling TLS validation as a test shortcut, claiming root detection prevents analysis, and ignoring backend authorization.

Questions: review a payment deep link; secure a content provider; explain Binder caller identity; threat-model a WebView bridge; investigate a native media-parser crash; design secure offline storage; compare Android app signing, Verified Boot, and hardware-backed keys.

Portfolio and Stretch

Publish only the purpose-built app and sanitized report. Stretch: AOSP build navigation, custom lint rule, Binder fuzz target, SELinux policy test, app attestation design review, or an authorized open-source Android finding with coordinated disclosure.

Security Engineer