Skip to content

Installation / Setup⚓

Everything you need to get a working Android pentesting environment without having to search elsewhere.

Android Platform Tools (ADB & Fastboot)⚓

Platform Tools is a set of command-line binaries Google ships for communicating with Android devices from your computer. You need this before you can do anything else.

adb — Android Debug Bridge⚓

ADB is a client-server tool made of three components:

  • Client — the adb binary you run on your machine
  • Server — a background daemon (adb server) that runs on your host on port 5037, multiplexing connections between clients and connected devices
  • Daemon (adbd) — a daemon running on the Android device itself, typically as root on emulators or as the shell user on production devices

When you run any adb command, the client talks to the local server over TCP 127.0.0.1:5037. The server then forwards the command to adbd on the device over USB (via the USB protocol) or over TCP (when using ADB over Wi-Fi). adbd executes the command and streams the result back.

Over USB, ADB uses the Android Open Accessory protocol wrapped over USB bulk transfers on a specific USB interface. Over Wi-Fi (TCP), it's a plain TCP connection to port 5555 on the device.

fastboot — Bootloader Protocol⚓

Fastboot is a separate protocol that operates at the bootloader level — before the Android OS boots. When a device is in fastboot mode it exposes a minimal USB interface that accepts a defined set of commands over USB bulk transfers:

  • getvar — read bootloader variables (device state, version, etc.)
  • flash <partition> — write a raw image to a named partition (e.g. boot, system, recovery, vbmeta)
  • erase <partition> — wipe a partition
  • boot <image> — boot a kernel image once without flashing it
  • oem unlock / flashing unlock — unlock the bootloader (disables verified boot, wipes data)
  • reboot — reboot the device

Fastboot does not go through the OS or adbd at all — it communicates directly with the bootloader's USB stack.

mke2fs — Filesystem Creator⚓

mke2fs is a Linux utility bundled with Platform Tools for creating ext2/ext3/ext4 formatted filesystem images. The Android tools use it internally when constructing disk images (e.g. creating a blank userdata.img). You will almost never call this directly during pentesting.

Windows⚓

  1. Download the latest zip from developer.android.com/tools/releases/platform-tools
  2. Extract to a permanent location, e.g. C:\platform-tools\
  3. Add to PATH so you can run adb from anywhere:
    • Search "Edit the system environment variables" → Environment Variables
    • Under System variables, find Path → Edit → New
    • Add C:\platform-tools
    • Click OK and restart any open terminals
  4. Verify:
adb version
fastboot version

Download and install Android Studio from developer.android.com/studio. During setup it will automatically download the Android SDK including Platform Tools. The default location after install is:

C:\Users\<you>\AppData\Local\Android\Sdk\platform-tools\

Add that path to your system PATH using the same steps above, or run adb from the full path.

Linux⚓

sudo apt update && sudo apt install adb fastboot

Warning

The package manager version can lag behind the official release. For the latest version, use the standalone method below.

wget https://dl.google.com/android/repository/platform-tools-latest-linux.zip
unzip platform-tools-latest-linux.zip
sudo mv platform-tools /opt/platform-tools

# Add to PATH — add this to ~/.bashrc or ~/.zshrc
export PATH="$PATH:/opt/platform-tools"

source ~/.bashrc
adb version

macOS⚓

brew install android-platform-tools

curl -O https://dl.google.com/android/repository/platform-tools-latest-darwin.zip
unzip platform-tools-latest-darwin.zip
sudo mv platform-tools /opt/platform-tools
echo 'export PATH="$PATH:/opt/platform-tools"' >> ~/.zshrc
source ~/.zshrc
adb version

USB Drivers (Windows Only)⚓

