Ghost Framework Android Tutorial: ADB Testing with Kali Linux

Ghost Framework does not automatically compromise an Android phone. It is a post-exploitation framework, meaning the Android device must already be accessible through ADB before Ghost can interact with it. Ghost connects through Android Debug Bridge (ADB), Google's command-line interface for communicating with Android devices, and provides an interactive console with commands for inspecting and interacting with the connected device.

This tutorial shows how to install and use Ghost Framework 8.0.0 on Kali Linux, connect it to an authorized Genymotion Android 10 emulator, and compare Ghost commands with direct ADB commands.

Quick Answer

Ghost Framework is an Android post-exploitation tool that interacts with Android devices through Android Debug Bridge (ADB). It does not automatically hack an Android phone or enable ADB by itself. To use Ghost, ADB must already be enabled and reachable on the Android device, and Ghost must be able to authenticate to it.

What Ghost Framework Actually Does

Ghost provides an interactive console for working with Android devices connected through ADB. Instead of repeatedly typing raw ADB commands, you can connect a device and run Ghost commands from the (ghost)> prompt. This tutorial uses Ghost Framework 8.0.0 from EntySec.

Ghost uses an accessible ADB service to communicate with the Android device. It does not discover or exploit a new Android vulnerability simply by starting the framework.

Ghost uses the ADB connection to:

• Connect to an Android device by IP address and port
• Keep track of connected devices as separate sessions
• Open an interactive prompt for a selected device
• Run commands and helper modules through that ADB connection

Internally, Ghost uses the Python adb-shell library, so its connection is separate from Kali's normal adb command-line client.

Modules present in Ghost 8.0.0 include:

Ghost can connect only when the Android device's ADB service is reachable and allows the connection.

Ghost Framework Prerequisites

Install the packages this tutorial expects on Kali:

sudo apt install python3 python3-venv python3-pip adb git

You need:

• Python 3
• python3-venv for creating an isolated Python environment
• pip for installing Ghost
• git for installing Ghost from GitHub
• adb for testing the Android connection independently

Kali must be able to reach the Genymotion IP address and ADB port.

Ghost uses its own Python ADB connection. The normal adb command is still useful because it lets you confirm that Kali can reach the emulator before troubleshooting Ghost itself.

The Android test device must also have ADB enabled and reachable from Kali. This tutorial uses Genymotion Android 10 (API 29) at 192.168.56.104:5555. Here, 192.168.56.104 is the emulator's IP address and 5555 is the TCP port used by Android's ADB service (adbd).

This Genymotion device provides a root ADB shell, so the commands have more privileges than ADB normally has on a production phone. Some Ghost commands may therefore behave differently on a physical device.

Confirm Python and ADB on Kali:

python3 --version

Python 3.14.6

Ghost requires Python 3.7 or later, so Python 3.14.6 is suitable. Check the ADB client next:

adb version

Android Debug Bridge version 1.0.41
Version 34.0.5-debian

Kali + Genymotion Lab Architecture

Kali and Genymotion only need to communicate with each other for this lab, so place them on a host-only network.

┌──────────────────────┐                ┌────────────────────────┐
│ Kali Linux           │                │ Genymotion Android 10  │
│ ├─ Ghost 8.0.0       │──── ADB TCP ──►│ adbd :5555             │
│ └─ adb client        │                │ API 29 / x86           │
└──────────────────────┘                └────────────────────────┘

A host-only network lets Kali communicate directly with the emulator while keeping this ADB lab separate from the external network. Test the connection with the normal adb client first. If direct ADB cannot reach the emulator, Ghost will not be able to connect either.

Use a Genymotion test device that does not contain important data, and take a snapshot before starting. Note its IP address. If Genymotion is not configured yet, complete the Genymotion Android pentest lab guide first.

You do not need a second physical phone for this tutorial. Android Studio AVD can also be used for ADB testing, but the commands below were tested with Genymotion's root ADB setup.

Verify ADB Connectivity First

