Module 0 — Lab Preparation, Ethics, and Tools

Por

Great — this module gives you a complete, practical blueprint to build a safe, repeatable Android mobile-pentest lab suitable for training security professionals working on banking apps. It’s written for defenders and red-teamers who will run authorized exercises in isolated environments and collect reliable evidence. I’ll cover objectives, recommended topology and VM images, device choices, tools (with install guidance for safe lab use), snapshotting and rollback, artifact collection and hashing, Rules of Engagement (RoE) checklist, and operational best practices for evidence handling and reporting.

0.0 Objectives of Module 0 (what you will be able to do)

  • Build an isolated and reproducible test environment (emulators + physical devices + VM) for mobile pentesting.
  • Install and configure the standard toolchain used in Android static & dynamic analysis and network interception.
  • Configure network isolation, traffic capture, and artifact collection with integrity (checksums, timestamps).
  • Create repeatable lab snapshots and CI-friendly lab redeploys.
  • Define and enforce Rules of Engagement (RoE), evidence handling, and reporting templates for vendor/consultant validation.

0.1 Mandatory Ethics & Legal Checklist (Before you touch anything)

Before any hands-on work begins, always confirm and store the following in writing:

  1. Scope of Testing (SOW / Scope document)
    • Target app package names (e.g. com.example.bank) and versions.
    • Allowed devices and networks (test devices only).
    • Allowed techniques (static, dynamic, instrumentation, fuzzing, kernel-level? — be explicit).
  2. Signed Authorization from the app owner that explicitly permits:
    • Local testing on their software, servers, and test accounts.
    • Collection of device images and memory dumps.
  3. RoE (Rules of Engagement) covering hours, escalation path, emergency stop, data handling, and non-disclosure clauses.
  4. Data minimization & test accounts: never use real customer accounts or production data. Use synthetic test users and isolate test APIs.
  5. Evidence-handling agreement: where images/dumps are stored, who has access, retention, and destruction policies.

Store all documents in a secure repository (managed with strict access control) and log who signed what + timestamps.

0.2 High-level Lab Topology (recommended)

Goal: fully isolated network that mimics production but cannot spill to the internet or customer data.

Two common safe topologies:

A) Isolated single-host lab (simpler)

  • Host machine (laptop/desktop) runs: VirtualBox/VMware guest as “lab controller.”
  • The controller runs: Android emulators + Burp Suite + mitmproxy + traffic capture.
  • Virtual network: Host-only network for emulator ↔ proxy communication.
  • Use NAT only when explicitly needed and under controlled rules.

B) Multi-host lab (recommended for team training)

  • lab-controller VM (Ubuntu): orchestration (ADB server, CI scripts, backups).
  • proxy VM (Ubuntu): Burp/mitmproxy, tcpdump, Wireshark, pcaps repository.
  • device hosts: physical devices connected to controller OR Android emulator VMs (separate AVD per trainee).
  • mock-api VM: host mock backend services to emulate bank APIs (allows safe, deterministic tests).
  • Management network: internal only (no default internet route), connected to your organization’s jump host for controlled internet access (if needed).

Simple ASCII example (multi-host):

[Trainee Laptop] --- SSH ---> [lab-controller VM]
                           |--[proxy VM: Burp, mitmproxy, tcpdump]
                           |--[mock-api VM: test backend]
                           |--[emulator/device instances attached via adb]

Make sure VMs use host-only or internal networks. Do not attach lab VMs to corporate production networks.

0.3 Host & VM Recommendations (base images / sizes)

  • Host OS: Linux (Ubuntu LTS) or macOS. Linux gives easiest permission handling for adb, usb, tcpdump.
  • VM specs (per trainee or per lab controller):
    • 4 vCPU, 8–16 GB RAM, 50–200 GB disk (snapshots consume space).
    • Ubuntu 22.04 LTS or 24.04 LTS recommended.
  • Android emulator images: use Google Play images for more realistic behavior (but isolate them) and arm/x86 images per CPU support.
  • Snapshots: always create a fresh snapshot after baseline install (clean emulator, no test APKs) so you can revert.

0.4 Device choices — emulator vs real devices vs cloud device farms

  • Emulators (Android Studio AVD)
    • Pros: fast snapshotting, fully controlled images, easy to install CA certs, inexpensive.
    • Cons: may behave differently from real devices (SafetyNet/Play Integrity may detect emulators).
    • Use: majority of training, automatable CI tests, instrumentation labs.
  • Real devices (recommended for final validation)
    • Pros: real hardware, hardware-backed keystore, realistic attestation behavior.
    • Cons: cost, slower snapshots (you must image devices), potential warranty/erase issues.
    • Use: final verification of hardening and attestation logic.
  • Cloud device farms
    • Pros: scalable, many device models.
    • Cons: less control over rooting, may violate legal constraints for some tests, higher cost.