Windows requires a USB driver to recognise the device over ADB. Without it, adb devices will show nothing or show the device as unknown.

  • Google Pixel: Install the Google USB Driver (available from Android Studio's SDK Manager → SDK Tools → Google USB Driver)
  • Samsung: Install Samsung USB Driver
  • Other manufacturers: Most install with the manufacturer's PC suite, or search for <brand> USB driver — many are on XDA Developers

After installing the driver:

adb kill-server
adb start-server
adb devices

Verify the Installation⚓

adb version
# Android Debug Bridge version 1.0.41
# Version 35.x.x

fastboot version
# fastboot version 35.x.x

If adb isn't found, your PATH isn't set correctly — re-check the steps above and make sure you opened a new terminal after editing PATH.

Connecting a Physical Device via ADB⚓

Enable Developer Options & USB Debugging⚓

  1. Go to Settings → About phone
  2. Tap Build number 7 times until "You are now a developer!" appears
  3. Go to Settings → Developer options
  4. Toggle Developer options on at the top if it isn't already

Below are the options worth knowing about — not all are needed for every test, but it's good to know what's there.

Debugging⚓

Option What it does
USB debugging Allows ADB to connect over USB — required for almost everything
Wireless debugging ADB over Wi-Fi without a cable (Android 11+)
Install via USB Allows APK installs over ADB — keep on
USB debugging (Security settings) On some devices, separately allows changing security settings via ADB
Revoke USB debugging authorizations Clears all trusted computers — useful to reset if something's broken

Layout & UI⚓

Option What it does
Pointer location Overlays a crosshair and touch coordinates on screen — useful when recording or reporting tap targets
Show touches Shows a dot wherever you touch — helpful during screen recordings
Show surface updates Flashes blue when any view on screen redraws — helps spot unnecessary redraws
Show layout bounds Draws borders around every UI element — useful when mapping out exported activity interfaces
Force RTL layout direction Forces right-to-left layout — can reveal alignment bugs

Networking⚓

Option What it does
Mobile data always active Keeps mobile data active even when on Wi-Fi — useful if an app behaves differently on cellular
Default USB configuration When plugging in via USB: set to MTP for file transfer or PTP for photos. For ADB you usually want No data transfer / Charging only and let USB debugging handle ADB
Bluetooth HCI snoop log Logs all Bluetooth HCI packets to a file on device — essential for BLE traffic analysis

BLE / Bluetooth Sniffing

Enable Bluetooth HCI snoop log, exercise whatever BLE functionality you're testing, then pull the log: 

adb pull /sdcard/Android/data/btsnoop_hci.log ./btsnoop.log
# Or on some devices:
adb bugreport > bugreport.zip
# The btsnoop log is inside the zip
Open btsnoop.log in Wireshark with the bthci_h4 dissector. You can inspect GATT reads/writes, advertisement packets, and pairing exchanges.

Other Useful Ones⚓

Option What it does
OEM unlocking Allows the bootloader to be unlocked — must be enabled before rooting with Magisk (see below)
Running services Shows all currently running services and memory usage — useful to see what's active in the background
Feature flags Lets you toggle internal Android feature flags — occasionally useful for bypassing feature-gated functionality

Connect via USB⚓

# Plug in device, then verify it shows
adb devices

# If it shows as "unauthorized" — check the device screen and tap "Allow"
# If nothing shows, try:
adb kill-server
adb start-server
adb devices

Connect over Wi-Fi⚓

Use this when you want to test a physical device without leaving it tethered by USB. It is especially useful with scrcpy, Burp, or when rotating the device a lot during runtime testing.

Android 11+ Wireless Debugging (Pairing)⚓

This is the modern, supported method.

  1. Put the computer and device on the same network
  2. On the device go to Developer options → Wireless debugging
  3. Tap Pair device with pairing code
  4. Note the IP, pairing port, and pairing code shown on screen

On your machine:

# Pair first using the pairing port shown on the device
adb pair 192.168.1.50:37099
# Enter the 6-digit pairing code when prompted

# Then connect to the adb port shown on the device
adb connect 192.168.1.50:43451

# Verify
adb devices

Once connected, the device appears like any other ADB target and you can use adb -s <serial> if needed.

Older TCP/IP Method (USB Needed First)⚓

Older devices and some test setups still use the classic TCP flow:

# While the device is still connected by USB
adb tcpip 5555

# Find the device IP
adb shell ip addr show wlan0

# Disconnect USB, then connect over the network
adb connect 192.168.1.50:5555

# Verify
adb devices

To switch back to normal USB-only debugging, reconnect the cable and run:

adb usb

Warning

Do not leave ADB exposed on open or untrusted networks. Anyone who can reach that port and has previously paired may be able to reconnect.

Working with Multiple Devices⚓

When more than one device or emulator is connected, ADB requires you to specify which one with -s. Without it, you'll get an error: error: more than one device/emulator.

# List all connected devices and emulators with their serial IDs
adb devices -l
# Example output:
# List of devices attached
# emulator-5554          device product:sdk_gphone64_x86_64 ...
# emulator-5556          device product:sdk_gphone64_x86_64 ...
# R5CRA1ZWXYZ            device product:beyond2qltecs       ...  ← physical device

# Target a specific device by serial
adb -s emulator-5554 shell
adb -s emulator-5556 install app.apk
adb -s R5CRA1ZWXYZ logcat

# Shorthand flags (when only one of each type is connected)
adb -e shell        # target the only emulator
adb -d shell        # target the only physical device (USB)

To avoid typing -s every time, set the ANDROID_SERIAL environment variable for your session:

# Linux / macOS
export ANDROID_SERIAL=emulator-5554
adb shell   # now always targets emulator-5554

# Windows (PowerShell)
$env:ANDROID_SERIAL = "emulator-5554"
adb shell

scrcpy — Screen Mirror & Control⚓

scrcpy mirrors your Android device's screen to your computer and lets you control it with your keyboard and mouse — no app installed on the device, no root required. Essential for testing on a physical device without having to look at a separate screen.

Install⚓

# Via Chocolatey
choco install scrcpy

# Or download the release zip from:
# https://github.com/Genymobile/scrcpy/releases
# Extract and run scrcpy.exe directly

sudo apt install scrcpy

For the latest version, build from source or use the prebuilt release:

# Download latest release
wget https://github.com/Genymobile/scrcpy/releases/latest/download/scrcpy-linux-x86_64.tar.gz
tar -xzf scrcpy-linux-x86_64.tar.gz
sudo mv scrcpy /usr/local/bin/

brew install scrcpy

Basic Usage⚓

With your device connected via USB (USB debugging on):

# Mirror screen
scrcpy

# If multiple devices connected, specify one
scrcpy -s emulator-5554
scrcpy -s R5CRA1ZWXYZ

Useful Options⚓

# Limit resolution (faster on slower USB connections)
scrcpy --max-size 1080

# Limit frame rate
scrcpy --max-fps 30

# Reduce bit rate (for slower connections / recording)
scrcpy --video-bit-rate 4M

# Start in fullscreen
scrcpy --fullscreen

# Keep device screen off while mirroring (saves battery)
scrcpy --turn-screen-off

# Stay awake — prevents device from sleeping while connected
scrcpy --stay-awake

# Record the session to a file while mirroring
scrcpy --record session.mp4

# Record only (no window, just record to file)
scrcpy --no-display --record session.mp4

# Mirror over Wi-Fi (device must already be connected via adb over TCP)
scrcpy --tcpip=<device-ip>:5555

Keyboard Shortcuts (while scrcpy window is focused)⚓

Shortcut Action
Ctrl+H Home button
Ctrl+B Back button
Ctrl+M Menu / Recents
Ctrl+P Power toggle
Ctrl+N Expand notifications
Ctrl+Shift+N Collapse notifications
Ctrl+V Paste clipboard from host to device
Ctrl+C Copy device clipboard to host
Ctrl+Z Rotate device
Ctrl+X Resize window to fit
Ctrl+F Toggle fullscreen

Copy Files via Drag & Drop⚓

You can drag and drop files onto the scrcpy window:

  • APK files → automatically installs the APK on the device
  • Any other file → copies it to /sdcard/ on the device

Setting Up an Android Emulator (Android Studio AVD)⚓

Install Android Studio⚓

  1. Download from developer.android.com/studio
  2. Install and open — let it download the Android SDK on first launch

Create a Virtual Device⚓

  1. Open Device Manager (toolbar or View → Tool Windows → Device Manager)
  2. Click Create Device
  3. Pick a hardware profile (e.g. Pixel 6)
  4. Select a system image — use Google APIs (not Google Play) for root access
    • x86_64 images run fastest on Intel/AMD with hardware acceleration (HAXM on Windows, KVM on Linux)
  5. Name it and finish

Start the Emulator with a Writable System Partition⚓

By default the system partition is read-only. For pentesting you want it writable so you can push CA certs and other files.

These commands run on your host machine (Windows PowerShell, macOS/Linux terminal) — not inside the emulator. The emulator binary ships with Android Studio and is located at:

  • Windows: C:\Users\<you>\AppData\Local\Android\Sdk\emulator\emulator.exe
  • macOS / Linux: ~/Android/Sdk/emulator/emulator

Add it to your PATH via the same method as Platform Tools, or run it by full path. Android Studio's terminal already has it on PATH if you open a terminal from within Studio.

# List available AVDs to get the exact name
emulator -list-avds

# Start with writable system partition
emulator -avd <AVD_NAME> -writable-system

Once the emulator has fully booted, in a second terminal run:

# Elevate ADB to root
adb root

# Remount /system as read-write
adb remount

# Confirm
adb shell whoami    # should print: root

Warning

-writable-system only works on Google APIs images. Google Play images are production-signed and cannot be remounted — use Google APIs for pentesting.

Persist Changes Across Reboots⚓

Changes to /system are lost on reboot if snapshots are enabled. Disable them:

emulator -avd <AVD_NAME> -writable-system -no-snapshot-load -no-snapshot-save

Or in the AVD Manager: click the pencil icon → Show Advanced Settings → set Snapshot to Store a new snapshot on exit: No.

In AVD Manager → pencil icon → Show Advanced Settings:

Setting Recommended
RAM 4096 MB
VM Heap 512 MB
Internal Storage 8192 MB
Graphics Automatic
Multi-Core CPU 4

Verify Emulator ADB Connection⚓

adb devices
# Should show: emulator-5554   device

# If multiple emulators, target a specific one
adb -s emulator-5554 shell

Rooting an Android Emulator⚓

Only works on Google APIs images — not Google Play. Rooting an emulator is non-destructive; you can always delete and recreate the AVD.

rootAVD automates the entire process: it patches the emulator's ramdisk with Magisk, installs the Magisk app, and reboots the emulator fully rooted.

Requirements: Git, Java, emulator running, ADB connected.

1. Clone rootAVD⚓

git clone https://github.com/newbit1/rootAVD.git
cd rootAVD

2. Start the emulator normally⚓

emulator -avd <AVD_NAME>

Wait for it to fully boot before continuing.

3. Find the ramdisk path⚓

# Lists all AVD ramdisk paths rootAVD can patch
./rootAVD.sh ListAllAVDs       # macOS / Linux
rootAVD.bat ListAllAVDs        # Windows

Example output:

system-images/android-34/google_apis/x86_64/ramdisk.img

4. Patch and root⚓

# macOS / Linux
./rootAVD.sh system-images/android-34/google_apis/x86_64/ramdisk.img

# Windows
rootAVD.bat system-images/android-34/google_apis/x86_64/ramdisk.img

rootAVD downloads the latest Magisk, patches the ramdisk, pushes it back to the AVD, and reboots the emulator. The Magisk app is installed automatically.

5. Verify⚓

adb shell su -c whoami    # root

Open the Magisk app — it should show the installed version with no warnings.

Tip

On subsequent boots, start the emulator without any special flags — rootAVD's patch is baked into the ramdisk. You do not need -writable-system after rooting with rootAVD.

Method 2 — adb root (No Magisk, Quick)⚓

Google APIs images ship with a debug adbd that can elevate to root without any patching. This gives you a root shell and a writable /system, which is enough for pushing CA certs or reading app data — but you won't have Magisk or Xposed.

# Start with writable system partition
emulator -avd <AVD_NAME> -writable-system

# In a second terminal once fully booted:
adb root          # restart adbd as root
adb remount       # remount /system as read-write
adb shell whoami  # root

Warning

Root access via adb root is lost on reboot unless you keep using -writable-system. For a persistent, Magisk-backed root use rootAVD instead.

Rooting a Physical Device with Magisk⚓

Magisk is the standard approach for systemless root — it doesn't modify the system partition, so it survives OTA updates and can hide itself from apps.

Danger

Rooting requires an unlocked bootloader which wipes all device data. Use a dedicated test device. This also voids warranty.

Step 1 — Unlock the Bootloader⚓

# First enable OEM unlocking: Settings → Developer options → OEM unlocking

# Boot into bootloader
adb reboot bootloader

# Unlock — this wipes the device
fastboot flashing unlock
# On older devices:
fastboot oem unlock

Confirm the unlock prompt on the device screen. It will factory reset.

Step 2 — Get the Stock boot.img⚓

You need the boot.img from the exact firmware matching your device model and current OS build number (visible in Settings → About phone → Build number). Sometimes you might not be able to see this boot.img, so installl an ota extractorExample, and paste the payload.bin in the exe for ota.

Extract the zip — locate boot.img inside (sometimes inside a nested zip like image-*.zip).

Step 3 — Patch boot.img Using the Magisk App⚓

  1. Transfer boot.img to the device:
adb push boot.img /sdcard/
  1. Sideload the Magisk APK (download from github.com/topjohnwu/Magisk/releases):
adb install Magisk-v*.apk
  1. Open the Magisk app → tap Install → Select and Patch a File → pick boot.img from /sdcard/
  2. Magisk patches it and saves to /sdcard/Download/magisk_patched_*.img
  3. Pull the patched image back to your machine:
adb pull /sdcard/Download/magisk_patched_*.img ./magisk_boot.img

Step 4 — Flash the Patched Boot Image⚓

adb reboot bootloader

fastboot flash boot magisk_boot.img

fastboot reboot

Step 5 — Verify Root⚓

adb shell
su
whoami    # should return: root

Open the Magisk app — the Installed field should show the current Magisk version.

Useful Magisk Modules for Pentesting⚓

Install these from Magisk → Modules → Install from storage (download the zip first):

Module Purpose
Shamiko Hides root from apps (successor to MagiskHide)
LSPosed Xposed framework — lets you install Xposed modules for hooking
MagiskTrustUserCerts Copies user CA certs to system store (fixes Android 7+ MITM issue)
Universal SafetyNet Fix Passes SafetyNet / Play Integrity checks

Rooting a Physical Device with KernelSU⚓

KernelSU is a kernel-level root solution for Android. Unlike Magisk, which patches the boot ramdisk and installs a userspace su binary, KernelSU integrates directly into the Linux kernel — giving root at the kernel layer rather than above it.

Danger

Rooting requires an unlocked bootloader which wipes all device data. Use a dedicated test device. This also voids warranty.

How KernelSU Works⚓

Magisk works in userspace: it mounts an overlay at boot, installs su into a path apps can find, and intercepts root requests in a daemon. Every app that calls su goes through Magisk's process.

KernelSU works differently. It patches the kernel itself — either by integrating KernelSU's source into a kernel build, or (on modern devices) by loading a Loadable Kernel Module (LKM) (Loadable Kernel Module — a .ko file that extends the kernel without recompiling it) into the existing GKI (Generic Kernel Image — Google's standardised kernel introduced in Android 12, required for all devices launching with Android 12+; ensures a single kernel binary works across many devices) kernel. Root access is granted at the UID (User Identifier) level inside the kernel itself, so the kernel enforces who is root rather than a userspace daemon.