Save the emulator's address in a shell variable so the later commands are easier to read. Replace the address if your Genymotion device uses a different IP:

export TARGET=192.168.56.104:5555

TARGET exists only in the current terminal, so export it again if you open a new shell.

Connect to the emulator with ADB:

adb connect "$TARGET"

connected to 192.168.56.104:5555

List attached devices and confirm the state is device, not offline or unauthorized:

adb devices -l

List of devices attached
192.168.56.104:5555    device product:vbox86p model:Phone device:vbox86p transport_id:6

In the output, device means the emulator is connected and ready for ADB commands. offline or unauthorized means the connection is not ready yet.

Check the Android version, API level, Genymotion version, and which user ADB is running as:

adb -s "$TARGET" shell '
echo "Android: $(getprop ro.build.version.release)"
echo "API: $(getprop ro.build.version.sdk)"
echo "Genymotion: $(getprop ro.genymotion.version)"
echo "ADB user: $(whoami)"
'

Android: 10
API: 29
Genymotion: 3.1.0
ADB user: root

root means commands sent through ADB have root privileges inside this emulator.

If the emulator is not reachable over ADB at all, fix the network or ADB configuration before continuing with Ghost.

Install the Current Ghost Framework

Ghost is not available through Kali's apt repositories, so install it from the EntySec GitHub repository with Python pip. Create a working directory and a virtual environment so Ghost and its Python dependencies stay separate from Kali's system Python installation:

mkdir -p ~/ghost-lab && cd ~/ghost-lab

Create the virtual environment:

python3 -m venv .venv

Activate the virtual environment in the same shell before you install packages:

source .venv/bin/activate

The shell prompt usually gains a (.venv) prefix. With the virtual environment active, install Ghost from its GitHub repository:

python -m pip install 'git+https://github.com/EntySec/Ghost'

When the install finishes, confirm the installed Ghost version:

python -m pip show ghost

Name: ghost
Version: 8.0.0

With the virtual environment still active, start Ghost. You should see the Ghost 8.0.0 banner and a (ghost)> prompt:

ghost

   .--. .-.               .-.
  : .--': :              .' `.
  : : _ : `-.  .--.  .--.`. .'
  : :; :: .. :' .; :`._-.': :
  `.__.':_;:_;`.__.'`.__.':_;