Advice: do most development & labs on emulators; validate final controls on real devices only and maintain full device images/backups for reproducibility and evidence.

0.5 Toolchain (core tools and purpose)

Below is a recommended minimal toolchain for Module 0. I include brief install guidance where appropriate for lab use.

  • Android SDK / Android Studio — AVD manager and emulator.
    • Use for building emulators and for adb.
  • adb (Android Debug Bridge) — device control, install/uninstall APKs, logcat.
  • apktool — unpack/repack APKs (used in safe labs).
  • jadx / JADX-GUI — decompile classes.dex to Java/Kotlin (static analysis).
  • Ghidra / radare2 / Cutter — native binary analysis (if native libs present).
  • Frida & frida-tools — runtime instrumentation (lab use with test APKs).
    • Install frida-tools in the lab environment (e.g., pip install frida-tools) for controller scripts.
  • Objection — runtime mobile exploration helper (use in controlled lab only).
  • Burp Suite (Community/Professional) — intercept & modify HTTP/S traffic.
  • mitmproxy — lightweight programmable proxy alternative.
  • tcpdump & Wireshark — packet capture & analysis.
  • openssl / keytool — inspect certs, create CA for lab, etc.
  • apk-signing tools: apksigner, jarsigner (for rebuilding lab APKs).
  • hash utilities: sha256sum, sha1sum — for checksums of images and artifacts.
  • Version control: Git for lab artifacts and scripts (private repo).
  • Infrastructure automation: Ansible / Terraform for lab provisioning (optional but recommended).

0.6 Quick install notes (lab-only, high-level)

You’ll likely run these on your lab-controller VM. Replace package manager commands according to distro.

  • Install Java (required by some tools), Android SDK, and adb.
  • Install apktool (download jar + wrapper script) and jadx (prebuilt).
  • Install Python + pip and then pip install frida-tools objection.
  • Install burpsuite on the proxy VM (Community is fine for labs; Professional adds useful features).
  • Install mitmproxy (pip install mitmproxy) if you want scriptable interception.
  • Install tcpdump and wireshark (wireshark for offline analysis).
  • Install openssl and keytool for certificate tasks.

0.7 Building a test CA and configuring the proxy (conceptual)

  • Create a lab CA (OpenSSL) on the proxy VM.
  • Configure Burp/mitmproxy to use the lab CA.
  • Install the lab CA on emulator/device ONLY for testing (do not install on production devices).
  • Configure device/emulator proxy settings to route traffic to the proxy VM. Use host-only/internal network to prevent unintended internet exposure.

(If you want the exact commands to create a lab CA and how to load it into an emulator AVD for training, I can provide those in a follow-up as part of Module 0 practical steps.)

0.8 Emulators: recommended baseline AVD configuration

  • Use an AVD with at least Android 11 or later (banking apps often require modern APIs).
  • Allocate 2+ GB RAM per AVD, enable hardware acceleration (HAXM / KVM) if host supports it.
  • Create one clean baseline image and snapshot it immediately. This is your “golden baseline.”
  • Create additional AVDs with Play Services where necessary to test Play Integrity flows (but remember Play Integrity behaves differently in emulators).

0.9 Real device preparation (for final validation)

When using physical devices:

  1. Keep a fleet of devices labelled and tracked (purchase cheap used devices for labs).
  2. Maintain an inventory spreadsheet with device model, IMEI (if allowed), Android version, bootloader state, and a device ID used for lab tracking.
  3. For reproducibility, create a device image (using adb pull, custom recovery, or vendor tools) after a clean flash and store its checksum. This image is your revert point.
  4. Use a dedicated USB hub and test bench so devices are physically organized and snapshots are handled consistently.
  5. Ensure devices used for training contain only synthetic test accounts and mock data.

Important: avoid rooting or changing production devices; any rooted device should be strictly labeled and isolated.

0.10 Test APKs and sample vulnerable apps

Use intentionally vulnerable applications only. Examples (safe for training):

  • DVIA (Damn Vulnerable iOS/Android Apps) — purposely insecure apps.
  • InsecureBankv2 / InsecureBankv1 — intentionally vulnerable banking app clones.
  • Custom-made apps for the course: include scenarios for pinning, attestation, keystore misuse.

Store these APKs in your private lab repo with versioning and checksums. DO NOT upload to public stores.