Magisk flow:
  app calls su → Magisk daemon intercepts → grants/denies → userspace su runs

KernelSU flow:
  app calls su → kernel checks UID whitelist → kernel grants root directly

Why this matters for pentesting: - Apps that detect root by looking for su in PATH or checking for Magisk-specific files have a harder time detecting KernelSU - The kernel UID approach is fundamentally different — most userspace root detection heuristics don't catch it - Useful when testing apps with aggressive root detection that Shamiko/Magisk Hide can't fully handle

Two deployment paths depending on your device:

Path When to use How
LKM (GKI) mode Android 12+ with a GKI 2.0 kernel (most modern devices) Patches a GKI boot.img with a KernelSU LKM — no kernel recompilation needed
Non-GKI mode Older devices or custom ROMs Requires building a kernel from source with KernelSU integrated

For pentesting, the LKM path is what you'll use on modern test devices — it's as straightforward as Magisk.

Step 1 — Check GKI Compatibility⚓

adb shell uname -r
# Example output: 5.15.123-android13-8-something
# Kernel version 5.10+ with android12/13/14 in the string = GKI compatible

Also check the Android version:

adb shell getprop ro.build.version.release   # e.g. 13
adb shell getprop ro.board.platform           # SoC platform

If the kernel is 5.10 or later and launched with Android 12+, you're on GKI and can use the LKM method.

