Module 1 — Android Fundamentals for Pentesters

Por

This module builds the foundation every mobile security professional needs before performing static or dynamic analysis. It explains how Android is structured, what an APK contains, where sensitive data commonly lives, and which app components create an attack surface. The goal: make you fluent in the platform so you can reason about where vulnerabilities live and how to test them safely.

1.0 Learning objectives

By the end of this module you will be able to:

  • Describe Android’s architecture and the role of kernel / userspace / ART.
  • Explain APK anatomy and locate manifest, Java/Kotlin code, native libraries, resources and signatures.
  • Enumerate Android app components (Activity, Service, ContentProvider, BroadcastReceiver) and understand common misuse patterns.
  • Identify common insecure storage patterns (SharedPreferences, external storage, SQLite) and why they’re risky.
  • Produce a quick fingerprint of an APK (package name, cert fingerprint, target SDK, permissions).
  • Run small practical checks in a lab (decompile, inspect manifest, search for strings) on intentionally vulnerable test APKs.

1.1 Android architecture (concise, practical)

Key layers and why they matter to pentesters:

  • Linux kernel — device drivers, process isolation, namespaces, SELinux, and syscall surface.
    • Relevance: kernel/root compromises change the entire threat model; many protections rely on kernel features (e.g., verified boot, SELinux policies).
  • Native libraries & Bionic libc — native code executes via JNI and can introduce memory bugs.
  • Android Runtime (ART / Dalvik) — runs app bytecode (.dex) and JIT/AOT. Understanding ART helps when instrumenting / hooking Java methods.
  • Framework & SDK — Android APIs used by apps (keystore, network, storage, intents).
  • App sandbox / UID — each app runs under its own Linux UID; privileges and file access are constrained by this. Misconfigured exported components can widen attack surface.

1.2 APK anatomy — what’s inside and why each part matters