0.11 Snapshotting, backups, and rollback strategy

  • VM snapshots: before any risky step (e.g., installing lab CA, running instrumentation), take a snapshot. Label snapshots with timestamp and commit message.
  • Emulator snapshots: use AVD snapshots to rollback quickly.
  • Device images: create and store a full device image (if possible) and a SHA256 checksum. Place images in an encrypted archive with access control.
  • PCAPs and logs: store packet captures and logs in a centralized evidence VM; hash each artifact (sha256sum artifact > artifact.sha256) and store sha file with artifact.
  • Retention: define retention policy in RoE (e.g., keep evidence for 90 days, then destroy unless required by incident response).

0.12 Evidence collection & tamper-evident handling

Always collect evidence in a way that preserves chain-of-custody and integrity.

For each evidence item (e.g., device image, memory dump, Play Integrity token, adb logcat file, pcap):

  1. Record metadata: who collected it, date/time (UTC), tool/version used, host name.
  2. Compute and record a cryptographic hash (SHA-256) and store the hash separately.
  3. Store evidence on encrypted storage (e.g., LUKS encrypted partition or S3 with server-side encryption and limited IAM access).
  4. If possible, timestamp via an internal TTP or use secure logging (Syslog over TLS) to an immutable store.
  5. For artifacts from vendors/third parties (e.g., the pentest vendor claiming a bypass), require: raw pcaps, console outputs, device images, Play Integrity/attestation tokens, and exact commands used — then validate the artifacts against your own lab or verification scripts. (Module 13 will include a forensic artifact checklist.)

0.13 CI / Automation for labs (recommended)

Automate lab provisioning and cleanup so exercises are reproducible:

  • Use Ansible to provision lab-controller and proxy VMs with required packages and baseline configs.
  • Use Docker for mock backends (stateless) and to run scripted test endpoints.
  • Create scripts to spin up emulators and install the latest test APK automatically (adb install -r path/to/app.apk).
  • Store lab configurations in Git (private) and tag releases (e.g., lab-v1.0 with specific APK versions).

0.14 Security controls for the lab itself

  • Access control: limit who can SSH to the lab controller and who can download evidence. Use MFA for logins.
  • Network controls: block outbound internet from lab VMs by default; allow only approved egress through a controlled jump host.
  • Logging: centralize logs for lab VMs to an immutable logging service.
  • Secrets: protect signing keys and CA private keys in a secrets manager (HashiCorp Vault, AWS KMS, etc.). Never store private keys in plaintext within the lab repo.

0.15 Example RoE & SOW items to require from a vendor

If a third-party pentester claims they bypassed protections, require these items as part of the SOW:

  • Exact test steps taken (high-level is okay in SOW, but forensic artifacts are required for validation).
  • Full set of artifacts for each finding:
    • Device image or a verified snapshot with checksum.
    • Raw adb logs/logcat output (timestamped).
    • PCAPs of the session including TLS handshakes.
    • Any attestation tokens returned (Play Integrity / Key Attestation) in base64/raw, with the nonce used.
    • Binary patch diffs if they modified the APK under test (original APK and modified APK, both hashed).
    • A reproducible lab environment description: emulator/device model, OS version, kernel version, bootloader locked/unlocked state.
  • A description of evidence validation steps you can perform to independently confirm the finding.

(Module 13 will expand this into an exhaustive forensic request checklist.)

0.16 Operational playbook — a short checklist before each session

Before starting a lab session, confirm:

  1. Signed authorization present for the app version and scope.
  2. Clean baseline snapshot exists and is tagged.
  3. Test accounts and mock backend are configured.
  4. Proxy CA installed only on lab devices/emulators.
  5. Evidence directory mounted with encryption and write-once for the session.
  6. Capture tools ready (tcpdump, burp logs, adb logs), and time synchronized (NTP) across lab machines.
  7. If vendor involvement: agree on artifact names and expected delivery format before they begin.

0.17 Deliverables & templates you should produce from the lab

Create these templates once and reuse:

  • Evidence manifest template (artifact name, SHA256, collected by, timestamp, notes).
  • Test session log template (who ran test, high-level steps, start/end time, devices used).
  • Report template for findings (executive summary, technical appendix, remediations, retest criteria).
  • Forensic request template to send to external testers (list of required artifacts and formats).

I can generate these templates (JSON/CSV and markdown) if you want — say the format you prefer.

0.18 Risks, limitations and responsible-use notes

  • Some behaviors (e.g., attestation enforcement, Play Integrity) behave differently on emulators vs real devices; always validate critical controls on real hardware.
  • Rooted/modified kernels on devices can trivially invalidate many client-side protections; do not confuse lab root/emulator tests with production guarantees. Use a defense-in-depth approach.
  • Never run attacker tooling against production systems, customer devices, or unapproved networks — even during training.