Step 2 — Unlock the Bootloader⚓

Same as Magisk — you only need to do this once per device.

# Enable OEM unlocking first: Settings → Developer options → OEM unlocking

adb reboot bootloader

fastboot flashing unlock
# On older devices:
fastboot oem unlock

Confirm the prompt on device screen. This wipes all data.

Step 3 — Install the KernelSU Manager App⚓

Download the KernelSU Manager APK from the official GitHub releases (search: KernelSU github releases). Install it:

adb install KernelSU-v*.apk

Open the app — it will show "Not installed" since KernelSU isn't in the kernel yet. That's expected at this point.

Step 4 — Get the Stock boot.img⚓

Grab the boot.img matching your exact device model and build number (same sources as Magisk):

  • Pixel: Google's firmware images page
  • Samsung: samfw.com or Samsung's firmware servers
  • Others: Manufacturer site or XDA Developers

If the factory image only ships payload.bin, extract with an OTA payload extractor tool to get boot.img.

Step 5 — Patch boot.img⚓

  1. Push boot.img to the device:
adb push boot.img /sdcard/
  1. Open KernelSU Manager → Install → Select and Patch a File → pick boot.img
  2. The app patches the image with the KernelSU LKM and saves to /sdcard/Download/kernelsu_patched_*.img
  3. Pull it back:
