This section covers everything needed to build a functional Android penetration testing lab. Each guide is self-contained and focuses on one tool or environment component. Work through them in order if you are starting from scratch, or jump to a specific tool if you already have the basics in place.
| File | Purpose |
|---|---|
| Linux-Kali.md | OS-level packages, USB rules, platform-tools, directory layout |
| ADB.md | Android Debug Bridge — the backbone of all device interaction |
| Burp-Suite.md | HTTP/S interception proxy setup for Android traffic |
| Frida.md | Dynamic instrumentation: frida-server, frida-tools, scripting |
| Objection.md | Runtime mobile exploration built on Frida |
| MobSF.md | Automated static and dynamic analysis framework |
| JADX.md | DEX-to-Java decompiler (GUI and CLI) |
| Apktool.md | APK decode, resource extraction, smali, and rebuild |
| Drozer.md | IPC assessment: activities, services, broadcast receivers, providers |
| Rooted-Test-Device.md | Why root matters for testing and how to get a root shell |
| Magisk.md | Systemless root, Zygisk, DenyList, and LSPosed |
| scrcpy.md | Screen mirror and recording for demonstrations and evidence |
The Android Virtual Device (AVD) manager bundled with Android Studio creates emulators ranging from stock AOSP to Google Play images.
Pros:
- No hardware required
- Easy to snapshot and restore a clean state
- x86/x86_64 images run at near-native speed on modern CPUs
- Can flash a root-enabled
userdebugimage for full root access
Cons:
- x86 architecture differs from real-device ARM; some native libraries behave differently
- Google Play images run on production-signed builds and resist root more aggressively
- Hardware sensors, camera, Bluetooth, and NFC are limited or absent
- Some banking and DRM apps detect emulator environment
Best for: Learning fundamentals, testing apps that have no emulator detection.
A real Android phone or tablet in developer mode with USB debugging enabled.
Pros:
- Real ARM architecture, real sensors
- Tests run in the environment the app was designed for
- Cheaper than expected — older flagship devices cost very little used
Cons:
- Cannot access
/data/data/<package>without root - Some tests are impossible without root (decrypting databases, reading keystore, etc.)
- Reflashing to a clean state takes effort
Best for: Traffic interception, exported component testing, basic static analysis workflow where root is not needed.
A physical device with an unlocked bootloader and Magisk installed.
Pros:
- Full access to
/data/data/<package>and shared storage - Can install Frida server as root, run Objection without restrictions
- Can push system certificates to the trusted CA store
- Best approximation of a real-world compromised device
Cons:
- Requires a device with an unlockable bootloader (not all do)
- Unlocking wipes the device
- Degrades some real-world security signal (e.g., SafetyNet/Play Integrity breaks)
Best for: Complete pentests, dynamic analysis with Frida, SSL pinning bypass, root detection bypass.
Kali Linux (bare metal or VM) as the attack workstation coordinating the other three options above. Most tools in this section are installed on Kali and communicate with the test device over ADB or over a shared WiFi network.
Pros:
- All tools pre-packaged or easily installable
- Familiar environment if coming from network pentesting
- Integrates well with other Kali tools (Burp, nmap, etc.)
Cons:
- Additional layer of setup if running as a VM (USB passthrough for physical devices)
Best for: The recommended host OS for this entire lab.
| Component | Minimum | Recommended |
|---|---|---|
| RAM | 8 GB | 16 GB |
| CPU | 4 cores | 8+ cores with hardware virtualisation (Intel VT-x / AMD-V) |
| Disk | 50 GB free | 100 GB free (emulator images, APKs, and tool collections add up) |
| OS | Kali Linux 2023+ | Kali Linux 2024+ (rolling) |
| Physical device | Android 8.0+ | Android 10–13 with unlockable bootloader |
For emulators, hardware virtualisation acceleration (KVM on Linux) is essential. Without it, emulators are unusably slow.
All testing described in this repository must be performed exclusively on dedicated test devices or emulators that you own and control.
- Never test on your personal daily-use phone.
- Never test on production applications you do not have written authorisation to test.
- Never connect your test device to your work or personal accounts.
- Factory reset test devices between engagements or use emulator snapshots to restore clean state.
- Keep test APKs, extracted data, and reports in an isolated directory that does not sync to personal cloud storage.
Security testing without authorisation is illegal in most jurisdictions regardless of intent.