An APK is a signed ZIP archive with predictable pieces:

  • AndroidManifest.xml — declares package name, components, permissions, exported status, permissions used/required. High value for initial reconnaissance.
  • classes.dex (or multiple .dex) — Dalvik bytecode containing app logic. Decompile to inspect control flow and secrets.
  • resources.arsc, res/, assets/ — UI strings, layouts, embedded files; secrets sometimes leak here (misplaced keys).
  • lib/<ABI>/*.so — native libraries. Can hide logic or sensitive checks that are harder to patch at runtime.
  • META-INF/ — signing information. CERT.RSA/CERT.SF let you check who signed the APK.
  • resources/ and assets/ — can include JSON config, hardcoded certs, or English translations revealing endpoints.

Practical note: an attacker looks for secrets in assets/, endpoints in strings.xml, and sensitive flows in classes.dex.

1.3 AndroidManifest.xml — what to inspect and why

What to look for (priorities):

  • Package name and versioning — package identifies the app and is needed for Play integrity and attestation checks.
  • <uses-permission> — requested permissions; excessive permissions can increase risk (e.g., READ_SMS, READ_CONTACTS).
  • Exported components (android:exported="true") — exported Activities/Services/Receivers/Providers are callable by other apps and are frequent sources of privilege escalation or intent injection.
  • <provider android:authorities> — ContentProviders backed by file storage can leak data if not guarded.
  • Intent filters — open intents can be abused for intent spoofing.
  • TaskAffinity / launchMode / allowBackup — android:allowBackup="true" can leak app data via adb backup (if device permits).
  • android:sharedUserId — risky if used to share UID between apps without strong controls.

Example quick-checks:

  • Are any components exported without permission guards?
  • Are there custom permissions declared but not enforced?
  • Is android:allowBackup set to true?

1.4 App components and common weak patterns

Short catalog with attack vectors:

  • Activities — if exported, can be launched with crafted intents (intent injection, data exfiltration).
  • Services — background components; exported services that accept commands can be hijacked.
  • BroadcastReceivers — if registered in the manifest and exported, they can accept crafted broadcasts.
  • ContentProviders — improper URI permission checks can expose app data.
  • Intents — implicit intents can leak data or accept input that’s later trusted.

Common insecure patterns:

  • Exported components without permission attributes.
  • Implicitly-handled URIs that do not validate inputs.
  • Use of File:// URIs or exposing file paths that rely on external storage.

1.5 Storage on Android — where data lives and common mistakes

Storage locations and risks:

  • Internal storage (/data/data/<package>/files, getFilesDir()) — private by default, but root or backup can expose it.
  • External storage (/sdcard/ or getExternalFilesDir) — world-readable on many devices; never store secrets here.
  • SharedPreferences — common for tokens; when stored plaintext, tokens leak easily.
  • SQLite databases — can contain PII, tokens; often left unencrypted.
  • Keystore / AndroidKeyStore — secure storage; when used properly with hardware-backed keys, it’s strong. But misuse (exporting keys, using software-only keystore) weakens it.
  • Cache / temp files — leftover sensitive payloads can remain.

Red flags:

  • Plaintext tokens or API keys in SharedPreferences or files.
  • Sensitive config in assets/ or res/strings.xml.
  • allowBackup="true" combined with sensitive local storage.

1.6 Permissions model and dangerous permissions

Understanding permission classes:

  • Normal — low-risk (e.g., ACCESS_NETWORK_STATE).
  • Dangerous — user must approve (contacts, SMS, storage). These grant direct access to sensitive data.
  • Signature — only apps signed with same cert may obtain (used for inter-app trust).
  • Runtime permissions — Android 6+ requires user approval; check whether the app requests permissions lazily or upfront, and how it handles denial.

Common testing angles:

  • Does app assume permission granted? (race condition / logic crash)
  • Overprivileged apps: requesting more permissions than necessary.

1.7 Native code & JNI — what to be aware of

  • JNI bridges can encapsulate crypto or attestation checks; native libs are harder to read and harder to patch.
  • Debug symbols: if present, they reveal function names and help reverse engineers.
  • Native vulnerabilities: buffer overflows, format strings, improper input validation.

Practical checklist:

  • Is there a lib/ directory with .so files?
  • Are symbols stripped? (presence of .sym or readable symbols suggests weaker builds)
  • Does the app use JNI for security-critical flows?

1.8 Common insecure design patterns (with examples)

  • Hardcoded secrets
    • Example: API key or private credential stored as String API_KEY = "deadbeef..." in code or strings.xml.
  • Trusting client-only checks
    • Example: client performs “isDeviceRooted” and proceeds if false — but server accepts client decisions without validating attestation.
  • Improper certificate validation
    • Example: app ignores hostname verification or accepts any server certificate in debug builds.
  • Poor session management
    • Example: tokens with long lifetimes not bound to device or user.

1.9 Quick practical labs & exercises (safe, lab-only)

These are small exercises you can run immediately in an isolated lab using intentionally vulnerable APKs (DVIA, InsecureBankv2), emulators or test devices.

Exercise A — APK fingerprint and manifest inspection

Goal: get package name, permissions, exported components, and cert fingerprint.

Steps (high-level):

  1. Obtain the test APK (from your lab repo).
  2. Run aapt dump badging app.apk to get package name and permissions.
  3. Run unzip -l app.apk or apktool d app.apk to extract AndroidManifest.xml.
  4. Use keytool -printcert -file META-INF/CERT.RSA (after extracting) or apksigner verify --print-certs app.apk to obtain cert fingerprints.

What to record: package name, targetSdkVersion, list of android:exported components, SHA-256 fingerprint of signing cert.

Exercise B — Strings and endpoints discovery

Goal: find hardcoded endpoints, API keys or suspicious strings.

Steps (high-level):

  1. strings app.apk | grep -Ei "http|api|key|password|token|client"
  2. Open res/values/strings.xml via apktool or jadx and search for endpoint-like values.

Record suspicious findings with file/line references.

Exercise C — Identify native libs

Goal: list native libraries and note presence of symbols.

Steps (high-level):

  1. unzip -l app.apk | grep '\.so'
  2. For each .so, run readelf -h lib.so to get ABI and readelf -s lib.so | head to sample symbols.
  3. If symbols present, note function names that look like crypto, attestation, or validation.

All commands above are intended for lab-only on test APKs. Do not use them on production app packages without authorization.

1.10 Tools & quick commands (cheat-sheet)

Short list of commonly used commands for Module 1 tasks (lab-only):

  • Inspect APK metadata:
    • aapt dump badging app.apk
    • apksigner verify --print-certs app.apk
    • unzip -l app.apk
  • Extract APK:
    • apktool d app.apk -o app_unpacked
  • Decompile to Java:
    • jadx-gui app.apk or jadx -d out app.apk
  • Search strings:
    • strings app.apk | grep -Ei "http|api|key|token|secret|password"
  • List native libs:
    • unzip -l app.apk | grep '\.so'
  • Check resources:
    • Inspect res/values/strings.xml after apktool extraction.

1.11 Deliverables for Module 1 (what to produce)

When finishing Module 1 for a target in a lab, produce:

  • APK fingerprint summary: package name, version, cert fingerprints, target SDK.
  • Manifest report: list of exported components, permissions, allowBackup flag.
  • String & resource inventory: endpoints, possible secrets, config files.
  • Native library inventory: list of .so files and notes on symbols.
  • Initial threat model: short mapping of each finding to potential impact (e.g., exported content provider → data leak).

These outputs feed Module 2 (recon) and Module 3 (static analysis).

1.12 Short quiz (self-check)

  1. What is stored in AndroidManifest.xml and why is it high value for reconnaissance?
  2. Name three locations where apps commonly leak secrets.
  3. Why is android:allowBackup="true" risky for apps with sensitive data?
  4. What is the difference between native (.so) issues and Java/Kotlin issues in terms of exploitation difficulty?

(Answers should be written down and checked against your lab instructor’s key.)

1.13 Suggested reading & references

  • OWASP Mobile Top Ten (conceptual mapping).
  • Android official docs: Application fundamentals, Security overview.
  • Sample vulnerable APKs: DVIA, InsecureBankv2 (use only in lab).