adb pull /sdcard/Download/kernelsu_patched_*.img ./kernelsu_boot.img

Option B — Using ksud on the Command Line⚓

# Install ksud (ships in the KernelSU release zip alongside the APK)
# On your host machine:
./ksud boot-patch -b boot.img -o kernelsu_boot.img

Step 6 — Flash the Patched Boot Image⚓

adb reboot bootloader

fastboot flash boot kernelsu_boot.img

fastboot reboot

Step 7 — Verify⚓

adb shell su -c whoami    # root

Open KernelSU Manager — it should now show "Installed" with the kernel version and KernelSU version.

KernelSU vs Magisk — When to Use Which⚓

KernelSU Magisk
Root mechanism Kernel-level UID control Userspace su daemon
Detection difficulty Harder to detect (no su in PATH by default) Easier to detect without Shamiko
Module support Yes (own module system + WebUI) Yes (larger ecosystem)
GKI requirement Yes for LKM method (Android 12+) No — works on older devices
Emulator support No — requires real GKI kernel Yes (via rootAVD)
Zygisk support Via ZygiskNext module Built-in

Rule of thumb: Use Magisk first — bigger module ecosystem, works on emulators, most apps don't detect it properly even without Shamiko. Switch to KernelSU when an app's root detection specifically targets Magisk patterns and Shamiko isn't enough.