--=[ Ghost Framework 8.0.0
--=[ Developed by EntySec (https://entysec.com/)

(ghost)>

Keep the virtual environment activated whenever you run ghost.

Connect Ghost to the Android Device

From the (ghost)> prompt, connect to the Genymotion device:

(ghost)> connect 192.168.56.104:5555
[*] Connecting to 192.168.56.104...
[+] Connected to 192.168.56.104!

[i] Type devices to list all connected devices.
[i] Type interact 0 to interact this device.

Ghost creates a separate ADB connection with adb-shell; it does not reuse the connection created earlier by Kali's adb command. Because of this, a physical Android device may show another Allow USB debugging? prompt when Ghost connects.

Accept that prompt only on an authorized test device. In this Genymotion setup, Ghost connected directly to the available ADB service.

List the Android devices currently connected to Ghost:

(ghost)> devices

Connected Devices
=================

  ID    Host              Port
  ~~    ~~~~              ~~~~
  0     192.168.56.104    5555

devices lists Ghost's own active sessions. The first session receives ID 0, so interact 0 opens that device's command prompt:

(ghost)> interact 0
[*] Interacting with device 0...
[+] Interactive connection spawned!
[*] Loading device modules...
[i] Modules loaded: 13
(ghost: 192.168.56.104)>

The prompt changes to (ghost: 192.168.56.104)>, showing that commands will now run against that connected device. You can now run Ghost commands for that connected Android device.

Inside the device prompt, help lists the available command categories:

(ghost: 192.168.56.104)> help

Manage Commands:
    download
    keyboard
    list
    network
    screenshot
    shell
    upload
    ...

Settings Commands:
    activity
    battery
    wifi

help groups Ghost's modules by category. The examples below use battery, shell, and list.

Enumerate the Test Device

Begin with commands that only read device information. Start with battery, which displays the device's current battery state:

(ghost: 192.168.56.104)> battery
[*] Getting battery information...
Current Battery Service state:
  AC powered: true
  present: true
  level: 99
  scale: 100

The shell command lets you run a normal Android shell command from inside Ghost:

(ghost: 192.168.56.104)> shell getprop ro.build.version.release
10

(ghost: 192.168.56.104)> shell pwd
/

/ is the Android filesystem root directory. This does not by itself prove that the shell has root privileges; the earlier whoami check established that separately.

/sdcard is Android's shared-storage area, where common folders such as Download, DCIM, and Pictures appear. List it with the list module:

(ghost: 192.168.56.104)> list /sdcard

Ghost should return familiar shared-storage directories such as Download, DCIM, Pictures, and Music.

When you are done with the device prompt, exit back to (ghost)>, then exit again to leave the framework.

Compare Ghost Commands with Direct ADB

Ghost gives you an interactive interface for commands that could otherwise be run through ADB. It does not provide a separate privilege level. Many Ghost modules ultimately retrieve information that Android already exposes through ADB once $TARGET is connected.

Compare the battery view with ADB:

adb -s "$TARGET" shell dumpsys battery

The level, present, and power-source values match what Ghost's battery module displayed. Ghost is convenient for interactive exploration, while direct ADB is usually easier to script and automate.

When a Ghost module fails, try the comparable direct ADB command. If both commands fail, check Android permissions and the target path. If ADB works but Ghost does not, investigate Ghost or its adb-shell connection.

Modern Android Limitations

Because Ghost communicates through ADB, Android's normal ADB restrictions still apply:

• ADB access must already be enabled—for example through USB debugging or Android's Wireless debugging feature
• The connecting computer normally must be authorized through Android's RSA debugging prompt
• Ghost only gets the permissions of the ADB connection. On a production phone, Android's app sandbox and SELinux can still block access to protected app data
• Commands that require root access will fail when adbd gives you Android's non-root shell user instead of root

ADB access also does not automatically bypass a modern lock-screen PIN; the Android lock-screen ADB guide explains those limits.

The keyboard module sends text to the active interface using Android's input text command; it does not record the user's keystrokes. Screenshot and file-transfer capabilities are also limited by the privileges of the ADB connection. Root ADB on Genymotion can access more of the filesystem than the non-root ADB shell normally available on production phones.

Android 11 and later support Wireless debugging with device pairing. When that method is used, the computer must be paired with the phone before ADB can connect. Emulator ADB setups are often simpler than this, so a Ghost connection that works in Genymotion may require additional setup on a physical phone.

Why Exposed ADB Port 5555 Is Dangerous

TCP ADB commonly uses port 5555. The port itself is not the vulnerability; the risk appears when an ADB service is reachable by systems that should not be allowed to use it.

Depending on the permissions of the ADB connection, unauthorized access could allow someone to:

• Run shell commands and read accessible files
• Install or remove APKs
• Download accessible files
• Send input events or take screenshots

Ghost is simply one interface for interacting with that service.

To prevent unintended ADB access:

• Keep USB debugging disabled when it is not needed, and do not enable network ADB on untrusted networks
• Remove old debugging authorizations for computers you no longer use
• Do not leave adb tcpip 5555 enabled after testing

When the lab is finished, stop or restore the Genymotion guest so its ADB service is no longer left running.

Summary

Ghost Framework 8.0.0 provides an interactive console for an Android device that is already reachable through ADB. Commands such as battery, shell, and list make common ADB tasks easier to run from one interface.

Ghost does not enable ADB or give you extra privileges. It can only use the access and permissions already available through its ADB connection.

References

• EntySec/Ghost - upstream Ghost Framework repository and install instructions
• Android Debug Bridge (adb) - official ADB documentation
• Genymotion - Android emulator used for the lab guest