Useful KernelSU Modules for Pentesting⚓

Install via KernelSU Manager → Modules → Install from storage:

Module Purpose
ZygiskNext Adds Zygisk support to KernelSU — required for Zygisk-based modules
Shamiko Hides root from apps (requires ZygiskNext)
LSPosed Xposed framework for hooking (requires ZygiskNext)
MagiskTrustUserCerts Copies user CA certs to system store (fixes Android 7+ MITM issue)

Uninstalling KernelSU⚓

KernelSU doesn't have a one-tap uninstall like Magisk. To remove it, flash the original stock boot.img via fastboot:

adb reboot bootloader
fastboot flash boot boot.img    # the unpatched original
fastboot reboot

After reboot, KernelSU Manager shows "Not installed" and su no longer works.

Unrooting a Physical Device⚓

When you're done testing, you may want to restore the device to a stock, unrooted state — especially before returning a device or re-enabling banking/work apps.

This is the cleanest method. Magisk restores the original stock boot image automatically.

  1. Open the Magisk app
  2. Tap the gear icon (Settings) → scroll down to Uninstall Magisk
  3. Tap Complete Uninstall

Magisk will restore the original boot.img, remove itself, and reboot the device. No fastboot required.

Method 2 — Flash the Original boot.img via Fastboot⚓

Use this if the Magisk app is missing or broken.

  1. Grab the stock boot.img for your exact firmware build (same source as when you rooted — Google firmware images, samfw.com, etc.)
  2. Boot into the bootloader and flash it:
adb reboot bootloader

fastboot flash boot boot.img

fastboot reboot

After reboot, Magisk will show as Not Installed and su will no longer work.

Method 3 — Re-lock the Bootloader (Full Stock Restore)⚓

Danger

Re-locking wipes all data on the device. Only do this for a complete stock restore.

  1. Flash a full factory image for your build (all partitions, not just boot):
# Pixel example — use the flash-all script from the factory image zip
adb reboot bootloader
./flash-all.sh    # or flash-all.bat on Windows
  1. Once fully stock, re-lock the bootloader:
fastboot flashing lock
# On older devices:
fastboot oem lock

Confirm the lock on the device screen. The device will factory reset again and boot with verified boot re-enabled.

Verify Unroot⚓

adb shell su
# Should output: su: not found  (or permission denied)

Connecting to an Emulator Running in Another VM⚓

A common setup is running the Android emulator inside a Linux VM (e.g. VirtualBox/VMware on a Windows host, or a remote Kali box) and ADB-ing into it from your host.

The emulator binds ADB to 127.0.0.1:5555 inside the VM — you need to expose that externally.

Option 1 — ADB Over TCP (Simple, Same LAN)⚓

Inside the VM (where the emulator is running):

# Redirect ADB to listen on all interfaces
adb tcpip 5555

# Find the VM's IP visible from your host
ip a    # look for the bridged/host-only adapter IP, e.g. 192.168.56.101

Make sure the VM firewall allows it:

sudo ufw allow 5555/tcp

On your host machine:

adb connect 192.168.56.101:5555
adb devices

More reliable, works over NAT, encrypted:

# On your host — forward local 5555 to the emulator's ADB port inside the VM
ssh -L 5555:127.0.0.1:5555 user@<vm-ip>

# In another terminal on the host:
adb connect 127.0.0.1:5555
adb devices

Keep the SSH tunnel open for the session. If you close it, ADB loses the connection.

Useful ADB Commands⚓

# Open a shell on the device
adb shell

# Install an APK
adb install app.apk
adb install -r app.apk          # reinstall, keep existing data
adb install -t app.apk          # allow test APKs

# Pull / push files
adb pull /sdcard/file.txt ./
adb push localfile.txt /sdcard/

# Pull the APK for an installed app
adb shell pm path com.example.app
# Output: package:/data/app/~~xxxx/com.example.app-xxx/base.apk
adb pull /data/app/~~xxxx/com.example.app-xxx/base.apk ./app.apk

# Logcat (live device logs)
adb logcat
adb logcat -s TAG                        # filter by tag
adb logcat | grep -i "error\|exception"
adb logcat -c                            # clear log buffer

# Forward a host port to the device (e.g. route traffic through Burp)
adb forward tcp:8080 tcp:8080
adb forward --list                       # show active forwards
adb forward --remove tcp:8080

# Reboot
adb reboot
adb reboot recovery
adb reboot bootloader

# Screenshot & screen record
adb shell screencap /sdcard/screen.png && adb pull /sdcard/screen.png
adb shell screenrecord /sdcard/demo.mp4  # Ctrl+C to stop, then pull

# List installed packages
adb shell pm list packages               # all
adb shell pm list packages -3            # third-party only
adb shell pm list packages | grep -i <keyword>

# Dump detailed app info (permissions, activities, version, etc.)
adb shell dumpsys package com.example.app

# Clear app data (equivalent to "Clear storage" in Settings)
adb shell pm clear com.example.app

# Grant / revoke a runtime permission
adb shell pm grant com.example.app android.permission.READ_CONTACTS
adb shell pm revoke com.example.app android.permission.READ_CONTACTS

# Get device properties
adb shell getprop ro.product.model
adb shell getprop ro.build.version.release
adb shell getprop | grep -i security